Detectar datos personales en un conjunto de entrenamiento: cómo se construye un detector agnóstico al modelo

Afinar un modelo con tu propio texto significa enseñarle también los datos personales que contiene. Los corpus de entrenamiento están llenos de nombres, direcciones, correos y teléfonos, números de identidad, cuentas bancarias y fechas de nacimiento.

Un modelo entrenado con texto sin limpiar puede memorizar esos datos y más tarde reproducir los de una persona real ante una petición que nunca pretendió sacarlos a la luz.

Esta guía explica un enfoque agnóstico al modelo para detectar datos personales antes de entrenar: cómo se construye, dónde sufre y qué dicen las mediciones.

El problema no está en los formularios

Los datos personales rara vez ocupan un campo de formulario ordenado. Se esconden en transcripciones de soporte, expedientes de personal, registros de chat y las largas columnas de texto libre de los conjuntos con los que los equipos afinan.

Además llegan en formatos desordenados y multilingües que ningún esquema previo anticipó. Esa es la dificultad real.

• Las herramientas habituales son modelos bidireccionales de clasificación de tokens: transformadores que etiquetan cada token con un tipo de dato personal.
• Esos tipos quedan fijados al entrenar; el esquema está congelado.
• Un identificador propio del dominio, como un número de empleado o una cartera cripto, queda fuera de ese esquema.
• Añadir uno exige reetiquetar y reentrenar, y la herramienta sigue atada a un modelo y un despliegue.

Un modelo de lenguaje replantea el problema

Un modelo de lenguaje lee sus instrucciones en el momento de la inferencia. Esa sola diferencia lo cambia todo: las entidades a detectar, el formato de salida y el backend pasan de ser código a ser configuración.

Un único detector puede apuntar a un tipo de entidad nuevo editando una instrucción en vez de reentrenar. Puede correr sobre una API gestionada o dentro de tu propia nube privada virtual, y razonar sobre contexto en ocho idiomas sin paso de traducción.

Dos decisiones de diseño

Dos decisiones hacen que el enfoque sea agnóstico al modelo, y ninguna se puede añadir después: hay que tomarlas desde el principio.

• Detección guiada por instrucciones: toda la lógica vive en las instrucciones y en una capa fina de análisis. Así no depende de las manías de ningún modelo concreto.
• Backend configurable: al modelo se llega por una interfaz de inferencia uniforme. Cualquier objeto que reciba una lista de mensajes y devuelva texto la cumple.
• El resultado: el mismo detector funciona con un servicio gestionado y con un modelo abierto en tu propia GPU.
• Entornos aislados: las instalaciones sin salida a internet siguen cubiertas por la misma razón.

La personalización viene de dos componentes independientes. El primero es el modelo, que fija precisión, latencia y coste. El segundo es el conjunto de entidades, que define qué cuenta como dato personal, y cambiarlo es una edición de una línea en las instrucciones.

Las cuatro partes del detector

El enfoque se compone de cuatro partes, leídas en el orden en que una petición atraviesa el sistema.

Parte	Su función
Instrucción	Define el esquema: quince categorías, definiciones de una línea, lista de lo que no debe marcarse
Backend	Ejecuta el modelo mediante una interfaz de inferencia uniforme
Análisis	Convierte la respuesta en tramos localizados
Secuencia de llamada	Une las tres anteriores

La tarea que se pide al modelo es estrecha y bien definida: leer el texto, encontrar todos los tramos con datos personales y etiquetar cada uno con un tipo del esquema. La respuesta vuelve como JSON estructurado.

Por qué el modelo no da las posiciones

El detector no pide al modelo posiciones de carácter, porque un modelo de lenguaje no las produce de forma fiable. El modelo devuelve solo el tipo de entidad y el valor textual exacto que encontró.

Las posiciones se recuperan después: cada valor se localiza en el texto original con una expresión regular y se convierte en un rango de caracteres. La distinción parece pequeña, pero de ahí viene buena parte de la fiabilidad.

La instrucción incluye además una lista de lo que no debe marcarse y algunos ejemplos opcionales. Esas dos adiciones evitan que el modelo se entusiasme y tome cada nombre propio por dato personal; aquí un falso positivo puede costar tanto como una omisión.

Recoger las etiquetas inventadas

Los modelos de lenguaje emiten a menudo etiquetas casi correctas: DATE en vez de DATES, EMAIL en vez de CONTACT_INFO.

• Cada etiqueta se reubica en el vocabulario de la propia instrucción mediante morfología y una tabla de alias preparada.
• Una etiqueta que ningún nivel logra mapear no se fuerza; se marca como UNK.
• Así las invenciones reales siguen siendo visibles en lugar de contarse en silencio como aciertos.
• Para la honestidad de la medición, ese comportamiento importa más que la tasa de detección.

Qué hace falta para ejecutarlo

La instalación es ligera. Python 3.11 o superior y Boto3 como única dependencia de ejecución bastan; el detector no levanta ningún otro servicio.

• En la vía gestionada hacen falta una cuenta en la nube y acceso habilitado para el modelo elegido.
• Las credenciales se resuelven por la cadena estándar; se recomienda un rol o un perfil SSO antes que claves estáticas de larga vida.
• El detector recibe un texto y devuelve una lista de tramos localizados, lista para alimentar un paso de enmascarado.
• Cambiar el identificador del modelo es cosa de una línea; el detector y el punto de llamada no cambian.

Si lo ejecutas en tu propio servidor, apagarlo sigue siendo responsabilidad tuya, porque el detector no gestiona la infraestructura del backend. En la vía gestionada solo pagas los tokens que consumes.

Cómo se hizo la prueba

La evaluación usó cinco corpus públicos, cada uno con tramos verificados, muestreando unas 10.000 filas por conjunto.

En total 49.365 registros y 222.114 tramos verificados principales en ocho idiomas: alemán, inglés, español, francés, hindi, italiano, neerlandés y telugu. Los dominios van de perfiles sintéticos multilingües a documentos ingleses de recursos humanos y atención al cliente.

Un tramo predicho se empareja con el verificado solo si coincide exactamente: inicio, fin y etiqueta deben concordar. De ahí salen precisión, exhaustividad y F1. Ese criterio estricto baja las puntuaciones pero hace significativa la comparación.

Alinear las etiquetas

Comparar detectores entre esos corpus es más difícil de lo que parece, porque las etiquetas no encajan. Cada detector y cada conjunto usa su propio vocabulario.

Para una comparación justa, toda etiqueta cruda se mapea a una única taxonomía canónica de doce entidades comunes: nombre, dirección, contacto, fecha, edad, número nacional, financiero, IP, URL, usuario, contraseña y número de documento. Cada detector se puntúa solo en el ámbito que él y el conjunto declaran, así ninguna herramienta se penaliza por una categoría que nunca reclamó.

Esa taxonomía canónica define además dos ámbitos de reporte. El F1 principal es la cifra justa de comparación sobre los doce tipos comunes. El F1 de entidades extendidas cubre categorías propias de cada conjunto, como profesión, nombre de empresa o cartera cripto, de las que la mayoría de herramientas comerciales ni tiene noción.

Los resultados

La métrica principal es el F1 principal a nivel de tramo. La tabla pone lado a lado modelos gestionados y modelos abiertos autoalojados.

• Mistral Large 3 obtuvo la mejor puntuación del lado gestionado con un 83,1%, a unos 1,16 segundos por detección.
• OSS-GPT 20B, autoalojado, quedó justo detrás con un 81,6% en un tiempo parecido.
• PrivacyFilter, la herramienta comercial, se quedó en el 80,7%.
• Nova Lite 2 puntuó más bajo, un 74,9%, pero fue el más rápido con 0,77 segundos.

El mensaje real aquí no es un ranking. Las puntuaciones están cerca y la elección correcta depende de dónde aprieta tu carga entre precisión, latencia y coste. En una limpieza por lotes diaria la latencia da igual; en un flujo en vivo pesa más que unos puntos de puntuación.

Visto desde un mercado regulado

Bajo las normas europeas de protección de datos, limpiar un conjunto antes de entregarlo a un modelo no es solo buena ingeniería sino una obligación. Lo más útil de este enfoque es la flexibilidad del esquema: identificadores locales como un número nacional, un número fiscal o un IBAN se definen añadiendo una línea a la instrucción.

Conviene añadir una advertencia. Hay idiomas que no están entre los ocho de la prueba. No des por hecho la precisión del mismo detector en un idioma ausente sin medirla con tus propios datos; los formatos de nombre y dirección dependen mucho de la lengua.

Un apunte práctico más: en qué fase ejecutas el detector. Escanear una vez justo tras recoger los datos no basta, porque el sistema de origen sigue funcionando y los registros nuevos deben pasar por el mismo proceso. Tratar la detección como una limpieza única deja sin protección cada lote posterior al primer entrenamiento.

Dónde detenerse

La detección no es una solución en sí misma sino la entrada del paso siguiente. Los tramos hallados alimentan un paso de enmascarado o borrado, y ahí se toma la decisión real: qué dato se elimina y cuál se sustituye por un seudónimo.

La segunda advertencia es sobre la medición. Ningún detector lo atrapa todo, y la mejor puntuación aquí está en el 83%. Así que en vez de cerrar el proceso como "limpiado", hay que dejar por escrito si consideras aceptable el riesgo restante.