En la mayoría de incidentes con datos PII, la filtración no se origina en los sistemas de producción. Se produce en entornos de staging sin auditar, en ficheros CSV copiados a equipos locales o en logs de APIs que registran payloads completos en buckets de almacenamiento sin cifrado.
Los datos personales identificables (PII, por sus siglas en inglés: Personally Identifiable Information) aparecen en el 53% de todas las brechas de seguridad registradas a nivel global, según el informe Cost of a Data Breach 2025 de IBM. Cada registro comprometido de PII de clientes cuesta una media de 160 dólares. El de empleados, 168 dólares. En una organización que gestiona decenas de miles de registros, el impacto económico de una filtración se escala rápidamente.
A continuación, analizamos qué es PII, cómo se clasifica, dónde suele quedar expuesto en entornos empresariales y qué técnicas de protección aplicar.
Qué es PII exactamente
PII (Personally Identifiable Information) es cualquier dato que, por sí solo o combinado con otros, permite identificar a una persona física concreta. Tiene definición regulatoria en el NIST SP 800-122 de Estados Unidos y, en Europa, se alinea con lo que el artículo 4 del RGPD llama "datos personales".
La diferencia clave es esta: PII es un término que nace del ámbito anglosajón y se centra en la capacidad de identificar a alguien. El RGPD va un paso más allá e incluye cualquier dato que pueda relacionarse con una persona identificada o identificable, incluso de forma indirecta. En la práctica, para una empresa que opera en España o en la UE, todo PII es dato personal bajo el RGPD, pero no todo dato personal encaja en la definición estricta de PII de NIST.
Esta distinción tiene implicaciones prácticas. Muchos equipos de seguridad aplican medidas de protección centradas en los identificadores más evidentes — DNI, email, nombre — sin considerar que una dirección IP, un identificador de dispositivo o un patrón de geolocalización también pueden constituir PII cuando se combinan con otros datos.
Tipos de PII: identificadores directos e indirectos
No todos los datos PII tienen el mismo nivel de riesgo. La clasificación más operativa los divide en dos categorías según su capacidad de identificación.
PII directo (identificadores explícitos)
Son datos que, por sí solos, identifican a una persona sin ambigüedad. Cada uno de estos datos permite, por sí solo, identificar a una persona sin ambigüedad:
- Nombre completo
- DNI, NIE o número de pasaporte
- Número de la Seguridad Social
- Dirección de correo electrónico personal
- Número de teléfono
- Número de cuenta bancaria (IBAN)
- Datos biométricos: huella dactilar, reconocimiento facial, iris
- Fotografía del rostro
- Número de historia clínica
PII indirecto (cuasi-identificadores)
De forma aislada, ninguno de estos datos permite identificar a una persona. Sin embargo, combinados entre sí o cruzados con fuentes externas, la identificación es posible. Es un tipo de riesgo que muchas organizaciones subestiman:
- Fecha de nacimiento
- Código postal
- Género
- Puesto de trabajo + nombre de empresa
- Dirección IP
- Identificadores de cookies o dispositivos
- Datos de geolocalización
- Historial de compras o navegación
Un estudio clásico de Latanya Sweeney en Harvard demostró que el 87% de la población de Estados Unidos podía identificarse combinando solo tres cuasi-identificadores: código postal, fecha de nacimiento y género. Son tres campos que la mayoría de empresas no clasifica como sensibles en sus políticas de protección de datos.
Dónde se esconde PII en tu infraestructura
El problema principal con PII no suele ser la falta de protección en los sistemas conocidos, sino el desconocimiento de todos los lugares donde se almacena.
Estos son los puntos donde los equipos de seguridad detectan PII expuesto con mayor frecuencia:
Bases de datos de producción clonadas a entornos inferiores. Es el caso más habitual. Alguien clona producción a staging o desarrollo para depurar un bug, y los datos reales de clientes quedan ahí, sin masking, accesibles para todo el equipo de ingeniería. El enmascaramiento de datos en entornos no productivos debería ser el paso obligatorio antes de cualquier copia.
Logs de aplicación y sistemas de monitorización. Las APIs que registran request/response completos suelen volcar nombres, emails, tokens y direcciones en texto plano. Si tus logs van a un Elasticsearch, Splunk o CloudWatch sin filtrado, tienes PII expuesto en un sistema que probablemente no está en el scope de tu auditoría RGPD.
Ficheros planos en almacenamiento cloud. CSVs, exports de Excel, dumps de base de datos. Muchos terminan en buckets de S3, Google Cloud Storage o Azure Blob con permisos excesivos. Informes puntuales y exports para análisis que permanecen almacenados con datos reales de personas durante meses o años sin supervisión.
Herramientas de BI y analítica. Dashboards de Metabase, Tableau o Looker que consultan directamente producción sin una capa de anonimización intermedia. Los analistas ven datos PII en claro cada vez que abren un informe.
Backups y snapshots. Un backup cifrado en reposo sigue conteniendo PII. Si alguien restaura ese backup en un entorno no controlado, los datos quedan al descubierto. La protección debe aplicarse antes del backup, no después.
El primer paso para proteger PII es identificar dónde se almacena. Las herramientas de clasificación de datos automatizan este descubrimiento, escaneando bases de datos, ficheros y almacenamiento cloud para localizar campos con PII de forma preventiva.
Por qué PII expuesto cuesta tanto
Las cifras del informe IBM Cost of a Data Breach 2025 son elocuentes:
- El coste medio global de una brecha de datos fue de 4,44 millones de dólares.
- En Estados Unidos, la cifra sube a 10,22 millones de dólares por incidente.
- El PII de clientes es el tipo de dato más frecuentemente comprometido, presente en el 53% de las brechas.
- El 20% de las brechas estudiadas estaban relacionadas con shadow AI — herramientas de IA adoptadas por empleados sin supervisión del equipo de seguridad — y añadían hasta 670.000 dólares extra al coste del incidente.
Al coste directo del incidente se suman las sanciones regulatorias. Bajo el RGPD, una brecha con PII puede suponer multas de hasta 20 millones de euros o el 4% de la facturación global. En España, la AEPD ha impuesto sanciones relevantes en los últimos años: 6,4 millones a CaixaBank y 8,15 millones a Vodafone, entre otras.
A eso hay que sumar el daño reputacional. Un cliente cuyo PII se filtra difícilmente renueva. Es el coste más difícil de cuantificar, pero el que más impacto tiene a largo plazo.
Cómo proteger PII: técnicas y enfoques
La protección de PII requiere combinar varias técnicas, y la elección entre ellas depende del uso que se dará a los datos y del nivel de riesgo aceptable.
Descubrimiento y clasificación automática
El descubrimiento automático escanea bases de datos, ficheros, cloud storage y logs para identificar dónde hay PII y de qué tipo: DNIs, emails, IBANs, números de teléfono, etc. Las herramientas de clasificación de datos utilizan motores de reconocimiento de patrones (regex, NLP, fingerprinting) para detectar estos identificadores de forma sistemática.
La alternativa — depender de que los equipos documenten manualmente qué tablas contienen PII — rara vez funciona a escala.
Enmascaramiento de datos (data masking)
El enmascaramiento de datos reemplaza los valores reales de PII por valores ficticios pero estructuralmente consistentes. Un nombre real se convierte en otro nombre creíble. Un IBAN real se transforma en un IBAN con formato válido pero que no pertenece a ninguna cuenta.
Hay dos variantes principales:
- Static Data Masking (SDM): se aplica sobre una copia de los datos. El destino (staging, QA, analytics) recibe datos ya enmascarados. Los datos originales en producción no se tocan.
- Dynamic Data Masking (DDM): se aplica en tiempo real según el perfil del usuario que consulta. Un DBA ve los datos completos; un analista ve los campos PII enmascarados.
Para entornos de desarrollo y testing, el masking estático es la opción estándar. Gigantics aplica enmascaramiento con integridad referencial, lo que garantiza que las relaciones entre tablas se mantienen intactas después del masking. Sin esta capacidad, los datos enmascarados pueden romper queries con JOINs e invalidar los procesos de QA.
Anonimización
La anonimización de datos es irreversible. No hay clave ni mapeo que permita volver al dato original. Esa irreversibilidad tiene una ventaja regulatoria importante: bajo el RGPD, los datos correctamente anonimizados dejan de considerarse datos personales. Esto reduce considerablemente las obligaciones de compliance y el nivel de riesgo asociado.
Técnicas habituales de anonimización incluyen generalización (convertir una edad exacta en un rango), supresión (eliminar el campo directamente), perturbación (añadir ruido estadístico) y k-anonimidad (garantizar que cada registro es indistinguible de al menos k-1 registros más).
Pseudonimización
La pseudonimización sustituye los identificadores directos por tokens o alias. A diferencia de la anonimización, el proceso es reversible si se tiene acceso a la tabla de mapeo. El RGPD la reconoce como una medida de seguridad válida (artículo 32), pero los datos pseudonimizados siguen siendo datos personales a efectos legales.
Es útil cuando necesitas poder re-identificar a las personas en ciertos escenarios (por ejemplo, para responder a una solicitud de acceso del interesado) pero quieres minimizar el riesgo en el uso diario.
Controles de acceso y mínimo privilegio
Ninguna técnica de protección de datos sustituye a un control de accesos bien definido. El principio de mínimo privilegio implica que cada persona y cada sistema accede únicamente al PII necesario para su función. Combinado con masking o pseudonimización, permite establecer una defensa en profundidad.
PII y el RGPD en España: lo que tu equipo legal necesita saber
En España, el RGPD se complementa con la LOPDGDD. La protección de PII es una obligación legal con consecuencias concretas. Estos son los puntos clave que tu equipo de compliance debe tener presentes:
El artículo 5 del RGPD establece el principio de minimización de datos: solo puedes recoger y almacenar los datos personales estrictamente necesarios para la finalidad declarada. Si tu base de datos de clientes tiene 120 campos y solo necesitas 15, esos 105 campos extra son una superficie de ataque innecesaria.
El artículo 32 exige medidas técnicas y organizativas apropiadas para garantizar la seguridad del tratamiento. La pseudonimización y el cifrado se mencionan explícitamente como ejemplos. El enmascaramiento de datos como medida del artículo 32 es una implementación directa de este requisito.
El artículo 33 obliga a notificar una brecha a la AEPD en un plazo máximo de 72 horas. Si los datos afectados estaban anonimizados o enmascarados, el impacto regulatorio del incidente se reduce de forma considerable, ya que la exposición real de información personal es mínima o inexistente.
Checklist: protección de PII en tu organización
Para evaluar el estado de protección de PII en tu organización, estos son los puntos de control más relevantes:
- ¿Tienes un inventario actualizado de dónde se almacena PII en tu infraestructura?
- ¿Los entornos de desarrollo, testing y staging usan datos enmascarados o utilizan copias directas de producción?
- ¿Los logs de aplicación filtran campos PII antes de persistirlos?
- ¿Los exports y ficheros planos en cloud storage tienen políticas de retención y cifrado?
- ¿Los dashboards de BI consultan datos anonimizados o producción en claro?
- ¿Tu equipo tiene un proceso definido para responder solicitudes de acceso o supresión de datos personales (derechos ARCO)?
- ¿Las herramientas de IA que usan tus empleados (shadow AI) están inventariadas y controladas?
Si la respuesta es "no" en más de dos puntos, la superficie de exposición es significativa y conviene actuar antes de que se materialice un incidente.