OpenAI Privacy Filter: El modelo PII de pesos abiertos que se ejecuta en su navegador (y su lugar en un agent stack)
El nuevo clasificador PII de pesos abiertos de OpenAI se ejecuta en su navegador y cubre la capa de governance que la mayoría de los agent stacks omiten. Así funciona el modelo, dónde encaja y qué cambia.
OpenAI acaba de publicar una herramienta, no un modelo. openai/privacy-filter es un clasificador bidireccional de tokens con 1.500 millones de parámetros, publicado bajo Apache 2.0, que se ejecuta en su navegador, detecta ocho categorías de información de identificación personal en un único forward pass y cubre la capa de governance que la mayoría de los agent stacks omiten.
Si usted lee las notas de la versión como otro lanzamiento de modelo, perderá la señal real.
Si hoy ejecuta agentes sobre datos de clientes, la redacción de PII probablemente sea una biblioteca de expresiones regulares que usted mantiene o una llamada a un LLM por la que preferiría no pagar. Este artículo explica qué es realmente openai/privacy-filter, las decisiones arquitectónicas que importan y dónde encaja en un agent governance stack real. También explicaremos por qué esta versión actualiza nuestra posición sobre los agentes que leen entradas no confiables, y qué hacer con ella si usted trabaja con cargas de trabajo reguladas.
Puntos clave
openai/privacy-filter es un clasificador entrenado para un propósito específico, no un LLM de uso general. 1.500 millones de parámetros totales, 50 millones activos mediante MoE routing, contexto de 128.000 tokens, licencia Apache 2.0.
La arquitectura deriva del linaje gpt-oss. El language-model head se reemplaza por un token-classification head de 33 clases con esquema BIOES. Se decodifica con Viterbi restringido para coherencia de span.
Se ejecuta en una pestaña del navegador mediante Transformers.js y WebGPU. Sin API round trip, sin egress de servidor, sin cuenta de OpenAI en tiempo de ejecución.
Detecta ocho categorías de PII: private_person, private_email, private_phone, private_address, private_url, private_date, account_number, secret.
No es anonimización. Prioriza el inglés con recall reducido en scripts no latinos. Taxonomía de etiquetas estática que requiere fine-tuning para ampliarse.
OpenAI publicó una herramienta, no un modelo. Esa es la noticia.
La mayoría de los medios lo reportarán como otro lanzamiento de OpenAI en Hugging Face. La señal arquitectónica es diferente. Se trata de un clasificador bidireccional post-entrenado a partir de un checkpoint autorregresivo con forma gpt-oss, con el language-model head sustituido por un token-classification head de 33 clases sobre ocho categorías de privacy span más una clase de fondo.
OpenAI no está publicando un modelo para conversar. Ha publicado una herramienta para filtrar entradas y salidas hacia otros modelos.
Eso importa porque el sector ha pasado tres años tratando los LLMs generativos como el primitivo por defecto para cada problema de texto, incluidos aquellos para los que los LLMs son inadecuados. La redacción de PII es un problema de clasificación. Ejecutar un modelo de propósito general con 70.000 millones de parámetros sobre cada solicitud entrante para pedirle que enmascare correos electrónicos es una solución costosa. Un clasificador de 1.500 millones de parámetros con 50 millones de parámetros MoE activos realiza el mismo trabajo en un único forward pass, se ejecuta en un portátil y no puede alucinar nuevos correos electrónicos.
La decisión de derivarlo de gpt-oss es la parte que menos se comenta. OpenAI está señalando que la familia gpt-oss no es un movimiento de relaciones públicas puntual. Se está convirtiendo en una base para modelos auxiliares de propósito específico que se espera que agencias y equipos de ingeniería ejecuten localmente. Habrá más de estos.
Si usted está evaluando un agent governance stack para una carga de trabajo regulada, webvise diseña stacks con compliance desde los cimientos.
La arquitectura, en lenguaje claro
Privacy Filter es un encoder stack pre-norm de ocho bloques con grouped-query attention (14 query heads, 2 KV heads, group size 7), rotary positional embeddings y un sparse MoE feed-forward block de 128 expertos con top-4 routing. El ancho del residual stream es 640. El total de parámetros asciende a 1.500 millones; los parámetros activos por token son 50 millones.
Utiliza banded attention con un band size de 128, lo que proporciona una ventana efectiva de 257 tokens. La longitud de contexto llega a 128.000 tokens, lo que elimina la necesidad de chunking para cargas de trabajo habituales con documentos largos.
El labeling head emite 33 logits por token: una etiqueta de fondo más ocho categorías de span expandidas en etiquetas BIOES (Begin, Inside, End, Single). La inferencia ejecuta un decodificador Viterbi restringido con linear-chain transition scoring sobre rutas de etiquetas completas. Seis parámetros de transition-bias controlan la persistencia del fondo, la entrada a spans, la continuación, el cierre y el handoff entre límites. El efecto práctico es que los límites de span permanecen coherentes en texto con formato mixto donde la decodificación argmax independiente los fragmenta.
Los runtime operating points permiten ajustar el balance entre precisión y recall sin necesidad de reentrenamiento. Sesgue hacia la entrada y continuación de spans para una sobre-redacción (favorable al compliance, más ruidosa). Sesgue hacia la persistencia del fondo para una sub-redacción (preserva contexto, con riesgo de filtración). La model card completa, incluida la metodología de evaluación, está disponible en huggingface.co/openai/privacy-filter.
Por qué la posibilidad de ejecutarlo en el navegador cambia la decisión de ubicación
La mayoría del middleware de redacción de PII se ejecuta en el servidor. Los datos atraviesan la red en texto plano, llegan a un servicio de redacción, se sanean y continúan hacia la API del modelo. Cada paso añade latencia, coste y un punto donde la versión en texto plano queda en los registros.
Privacy Filter se ejecuta en una pestaña del navegador mediante Transformers.js con WebGPU y cuantización q4. La implicación: puede redactar la entrada del usuario en su propio navegador antes de que el texto abandone el dispositivo.
El servidor recibe una versión redactada. El almacén de registros recibe una versión redactada. El proveedor de LLM recibe una versión redactada. No es necesario confiar en que su propia infraestructura sea perfecta, porque el texto plano nunca llega a ella.
Esto cambia el cálculo de ubicación de tres maneras. La inferencia en el cliente desplaza el trust boundary fuera de su centro de datos. Un modelo con 50 millones de parámetros activos es lo suficientemente pequeño para distribuirse como parte de un bundle estándar sin superar el presupuesto de carga de una aplicación web moderna. Y la licencia Apache 2.0 significa que puede hacer fine-tuning con sus propios datos de dominio y alojar los pesos sin negociar un acuerdo comercial.
Existe un coste real. El soporte de WebGPU es inconsistente fuera de los navegadores Chromium, los pesos del modelo deben descargarse una vez por cada cache bust y la ventana de inferencia está limitada por la memoria disponible del dispositivo. Para un flujo de trabajo de compliance en una aplicación web de escritorio, esos costes son aceptables. Para un webview móvil con evicción de caché agresiva, generalmente no lo son.
Dónde encaja en un agent governance stack
Un agent governance stack real tiene capas diferenciadas. El modelo de trabajo que usamos en webvise es el siguiente:
Capa 1: Autenticación de ingreso y rate limiting
Capa 2: Minimización de datos (redacción de entrada)
Capa 3: Composición de prompts y ensamblaje de contexto
Capa 4: Inferencia del modelo
Capa 5: Filtrado de salida (PII, seguridad, políticas)
Capa 6: Egress hacia action handlers, almacenamiento y APIs de terceros
openai/privacy-filter encaja con precisión en la Capa 2 y, con una calibración diferente del operating point, en la Capa 5. No reemplaza los modelos de seguridad, los detectores de prompt injection ni los motores de políticas a nivel de agente. Sí reemplaza la biblioteca de expresiones regulares que usted ha estado manteniendo, y lo hace con propiedades arquitectónicas que los enfoques basados en reglas no pueden igualar.
| Ubicación | Trust boundary | Cuándo usar |
|---|---|---|
| Client-side (navegador + WebGPU) | El texto plano nunca abandona el dispositivo | Aplicaciones web con compliance prioritario, industrias reguladas, herramientas internas |
| Server middleware (Node + Transformers) | Servidor confiable, registros auditados | APIs, agentes backend, pipelines de procesamiento por lotes |
| Output filter (post-respuesta) | La salida del modelo nunca llega al cliente sin procesar | Agentes de chat, contenido generado, flujos RAG orientados al usuario |
Para la mayoría de los client stacks que diseñamos, la respuesta es la combinación de Capas 2 y 5. La verificación local en el navegador impide que el PII accidental entre en el context window desde el principio. La verificación de salida en el servidor detecta cualquier dato que el modelo genere o filtre en su respuesta. La defensa en profundidad es el objetivo.
Si usted está mapeando sus flujos de datos contra una capa de governance hoy, hable con webvise sobre el diseño del stack antes de comprometerse.
Las ocho categorías, y dónde falla esto
La taxonomía de etiquetas de Privacy Filter es estática. Ocho categorías más una clase de fondo, con etiquetas de límite BIOES por categoría.
| Categoría | Qué detecta | Modo de fallo conocido |
|---|---|---|
| private_person | Nombres personales | Nombres regionales poco comunes, iniciales y referencias con tratamientos honoríficos presentan sub-detección |
| private_email | Direcciones de correo electrónico | Cobertura sólida. Los formatos ofuscados ("nombre arroba dominio") pueden omitirse |
| private_phone | Números de teléfono | Formatos internacionales sólidos. Los separadores no estándar fragmentan ocasionalmente |
| private_address | Direcciones postales | Las direcciones multilínea en diseños densos se fragmentan en los límites |
| private_url | URLs identificativas | Sobre-redacta URLs de entidades públicas cuando el contexto local es ambiguo |
| private_date | Fecha de nacimiento, citas | Sensible al contexto. Las fechas de calendario en texto de programación a veces se sobre-redactan |
| account_number | IDs bancarios, de cliente o de paciente | Sub-detecta patrones de identificadores específicos del dominio |
| secret | Claves API, credenciales, tokens | Los formatos de credenciales novedosos y los secretos divididos se omiten |
Si su dominio tiene categorías fuera de esta lista, realice fine-tuning. La model card es explícita en que no se puede cambiar la política de etiquetas en tiempo de ejecución. Ese es el coste de un clasificador con 50 millones de parámetros activos: la taxonomía está incorporada. Para equipos que comparan opciones, nuestra guía sobre los mejores modelos de IA locales para empresas con compliance en 2026 cubre el lado de los LLMs de propósito general de la misma decisión.
La model card de OpenAI es inusualmente directa. Tres limitaciones que conviene tomar en serio antes de publicar.
Prioridad al inglés, no multilingüe
El modelo fue evaluado en benchmarks multilingües seleccionados, pero la precisión disminuye con scripts no latinos y convenciones de nomenclatura de grupos protegidos. Si usted trabaja con un cliente con datos personales en alemán, polaco o italiano, espere una degradación del recall. Realice fine-tuning con ejemplos del dominio o aplique un fallback de expresiones regulares en una segunda pasada para las categorías más relevantes.
No es anonimización
Esta es una ayuda para la redacción, no una garantía de anonimización. Eliminar el PII superficial no elimina el riesgo de re-identificación cuando los quasi-identifiers (código postal, edad, diagnóstico poco frecuente) se agrupan. Si su obligación de compliance es la anonimización del RGPD o la de-identificación HIPAA bajo el método Safe Harbor, necesita un pipeline dedicado por encima de esto, no solo esto. Nuestro análisis sobre regulaciones y certificaciones de IA en Alemania y Europa detalla el stack regulatorio.
Los flujos de trabajo de alta sensibilidad requieren personas en el proceso
Medicina, derecho, finanzas, recursos humanos, educación, administración pública. En estos sectores, los falsos negativos exponen datos y los falsos positivos eliminan contexto que los revisores necesitan para tomar decisiones. Privacy Filter es una entrada a un proceso de revisión en estos entornos, no un sustituto de uno.
Nuestra norma: Privacy Filter se integra en un stack con al menos otra verificación posterior. Si es la única capa, una actualización del modelo puede introducir una regresión que nadie detecta.
Actualización de nuestra posición sobre "no agents en la web abierta"
A principios de este mes publicamos una posición: webvise no publicará agentes de IA que lean la web abierta para sus clientes. La razón era concreta. Las entradas controladas por atacantes (una página scrapeada, una URL enviada por el usuario, un feed de terceros) proporcionan al agente PII, credenciales o payloads de prompt injection que se filtran hacia acciones posteriores.
openai/privacy-filter cambia parcialmente ese cálculo. En lo que respecta a la filtración de entradas, ejecutar un clasificador local en el navegador sobre el contenido scrapeado antes de que entre en el contexto del prompt atenúa dos patrones específicos: la exposición de datos sensibles y el envenenamiento de contexto mediante PII embebido.
No afecta al vector de prompt injection. No impide que una página cuidadosamente diseñada indique al agente que envíe por correo el contenido de su memoria. Sí impide que esa página lleve accidentalmente la dirección particular de un cliente al context window del modelo.
La actualización de posición: ahora publicaremos lectores de web abierta de alcance limitado para flujos de trabajo no sensibles (agregación de datos públicos, inteligencia competitiva, investigación de mercado) si Privacy Filter está integrado en ambos lados de la llamada al modelo. Seguiremos sin publicarlos para flujos de trabajo que involucren registros de clientes, documentos internos o acciones autenticadas sin un red-team pass dedicado previo.
Cómo integrarlo
Dos patrones comunes, ambos directamente de la model card. El pipeline en Python para redacción en el servidor:
`from transformers import pipeline; classifier = pipeline(task="token-classification", model="openai/privacy-filter"); classifier("My name is Alice Smith")`
Y el pipeline de Transformers.js para redacción en el navegador mediante WebGPU:
`import { pipeline } from "@huggingface/transformers"; const classifier = await pipeline("token-classification", "openai/privacy-filter", { device: "webgpu", dtype: "q4" }); await classifier(input, { aggregation_strategy: "simple" });`
Coloque el pipeline del navegador en un Web Worker para que la inferencia no bloquee el hilo principal. Almacene en caché los pesos del modelo con un service worker para que el penalti de la primera visita solo se aplique una vez por cache bust. Ajuste el operating point en staging con datos representativos antes de tocar producción. El repositorio oficial contiene la model card completa, el demo space y las instrucciones de fine-tuning.
El lanzamiento de privacy-filter de OpenAI no es un modelo. Es una tesis sobre hacia dónde se dirige el sector: clasificadores de propósito específico, ejecutables en el navegador, bajo Apache 2.0, funcionando en los extremos de su stack, controlando lo que sus LLMs reciben y lo que devuelven. Esa es la forma del trabajo de compliance que realizamos en webvise, y es la forma de la capa de governance que la mayoría de los agentes no tienen hoy.
Si su agent stack no tiene una capa de minimización de datos, esta es la versión sobre la que construirla. Si desea ayuda para integrarlo en algo con lo que los clientes puedan operar de manera confiable en producción, webvise lo construye.
Las prácticas de webvise están alineadas con las normas ISO 27001 e ISO 42001.