Esta es una traducción automática del documento original en inglés. En caso de cualquier discrepancia entre esta traducción y la versión original en inglés, prevalecerá la versión en inglés. Leer la versión original en inglés
Seudonimizador en el dispositivo: desarrollado y evaluado
2026-05-22 · Caiioo Team
Queríamos resolver el problema de privacidad de los sistemas de IA que entrenan y retienen información de identificación personal real. Las políticas y acuerdos de "Retención de datos cero" reducen el riesgo, pero están llenos de excepciones. Básicamente dicen: "No almacenaremos ninguna de sus instrucciones o resultados, excepto para: (ingrese aquí una larga lista de excepciones: fines de seguridad, vigilancia gubernamental, retenciones legales, desarrollo de productos, registros de errores, mejora de los servicios...)"
Para solucionar esto, creamos un filtro de datos personales que se ejecuta en la propia máquina del usuario, ve el mensaje antes de que salga del dispositivo y devuelve la misma respuesta que el usuario habría recibido si lo hubiera escrito sin ningún filtro.
Así que lo construimos. La próxima versión de Caiioo incluirá el Seudonimizador. Accesible a través del icono del escudo en el chat del agente, así como en la configuración.
Este libro blanco describe la lógica, la arquitectura, el proceso de evaluación y los principios de diseño detrás de nuestro sistema de filtrado de privacidad.
Lo que nos propusimos hacer
Protección general de la privacidad mediante la minimización de datos. Cuando un usuario chatea con un modelo remoto, el modelo no necesita un nombre real, una dirección particular, un correo electrónico real o el número de teléfono de un cliente para responder a la pregunta del usuario. Necesita la forma de la pregunta, y necesita que parezca una pregunta real para que el LLM no descarte la consulta como una prueba. Por lo tanto, el filtro elimina los identificadores reales de los datos enviados a la IA y vuelve a integrar los valores reales en el camino de vuelta. El modelo ve nombres e identificadores sintéticos; el usuario ve la conversación real.
Asistencia para el cumplimiento de HIPAA. Un segundo modo se enfoca en los 18 identificadores de la regla Safe Harbor de HIPAA (§164.514) y la variante más flexible de Conjunto de Datos Limitados (Limited Data Set). Un clínico, un administrador de atención médica o cualquier persona que trabaje en un flujo de trabajo cubierto puede hablar con un modelo de propósito general sobre casos reales sin enviar información de salud protegida (PHI) a la IA. No somos el oficial de cumplimiento de la entidad cubierta, pero podemos ser la capa que evita que la PHI salga de la computadora portátil en primer lugar. Nuestras evaluaciones proporcionan puntos de referencia medibles que las organizaciones pueden utilizar para evaluar la idoneidad del filtro para sus estándares de cumplimiento y privacidad. Todas las medidas de privacidad y seguridad son decisiones de juicio que son responsabilidad del usuario o de la entidad del usuario.
Elegimos ambos porque la ingeniería es la misma, y el caso de uso de PHI es en realidad técnicamente más sencillo debido al uso de entidades con nombre distintivas, que son más fáciles de redactar que los datos más generales en la categoría de Datos Personales. El filtrado de HIPAA también se ve favorecido por el hecho de que generalmente es en inglés o español. Detectamos identificadores, sustituimos seudónimos estables e identificadores sustituidos en el mismo formato, los restauramos al regresar y nunca registramos los valores reales. El mapa entre la información sintética y la información real permanece únicamente en el dispositivo del usuario, de modo que el usuario pueda leer información real en las respuestas del agente. La lista de categorías y la puerta de enlace de políticas son lo que cambia entre modos.
Por qué regex más machine learning, y no solo uno de ellos
Existen dos tecnologías de filtrado principales en nuestro seudonimizador: un lenguaje de reconocimiento de patrones determinista llamado regex y modelos de machine learning entrenados.
Regex es imbatible en formatos superficiales. Una dirección de correo electrónico tiene una forma ([email protected]). También la tiene una IP, una tarjeta de crédito, un IBAN, un VIN, un SSN (XXX-XX-XXXX) o una clave API. Si el formato es confiable, regex lo detecta de forma determinista, siempre, sin carga de modelo y sin costes de inferencia.
Regex es, sin embargo, inútil ante el contexto. "La gráfica de Sarah del martes pasado" contiene una persona y una fecha, pero ninguna de las dos puede distinguirse solo por su formato. "El paciente en 14 Elm" contiene una dirección que se solapa con mil elementos que no son direcciones. "Su MRN es 7741032" necesita las palabras que rodean al número para significar algo.
Un modelo de lenguaje pequeño y ajustado (fine-tuned) maneja el contexto; el nuestro es un codificador de 110 millones de parámetros especialmente entrenado y destilado a partir de un modelo de lenguaje pequeño y multilingüe. Lee la oración, no la subcadena, y es lo suficientemente pequeño como para ejecutarse de forma extremadamente rápida en un dispositivo, incluso en un teléfono móvil.
Los puntos de referencia (benchmarks) ilustran las fortalezas complementarias de las dos capas. Evaluamos las dos capas de forma aislada para asegurarnos de que cada una esté aportando su valor real. En el conjunto de 150 preguntas de PrivacyBench-PD, donde las preguntas y respuestas explícitamente NO se utilizaron para entrenar el modelo:
| Capa | PII detectada | Tasa de detección |
|---|---|---|
| Solo Regex | 205 / 670 | 30.6 % |
| Solo ML | 516 / 670 | 77.0 % |
| Ambas (producción) | 625 / 670 | 93.3 % |
Regex por sí solo omite tres cuartas partes de los identificadores porque la mayoría de los identificadores en la prosa real no están estructurados. El ML por sí solo pierde 16 puntos porcentuales que la capa regex habría detectado: las cosas que son puramente su forma (una tarjeta de crédito parece una tarjeta de crédito; el modelo no tiene ninguna señal adicional que añadir). Juntos cubren lo que ninguno cubre por separado.
Analizando más a fondo dónde cada capa es decisiva: en ese mismo conjunto, 16 valores de prueba fueron detectados solo por regex (correos electrónicos, IPs, cuentas financieras, IDs estructurados) y 327 fueron detectados solo por ML (nombres, identificadores contextuales, frases multilingües).
Pequeño, inteligente, rápido y funciona en todas partes
Tuvimos que hacer que el filtro se ejecutara en el dispositivo, lo cual fue un desafío de ingeniería.
Tiene que ser pequeño porque nuestra aplicación se ejecuta localmente en muchos sistemas: dentro de una extensión de Chrome, una aplicación de macOS, una aplicación de iOS, una aplicación de Android o en Windows y Linux. El paquete es de unos 113 MB por modelo. Hay dos modelos (uno para datos personales generales y otro para información de salud protegida) y el modo Safe Harbor ejecuta ambos en paralelo. Entre estos, un dispositivo Android de gama baja es el de menor rendimiento, pero nuestro sistema funciona sin problemas.
Tiene que ser inteligente porque los falsos negativos filtran datos reales a un LLM remoto y los falsos positivos arruinan la conversación. Los nombres deben ser redactados; los pronombres no. El correo electrónico del médico en un hilo reenviado debe ser redactado; el pie de página de [email protected] probablemente no.
Tiene que ser rápido porque se interpone directamente en cada mensaje que el usuario envía o recibe. Medimos la sobrecarga del viaje de ida y vuelta en menos de 200 ms en un solo hilo de CPU, principalmente en la tokenización. En WebGPU y en el Neural Engine de Apple es minúsculo en comparación con la latencia de red de la propia llamada al LLM.
Tiene que ejecutarse en múltiples entornos porque Caiioo es multiplataforma. El mismo sistema funciona en extensiones de Chrome, macOS e iOS, Android, y en Windows y Linux. Un modelo de detección, una biblioteca de regex, un fusionador, una política: comportamiento idéntico en cada superficie donde se ejecuta Caiioo.
Los resultados
Tras varias rondas de pruebas y entrenamiento, nos decidimos por la versión 16 de nuestros modelos. A continuación se presentan tres evaluaciones comparativas (benchmarks), cada una de las cuales mide un aspecto diferente.
Nuestro propio conjunto de pruebas, 150 preguntas que el modelo nunca ha visto
Antes de realizar las pruebas con benchmarks públicos, ejecutamos nuestro filtro de Personal Data contra un conjunto de pruebas interno que mantuvimos deliberadamente fuera de los datos de entrenamiento; por lo tanto, el detector nunca ha visto ninguna de estas preguntas antes. 150 preguntas divididas en cuatro grupos (fragmentos de código, prosa de documentos, frases intencionadamente desconocidas y 10 idiomas distintos del inglés), además de un grupo "negativo" que no contiene ningún dato privado (una comprobación de coherencia para asegurar que no redactamos en exceso). Pipeline combinado de regex + ML:
| Sub-bench | Capturados | Tasa |
|---|---|---|
| code_bench | 69 / 74 | 93.2 % |
| doc_bench | 233 / 247 | 94.3 % |
| generalization_bench | 123 / 133 | 92.5 % |
| multilingual_bench | 200 / 216 | 92.6 % |
| Los 4 benches positivos | 625 / 670 | 93.3 % |
(El grupo negativo no tenía datos privados que encontrar. El filtro enmascaró un elemento que no debería haber enmascarado, lo cual es consistente con las cifras de precisión que se detallan más adelante).
El evaluador es estricto: cada dato privado esperado debe desaparecer por completo de la salida enmascarada para que la pregunta puntúe. No hay crédito parcial ni "suficientemente cerca". Esto es más riguroso que los benchmarks que piden a otro LLM que sea el juez (los jueces LLM tienden a ser generosos). Para ver cifras directamente comparables con otros sistemas, consulte la sección de comparativa directa más abajo.
PrivacyBenchHIPAA — 40 preguntas de atención médica
Cada pregunta enumera información de salud protegida que debe ser redactada (nombres, números de historial médico, etc.) Y señales que deben mantenerse (fechas, geografía, edad si es menor de 90 años — la regla del Limited Data Set de HIPAA). El evaluador comprueba ambas direcciones: ¿eliminamos lo que debíamos eliminar y dejamos intacto lo que debíamos dejar intacto?
| Modo | PHI redactado | Retenidos mantenidos |
|---|---|---|
| Limited Data Set (preservar fechas / geografía / edad ≤89) | 79 / 79 (100 %) | 34 / 34 |
| Safe Harbor (redactar todo, incluidas las fechas) | 99 / 104 (95.2 %) | — |
El submodo Limited Data Set es perfecto en este benchmark. Safe Harbor —que tiene más elementos que redactar y, por tanto, más oportunidades de error— cubre el 95.2%.
Resultados categoría por categoría en nuestros propios datos, 200 muestras por modo
Los benchmarks públicos agrupan todo. Nuestros datos de prueba internos desglosan los resultados por categoría (nombres, correos electrónicos, direcciones, etc.) y ejecutan cada una de tres maneras: solo regex, solo ML y ambos juntos. Eso nos indica exactamente qué tecnología está capturando qué tipo de identificador, y dónde cada una necesita de la otra. Ejecución más reciente, 2026-05-20:
Resumen de los tres modos de filtro
| Modo | Recall combinado | Precisión | F2 | Muestras |
|---|---|---|---|---|
| Personal Data filter | 97.3 % | 97.8 % | 97.4 | 200 |
| HIPAA filter — Limited Data Set | 92.3 % | 92.3 % | 92.3 | 200 |
| HIPAA filter — Safe Harbor | 91.9 % | 91.5 % | 91.8 | 200 |
Estas cifras excluyen las URLs, que dejamos intactas deliberadamente; eliminar una URL rompería acciones posteriores como "abrir este enlace" o "recuperar esa página". Más sobre esto en la sección de flujo de trabajo a continuación.
La visión general antes de las tablas por categoría: en todos los modos, los identificadores que realmente identifican a una persona se capturan el 100% de las veces o cerca de ello. Nombres, correos electrónicos, números de teléfono, direcciones postales, identificaciones gubernamentales, identificaciones biométricas, geolocalización precisa, números de historial médico, fechas de nacimiento, números de seguro social: capturados en cada muestra, en cada prueba. Las categorías en las que bajamos del 100% son predecibles: IDs de dispositivos (gran variedad de formatos en texto real), IDs institucionales misceláneos (números de fidelidad, IDs de empleados — mismo problema) y fotos (un filtro de solo texto no puede ver lo que hay dentro de una imagen). Ninguno de esos es el identificador de "nombre en un gráfico" o "correo electrónico en un borrador" que realmente importa para las filtraciones. Las categorías de alto riesgo son las fiables.
Personal Data filter
Ordenado por recall combinado (mejor primero), luego por nivel de riesgo (T1 = más sensible).
| Categoría | Nivel | Recall Regex | Recall ML (bruto) | Recall combinado | Gold n |
|---|---|---|---|---|---|
| biometric_id | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| email_address | T1 | 100.0 % (20/20) | 100.0 % (20/20) | 100.0 % | 20 |
| government_id | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| person_name | T1 | 13.3 % (4/30) | 96.7 % (29/30) | 100.0 % | 30 |
| phone_or_fax | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| postal_address | T1 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| precise_geolocation | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| birth_date | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| ip_address | T2 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| online_handle | T2 | 40.0 % (4/10) | 100.0 % (10/10) | 100.0 % | 10 |
| vehicle_id | T2 | 50.0 % (5/10) | 100.0 % (10/10) | 100.0 % | 10 |
| authentication_secret | T4 | 40.0 % (4/10) | 100.0 % (10/10) | 100.0 % | 10 |
| financial_account | T1 | 90.0 % (18/20) | 100.0 % (20/20) | 90.0 % | 20 |
| institutional_id | T3 | 80.0 % (8/10) | 90.0 % (9/10) | 90.0 % | 10 |
| device_id | T3 | 40.0 % (4/10) | 50.0 % (5/10) | 80.0 % | 10 |
Al analizar los datos, el diseño de dos capas está dando sus frutos. Las direcciones postales, las fechas de nacimiento y los nombres de personas obtienen una puntuación de 0–13% solo con regex —no hay un patrón que coincida, por lo que solo el modelo de ML puede capturarlos—. Los correos electrónicos, números de teléfono, IPs, identificaciones gubernamentales, identificaciones biométricas y geolocalización precisa obtienen un 100% solo con regex —formatos superficiales que el modelo de ML obtiene de forma inherente—. Los nombres de usuario en línea, IDs de vehículos y secretos de autenticación son mixtos: regex captura las formas estándar, ML captura el resto. El recall combinado iguala o supera a cualquiera de las capas individuales por separado, en cada categoría.
Los IDs de dispositivos y los IDs institucionales misceláneos son las categorías por debajo del 100%, y sabemos por qué: tienen la mayor variedad de formatos en el texto real. Preferimos ser honestos sobre las categorías donde el recall disminuye que fingir que el filtro es perfecto en todas partes.
HIPAA filter — submodo Limited Data Set
El submodo Limited Data Set preserva fechas, geografía y edades de 89 años o menos por diseño —esas son las señales que HIPAA permite que una organización conserve para investigación clínica y operaciones legítimas—.
| Categoría | Nivel | Recall Regex | Recall ML (bruto) | Recall combinado | Gold n |
|---|---|---|---|---|---|
| biometric_id | T1 | 100.0 % (12/12) | 100.0 % (12/12) | 100.0 % | 12 |
| email_address | T1 | 100.0 % (13/13) | 100.0 % (13/13) | 100.0 % | 13 |
| medical_record_number | T1 | 100.0 % (26/26) | 100.0 % (26/26) | 100.0 % | 26 |
| person_name | T1 | 15.4 % (4/26) | 100.0 % (26/26) | 100.0 % | 26 |
| phone_or_fax | T1 | 100.0 % (13/13) | 100.0 % (13/13) | 100.0 % | 13 |
| social_security_number | T1 | 100.0 % (12/12) | 100.0 % (12/12) | 100.0 % | 12 |
| account_number | T2 | 0.0 % (0/13) | 100.0 % (13/13) | 100.0 % | 13 |
| health_plan_id | T2 | 0.0 % (0/13) | 100.0 % (13/13) | 100.0 % | 13 |
| ip_address | T2 | 100.0 % (12/12) | 100.0 % (12/12) | 100.0 % | 12 |
| license_number | T2 | 0.0 % (0/12) | 100.0 % (12/12) | 100.0 % | 12 |
| vehicle_id | T2 | 25.0 % (3/12) | 100.0 % (12/12) | 100.0 % | 12 |
| device_id | T3 | 41.7 % (5/12) | 100.0 % (12/12) | 100.0 % | 12 |
| photo | T2 | 0.0 % (0/12) | 0.0 % (0/12) | 0.0 % | 12 |
Las fotos son un fallo conocido: un filtro de solo texto no puede ver lo que hay dentro de una imagen. El PHI en imágenes es un problema aparte que aún no hemos lanzado. Todas las demás categorías en este modo están al 100%.
HIPAA filter — submodo Safe Harbor
Safe Harbor elimina todo lo que el submodo Limited Data Set habría conservado: fechas, edades superiores a 89 años, geografía. Para obtener la cobertura más estricta, ejecuta ambos modelos de filtro en paralelo: el específico de HIPAA y el general de datos personales.
| Categoría | Nivel | Recall Regex | Recall ML (bruto) | Recall combinado | Gold n |
|---|---|---|---|---|---|
| age_over_89 | T1 | 100.0 % (18/18) | 0.0 % (0/18) | 100.0 % | 18 |
| biometric_id | T1 | 100.0 % (9/9) | 100.0 % (9/9) | 100.0 % | 9 |
| email_address | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| medical_record_number | T1 | 100.0 % (20/20) | 100.0 % (20/20) | 100.0 % | 20 |
| person_name | T1 | 20.0 % (4/20) | 100.0 % (20/20) | 100.0 % | 20 |
| phone_or_fax | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| social_security_number | T1 | 90.0 % (9/10) | 100.0 % (10/10) | 100.0 % | 10 |
| account_number | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| general_date | T2 | 100.0 % (27/27) | 29.6 % (8/27) | 100.0 % | 27 |
| health_plan_id | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| ip_address | T2 | 100.0 % (9/9) | 100.0 % (9/9) | 100.0 % | 9 |
| license_number | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| vehicle_id | T2 | 10.0 % (1/10) | 100.0 % (10/10) | 100.0 % | 10 |
| device_id | T3 | 22.2 % (2/9) | 88.9 % (8/9) | 77.8 % | 9 |
| photo | T2 | 0.0 % (0/9) | 0.0 % (0/9) | 0.0 % | 9 |
Las dos filas interesantes son las fechas generales (regex 100%, ML 30%) y las edades superiores a 89 años (regex 100%, ML 0%). Dejamos deliberadamente que regex maneje ambas en Safe Harbor: las fechas tienen un patrón que regex captura siempre, y no queremos que un modelo probabilístico cuestione un umbral numérico como ">89". Una regla determinante es más fiable que pedirle al modelo de ML que aprenda la misma regla.
Cifras globales en todas las categorías
Sumándolo todo: ¿cómo se compara el pipeline completo (regex + ML juntos) con cualquiera de las capas por separado?
| Modo | Capas | Recall | Precisión | F2 |
|---|---|---|---|---|
| Personal Data | solo regex | 65.8 % | 93.0 % | 69.9 % |
| Personal Data | solo ML | 95.4 % | 92.4 % | 94.8 % |
| Personal Data | ambas (full) | 96.9 % | 98.0 % | 97.1 % |
| Limited Data Set | solo regex | 55.9 % | 95.0 % | 60.9 % |
| Limited Data Set | solo ML | 92.9 % | 84.5 % | 91.0 % |
| Limited Data Set | ambas (full) | 92.9 % | 89.3 % | 92.1 % |
| Safe Harbor | solo regex | 58.9 % | 93.6 % | 63.6 % |
| Safe Harbor | solo ML | 82.4 % | 88.3 % | 83.5 % |
| Safe Harbor | ambas (full) | 92.4 % | 88.9 % | 91.7 % |
La fila "full" del filtro Personal Data supera a ambas versiones de una sola capa en todas las métricas; combinar regex (para formatos superficiales) con el modelo de ML (para el contexto) proporciona genuinamente algo que ninguna capa por sí sola puede ofrecer. El titular del 97.3% al principio de este post es la cifra que refleja lo que obtiene un usuario real. El número en la tabla anterior es un poco más bajo solo porque incluye la categoría URL, que preservamos deliberadamente para no romper enlaces y llamadas a herramientas.
Comparativa directa con otros filtros de privacidad dedicados
La comparación justa para un filtro de privacidad en el dispositivo y casi instantáneo como el nuestro es contra otros filtros de privacidad en el dispositivo y casi instantáneos, no contra LLMs gigantes alojados en la nube que tardan segundos por mensaje y necesitan un viaje de ida y vuelta por la red. Ejecutamos todos los sistemas de esta clase contra los mismos conjuntos de pruebas, utilizando las mismas reglas de coincidencia. El mismo estándar para todos.
La clase de pares:
- openai/privacy-filter: el filtro de privacidad dedicado de código abierto de OpenAI. Unos 50 millones de parámetros, lo suficientemente pequeño como para ejecutarse en cualquier navegador moderno.
- piiranha-v1: un detector de 278 millones de parámetros de iiiorg. Su licencia lo restringe solo a investigación y evaluación (podemos medirlo, pero no se puede comercializar).
- Microsoft Presidio: el redactor de código abierto más desplegado, que combina la coincidencia de patrones tradicional con un pequeño modelo de lenguaje para el contexto.
- Familia GLiNER PII: una familia de clasificadores de entidades de propósito general y tamaño reducido. Knowledgator ofrece las variantes small (~44M), base (~86M) y large (~304M); NVIDIA lanzó una variante de 570M en octubre de 2025.
- Caiioo en los tres modos (Personal Data, HIPAA Limited Data Set, HIPAA Safe Harbor).
Recall en los cinco conjuntos de pruebas, ordenados con Caiioo primero:
| Sistema | PrivacyBench PD-25 | Caiioo sintético PD-200 | PrivacyBenchHIPAA-40 | Caiioo sintético PHI-200 | Multilingüe PD-40 (10 locales) |
|---|---|---|---|---|---|
| Caiioo — Personal Data | 96.2 % (76/79) | 99.0 % (198/200) | — | — | 92.6 % (200/216) |
| Caiioo — HIPAA Limited Data Set | — | — | 100.0 % (79/79) | 100.0 % (200/200) | — |
| Caiioo — HIPAA Safe Harbor | — | — | 100.0 % (79/79) | 100.0 % (200/200) | — |
| openai/privacy-filter (50M) | 96.2 % (76/79) | 83.0 % (166/200) | 93.7 % (74/79) | 77.0 % (154/200) | 94.9 % (205/216) |
| gliner_pii_nvidia (570M) | 94.9 % (75/79) | 85.5 % (171/200) | 84.8 % (67/79) | 85.0 % (170/200) | 76.9 % (166/216) |
| gliner_pii_large (~304M) | 72.2 % (57/79) | 86.5 % (173/200) | 84.8 % (67/79) | 93.0 % (186/200) | 50.0 % (108/216) |
| gliner_pii_base (~86M) | 87.3 % (69/79) | 66.0 % (132/200) | 74.7 % (59/79) | 66.0 % (132/200) | 51.4 % (111/216) |
| gliner_pii_small (~44M) | 88.6 % (70/79) | 84.5 % (169/200) | 91.1 % (72/79) | 83.0 % (166/200) | 68.5 % (148/216) |
| Microsoft Presidio | 82.3 % (65/79) | 76.5 % (153/200) | 84.8 % (67/79) | 76.5 % (153/200) | 69.0 % (149/216) |
| piiranha-v1 (~278M) | 60.8 % (48/79) | 58.5 % (117/200) | 43.0 % (34/79) | 47.0 % (94/200) | 82.4 % (178/216) |
Caiioo lidera la clase de filtros dedicados en las dos pruebas más grandes (PD-200 y PHI-200), empata o lidera en los benchmarks públicos y es segundo en multilingüe. En la prueba más pequeña (PrivacyBench PD-25, solo 25 preguntas), Caiioo y openai/privacy-filter empatan con un 96.2%. En multilingüe, openai/privacy-filter sigue liderando con un 94.9%, con Caiioo en un 92.6%; el idioma en el que más nos quedamos atrás es el chino; en todos los demás estamos en la cima o cerca de ella. Si la cobertura multilingüe es de misión crítica, openai/privacy-filter es una alternativa razonable. Para la mayoría de las demás cargas de trabajo en esta clase, Caiioo lo es.
El resultado de HIPAA es el titular. Ambos modos HIPAA de Caiioo alcanzaron un 100% de recall en cada prueba de HIPAA: se capturaron todos los nombres de pacientes, todos los números de historial médico, todas las fechas de nacimiento y todos los números de cuenta. El segundo mejor sistema es openai/privacy-filter con un 93.7% en PrivacyBenchHIPAA, una brecha de 6.3 puntos en un benchmark donde cada fallo es una divulgación en el mundo real.
Una segunda cifra que vale la pena leer: sobrerredacción, es decir, enmascarar cosas que en realidad no eran datos privados. La sobrerredacción no es un daño a la privacidad, es un coste de usabilidad. Si se enmascaran demasiadas cosas, el razonamiento del LLM empeora y la respuesta devuelta se degrada. Caiioo enmascara innecesariamente entre 1 y 24 veces en los conjuntos de pruebas. Presidio: 10–51. GLiNER de NVIDIA: 31–64 solo en las pruebas de HIPAA. La precisión importa tanto como el recall cuando el objetivo es la mejor respuesta posible con la menor exposición posible.
¿Qué tal si usamos simplemente un LLM de frontera como filtro?
Pueden hacerlo y, en recall bruto, ganan. Los grandes LLMs de propósito general (Llama 3.1 8B, Gemma 4, Qwen 3.5 9B y similares), que se ejecutan en la nube o localmente, pueden puntuar entre el 95 y el 100% en todas las pruebas, incluida la multilingüe. Esa es una opción real para los usuarios que necesitan el máximo recall y están dispuestos a pagar por ello.
Sin embargo, los inconvenientes son reales:
- Es lento. Segundos por mensaje en lugar de milisegundos. El filtro se sitúa delante de cada mensaje que envía el usuario.
- O el mensaje sale de la máquina del usuario, o el modelo lo hace. Para filtrar en la nube, el mensaje tiene que subir allí, lo que anula el propósito. Para filtrar en el dispositivo es necesario descargar un modelo de entre 1 y 17 GB.
- Se puede engañar. A un modelo generativo se le puede convencer, a mitad del mensaje, para que no redacte (un ataque de "prompt injection"). A un pequeño clasificador como el nuestro, no.
- Misma entrada, diferente salida. Los modelos generativos no siempre dan la misma respuesta dos veces. Eso rompe el viaje de ida y vuelta: el enmascaramiento al salir y el desenmascaramiento al volver dependen de que el mismo valor real siempre se asocie al mismo valor falso.
Caiioo está diseñado para el otro lado de esa balanza: un filtro diminuto, predecible y de menos de un segundo que se ejecuta en el editor antes de que el usuario pulse enviar, y que siempre produce el mismo falso para el mismo valor real dentro de una conversación, para que el viaje de ida y vuelta sea coherente. La tabla de la clase de pares anterior es la comparación equitativa para ese tipo de caso de uso.
La prueba de fuego
Los bancos de pruebas son un punto de partida, no la meta final. El filtro está integrado en la nueva función de Caiioo: pseudonymizer — el componente que realmente se sitúa entre el compositor y el modelo.
Esto es lo que sucede cuando el usuario pulsa enviar.
- Detectar. La capa de regex se ejecuta primero — es determinista y rápida en microsegundos. El modelo de ML se ejecuta a continuación sobre lo que queda. Si las dos capas se solapan en el mismo fragmento de texto, utilizamos una regla sencilla: regex gana en formatos superficiales, ML gana en contexto.
- Etiquetar propio vs. ajeno. Caiioo separa los identificadores que se refieren a el usuario de los identificadores que se refieren a otras personas. El usuario puede elegir redactar solo uno, o ambos. Los nombres que el usuario ha añadido a un diccionario personal siempre cuentan como "propio".
- Sustituir. Cada valor real recibe un seudónimo estable y adaptado al estilo. "Sarah Goldberg" se convierte en "Maya Hartwell" — y se mantiene como "Maya Hartwell" durante toda la conversación, para que el razonamiento del modelo sobre esa persona no se fragmente entre turnos. Una tabla de búsqueda de real-a-falso se guarda en el dispositivo del usuario, cifrada con una clave del llavero de la plataforma.
- Enviar. El modelo recibe un mensaje completamente falso. Ningún identificador real cruza jamás la red, y nuestro registro de auditoría solo registra recuentos — nunca los valores en sí mismos.
- Restaurar. La respuesta en streaming se reasigna a medida que llega. "Maya Hartwell" en la respuesta del modelo vuelve a ser "Sarah Goldberg" antes de llegar a la pantalla, renderizada con una pequeña pastilla brillante para que el usuario pueda ver de un vistazo qué fue protegido.
- Restaurar también los argumentos de las herramientas. Si el modelo llama a una herramienta — enviar un correo electrónico, registrar un ticket, escribir en un documento — y los argumentos contienen datos falsos, sustituimos los valores reales de nuevo antes de que la herramienta se ejecute. El modelo razona sobre los datos falsos; la acción toma el valor real.
Al filtro no le importa qué servicio de AI esté en uso. Se ejecuta antes de que el mensaje llegue al modelo, por lo que OpenRouter, Anthropic, Google, OpenAI y un Ollama local reciben todos la misma carga útil enmascarada. Añadir un nuevo proveedor no vuelve a abrir el agujero de privacidad.
A quién protege
Al usuario. El nombre, correo electrónico, dirección, teléfono, IP e identificadores biométricos del usuario (las cosas que, en conjunto, identifican a una persona ante un agregador) nunca salen del dispositivo cuando el filtro está activado.
A las personas de las que habla el usuario. La mayoría de las herramientas de privacidad se centran en la persona que escribe, pero ignoran el "contrato social": el hecho de que todos tenemos una responsabilidad hacia los demás tanto como hacia nosotros mismos. Enviar "Por favor, analice la conducta del Sr. Saunders por incompetencia" a un LLM, donde puede quedar registrado en los registros del sistema indefinidamente, es irresponsable (y potencialmente difamatorio). Pedir ayuda a un LLM con una hoja de cálculo de Google que contiene 1,000 contactos comerciales deposita a todos ellos en la red de retención de datos (en diversos grados, dependiendo de la "retención de datos cero" real vigente). El filtro de Caiioo también cubre a terceros: el cliente para el que se redacta un contrato, el paciente cuyo registro se está analizando, el colega cuyo correo electrónico se pegó en el contexto. Ellos no consintieron que un LLM remoto viera sus identificadores. El filtro respeta eso por defecto; el usuario puede cambiar a "solo yo" o "solo otros" si un flujo de trabajo lo requiere.
A las entidades: empresas, hospitales, firmas. Números de cuenta, números de licencia, números de registro médico, detalles de rutas financieras, IDs internos, claves API, listas de clientes. Una empresa tiene el mismo interés en la minimización de datos que una persona. Un médico que usa Caiioo para redactar una nota de alta no está enviando el número de registro médico del paciente a OpenAI. Un abogado no está enviando el número de cuenta del cliente a Anthropic. Un ingeniero de soporte no está enviando la clave API del registro del cliente a Google. El filtro no pregunta si el identificador pertenece a una persona o a una entidad; simplemente lo mantiene en el dispositivo.
Máxima utilidad, mínima exposición
El objetivo principal es que el usuario no sienta el filtro.
La mayoría de las herramientas de privacidad obligan a elegir: redactar agresivamente y ver cómo empeora la respuesta del modelo, o mantener la instrucción utilizable y ver cómo se erosiona la promesa de privacidad. Rechazamos ese compromiso. El modelo sigue recibiendo una instrucción completa: ve un nombre, un lugar, una fecha, un número de registro médico, todo en las posiciones gramaticales correctas. Solo que ve datos falsos. Su razonamiento es idéntico; solo se limpian las cadenas de texto.
La sustitución estable es lo que hace que esto funcione. Debido a que el mismo valor real siempre se asigna al mismo valor falso dentro de una conversación (en el mensaje del usuario, en el resultado de la herramienta que referencia ese nombre, en la respuesta anterior del modelo que lo mencionó), el modelo tiene una persona, lugar o cosa coherente sobre la cual razonar. Las conversaciones de varios turnos no se desordenan. Las llamadas a herramientas no se rompen. Los subagentes heredan el mapa de la conversación principal y mantienen la coherencia en toda la tarea.
El resultado que ve el usuario es la conversación real. Los datos que ve el proveedor son una ficción coherente. El trabajo ocurre en el espacio entre esas dos vistas, y el objetivo (el único objetivo) es hacer que ese espacio sea invisible.
Un filtro de privacidad que estorba terminará siendo desactivado. Un filtro de privacidad que desaparece en el flujo de trabajo es el único que vale la pena lanzar.
Ese es el estándar bajo el cual construimos.