Modelos de anonimización de PII en 2026: qué funciona de verdad

Regex es aburrido. Probablemente lo sigas necesitando.

Para identificadores estructurados, las expresiones regulares siguen siendo difíciles de superar. Números de tarjeta, IBAN, identificadores nacionales, direcciones de correo y otros valores con estructura relativamente predecible a menudo se pueden detectar de forma barata y determinista. Los checksums lo hacen aún más sólido: la validación de Luhn puede ayudar a distinguir números de tarjeta de pago plausibles, mientras que los IBAN se pueden validar usando su propio checksum en lugar de confiar solo en el patrón.

Lo bueno de esta capa es que apenas hay misterio. Puedes inspeccionar la regla. Sabes por qué saltó. Puedes probar los casos límite raros. Es lo bastante rápida como para ejecutarse casi en cualquier sitio.

Su debilidad es igual de obvia: regex entiende estructura, no significado.

• 4111 1111 1111 1111 parece un número de tarjeta por su estructura.
• «Envía los documentos a mi hija, a la casa detrás de la farmacia» necesita un tipo de razonamiento completamente distinto.

Por eso regex es útil como una capa, no como una estrategia de anonimización completa.

Presidio se entiende mejor como infraestructura que como modelo

Microsoft Presidio es uno de los bloques open source más útiles en este espacio porque no asume que la detección de PII tenga que venir de un único mecanismo. Su analizador puede combinar reconocedores basados en patrones, checksums, modelos de NLP y lógica personalizada, y el anonimizador después aplica transformaciones a los spans detectados.

Esa arquitectura ha envejecido bien.

Lo que no haría es tratar la configuración por defecto como un benchmark de precisión. Presidio permite deliberadamente sustituir o ampliar el motor de NLP subyacente y los reconocedores. El propio framework documenta el uso de modelos de PII basados en transformers junto a sus reconocedores existentes.

Así que «Presidio contra el transformer X» suele ser la comparación equivocada. En un sistema real, Presidio puede ser la capa de orquestación alrededor del transformer X.

Esto se vuelve especialmente importante fuera del inglés. Presidio incluye reconocedores predefinidos, pero la cobertura varía considerablemente por entidad y por idioma, y los reconocedores personalizados forman parte del diseño previsto.

GLiNER hizo mucho más interesante la detección de entidades abierta

El NER tradicional tiene una propiedad molesta: la taxonomía de entidades suele estar fijada en el entrenamiento. Si tu modelo se entrenó para encontrar personas, organizaciones y lugares, pedirle mañana que detecte «alias de cuenta de cliente» no necesariamente sirve de nada.

GLiNER tomó una dirección distinta. Convirtió las categorías de entidad en algo que puedes describir, lo que hizo mucho más práctica la extracción zero-shot y con pocos datos.

Eso es particularmente atractivo para la privacidad porque el PII no es una taxonomía limpia. Cambia según el país, el sector y la aplicación. Un hospital, una plataforma de videojuegos y una aplicación financiera pueden decir todos que detectan PII queriendo decir cosas bastante distintas.

La investigación ya ha ido más allá de los modelos GLiNER genéricos. En mayo de 2026, GLiNER2-PII presentó un modelo de 0,3B de parámetros adaptado específicamente a 42 tipos de entidad PII y reportó el mejor F1 a nivel de span de los cinco sistemas evaluados en el benchmark SPY.

También hay ejemplos específicos de dominio que muestran hasta dónde puede llegar la especialización. Un estudio clínico de 2025 ajustó GLiNER para historiales psiquiátricos y reportó un micro-F1 de 0,98 en su propio conjunto de evaluación, sustancialmente por encima de los otros sistemas que probó.

Ese número es impresionante. También es un buen ejemplo de por qué los benchmarks de PII hay que leerlos con cuidado.

Un F1 de 0,98 y uno de 0,14 pueden ser ciertos a la vez

Esto es probablemente lo más importante que hay que entender sobre la literatura actual de detección de PII.

En abril de 2026, PIIBench combinó diez datasets públicos en un benchmark mucho más amplio que cubre 48 tipos de PII normalizados. Se evaluaron ocho sistemas existentes.

Cada sistema obtuvo menos de 0,14 F1 a nivel de span. Presidio fue la línea base más fuerte, con 0,1385.

A primera vista eso parece incompatible con artículos que reportan puntuaciones F1 en torno a 0,9 o superiores. No lo es. Están midiendo problemas distintos.

Un modelo especializado evaluado sobre datos parecidos a su dominio de entrenamiento puede rendir extremadamente bien. Un modelo lanzado contra idiomas, dominios, convenciones de anotación y categorías de entidad raras está resolviendo un problema de generalización sustancialmente más difícil.

Así que desconfiaría de cualquier producto de PII cuyo argumento principal sea simplemente:

«Nuestro F1 es del 97%.»

Mis siguientes preguntas serían: ¿sobre qué datos, qué entidades, qué idiomas, qué criterio de coincidencia, y cuán parecido es ese dataset al mío?

Para los sistemas de privacidad, el benchmark no es el producto. Tu tráfico es el benchmark.

Roblox es uno de los casos de producción más útiles

Hay relativamente pocas descripciones públicas de detección de PII operando a escala genuinamente grande, por eso vale la pena mirar el lanzamiento de Roblox en 2025.

Su problema es ligeramente distinto de la redacción clásica. Roblox no solo intenta encontrar spans literales como números de teléfono. También quiere identificar conversaciones en las que los usuarios intentan intercambiar o solicitar PII, incluyendo intentos deliberadamente ofuscados.

Roblox ajustó un encoder XLM-RoBERTa-Large para esta tarea.

Esos números son impresionantes, pero el contexto es esencial. Es un clasificador optimizado contra la definición de Roblox de conversación relacionada con PII, entrenado con sus propios datos de producción etiquetados y ejemplos sintéticos. No debería interpretarse como «XLM-RoBERTa consigue un 98% de recall en PII».

La lección real es más útil de todas formas. Un modelo mejora drásticamente cuando el problema de detección, los datos de entrenamiento y el tráfico de producción realmente coinciden.

Eso es menos emocionante que descubrir un modelo de PII universal, pero mucho más accionable.

¿Y usar un LLM?

Puedes pedirle a un LLM que redacte PII directamente. A veces funciona extremadamente bien.

Los LLM son particularmente atractivos cuando la información sensible es contextual en lugar de estructuralmente obvia. Pueden razonar sobre frases y relaciones que un regex nunca va a entender.

La investigación sobre redacción de PII basada en LLM está activa, incluyendo trabajos que comparan calidad de redacción, preservación semántica, fuga de información, latencia y coste computacional.

Pero poner un modelo autoregresivo grande delante de cada otra petición al modelo suele ser una arquitectura cara. Has aumentado la latencia, aumentado el coste de inferencia, introducido otro modelo cuyo comportamiento hay que evaluar y, si es una API externa, potencialmente creado exactamente el problema de compartición de datos que el redactor pretendía resolver.

Eso no vuelve inútil la detección basada en LLM. La convierte en una herramienta que usaría de forma selectiva, no ciega.

La arquitectura que me convence es una cascada

El diseño práctico más sólido cada vez es menos «¿qué detector deberíamos elegir?» y más «¿qué detector debería encargarse de cada tipo de incertidumbre?».

Empieza barato. Usa reglas deterministas para lo que genuinamente tiene estructura determinista. Luego usa un NER contextual o un modelo encoder para nombres, direcciones y otras entidades ambiguas. Añade detectores específicos de dominio donde el coste de un fallo lo justifique. Y evalúa la unión del sistema contra tráfico representativo.

validación estructurada
→ detección contextual
→ detección específica de dominio
→ resolución de entidades / seudonimización
→ política
→ auditoría

Los enfoques híbridos ya están produciendo resultados interesantes. Un estudio multilingüe publicado en 2025 encontró que su método combinado mejoraba de forma sustancial el recall ponderado frente a NER independiente y líneas base de LLM en zero-shot.

Esto crea un segundo problema: los desacuerdos. Un detector dice que «Jordan» es una persona. Otro cree que es un país. Un reconocedor de regex no ve nada. El texto que lo rodea puede hacer correcta cualquiera de las dos interpretaciones.

Los sistemas de producción, por tanto, necesitan una política por encima de la detección: umbrales, prioridades, resolución de solapes y normalmente cierta tolerancia a falsos positivos específica por entidad. Esa política forma parte del sistema de privacidad. Debería probarse como tal.

La redacción no siempre es la transformación correcta

Hay otro problema que se pierde cuando la gente reduce la anonimización a [PERSON].

Imagina este prompt:

Compara la cuenta de Alice con la de Bob y dime si Alice le ha pagado a Bob.

Convierte ambos nombres en [PERSON] y habrás protegido los identificadores dañando la tarea.

Una representación mejor podría ser:

Compara la cuenta de [PERSON_1] con la de [PERSON_2] y dime si [PERSON_1] le ha pagado a [PERSON_2].

Ahora el modelo puede seguir razonando sobre las relaciones sin ver las identidades originales.

Aquí es donde la seudonimización se vuelve más útil que la redacción simple. Presidio en sí soporta tanto operadores de anonimización como de deanonimización, y los diseños de pasarela actuales usan cada vez más mapeos acotados entre identificadores sustitutos y valores originales.

Pero la distinción importa tanto legal como técnicamente. Los datos seudonimizados siguen siendo datos personales bajo el RGPD cuando se pueden vincular de vuelta a una persona. Los datos verdaderamente anonimizados son distintos: el vínculo con la persona tiene que eliminarse de forma efectiva. Llamar «anonimización» a una tokenización reversible no la hace anónima.

La privacidad diferencial resuelve un problema distinto

La privacidad diferencial suele aparecer en la misma conversación, pero pertenece a otra capa.

La detección de PII pregunta: ¿puedo identificar y transformar información sensible en este registro?

La privacidad diferencial pregunta algo más parecido a: ¿puede la salida de este cálculo revelar demasiado sobre si una persona concreta contribuyó al dataset subyacente?

Esas no son garantías intercambiables. Para una petición de API que contiene el correo de alguien, la privacidad diferencial no sustituye a encontrar ese correo antes de transmitirlo. Para estadísticas agregadas, entrenamiento de modelos o publicación de datasets, puede ser exactamente el mecanismo de privacidad que necesitas.

Esta distinción se vuelve más importante a medida que la investigación en anonimización mejora mostrando cómo fragmentos aparentemente inofensivos se pueden vincular entre sí. El trabajo del EDPB de 2026 sobre anonimización enmarca esto explícitamente en términos de si los registros todavía se pueden aislar, vincular o usar para inferir información sobre individuos.

¿Qué construiría hoy?

No un modelo. Construiría un pipeline. Algo como:

validación estructurada → detección contextual → detección específica de dominio donde haga falta → resolución de entidades/seudonimización → política → auditoría

Y luego lo mediría sobre los datos que realmente va a ver.

La configuración correcta para tickets de soporte al cliente probablemente no sea la correcta para notas clínicas. La configuración correcta para inglés probablemente no sea la correcta para seis idiomas europeos. Y el detector que gana un benchmark puede no ser el detector que te da el mejor equilibrio latencia-recall en producción.

Eso, creo, es dónde está el campo en 2026. Los modelos individuales están mejorando mucho. El problema difícil ahora es diseñar el sistema alrededor de ellos.