Anonimizar los datos antes de que vayan a la IA: ¿basta?
En parte. Ocultar las entradas antes del envío reduce notablemente el riesgo y vale más que nada. Jurídicamente, sin embargo, casi siempre se trata de seudonimización y no de anonimización, porque la correspondencia existe en algún lugar; de lo contrario la respuesta no volvería legible. Los datos siguen siendo personales, el RGPD continúa aplicándose y el tratamiento sigue ocurriendo en el proveedor externo. Quien quiera evitarlo no necesita un enmascarado mejor, sino que los datos no salgan en absoluto.
Para qué sirve realmente el enmascarado
El procedimiento se explica rápido: antes de que un texto salga hacia un modelo de lenguaje, un detector busca las referencias personales —nombres, direcciones, fechas de nacimiento, IBAN, números de expediente— y las sustituye por marcadores. El modelo trabaja sobre el texto enmascarado y los valores originales se reinsertan en la respuesta. Para quien lo usa parece que la IA hubiera leído el expediente real.
La ganancia es real y no se minimiza aquí. Un nombre en claro menos en el prompt es un nombre en claro menos en los registros del proveedor. Contra el error más frecuente del día a día —alguien pega la carta completa de un cliente en una ventana de chat— un enmascarado automático ayuda de forma más fiable que cualquier formación.
Pero la pregunta decisiva no es si ayuda. Es: ¿basta para cumplir las obligaciones que le hicieron reflexionar al principio? Y ahí la respuesta se vuelve menos nítida.
Dónde está el límite
Un detector que reconoce el carácter personal en un texto libre trabaja con probabilidades. Es imperfecto no porque esté mal construido, sino porque la tarea misma no tiene una solución unívoca: que una secuencia de caracteres identifique o no depende del contexto, no de su forma.
Por eso los proveedores de tales procedimientos indican tasas de detección y no garantías. Una tasa del 95 por ciento suena alta, pero significa que una de cada veinte apariciones no se reconoce como tal. Con mil páginas de correspondencia al mes eso ya no es una magnitud teórica.
La última fila es la más importante y lleva directo al núcleo jurídico.
Seudonimización no es anonimización
El RGPD distingue claramente ambas cosas. Los datos son anónimos solo si nadie puede ya restablecer el vínculo con una persona con un esfuerzo razonable; tales datos quedan completamente fuera del ámbito del reglamento según el considerando 26. Los datos están seudonimizados si pueden reatribuirse con ayuda de información adicional (art. 4 n.º 5 RGPD). Los datos seudónimos siguen siendo datos personales y todas las obligaciones continúan aplicándose.
Un procedimiento que coloca marcadores y los vuelve a resolver en la respuesta cae por definición en el segundo caso. La correspondencia tiene que existir, o el producto no funciona. Sigue tratándose, por tanto, de un tratamiento de datos personales: con contrato de encargo, registro de actividades, base jurídica y, en su caso, evaluación de impacto.
Para los profesionales sujetos a secreto —despachos de abogados, consultas médicas, profesiones de asesoramiento— eso desplaza la pregunta una vez más. Ahí la revelación a un tercero ya es el paso crítico, al margen de la calidad del ocultado. El enmascarado puede atenuar ese paso, pero no lo elimina.
Cuándo el enmascarado sigue siendo la elección correcta
Nada de esto vuelve inútil el procedimiento. Hay casos en los que encaja exactamente:
- Cuando se necesita un modelo externo concreto. Algunas tareas funcionan hoy mejor en uno de los grandes modelos del mercado. Quien depende de ello está claramente mejor con enmascarado que sin él.
- Como red frente al error humano. Incluso junto a una solución interna queda la tentación de meter algo rápido en una ventana de chat privada. Un enmascarado obligatorio lo intercepta.
- Para material sin datos personales. Para documentación técnica, textos de marketing o expedientes públicos de licitación todo el debate carece de objeto.
El error no es enmascarar. Es tomar el enmascarado por una decisión sobre el lugar. Cambia qué sale, no si sale algo ni hacia dónde.
La alternativa: no enviar en absoluto
La segunda vía invierte el orden. En lugar de enmascarar los datos antes de que salgan de casa, no sale nada de casa. El modelo se ejecuta donde ya están los documentos: on-premise en su propia infraestructura o en un centro de datos alemán.
Varias preguntas se disuelven entonces en lugar de pedir respuesta. No hay tasa de detección, porque no hay nada que detectar. No hay transferencia a un tercer país ni cuestión de la CLOUD Act, porque no participa ningún tercer país. Y la calidad de las respuestas no sufre por el enmascarado: el modelo ve el expediente completo, porque puede.
Así está construido exactamente KOSMO. El asistente trabaja sobre sus propias fuentes, indica la referencia de cada respuesta y no se entrena ningún modelo con sus contenidos. Cómo es en el día a día lo encontrará en Cómo funciona; la valoración jurídica de los servicios en la nube en ChatGPT, Claude y compañía con datos de clientes.
Nota: esta página sitúa un patrón técnico y jurídico y no sustituye el asesoramiento jurídico. La licitud de un uso concreto depende del sector, de los datos tratados y de la implementación en el caso particular; en caso de duda, aclárelo con su delegado de protección de datos o un despacho especializado.
Preguntas frecuentes
¿Basta la anonimización para usar ChatGPT conforme al RGPD?
Ayuda, pero por sí sola no suele bastar. Los procedimientos que vuelven a resolver los marcadores en la respuesta son jurídicamente seudonimización: los datos siguen siendo personales y el tratamiento sigue ocurriendo en el proveedor externo. El contrato de encargo, la base jurídica y la cuestión de la transferencia fuera de la UE permanecen.
¿Qué diferencia hay entre anonimización y seudonimización?
Los datos anónimos ya no puede referirlos nadie a una persona con un esfuerzo razonable; según el considerando 26 quedan fuera del ámbito del RGPD. Los datos seudónimos pueden reatribuirse con información adicional (art. 4 n.º 5) y siguen plenamente protegidos. Quien retraduce marcadores posee necesariamente esa información adicional.
¿Qué fiabilidad tienen estos procedimientos al detectar datos personales?
Buena, pero no completa. Las referencias estructuradas como el IBAN o las fechas de nacimiento se encuentran con seguridad por patrón. Más difíciles son los identificadores internos sin formato fijo y sobre todo las combinaciones: un diagnóstico raro con un municipio y un periodo identifica a una persona incluso sin nombre.
¿Sufre la calidad de las respuestas por el enmascarado?
Es un compromiso. Cuanto más cuidadosamente se enmascara, menos contexto le queda al modelo. En textos jurídicos o médicos, donde las relaciones entre las personas implicadas son la información misma, eso puede volverse delicado.
¿Vale también para los profesionales sujetos a secreto?
Ahí la situación es más estricta. Lo crítico es ya la revelación a un tercero, al margen de la calidad del ocultado. El enmascarado reduce el riesgo pero no elimina el paso. Quien trata datos de clientes, pacientes o asesoramiento debería hacer examinar este punto expresamente.
¿Necesita KOSMO anonimización?
No. KOSMO funciona on-premise o en un centro de datos alemán: los datos no salen de su infraestructura, así que no hay destinatario alguno ante el que enmascarar nada. Tampoco se entrena ningún modelo con sus contenidos.
¿Se pueden combinar ambas cosas?
Sí, y en organizaciones grandes a menudo tiene sentido. El asistente interno cubre el día a día con datos reales; para los casos raros en que se necesita un modelo externo concreto, el enmascarado sigue siendo la herramienta adecuada.
Un asistente en el que la pregunta no se plantea
KOSMO trabaja sobre sus propias fuentes, on-premise o en un centro de datos alemán. Nada se transmite al exterior, nada se usa para entrenar.
