¿La IA necesita saber quién eres? Enmascaramiento de datos personales por diseño

Una empresa puede tener una finalidad legítima para usar inteligencia artificial y, aun así, entregar al modelo más información de la necesaria. Esto ocurre cuando un contrato se envía con firmas y domicilios, un chatbot recibe el correo y el número de identificación del cliente o una base de análisis conserva nombres aunque el resultado buscado sea estadístico. Por eso, la primera decisión no debería ser qué proveedor elegir, sino qué necesita conocer realmente la IA para completar la tarea. Al terminar esta guía podrás distinguir cuándo retirar, sustituir o generalizar datos personales, cuándo la identidad sí resulta necesaria y qué evidencia conviene conservar para justificar la decisión.

La regla práctica: identidad fuera del modelo por defecto

El punto de partida es la minimización: cada dato debe guardar relación con una finalidad concreta y ser necesario para alcanzarla. El Reglamento General de Protección de Datos↗ (abre en una pestaña nueva) exige datos adecuados, pertinentes y limitados, además de medidas desde el diseño y por defecto. A su vez, la Ley 21.719 de Chile↗ (abre en una pestaña nueva) incorpora proporcionalidad y protección de datos desde el diseño a partir del 1 de diciembre de 2026. En consecuencia, si una IA puede clasificar un ticket, resumir una cláusula o detectar una tendencia sin conocer quién es la persona, la identidad debería quedar fuera de esa operación.

Antes de entregar datos personales a una IA, la empresa debe demostrar qué información necesita cada operación. Si la tarea funciona sin identidad, esa identidad no debería llegar al modelo; y si funciona con menos datos personales, tampoco deberían enviarse datos adicionales que no sean necesarios.

Enmascarar, seudonimizar y anonimizar no significan lo mismo

Enmascaramiento es una expresión amplia para describir técnicas que ocultan, sustituyen o reducen información. Sin embargo, su efecto jurídico depende de si la persona todavía puede ser identificada con datos adicionales o mediante el contexto. Por tanto, sustituir un nombre por CLIENTE-27 puede ser útil para reducir exposición, pero el resultado continúa siendo un dato personal si la empresa conserva la tabla de correspondencia o si otros atributos permiten reconstruir la identidad. Solo una anonimización efectiva, evaluada frente a medios razonablemente utilizables, puede sacar la información del régimen de datos personales. En la práctica, estas técnicas cumplen funciones distintas y no producen el mismo efecto sobre el dato:

• Supresión: elimina un campo o fragmento que no aporta nada a la tarea de IA.
• Generalización: reemplaza una edad, fecha o ubicación exacta por un rango o categoría suficiente.
• Enmascaramiento: oculta parcialmente valores, pero no determina por sí solo su condición jurídica.
• Tokenización: sustituye determinados valores por tokens para reducir su exposición; según el diseño, puede utilizarse como técnica de seudonimización.
• Seudonimización: impide atribuir los datos a una persona sin información adicional, que debe mantenerse separada y protegida.
• Agregación: trabaja con totales, grupos o tendencias en lugar de registros individuales, siempre que la granularidad no permita identificar personas.
• Anonimización: busca romper el vínculo entre la información y la persona de manera que esta deje de ser identificable conforme al estándar jurídico aplicable; exige evaluar el riesgo real de reidentificación.

Ahora bien, retirar identificadores directos no siempre basta. Un cargo único, una localidad pequeña, una enfermedad poco frecuente o la combinación de fechas y hechos puede identificar indirectamente. Por esa razón, NIST advierte↗ (abre en una pestaña nueva) que no toda herramienta que simplemente enmascara información consigue una desidentificación suficiente. Del mismo modo, el EDPB exige analizar caso por caso↗ (abre en una pestaña nueva) si un modelo permite identificar personas o extraer datos mediante consultas. Así, el control debe abarcar identificadores, contexto, memoria, outputs y posibilidad de cruce con otras fuentes.

La prueba de necesidad de identidad

Para aplicar la minimización de manera consistente, conviene abandonar las decisiones binarias del tipo “usar o no usar datos personales”. En su lugar, la empresa debería descomponer el flujo en operaciones: autenticar al usuario, recuperar un documento, extraer el fragmento pertinente, consultar al modelo, revisar el resultado y ejecutar una acción. Esa separación revela que una fase puede necesitar identidad y otra solo contenido. Además, permite asignar responsables, límites de acceso y períodos de retención distintos, en vez de conceder al sistema completo una autorización amplia y difícil de controlar.

1. Definir el resultado: describir qué debe producir la IA y para qué decisión se utilizará.
2. Probar el contrafactual: verificar si el resultado conserva utilidad cuando nombres e identificadores se sustituyen por roles o tokens.
3. Determinar el mínimo: si la calidad disminuye, identificar qué atributo específico falta y por qué resulta pertinente.
4. Separar operaciones: evaluar si la identidad puede reincorporarse después de la inferencia dentro de un entorno controlado.
5. Evaluar reidentificación: revisar identificadores indirectos, combinaciones singulares, memoria, logs y fuentes disponibles para el receptor.
6. Conservar evidencia: registrar pruebas, métricas, configuración, responsables, excepciones y fecha de revisión de la decisión.

Cómo aplicarlo en APIs, chatbots y análisis de datos

En un chatbot de soporte, por ejemplo, la aplicación puede autenticar al cliente y recuperar su pedido sin exponer al modelo el correo, teléfono o número de identificación. La IA recibe un token temporal, el producto, el problema y el estado estrictamente necesario; después, el backend vincula la respuesta con la cuenta correcta. Esta separación coincide con las orientaciones de la AEPD sobre IA agéntica↗ (abre en una pestaña nueva), que distinguen entre operaciones y recomiendan políticas de necesidad de conocer, filtrado entre componentes, seudonimización de interacciones y memoria limitada. De este modo, personalizar el servicio no obliga a entregar toda la identidad en cada llamada.

La misma lógica funciona con contratos y CV. Para localizar una cláusula de terminación, comparar obligaciones o mejorar la redacción, normalmente importan el texto, el rol de cada parte y la jurisdicción, no las firmas, direcciones o datos de contacto. En un CV, la experiencia y las competencias pueden separarse del nombre, la fotografía y el domicilio. Sin embargo, esa retirada no resuelve por sí sola riesgos de discriminación ni las restricciones aplicables a decisiones automatizadas. En selección laboral, crédito, salud u otros contextos de impacto significativo pueden existir exigencias adicionales de evaluación, transparencia y supervisión, según la jurisdicción y el uso concreto.

En análisis de datos, por su parte, el objetivo suele ser conocer tendencias, distribución o causas frecuentes. Por eso, antes de enviar filas nominales conviene preguntar si bastan agregados, rangos, una interfaz de consulta o un entorno en el que el cálculo viaje hacia los datos sin copiar la base completa. No obstante, minimizar tampoco significa empobrecer el conjunto hasta volverlo inútil. La nota técnica de la AEPD sobre calidad e IA↗ (abre en una pestaña nueva) explica que necesidad, exactitud e idoneidad deben medirse frente a la finalidad. En consecuencia, la empresa debe demostrar tanto que no sobran datos como que los datos restantes permiten un resultado razonable.

Una arquitectura de separación necesita controles y responsables

El patrón general es sencillo de expresar: dato original, filtrado local, contexto mínimo o token, inferencia de IA, revisión del output y reidentificación interna autorizada. Sin embargo, su efectividad depende de cómo se implemente. La tabla que relaciona tokens e identidades debe permanecer separada, protegida y fuera del proveedor cuando sea posible; además, no debería reutilizarse el mismo token entre finalidades si eso facilita perfiles o cruces. A su vez, los filtros deberían aplicarse en una capa técnica controlada por la organización y no depender exclusivamente de que la persona usuaria retire manualmente los datos.

• Producto define la tarea, los datos mínimos y el momento en que la identidad puede reincorporarse.
• Legal o privacidad confirma finalidad, base de licitud, roles, transparencia, derechos y necesidad de evaluación de impacto.
• Seguridad controla llaves, permisos, aislamiento entre tenants, filtrado, monitoreo y riesgo de reidentificación.
• Compras o proveedores verifica DPA, subencargados, transferencias, retención, borrado y usos para entrenamiento o mejora.
• El equipo de datos mide utilidad después del enmascaramiento y documenta errores, sesgos y atributos indispensables.
• Operaciones conserva evidencia mínima de configuración y pruebas sin copiar prompts, documentos ni contenido sensible en los logs.
• Una persona autorizada revisa excepciones, resultados de alto impacto y cambios relevantes del flujo antes de persistir conclusiones.

“No usamos tus datos para entrenar” no significa “no conservamos datos”

Al evaluar una API, conviene separar entrenamiento, inferencia, logs de seguridad, estado persistente y borrado. La documentación actual de OpenAI↗ (abre en una pestaña nueva) indica que los datos de API no se usan para entrenar por defecto, pero describe retención de monitoreo y funciones con estado según el endpoint. De manera comparable, Anthropic documenta↗ (abre en una pestaña nueva) un plazo estándar con excepciones, mientras Microsoft distingue↗ (abre en una pestaña nueva) inferencia, servicios con estado, ubicación y monitoreo. Por lo tanto, el contrato, el endpoint y la configuración real deben revisarse juntos y nuevamente antes de publicar o desplegar, porque estas condiciones pueden cambiar.

Qué cambia en Chile y cómo demostrar una decisión razonable

En Chile, la transición merece una explicación expresa. Hasta el 30 de noviembre de 2026 continúa el régimen anterior; desde el 1 de diciembre de 2026, la Ley 21.719↗ (abre en una pestaña nueva) incorpora proporcionalidad, protección desde el diseño y por defecto, y seudonimización entre las medidas posibles. Aun así, activar un filtro no acredita cumplimiento completo. La evidencia útil incluye el mapa del flujo, la prueba de necesidad por operación, resultados de calidad, riesgo de reidentificación, DPA, configuración de retención, permisos, responsables, excepciones y fecha de revisión. En definitiva, el objetivo no es producir un sello, sino demostrar por qué la empresa entregó solo lo necesario y qué hizo con la incertidumbre restante.