¿Qué es la PII?
Privacidad, seguridad e identidad
PII significa información de identificación personal (personally identifiable information). Es un término ampliamente utilizado en seguridad, entornos cloud y textos de privacidad de orientación estadounidense para describir información que puede identificar, distinguir o vincularse a una persona. En el ámbito de la protección de datos del Reino Unido y la UE, el término jurídico más relevante suele ser datos personales. Para los flujos de trabajo de IA, lo importante en la práctica es identificar la información que se relaciona con una persona identificable antes de copiarla en herramientas, prompts, registros, conjuntos de datos o resultados.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
PII significa información de identificación personal. El término es habitual en políticas de seguridad, contratos cloud, documentación técnica y materiales de privacidad de orientación estadounidense. Las definiciones de NIST describen la PII como información que puede distinguir o rastrear la identidad de una persona, ya sea por sí sola o combinada con otra información vinculada o vinculable.
La práctica de protección de datos en el Reino Unido y la UE suele centrarse en los "datos personales", no en la PII. La ICO explica los datos personales como información que se relaciona con una persona identificada o identificable. Esto incluye identificadores evidentes, como el nombre y la dirección de correo electrónico, y otros menos obvios, como números de identificación, datos de localización, direcciones IP, identificadores de cookies y combinaciones de información que pueden identificar a alguien de forma indirecta.
Para el trabajo de IA al estilo Levellers, el enfoque práctico más seguro es tratar la PII como una abreviatura útil en materia de seguridad, pero utilizar datos personales para el análisis del UK GDPR. La pregunta no es solo "¿identifica este campo a alguien por sí solo?", sino también "¿podría esta información relacionarse con una persona identificable en este flujo de trabajo, con este contexto y estos registros vinculados?"
Por qué es importante
La IA hace que la precisión terminológica sea más importante, porque la información se mueve con rapidez entre documentos, prompts, bases de datos, índices de recuperación y resultados. Un nombre en una hoja de cálculo es fácil de detectar. Una referencia de cliente incrustada en una transcripción, un resumen de soporte, un rastro de ubicación, un identificador de dispositivo o una nota de texto libre puede ser menos evidente.
Si el personal cree que la PII solo abarca identificadores directos como pasaportes o números de cuenta bancaria, puede pegar datos personales en herramientas sin reconocerlos como tales. Si los responsables tratan cada dato como igualmente sensible, pueden bloquear flujos de trabajo útiles y de bajo riesgo. El objetivo es clasificar los datos con suficiente claridad para aplicar controles proporcionados.
Una buena clasificación ayuda con la minimización de datos, las DSAR, el ROPA, la revisión de proveedores y el diseño de seguridad. También ayuda a los equipos a entender cuándo la anonimización es real y cuándo los datos solo están seudonimizados o enmascarados.
Cómo funciona
Un modelo de clasificación práctico debe separar los identificadores directos, los identificadores indirectos, el contexto sensible y los registros vinculados. Los identificadores directos incluyen nombres, direcciones de correo electrónico, números de teléfono, identificadores nacionales, números de cuenta y registros biométricos. Los identificadores indirectos incluyen combinaciones como cargo más empleador más ubicación, o datos de eventos que pueden vincularse a una persona concreta.
La guía de la ICO sobre datos personales hace hincapié en el contexto. La misma información puede ser datos personales para un responsable del tratamiento y no para otro, dependiendo de si se relaciona con una persona identificable y de qué otra información está razonablemente disponible. Los datos seudonimizados siguen siendo datos personales si pueden atribuirse a una persona mediante información adicional. Los datos verdaderamente anónimos quedan fuera del UK GDPR, pero la anonimización debe ser real.
En los flujos de trabajo de IA, la clasificación debe realizarse antes de que se utilicen los datos. Los equipos deben preguntarse qué datos personales son necesarios, si pueden eliminarse, generalizarse, enmascararse, mantenerse en local o sustituirse por ejemplos sintéticos, y si el proveedor de IA conservará o utilizará los datos para otros fines.
Un buen proceso de clasificación de datos para IA también debe considerar dónde aparecen los datos tras el uso inicial. Los datos personales pueden trasladarse al historial de prompts, al contexto en caché, a bases de datos vectoriales, exportaciones, registros de auditoría, capturas de pantalla y borradores generados. Un campo puede eliminarse del prompt y seguir estando presente en el documento fuente o en el índice de recuperación. Por ello, los equipos deben clasificar el flujo de trabajo completo, no solo el cuadro de texto que ve el usuario.
Ejemplos
Un ticket de soporte contiene el nombre del cliente, su dirección, el detalle de la reclamación y el número de pedido. El nombre y la dirección son identificadores evidentes, pero el texto de la reclamación también puede ser un dato personal porque se relaciona con el cliente. Si el ticket es resumido por IA, el resumen también puede contener datos personales.
Un equipo de operaciones de ventas exporta notas del CRM para la puntuación de leads. Los nombres, correos electrónicos y números de teléfono individuales son identificadores directos. Los cargos, nombres de empresas, territorios, historial de interacciones y etiquetas de puntuación también pueden relacionarse con contactos identificables en contexto.
Un equipo de producto utiliza transcripciones de llamadas para identificar problemas frecuentes. Si las transcripciones incluyen nombres, voces, datos de cuenta o circunstancias únicas, deben tratarse como datos personales a menos que estén debidamente anonimizadas. Enmascarar solo los nombres puede no ser suficiente si el relato restante identifica a la persona.
Un asistente de búsqueda interno indexa documentos de política y guías de RRHH. Los documentos pueden parecer genéricos, pero los ejemplos incrustados, los registros disciplinarios, los partes de baja o las aprobaciones nominativas pueden generar exposición de datos personales dentro del sistema de recuperación.
Malentendidos frecuentes
PII y datos personales son términos idénticos. Se solapan, pero no siempre se utilizan de la misma manera. El análisis del UK GDPR debe emplear normalmente el término datos personales.
Solo cuentan los nombres y las direcciones de correo electrónico. Los identificadores indirectos, los identificadores en línea, los datos de localización y los registros vinculados también pueden identificar a personas.
Los datos seudonimizados son anónimos. No lo son. La ICO establece que los datos seudonimizados siguen siendo datos personales a efectos del UK GDPR.
El texto libre es de bajo riesgo porque no tiene campos fijos. El texto libre puede contener nombres, datos de salud, reclamaciones, opiniones, direcciones, números de referencia y otros datos personales.
La redacción automática mediante IA es siempre fiable. La detección automatizada puede ayudar, pero puede pasar por alto el contexto, nombres poco habituales, identificadores combinados y datos incrustados en documentos o imágenes.
Riesgos y límites
El principal riesgo es la infraclasificación. Si los equipos etiquetan solo un conjunto reducido de campos como PII, pueden dejar datos personales en prompts, exportaciones, registros y ejemplos de entrenamiento. El segundo riesgo es la falsa anonimización. Eliminar los identificadores evidentes puede no ser suficiente si los datos restantes aún permiten identificar a la persona por contexto o vinculación.
También existe una frontera entre el lenguaje de privacidad y el de seguridad. Los equipos de seguridad suelen utilizar la PII para decidir los controles de tratamiento. Los equipos de protección de datos necesitan determinar si se aplica el UK GDPR, qué base jurídica se utiliza, qué derechos son aplicables y si se necesitan salvaguardas adicionales. Ambas perspectivas deben complementarse, no competir.
Para flujos de trabajo sensibles o de alto impacto, la clasificación no debe dejarse a criterio de los usuarios en el momento de introducir el prompt. Conviene utilizar categorías de datos aprobadas, ejemplos, restricciones de herramientas y pasos de revisión. Este artículo no constituye asesoramiento jurídico y no sustituye a una evaluación de protección de datos.
Otro riesgo es tratar la detección de PII como un asunto puramente técnico. Las herramientas de redacción automatizada son útiles, pero pueden tener dificultades con formatos locales, nombres poco habituales, contexto, imágenes, escritura a mano y combinaciones de datos que solo identifican a alguien para las personas dentro de la organización. La revisión humana y los límites del flujo de trabajo siguen siendo necesarios cuando las consecuencias de una exposición son significativas.
Próximos pasos
Elabore una guía breve de clasificación de datos para el uso de IA. Incluya ejemplos de identificadores directos, identificadores indirectos, datos de categoría especial, datos empresariales confidenciales y datos que nunca deben introducirse en herramientas no aprobadas. Haga que los ejemplos sean específicos para sus flujos de trabajo, no formación genérica sobre privacidad.
A continuación, añada controles en los puntos donde se mueven los datos. Para los prompts, utilice reglas y plantillas. Para las cargas, use ubicaciones aprobadas y pasos de redacción. Para RAG o búsqueda, revise qué se indexa y quién puede recuperarlo. Para los proveedores, compruebe el DPA y la configuración de retención. El objetivo es reducir los datos personales innecesarios antes de que entren en el flujo de trabajo de IA.
Añada ejemplos a la política de IA que las personas puedan reconocer de inmediato. Por ejemplo: no pegue reclamaciones completas de clientes en herramientas abiertas; elimine nombres y referencias de cuenta antes de pedir ayuda con la redacción; no cargue archivos de RRHH a menos que la herramienta y el flujo de trabajo estén aprobados; trate las transcripciones como datos personales hasta que sean revisadas. Los ejemplos claros reducen la dependencia de que el personal interprete un lenguaje de privacidad abstracto bajo presión.
Para los responsables, el hábito útil es pedir ejemplos concretos a cada equipo. ¿Qué datos personales aparecen en notas de ventas, reclamaciones, transcripciones, facturas, registros de RRHH y capturas de pantalla? ¿Qué ejemplos son seguros para una herramienta de IA, cuáles necesitan enmascaramiento y cuáles deben quedar completamente fuera? Esto convierte la clasificación en una norma operativa práctica en lugar de una definición teórica.
¿Tiene alguna pregunta o sugerencia, o desea saber cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿Es PII un término del UK GDPR?
Generalmente no. El UK GDPR y las orientaciones de la ICO se centran en los datos personales. La PII sigue siendo útil como abreviatura técnica y de seguridad, pero no debe sustituir al análisis de datos personales conforme al UK GDPR.
¿Es una dirección de correo electrónico PII?
Generalmente sí, si identifica a una persona o puede vincularse a ella. También puede ser un dato personal conforme al UK GDPR si se relaciona con una persona identificada o identificable.
¿Es una dirección IP un dato personal?
Puede serlo. La ICO incluye los identificadores en línea, como las direcciones IP y los identificadores de cookies, como posibles datos personales, dependiendo del contexto.
¿Son seguros los datos enmascarados para su uso en herramientas de IA?
Depende de la calidad del enmascaramiento y del contexto restante. Los datos seudonimizados o redactados pueden seguir siendo datos personales si las personas siguen siendo identificables.
¿Cuál es el primer control más recomendable?
Evitar que datos personales innecesarios entren en el flujo de trabajo. La minimización de datos suele ser más fiable que intentar limpiar todo después de que se haya propagado por herramientas, registros y resultados.