Capítulo 8 — Anonimización de datos en la pipeline RAG

Octava entrega del recorrido capítulo por capítulo de LLM Primer III: Enhancing Enterprise AI with RAG. ¿Deberían anonimizarse los datos antes de que el modelo los vea, o antes de que el usuario vea la salida? La respuesta cambia todo en la pipeline, y el régimen regulatorio normalmente elige la respuesta por ti.

Por qué existe este capítulo

El Capítulo 7 respondió a quién puede ver qué. Asumió que había algo que restringir. Pero el Capítulo 6 mostró también que el embedding no es una función de una sola dirección — el almacén vectorial es una copia difusa de la fuente, y el control de acceso es sólo la capa externa. Si el corpus contiene números de seguridad social, entradas de historial médico, nombres de cliente o rutas de código propietario, la pregunta deja de ser sólo quién está autorizado a recuperarlos. La pregunta es si deberían haberse embebido en esa forma.

Esa es la pregunta de la anonimización, y es la decisión de seguridad con más peso de ingeniería en un despliegue RAG. La elección es de posición antes que de algoritmo: ¿en qué etapa se transforma el contenido sensible?

8.1 Pre-generación frente a post-generación

La anonimización pre-generación transforma los datos antes de embedderlos y almacenarlos. El almacén vectorial nunca contiene los valores sensibles originales; ni siquiera un compromiso completo de la capa de modelo puede extraer lo que nunca estuvo allí. Es la arquitectura obligatoria para muchos RAG médicos cubiertos por HIPAA y varias aplicaciones legales sujetas a GDPR. El coste es la calidad de recuperación: la consulta dice "Acme Corp" pero el corpus decía "[ORG_47]" antes de embedder, y la similitud densa cae justo en el token más informativo.

La anonimización post-generación corre sobre la salida del modelo. La calidad de recuperación se preserva; la garantía de privacidad es más débil porque los datos sensibles están en el índice. Es apropiada cuando el modelo de amenaza es la fuga hacia el usuario en lugar de la fuga hacia la infraestructura. La mayoría de los sistemas en producción terminan usando una mezcla híbrida — identificadores directos y categorías de alto peso regulatorio tratados pre-generación, sensibilidades operativas de menor peso enmascaradas en la salida según el perfil de autorización del usuario. Dos disciplinas de implementación importan: corre la anonimización antes del chunking (si no, el chunker destruye el contexto que el detector necesita), y mantén una bóveda de de-tokenización como tabla de mapeo separada y controlada por acceso, para que un médico con el rol correcto pueda seguir viendo el identificador del paciente que el índice enmascaró.

8.2 Enmascaramiento, reemplazo sintético, privacidad diferencial

Las técnicas se dividen en tres familias sobre un único dial. El enmascaramiento de PII detecta entidades (Microsoft Presidio es la implementación abierta más desplegada) y las reemplaza por placeholders. Los problemas duros son el recall — un detector que se deja un diez por ciento de los nombres produce documentos redactados que un atacante puede localizar vía similitud de embedding — y el sobre-enmascaramiento, que colapsa el vocabulario y daña la recuperación. La disciplina es medición dual: recall sobre un conjunto etiquetado y un benchmark offline de calidad de recuperación.

El reemplazo sintético sustituye un valor falso plausible en lugar de un placeholder, de modo que "Juan Pérez" se vuelve "Álex Romano" en lugar de [NOMBRE]. El embedding se mantiene bien distribuido y al modelo le resulta natural. El mapeo es determinista — un hash con clave de entidad real a falsa — así que la misma entidad real recibe la misma falsa a lo largo del corpus, y la clave vive en la bóveda. El reemplazo sintético sigue filtrando ante un adversario con información auxiliar, pero es una mejora significativa frente al enmascaramiento cuando la calidad de recuperación importa.

La privacidad diferencial es la familia que ofrece una garantía matemática real — un mecanismo es ε-DP si la distribución de salida cambia como mucho un factor exp(ε) cuando se añade o se quita cualquier registro. DP-Prompt perturba los chunks seleccionados para el prompt; DP-MLM perturba la pasada de embedding del modelo de lenguaje enmascarado; 1-Diffractor combina DP con reescritura que preserva la semántica. DP es un presupuesto, no un interruptor — cada consulta gasta algo, y la disciplina operativa es en gran parte contabilidad del presupuesto. Las tres familias componen, y un buen despliegue suele estratificarlas.

8.3 La disyuntiva utilidad-privacidad

Los tokens que más vale la pena anonimizar son los tokens cuya anonimización más daña la recuperación. La asimetría es desafortunada pero innegociable. Las mitigaciones son parciales: el reemplazo sintético preserva más señal que los placeholders; los placeholders con tipo etiquetado ([PERSONA llamada Álex] en vez de [PERSONA]) preservan aún más, a costa de un enmascaramiento más débil. Los corpus anonimizados suelen querer chunks un poco más grandes que los no anonimizados, porque la pérdida por redacción se amortiza sobre más contenido superviviente.

El planteamiento honesto es que la disyuntiva no es un dial de un solo eje, sino una superficie bidimensional — el suelo regulatorio por debajo del cual el sistema es ilegal, el suelo de utilidad por debajo del cual los usuarios lo abandonan, y la región operativa entre ambos. A veces el hueco es ancho y muchos diseños funcionan. A veces el hueco está vacío: el suelo regulatorio queda por encima del suelo de utilidad, y lo más valioso que la fase de diseño puede hacer es reconocerlo antes de hundir esfuerzo en un sistema que no se puede construir.

8.4 Integración empresarial y elegir un diseño

Zilliz Cloud expone la anonimización como una transformación de pipeline entre parser y embedder, con hooks en cuatro puntos de control (ingesta, recuperación, de-tokenización, salida). PII Masker toma la forma opuesta — un bloque de construcción enfocado que los equipos componen en sus propias pipelines. Los despliegues maduros suelen construir un servicio centralizado de anonimización con cuatro operaciones: anonimizar un documento parseado, consultar la de-tokenización bajo un contexto de autorización, escanear una cadena de salida en busca de contenido sensible residual e informar del presupuesto de privacidad consumido.

La decisión de diseño parte de la regulación, no del algoritmo. HIPAA Safe Harbor encaja limpiamente con el enmascaramiento de PII con una lista fija de dieciocho categorías. PCI DSS se satisface con tokenización — reemplazo sintético más bóveda. El principio de minimización de datos del GDPR empuja hacia pre-generación para las categorías más sensibles. La privacidad diferencial no la exige ninguna regulación importante, pero es la respuesta correcta cuando el modelo de amenazas incluye un adversario sofisticado con datos auxiliares y el corpus contiene registros que serían reportables si fueran reidentificados.

Lo que prepara el Capítulo 8

Los Capítulos 7 y 8 juntos completan la Parte IV. El control de acceso responde a quién puede ver qué; la anonimización responde a qué hay para ver, para empezar. Ambos son decisiones de infraestructura que el resto de la pipeline debe respetar, y ambos dependen de elecciones hechas en tiempo de parsing y chunking que no se pueden revertir baratas más tarde. Con el sistema diseñado y asegurado, la siguiente pregunta es si funciona — y eso requiere una manera de medirlo.

Próximamente — Capítulo 9: La tríada de evaluación de RAG. Relevancia del contexto, fidelidad (groundedness) y relevancia de la respuesta — tres señales independientes que, juntas, le dicen al operador si el sistema está fallando en la recuperación, en la generación o en la conexión entre ambas.