Presentación de OpenAI Privacy Filter

• Es un modelo de pesos abiertos para detectar y enmascarar información de identificación personal en texto no estructurado, y al ejecutarse localmente permite que los datos no salgan del dispositivo antes del filtrado
• Combina clasificación bidireccional de tokens con span decoding para etiquetar la entrada completa de una sola vez, y está diseñado para reconstruir rápidamente spans de PII en contextos de hasta 128,000 tokens
• A diferencia de los métodos basados en reglas que dependen de formatos como números telefónicos o correos electrónicos, distingue mejor entre información pública y datos que deben enmascararse gracias a su comprensión del lenguaje y del contexto
• Se entrenó con una combinación de datos públicos y sintéticos, logró F1 de 96% en PII-Masking-300k y F1 de 97.43% en una versión corregida, y con pocos datos elevó el desempeño de adaptación de dominio de 54% a 96%
• No sustituye herramientas de anonimización ni certificaciones de cumplimiento, y en áreas altamente sensibles siguen siendo importantes la revisión humana, la evaluación por dominio y el ajuste fino adicional

---

Descripción del producto y forma de distribución

• Es un modelo de pesos abiertos especializado en la detección y ocultamiento de información de identificación personal, capaz de encontrar PII en texto para enmascararla o eliminarla
• Admite ejecución local, por lo que los datos pueden permanecer en el dispositivo antes del filtrado, reduciendo el riesgo de exposición frente a enviarlos a un servidor para desidentificarlos
• Está diseñado para procesar entradas largas con rapidez, y puede decidir qué debe ocultarse en una sola pasada
• Los desarrolladores pueden ejecutarlo en su propio entorno y ajustarlo para sus casos de uso, incorporando una protección de privacidad más fuerte en pipelines de entrenamiento, indexación, logging y revisión
• Se publicó en Hugging Face y GitHub bajo licencia Apache 2.0, pensando en experimentación, personalización e incluso despliegue comercial

En qué se diferencia de los métodos existentes

• Las herramientas tradicionales de detección de PII suelen depender de reglas determinísticas sobre formatos como números telefónicos o direcciones de correo electrónico
• Ese enfoque puede funcionar bien en casos acotados, pero tiende a pasar por alto información personal más sutil y maneja mal el contexto
• Privacy Filter puede detectar un rango más amplio de PII en texto no estructurado gracias a una comprensión más profunda del lenguaje y el contexto
• Está diseñado para distinguir mejor entre la información pública que debe conservarse y la información vinculada a una persona que debe enmascararse o eliminarse
• Fue desarrollado con el objetivo de elevar el estándar de privacidad más allá de lo existente, y ya se usan versiones ajustadas dentro de flujos internos de preservación de privacidad

Arquitectura del modelo y alcance de detección

• Usa una arquitectura que combina un modelo bidireccional de clasificación de tokens con span decoding
• Parte de un checkpoint preentrenado autorregresivo y luego se adapta como clasificador de tokens sobre un esquema fijo de etiquetas de privacidad
• En vez de generar el texto token por token, etiqueta toda la secuencia de entrada de una sola vez y luego reconstruye spans consistentes con un procedimiento Viterbi restringido
• Gracias a esta arquitectura, ofrece un comportamiento de alta velocidad y eficiencia al etiquetar todos los tokens en un solo forward pass
• Puede usar el contexto circundante para identificar spans de PII, y el modelo publicado admite contextos de hasta 128,000 tokens
• Es posible ajustar el equilibrio entre recall y precisión según el entorno operativo
• El modelo publicado tiene 1.5 mil millones de parámetros en total, de los cuales 50M están activos
• Las categorías de predicción son 8: private_person, private_address, private_email, private_phone, private_url, private_date, account_number, secret
• account_number se usa para ocultar distintos números de cuenta, incluidos números de tarjeta de crédito y cuentas bancarias, mientras que secret cubre elementos como contraseñas y claves API
• Las etiquetas se decodifican con marcas de span BIOES, lo que produce límites de enmascaramiento más limpios y consistentes

Proceso de entrenamiento y resultados de evaluación

• Primero se creó una taxonomía de privacidad para definir los tipos de spans que el modelo debía detectar
  • Incluye identificadores personales, información de contacto, direcciones, fechas privadas, varios números de cuenta como información crediticia o bancaria, y secretos como claves API y contraseñas
• Después de reemplazar el language modeling head del modelo de lenguaje preentrenado por un token-classification head, se realizó entrenamiento posterior con un objetivo de clasificación supervisada
• Se entrenó con una mezcla de datos públicos y sintéticos para capturar tanto texto realista como patrones complejos de privacidad
  • En los datos públicos, las partes con etiquetas incompletas se cubrieron con anotación asistida por el modelo y revisión para mejorar la cobertura
  • Los ejemplos sintéticos se usaron para ampliar la diversidad de formatos, contextos y subtipos de privacidad
• Durante la inferencia, las predicciones a nivel de token se convierten en spans consistentes mediante decodificación de secuencia restringida
• Se realizaron tanto benchmarks estándar como evaluaciones sintéticas y de estilo conversacional enfocadas en casos más difíciles y sensibles al contexto
• En PII-Masking-300k registró F1 de 96%, precisión de 94.04% y recall de 98.04%
• En una versión corregida que refleja problemas de anotación del dataset detectados durante la revisión, registró F1 de 97.43%, precisión de 96.79% y recall de 98.08%
• Incluso con pocos datos, la adaptación de dominio se logró rápidamente, y en el benchmark de adaptación evaluado el F1 subió de 54% a 96%
• La model card también incluye pruebas de estrés para detección de secretos en bases de código y ejemplos multilingües, adversariales y dependientes del contexto

Limitaciones y consideraciones de uso

• No es una herramienta de anonimización, tampoco una certificación de cumplimiento, ni reemplaza la revisión de políticas en entornos de alto riesgo
• Es un componente dentro de un sistema más amplio diseñado con la privacidad como eje
• Su comportamiento está influido por la taxonomía de etiquetas usada en el entrenamiento y por los umbrales de decisión
• Como cada organización puede querer políticas distintas de detección y enmascaramiento, puede requerirse evaluación en el dominio o ajuste fino adicional
• El rendimiento puede variar en idiomas, sistemas de escritura, convenciones de nombres y dominios distintos de la distribución de entrenamiento
• Puede pasar por alto identificadores poco frecuentes o referencias personales ambiguas, y especialmente cuando el contexto es limitado, como en secuencias cortas, puede ocultar demasiado o demasiado poco
• En áreas altamente sensibles como lo legal, médico o financiero, siguen siendo importantes la revisión humana, la evaluación por dominio y el ajuste fino

Intención de publicación y dirección futura

• La protección de la privacidad se aborda como un reto continuo que atraviesa investigación, diseño de producto, evaluación y despliegue
• Refleja la importancia de modelos pequeños y eficientes que pueden ofrecer desempeño de nivel frontier en tareas reales definidas de forma acotada
• Se publica con el objetivo de que la infraestructura de preservación de privacidad sea más fácil de auditar, ejecutar, adaptar y mejorar
• Se plantea como una herramienta para ayudar a que los modelos aprendan sobre el mundo sin aprender información privada de las personas
• Esta publicación preliminar también es una etapa para recoger retroalimentación de la comunidad de investigación y privacidad y seguir mejorando el rendimiento

[GN⁺]

Comentarios en Hacker News

• Este tipo de función ya la implementé hace varios años, y el resultado dejó claras varias cosas
  La depuración de PII necesita revertirse en el cliente para mantener la UX. Por ejemplo, si el nombre es John pero queda oculto como [NAME], y el modelo responde Hi [NAME], antes de mostrarlo al usuario hay que restaurarlo a Hi John
  Al final, la capa con la que interactúa el usuario necesita un mecanismo de sustitución inversa
  Además, los datos de PII ocultos casi no sirven para la mayoría de los usos. El modelo necesita hasta cierto punto datos reales para funcionar, pero como hay muchísimos elementos que se clasifican como PII, un chat simple puede estar bien, pero cuando el usuario necesita interactuar de forma compleja con el LLM, la dificultad sube muchísimo. Incluso puede que no logre hacer nada o que aparezcan hallucinations
  Por eso, aunque se ofrece a nivel de plataforma, en la práctica no se usa mucho por estas limitaciones
  Me parece que el enfoque realista es quitar solo cierta PII de alto riesgo de seguridad y usar un modelo confiable que descarte la PII lo antes posible. Para eso, también hay que cambiar bastante el diseño del sistema
• Estoy haciendo https://github.com/KevinXuxuxu/anon_proxy, una especie de proxy de anonimización que se coloca delante del proveedor de LLM
  Usa detección basada en modelos junto con regex PII detection, y maneja sustitución y restauración en ambas direcciones tanto en las solicitudes como en las respuestas de la API. Si alojas el modelo de detección localmente, la PII no sale del entorno local
  Fue especialmente útil al tratar documentos sensibles como temas legales, fiscales o migratorios
  • Lo bueno de este enfoque es que se puede conectar con cualquier modelo
    Aun así, el contexto completo de la conversación sigue siendo visible para el modelo y el operador
    Por eso me gusta más un enfoque como el de Moxie Confer https://confer.to/, que cifra todo para que nadie salvo el usuario final pueda ver el texto en claro
  • Me da curiosidad cómo manejan la restauración del lado de la respuesta
    Si ocultaste un documento en la entrada, la salida del LLM también contendrá ese contenido oculto, así que no me queda claro cómo sigue el flujo después de eso
• En este lanzamiento hay varias partes técnicamente interesantes
  Privacy Filter tiene la forma de un token-classification model bidireccional con decodificación de spans, y dicen que parte de un checkpoint preentrenado autoregresivo adaptado como clasificador de tokens sobre una taxonomía fija de etiquetas de privacidad
  En vez de generar texto token por token, etiqueta toda la secuencia de entrada de una sola vez y decodifica spans consistentes mediante un procedimiento de Viterbi con restricciones
  Dicen que el modelo publicado tiene 1.5B parámetros en total y 50M de parámetros activos
  También explican que lo construyeron reemplazando el LM head del modelo de lenguaje preentrenado por un token-classification head, y luego afinándolo con un objetivo de clasificación supervisada
  • Entonces parece que esto también podría servir para encontrar la ubicación de datos sensibles en texto no estructurado sin depender de otras herramientas de detección de PII
    Si pasas el texto original por el filtro para obtener los spans y luego vuelves a mapear esos spans al original, al final consigues toda la información de ubicación de la PII
• No es tan inteligente como OpenAI, pero hice https://tools.nicklothian.com/webner/index.html, que oculta parte de la PII en el navegador usando NER basado en BERT
  En los usos que probé funcionó bastante bien
  El modelo de OpenAI se ve lo bastante pequeño como para que estoy pensando en integrarlo también en mi herramienta
  • Acabo de probarlo en un documento y parece bastante difícil de usar por la cantidad de false positives
    Le metí un documento markdown de unas 100 líneas, y tomó matter como si fuera una organización por ser parte de frontmatter, end también como organización por ser parte de frontend, y MCP igual lo clasificó como organización
    Hubo muchos resultados gramaticalmente absurdos, como Following the discussion in , blahblah
    Se siente exactamente como volver al NLP de hace 10 años, y eso me hizo recordar otra vez lo gran proyecto que fue spaCy en ese campo
• Hay que dejar claro que casi todos los modelos de este tipo son ingenuos y básicos
  Si solo tienes un mensaje aislado y neutro como Hi, this is Bob., normalmente será suficiente, pero una vez que los datos empiezan a acumularse, todavía no he visto una herramienta de redacción de PII que realmente contemple todo el riesgo de filtración de identidad
  Y en el momento en que las empresas usan esto y creen que sus datos ya quedaron anonimizados, el problema se vuelve grande. Eso no es anonimización
  Aun así, este tipo de filtrado puede ser bastante útil en etapas intermedias de procesamiento como moderation, human eval o model training, cuando los datos no se van a publicar ni compartir de inmediato
• Me da un poco de pena que la mayoría de los ejemplos sean cosas que también se pueden detectar fácilmente con regex, pero me alegra que haya salido como modelo local abierto
  • Con mis clientes uso expresiones regulares para evitar que correos personales o números de teléfono se publiquen en sitios web
    Aun así, parece razonable correr también un modelo de este tipo para tener una capa extra de tranquilidad
    No tengo GPU en el servidor, pero ojalá sea un modelo lo bastante liviano como para que con menos de 2k tokens por vez se pueda manejar incluso con CPU-only inference
• Al hacer clic en el enlace te redirige a una versión traducida automáticamente del sitio de OpenAI, y el sentido queda completamente arruinado
  Tradujeron redacted usando el polaco redagować, pero eso se acerca más a editar o pulir un texto que a anonimizarlo
• Me pregunto cómo se comparará esto con Presidio, que mezcla regex y modelos: https://microsoft.github.io/presidio/
  • Capaz incluso se podría meter este modelo dentro de Presidio
• Creo que https://peyeeye.ai resuelve literalmente todo de lo que todos están hablando en este hilo
  • Una empresa que raspó datos ajenos sin permiso haciendo ahora una herramienta de privacidad; la ironía es enorme
• Me alegra esta publicación
  Incluso fuera de industrias reguladas, hay muchas razones para tener este tipo de modelos y prácticas, y en teoría parte de esto también se vuelve necesario por la EU AI Act
  En https://grepture.com ya tengo integrados redaction y rehydration con un modelo NER especializado, así que pienso añadir esto también al pipeline
  Si se pone opcionalmente en el hot path y permite tocar de verdad lo que entra y sale antes y después de que la solicitud llegue al LLM, puede ser bastante útil en escenarios de compliance o cuando recibes entrada directa de usuarios