BV-PRGA: la puerta de privacidad, por dentro

Cada prompt que sale hacia un modelo externo es una exportación de datos. La mayoría de las veces, exporta más de lo que la tarea necesita: el nombre del cliente cuando bastaba un cliente, el IBAN completo cuando el modelo solo tenía que redactar un recordatorio, una clave de API pegada por accidente. BV-PRGA es la puerta que se coloca antes de esa salida — como extensión de navegador para personas, como gateway autoalojado para equipos — y garantiza una propiedad simple de enunciar: lo sensible se queda en tu sistema; fuera viaja solo lo necesario para resolver la tarea.

El viaje de ida y vuelta, formalizado

El corazón de BV-PRGA es un enmascaramiento reversible cuya clave nunca sale. A la ida, la petición $x$ se transforma en un par

donde $\tilde{x}$ es la versión protegida que viaja al proveedor y $\kappa$ es el mapa de correspondencias — qué token sustituye a qué valor — que se queda en tu entorno. Cada dato detectado se sustituye por un marcador estable del tipo [BV:PERSON:a1b2c3], [BV:IBAN:2e5d8c]: consistente dentro de la petición (el modelo puede razonar sobre «la misma persona») y opaco fuera de ella. A la vuelta, la respuesta $\tilde{r}$ del proveedor se reconstruye localmente:

La propiedad clave es dónde vive cada pieza: el proveedor externo solo ve $\tilde{x}$ y produce $\tilde{r}$; el par $(\kappa, r)$ no abandona tu infraestructura en ningún punto del ciclo. La reversibilidad es local por construcción, no por promesa.

Secretos: bloquear, no pseudonimizar

No todo lo sensible admite el mismo tratamiento. Un nombre o un IBAN pseudonimizados siguen permitiendo resolver la tarea; una clave de API no pinta nada en un prompt bajo ninguna forma — ni en claro ni enmascarada, porque un marcador reversible de un secreto sigue siendo un secreto con un paso de indirección. Por eso la política distingue dos verbos:

• Pseudonimizar lo que la tarea necesita referenciar: personas, identificadores, cuentas, correos.
• Bloquear lo que jamás debería viajar: credenciales, claves, tokens de sesión. La petición se detiene con una decisión explícita — DENY — y el contador de la puerta lo registra: qué se pseudonimizó, qué se bloqueó y por qué la petición no salió.

Fail-closed: la puerta falla cerrada

La detección es un problema de etiquetado de secuencias, y ningún detector es perfecto. La pregunta de diseño honesta no es «¿cuánto acierta?» sino «¿qué pasa cuando duda?». En BV-PRGA la respuesta es estructural: ante la duda, la puerta se cierra. Si el análisis de una petición no puede completarse con confianza — el clasificador no converge, el gateway no responde, el formato desborda lo esperado — el valor por defecto es no enviar. Formalmente, la política es un retículo donde DENY domina: ningún fallo de un componente puede degradar silenciosamente hacia «enviar en claro».

Ese sesgo tiene un precio (a veces se bloquea de más) y es un precio que elegimos con gusto: el coste de un falso positivo es un reintento; el de un falso negativo es una exportación de datos que ya no se puede deshacer.

Lo que esta puerta no es

La honestidad forma parte de la especificación. BV-PRGA reduce la superficie de exposición y de cumplimiento — menos datos personales viajando a terceros, menos copias fuera de tu perímetro — pero no es un sustituto de tu marco legal de protección de datos: las bases jurídicas, los contratos de encargado y las evaluaciones de impacto siguen siendo tuyos. La puerta te da un hecho técnico verificable sobre el que apoyar ese marco: lo sensible no salió.

Posición en la literatura

La detección de PII como etiquetado de secuencias tiene un linaje largo, y viene de la clínica: el shared task i2b2/UTHealth de 2014 fijó el molde experimental — corpus anotado, precision/recall, sistemas híbridos — y su resultado clave: los mejores sistemas rondaron F1 0,90, y ninguno alcanzó la detección perfecta (Stubbs et al., 2015). Esa tecnología se industrializó en herramientas como Presidio, cuya propia documentación advierte que no hay garantía de encontrar toda la información sensible (Microsoft / Data Privacy Stack community, 2026). La crítica académica llegó después: etiquetar entidades no es medir riesgo de divulgación (Lison et al., 2021), y el benchmark TAB convirtió esa crítica en programa de evaluación, con métricas separadas para protección y utilidad (Pilán et al., 2022). BV-PRGA se inserta aquí sin pretender un detector mejor: lo que cambia es la semántica del error — si el detector duda, el texto no sale. Se paga en utilidad, que es la moneda barata según la misma asimetría que TAB formaliza.

La amenaza que motiva todo esto está cuantificada. Lo que entra en un modelo puede salir: la extracción verbatim de datos de entrenamiento está demostrada (Carlini et al., 2021) y la memorización crece con la escala del modelo — «likely to get worse», en palabras de sus autores (Carlini et al., 2022). Y las salidas fáciles están cerradas por la propia literatura: pedirle discreción al modelo no funciona — GPT-4 revela información en contextos donde un humano no lo haría un 39 % de las veces, y la fuga persiste con privacy prompts y cadena de razonamiento (Mireshghallah et al., 2024) — y quitar identificadores tampoco basta, porque los LLM infieren atributos personales del texto restante con hasta un 85 % de acierto (Staab et al., 2024). La conclusión compartida es estructural: la protección tiene que ocurrir antes del proveedor, en el entorno del cliente.

Los gateways reversibles ya existen, y hay que citarlos. Hide and Seek (HaS) propone explícitamente el patrón: anonimizar el prompt localmente, consultar al LLM remoto, des-anonimizar la respuesta localmente (Chen et al., 2023); PAPILLON es la variante moderna por ensamble local/remoto, con el compromiso cuantificado — 85,5 % de calidad mantenida con la fuga restringida al 7,5 % (Siyan et al., 2025). Frente a ambos, la diferencia de BV-PRGA es triple: reconstrucción determinista $r=\kappa^{-1}(\tilde{r})$ por mapa de marcadores estables — no un segundo modelo local que reintroduce error probabilístico a la vuelta —, la distinción pseudonimizar-vs-bloquear — un secreto no se sustituye: se deniega — y la semántica fail-closed, ausente en ambos precedentes, que tratan la fuga residual como métrica a optimizar y no como evento a impedir. La privacidad diferencial para texto es el polo metodológico opuesto (Feyisetan et al., 2020): garantía formal $\epsilon$ contra adversarios arbitrarios, al precio de la fidelidad — el propio campo admite que sus mecanismos de sanitización «still provide low utility» (Yue et al., 2021) — y de la reversibilidad exacta, que la DP excluye por construcción.

El ancla regulatoria cierra el círculo con una simetría notable. La definición de pseudonimización del art. 4(5) del RGPD describe $m(x)=(\tilde{x},\kappa)$ casi literalmente: datos que ya no pueden atribuirse a un interesado «sin utilizar información adicional», siempre que esa información «figure por separado» bajo medidas técnicas y organizativas (European Parliament and Council of the European Union, 2016). Las directrices 01/2025 del EDPB bendicen específicamente la pseudonimización diseñada para revertirse, con tablas pseudónimo↔valor o claves criptográficas como esa información adicional (European Data Protection Board, 2025) — la descripción regulatoria de $\kappa$ —, y ENISA aporta la ingeniería de los pseudónimos y sus ataques: los marcadores aleatorios estables (no hashes del valor sustituido) esquivan precisamente los ataques de diccionario que su informe analiza (ENISA (European Union Agency for Cybersecurity), 2019). El recordatorio honesto viene del propio EDPB: el dato pseudonimizado sigue siendo dato personal; BV-PRGA reduce el riesgo frente al proveedor, no exime del RGPD.

Problemas abiertos

1. Del etiquetado al riesgo de divulgación. El campo carece de métodos que incorporen medidas explícitas de riesgo de reidentificación al proceso (Lison et al., 2021); cómo un gateway estima ese riesgo en línea sigue abierto.
2. La inferencia de atributos derrota a la anonimización actual. Con las mitigaciones comunes declaradas «currently ineffective» y hasta un 85 % de acierto infiriendo atributos del texto residual (Staab et al., 2024), queda abierto cómo proteger la señal contextual y estilística que ningún sustituidor de entidades toca. Es la frontera declarada de esta puerta.
3. La fuga contextual no se arregla con prompting. La fuga persiste incluso con instrucciones de privacidad y cadena de razonamiento (Mireshghallah et al., 2024); mientras los modelos no respeten una noción operativa de integridad contextual, solo valen soluciones estructurales.
4. Memorización creciente sin mitigación activa. La memorización crecerá con la escala «at least without active mitigations» (Carlini et al., 2022) — y esas mitigaciones son exógenas a cualquier cliente del proveedor.
5. Evaluación específica de gateway. TAB existe porque las métricas estándar no capturan a la vez protección y utilidad (Pilán et al., 2022); falta consenso en métricas — y corpus no clínicos ni jurídicos — que capturen la asimetría falso-negativo-irreversible vs falso-positivo-barato en escenarios de gateway.
6. Garantía formal + fidelidad + reversibilidad. La DP da la primera renunciando a las otras dos (Feyisetan et al., 2020; Yue et al., 2021); los gateways reversibles dan las segundas renunciando a la primera (Chen et al., 2023; Siyan et al., 2025). Conciliar las tres sigue siendo el problema abierto del campo.

Nota: las cifras de esta sección (F1 del shared task, 39 %/57 %, 85 %, 85,5 %/7,5 %…) provienen de la literatura citada y describen esos trabajos, no mediciones de BV-PRGA.

Dónde está esto hoy

BV-PRGA está productivizado como producto independiente en privacy.bivelio.com, en dos formas: una extensión de navegador gratuita (Chrome, Edge y Brave) que protege a las personas en ChatGPT y Claude antes de que el texto salga del dispositivo, y un gateway autoalojado para desarrolladores y equipos, publicado en PyPI, que aplica la misma política delante de cualquier API de IA — OpenAI, Anthropic, DeepSeek y muchas otras. Dentro de BiVelio es la capa Protect: la misma puerta, delante de cada interacción con un modelo.

Referencias