RAG y agentes seguros para PII: tokenización reversible en producción

El problema: el RAG filtra datos

Te lo digo directo: en el momento en que montas un pipeline RAG sobre documentos de negocio reales, casi seguro has construido una máquina de fugas de datos. Nombres de clientes, IBAN, identificadores de salud y números de expediente fluyen desde tus documentos hacia tres lugares no confiables: el proveedor del modelo, el vector store y tus logs. La mayoría de los equipos no se da cuenta hasta que una revisión de seguridad o un regulador pregunta a dónde fueron los datos personales.

El arreglo ingenuo es borrarlo todo. Reemplazas cada nombre por [REDACTED] y sigues adelante. Eso rompe dos cosas a la vez. El modelo pierde el contexto que necesita para responder bien, y el retrieval se desmorona porque la consulta enmascarada ya no coincide con los documentos enmascarados. Necesitas que los datos personales desaparezcan de los sistemas no confiables, pero que el significado se preserve. Es un problema más difícil, y tiene solución.

El objetivo no es borrar los datos personales de tu pipeline de IA. Es asegurar que los valores crudos nunca crucen hacia un sistema en el que no confías, mientras el modelo sigue teniendo lo suficiente para hacer su trabajo.

Nosotros metemos esta disciplina en los sistemas de nuestros clientes, y construimos un runtime para ello: OGuardAI, una capa propietaria de protección de datos que se coloca entre tu aplicación y el modelo. Esta guía es la arquitectura de hacer IA segura para PII como corresponde. Para el enfoque de negocio, mira nuestra guía de prevención de fugas de datos con IA, y esto es trabajo central de nuestros servicios de IA.

A quién le importa qué

El límite de confianza

Todo empieza con una línea trazada a través de tu arquitectura. A un lado, la zona confiable: tu aplicación y el runtime de protección. Al otro, la zona no confiable: el proveedor del modelo, el vector store, las herramientas de terceros y tus logs.

   TRUSTED                          │   UNTRUSTED
                                    │
  App ──▶ Protection runtime ──────▶│──▶ LLM provider
          (detect, tokenize)        │──▶ Vector store
          (restore on the way back) │──▶ Logs, tools
                                    │
  raw PII lives here, transiently   │   only tokens cross this line

Los datos personales crudos existen solo de forma transitoria dentro del runtime, durante una petición. Lo que cruza el límite son tokens y metadatos seguros, nunca valores crudos. El principio de diseño que hace esto confiable: la configuración solo puede añadir o endurecer protección, nunca aflojar el piso integrado. No puedes reconfigurar la fuga por accidente. Nuestra guía de gobernanza de IA explica por qué esta postura de fallar hacia lo seguro importa en sistemas agénticos.

Detección: encontrar las partes sensibles

No puedes proteger lo que no encuentras. La detección corre en dos capas.

La primera es un piso de regex determinista: docenas de patrones basados en formato que son independientes del idioma. Emails, números de teléfono, IBAN, números de IVA, tarjetas de crédito validadas por checksum, IP, identificadores nacionales, identificadores fiscales. Son rápidos, del orden de un milisegundo, y nunca se les escapa un IBAN bien formado porque no dependen del humor de un modelo.

La segunda es el reconocimiento de entidades nombradas para lo que la regex no puede atrapar: nombres de personas, organizaciones, ubicaciones, direcciones. Esto corre a través de un detector basado en modelo y es ampliamente multilingüe, con un coste de latencia mayor.

La parte importante es la política de fallo. Eliges un modo: solo builtin, both con degradación limpia al piso de regex si el NER está caído, o advanced donde el NER es obligatorio y la petición falla cerrada si no puede correr. Un sistema que degrada en silencio a "sin detección de PII" porque un sidecar dio timeout es peor que uno que rechaza la petición. Fail closed.

Tokens semánticos, no redacción

Aquí viene la idea clave que mantiene al modelo útil. En vez de borrar una entidad detectada, la reemplazas por un token estructurado que lleva su tipo y una identidad única, pero no su valor.

Input:  "Email the invoice to Max Mustermann at max.mustermann@beispiel.de"
Masked: "Email the invoice to {{person:p_001:ad4f97}} at {{email:e_002:5873cc}}"

El token le dice al modelo "aquí hay una persona" y "aquí hay un email", y los mantiene distintos y referenciables, para que el modelo pueda escribir una respuesta coherente sobre ellos. El nombre y la dirección reales nunca salen de tu límite de confianza. En el camino de vuelta, el runtime restaura los valores reales en la salida final.

Esto le gana a [REDACTED] en todo lo que importa. El modelo conserva la estructura y las relaciones. Los valores idénticos colapsan al mismo token, así que el modelo entiende que dos menciones son la misma persona. Las entidades cercanas se pueden vincular, así que un nombre y su email se restauran de forma coherente. La redacción tira todo eso a la basura.

Los seis modos de restauración

No todo debería volver completo. La restauración se gobierna por entidad y por canal de salida, con seis modos.

Así, una respuesta de soporte al cliente puede restaurar su nombre completo, mientras la misma interacción escrita en un log interno restaura solo una forma enmascarada. El canal decide. Así es como le sirves una respuesta útil a la persona mientras mantienes tus logs limpios.

El problema del RAG: el retrieval tiene que seguir funcionando

Esta es la parte donde tropieza cada equipo que intenta montárselo por su cuenta. Si enmascaras un documento con tokens aleatorios en la ingesta, y luego enmascaras la consulta del usuario con tokens aleatorios distintos en el momento de la búsqueda, el retrieval se rompe. El token de consulta para "Mustermann" no coincide con el token de documento para "Mustermann", porque se acuñaron de forma independiente.

El arreglo son tokens deterministas con alcance de corpus. Dentro de un corpus, un valor se tokeniza a través de un hash con clave, de modo que el mismo valor siempre produce el mismo token, en cada documento y en la consulta. Ahora una consulta enmascarada coincide con chunks enmascarados, porque "Mustermann" se tokeniza idéntico en ambos lados.

Ingestion:  doc chunk  "...contract with Mustermann..."  ──▶  "...contract with {{person:h_9f3a...}}..."
Query:      "what did Mustermann sign"                    ──▶  "what did {{person:h_9f3a...}} sign"
                                                                       │
                                        same value ──▶ same token ──▶ retrieval matches

Los tokens se derivan por corpus desde un secreto, así que el mismo valor en otro corpus es un token sin relación, y una colisión de hash falla cerrada en vez de fusionar a dos personas distintas. Esto es lo que te permite correr retrieval sobre documentos enmascarados con consultas enmascaradas y aún así obtener resultados correctos. Cubrimos el lado del retrieval en general en nuestra guía de sistemas RAG empresariales y en la guía de arquitectura de búsqueda vectorial. Combinado con los patrones de memoria de agentes de nuestra guía de memoria de agentes, así es como construyes agentes que recuerdan y recuperan sin acumular datos personales.

Sesiones: dónde vive el mapeo

El mapeo de tokens de vuelta a valores reales tiene que vivir en un lugar seguro y ser usable entre réplicas. El default es una sesión sellada: el mapeo se cifra con AES-256-GCM en un blob que viaja con la petición, así que el servidor no guarda estado y cualquier réplica puede procesar cualquier petición. Para setups compartidos, un almacén cifrado guarda solo ciphertext más metadatos de enrutamiento no personales.

Cada carga de sesión revalida el tenant al que pertenece y falla cerrada si hay un desajuste, así que un tenant nunca puede abrir el mapeo de otro. Las sesiones expiran con un TTL, y un blob manipulado o expirado se rechaza por su etiqueta de autenticación. Esta es la fontanería criptográfica aburrida que hace que todo sea confiable, y hacerla mal es cómo "tokenizamos PII" se convierte en "tenemos una fuga de secreto compartido". Nuestra guía de diseño de sistemas para el fallo cubre esta mentalidad defensiva.

Policy: declarar lo que pasa

No hardcodeas las decisiones de protección. Las declaras en una policy, para que un responsable de seguridad o compliance pueda leerlas y cambiarlas sin tocar el código de la aplicación.

name: support-desk
version: 1.0.0
defaults:
  restore_mode: masked
rules:
  - entity_type: credit_card
    action: redact          # nunca reversible, nunca llega al modelo
  - entity_type: person
    action: tokenize        # reversible, restaurado para el cliente
    restore_mode: full
  - entity_type: email
    action: tokenize
    restore_mode: masked    # enmascarado en logs, completo para el usuario según el canal

Las acciones son explícitas: tokenize para protección reversible, redact para eliminación irreversible, abstract para una etiqueta gruesa. Un nombre de policy desconocido hace fallar la petición en vez de caer a algo permisivo. El piso no se puede debilitar por policy, solo endurecer. Esto es autorización como configuración, y saca la decisión de seguridad del código disperso hacia un solo lugar revisable. Nuestra guía de gobernanza de IA explica por qué esa separación importa.

El proxy drop-in

La forma más rápida de proteger una app existente es no cambiar nada en ella. Un proxy transparente habla la misma API que tu proveedor de modelo, así que apuntas tu SDK a la URL del proxy y este enmascara a la ida y restaura a la vuelta. Sin reescribir la aplicación.

Your app ──▶ proxy (mask) ──▶ OpenAI / Anthropic ──▶ proxy (restore) ──▶ your app

El proxy sostiene la sesión, así que tu app nunca maneja el mapeo de tokens. Para equipos que quieren un control más fino, SDK ligeros en varios lenguajes te dan las mismas primitivas con integraciones de framework para los stacks comunes de agentes y RAG. En cualquier caso, la integración es una costura, no una reescritura, y eso es lo que hace práctico adoptarla. Nuestros equipos de software a medida y consultoría cablean esto en sistemas existentes.

GDPR: borrado por revocación

Una solicitud de derecho al borrado tiene una respuesta limpia en este modelo. Como el mapeo de token a valor es el único enlace a los datos reales en tu pipeline, lo revocas. El mapeo almacenado guarda solo hashes con clave de los valores, nunca los valores crudos, y una vez que un valor se revoca, se restaura como un marcador de borrado sin importar lo que diga cualquier blob de sesión. Una sesión reproducida o revertida no puede deshacer la revocación.

Eso te da un borrado dirigido y demostrable a lo largo del pipeline de IA, con un recibo de auditoría y sin datos personales crudos en la propia pista de auditoría. Cubrimos el panorama de compliance más amplio en nuestra guía de GDPR e IA, y cómo lo manejamos en la entrega en nuestras páginas de confianza y GDPR.

Cómo empezar

1. Mapea tus flujos de datos. Encuentra cada punto donde documentos o mensajes llegan al modelo, al vector store o a los logs.
2. Empieza con el piso de regex. La PII estructurada, IBAN, tarjetas, emails, es la victoria más rápida y de mayor certeza.
3. Añade NER donde importan los nombres y direcciones. Elige tu modo de fallo deliberadamente.
4. Usa tokens con alcance de corpus para el RAG. Esto es lo que mantiene el retrieval funcionando sobre datos enmascarados.
5. Declara policy, no código. Pon las decisiones de protección donde un responsable de compliance pueda leerlas.

Es trabajo por etapas y de bajo riesgo, y encaja en la entrega por fases de nuestra metodología. Empieza en contacto o pide un presupuesto acotado.

Formas comunes en que esto sale mal

1. Redactar en vez de tokenizar. Pierdes el contexto del modelo y rompes el retrieval. Usa tokens semánticos reversibles.
2. Tokens independientes para consulta y documentos. El retrieval se rompe. Usa tokens deterministas con alcance de corpus.
3. Degradación silenciosa cuando cae el detector. "Sin detección" es una fuga. Fail closed.
4. Lógica de protección dispersa en el código. Nadie puede auditarla. Declárala en policy.
5. Sin camino de borrado. Si no puedes revocar un mapeo, no puedes honrar una solicitud GDPR. Diseña el borrado desde el principio.

Quién construye esto

Oronts es una empresa de software liderada por su fundador, con sede en Múnich. Refaat Al Ktifan, nuestro fundador y arquitecto de soluciones, lidera un equipo senior de backend, seguridad e IA. OGuardAI es nuestro propio runtime de protección de datos, construido porque necesitábamos esta disciplina en nuestro propio trabajo de IA antes de poder recomendársela a los clientes. Mapeamos tus flujos de datos, añadimos la capa de protección como una costura, y te entregamos un pipeline defendible bajo el GDPR y el AI Act de la UE. Mira nuestras páginas de servicios y soluciones.

Conclusiones

• Un pipeline RAG sobre documentos reales filtra PII al modelo, al vector store y a tus logs por defecto.
• Tokeniza, no redactes, para que el modelo conserve el contexto y los valores idénticos sigan vinculados.
• Usa tokens deterministas con alcance de corpus para que el retrieval siga funcionando sobre datos enmascarados.
• Guarda el mapeo de tokens en sesiones cifradas y ligadas al tenant, y falla cerrado ante cualquier error.
• Declara la protección en policy, y honra el borrado revocando el mapeo.

Decir "tokenizamos PII" es fácil; hacerlo bien es difícil. Los detalles, tokens con alcance de corpus, detección fail-closed, sesiones ligadas al tenant, son lo que separa una capa de protección real de una falsa sensación de seguridad.

Si tu pipeline de IA toca datos personales, cuéntanos cómo fluyen hoy. Empieza en contacto o pide un presupuesto acotado.