Introducción a OpenAI Privacy Filter

• Es un modelo de pesos abiertos que realiza detección y ocultamiento de información de identificación personal en texto no estructurado, y puede ejecutarse localmente para que los datos no salgan del dispositivo antes del filtrado
• Combina clasificación bidireccional de tokens con span decoding para etiquetar toda la entrada 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 de teléfono o correos electrónicos, distingue mejor entre información pública e información que debe enmascararse gracias a su comprensión de lenguaje y contexto
• Se entrenó con datos públicos y sintéticos, obtuvo F1 de 96% en PII-Masking-300k y F1 de 97.43% en una versión corregida, y su desempeño de adaptación de dominio subió de 54% a 96% incluso con pocos datos
• No es una herramienta de anonimización ni un sustituto de certificaciones de compliance, y en áreas de alta sensibilidad siguen siendo importantes la revisión humana, la evaluación por dominio y el ajuste fino adicional

---

Resumen del producto y forma de distribución

• Es un modelo de pesos abiertos especializado en 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, lo que permite que los datos no salgan del dispositivo antes del filtrado y reduce el riesgo de exposición frente a enviarlos a un servidor para desidentificación
• Está diseñado para procesar entradas largas con rapidez y puede decidir qué ocultar en una sola pasada
• Los desarrolladores pueden ejecutarlo en su propio entorno y ajustarlo a sus propios casos de uso para incorporar protecciones de privacidad más fuertes en pipelines de entrenamiento, indexación, logging y revisión
• Se publicó bajo licencia Apache 2.0 en Hugging Face y GitHub, pensando en experimentación, personalización y despliegue comercial

Qué lo diferencia de los enfoques existentes

• Las herramientas tradicionales de detección de PII suelen depender de reglas deterministas para formatos como números de teléfono o direcciones de correo electrónico
• Ese enfoque puede funcionar bien en escenarios acotados, pero tiende a pasar por alto datos personales más sutiles y tiene limitaciones para procesar el contexto
• Privacy Filter puede detectar una gama más amplia de PII en texto no estructurado gracias a una comprensión más profunda de lenguaje y contexto
• Está diseñado para distinguir mejor entre información pública que debe conservarse e 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á del nivel existente, y OpenAI también usa versiones ajustadas en workflows 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 de preentrenamiento autorregresivo y luego se adapta como clasificador de tokens sobre un esquema fijo de etiquetas de privacidad
• En lugar de generar el texto token por token, etiqueta toda la secuencia de entrada de una vez y luego reconstruye spans consistentes mediante un procedimiento Viterbi restringido
• Gracias a esta estructura, ofrece un comportamiento de alta velocidad y alta eficiencia, etiquetando todos los tokens en un solo forward pass
• Puede identificar spans de PII usando el contexto circundante, y el modelo publicado admite contextos de hasta 128,000 tokens
• Se puede ajustar el punto de equilibrio entre recall y precisión según el entorno operativo
• El modelo publicado tiene 1.5B parámetros en total, con 50M parámetros activos
• Las categorías de predicción son 8: private_person, private_address, private_email, private_phone, private_url, private_date, account_number y secret
• account_number se usa para ocultar varios tipos de 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 etiquetas de span BIOES para producir 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 datos de crédito y banca, y secretos como claves API y contraseñas
• Se reemplazó el language modeling head del modelo de lenguaje preentrenado por un token-classification head, y luego se continuó el entrenamiento con un objetivo de clasificación supervisada
• Se entrenó mezclando 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 ampliar la cobertura
  • Los ejemplos sintéticos se usaron para aumentar la diversidad de formatos, contextos y subtipos de privacidad
• En inferencia, las predicciones por token se convierten en spans consistentes mediante decodificación de secuencia restringida
• También se realizaron evaluaciones con benchmarks estándar y pruebas sintéticas y tipo chat 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 detectados durante la revisión del dataset, registró F1 de 97.43%, precisión de 96.79% y recall de 98.08%
• Incluso con pocos datos, la adaptación de dominio fue rápida, y en el benchmark evaluado el F1 subió de 54% a 96%
• La model card también incluye pruebas de estrés para detección de secretos en codebases y ejemplos multilingües, adversariales y dependientes del contexto

Limitaciones y precauciones de uso

• No es una herramienta de anonimización, ni una certificación de compliance, ni reemplaza la revisión de políticas en entornos de alto riesgo
• Se posiciona como un componente dentro de un sistema completo diseñado con foco en privacidad
• 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 ser necesaria evaluación dentro del 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 de más o de menos
• En áreas de alta sensibilidad como legal, salud o finanzas, 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 privacidad se aborda como un desafío continuo a lo largo de investigación, diseño de producto, evaluación y despliegue
• Refleja la importancia de modelos pequeños y eficientes que alcancen 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 presenta como una herramienta para ayudar a que los modelos aprendan sobre el mundo sin aprender información privada de las personas
• Esta publicación en preview también es un paso para recoger feedback 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