Filtraciones de PII en Ventanas de Contexto RAG: Deteccion, Prevencion y Diseno de Pipelines

Un usuario le pregunta a tu asistente RAG sobre la politica de licencias de la empresa. El sistema recupera el documento de politica relevante, ensambla el contexto y lo envia al LLM. La respuesta es precisa y util. Tambien contiene el nombre, el ID de empleado y la direccion de correo electronico de un gerente de recursos humanos cuya informacion de contacto estaba incrustada en el documento de politica. Eso es una filtracion de PII.

Las filtraciones de PII a traves de pipelines RAG no son hipoteticas. Ocurren en sistemas de produccion todos los dias. La arquitectura de RAG — recuperar documentos, inyectarlos en un prompt de LLM, generar una respuesta — crea multiples puntos donde la informacion de identificacion personal puede entrar en la ventana de contexto y terminar en la salida visible para el usuario. El LLM no sabe que es sensible. Trata cada token en el contexto por igual.

Este articulo mapea cada punto en el pipeline RAG donde la PII puede filtrarse, explica por que ocurre cada filtracion y proporciona un marco practico para la prevencion.

La Superficie de Filtracion de PII en Pipelines RAG

Un pipeline RAG estandar tiene seis etapas. La PII puede entrar y filtrarse en cinco de ellas.

Etapa 1: Ingestion de Documentos Los documentos fuente se cargan en el pipeline. PDFs, documentos de Word, correos electronicos, exportaciones de bases de datos, tickets de soporte, registros de CRM.

Riesgo de PII: Los documentos fuente frecuentemente contienen PII por diseno. Los documentos de RRHH tienen nombres de empleados y numeros de seguridad social. Los tickets de soporte tienen correos electronicos y numeros de telefono de clientes. Las exportaciones de CRM tienen detalles de contacto. Los registros medicos tienen identificadores de pacientes. Los documentos son la PII.

Etapa 2: Analisis y Extraccion Los documentos se analizan para convertirlos en texto. OCR para documentos escaneados. Extraccion de tablas para hojas de calculo. Extraccion de metadatos para encabezados y propiedades.

Riesgo de PII: Los parsers extraen todo, incluyendo PII incrustada en encabezados, pies de pagina, campos de metadatos y marcas de agua que los lectores humanos podrian ni siquiera notar. Los metadatos de un PDF podrian contener el nombre completo y correo electronico del autor. El historial de revisiones de un documento de Word podria contener los nombres de cada persona que lo edito.

Etapa 3: Chunking El texto analizado se divide en chunks para embedding y recuperacion.

Riesgo de PII: El chunking no discrimina. Si hay PII en el texto, termina en los chunks. Un chunk que contiene una declaracion de politica tambien contendra cualquier nombre de empleado, numero de telefono o direccion de correo electronico que apareciera en el mismo parrafo.

Etapa 4: Embedding y Almacenamiento Los chunks se convierten en vectores y se almacenan en la base de datos vectorial junto con el texto crudo del chunk.

Riesgo de PII: La base de datos vectorial almacena el texto crudo de cada chunk para recuperacion. Esto crea un almacen de datos de PII que puede no estar sujeto a los mismos controles de acceso que el sistema de origen. Tu base de datos vectorial es ahora una copia de cada pieza de PII que estaba en los documentos fuente.

Etapa 5: Recuperacion y Ensamblaje de Contexto Las consultas de los usuarios activan la busqueda vectorial, y los top-k chunks se ensamblan en el prompt del LLM.

Riesgo de PII: La recuperacion se basa en la similitud semantica, no en el control de acceso. Una consulta sobre "beneficios de empleados" podria recuperar un chunk que contiene los detalles de inscripcion de beneficios de un empleado especifico, completo con su nombre, fecha de nacimiento e informacion de dependientes. El sistema de recuperacion no verifica si el usuario que consulta esta autorizado para ver los datos de ese empleado.

Etapa 6: Generacion del LLM El LLM genera una respuesta basada en el contexto.

Riesgo de PII: El LLM incluye PII del contexto en su respuesta. No tiene concepto de que es sensible. Si el contexto contiene un numero de telefono, y ese numero de telefono es relevante para la respuesta, el LLM lo incluira.

Escenarios Comunes de Filtracion de PII

Estos son los escenarios que vemos con mayor frecuencia en produccion:

Escenario 1: El contacto servicial. Los documentos de politica incluyen "Para preguntas, contacte a Jane Doe en jane.doe@company.com o ext. 4521." El sistema RAG recupera el chunk de politica y el LLM amablemente incluye la informacion de contacto de Jane en cada respuesta sobre esa politica, incluso cuando el usuario no la solicito.

Escenario 2: El ejemplo en la plantilla. Una plantilla de formulario incluye datos de muestra: "Nombre: John Smith, SSN: 123-45-6789, Fecha de nacimiento: 01/15/1980." Los datos de muestra estaban destinados a mostrar como completar el formulario. El sistema RAG los trata como datos reales y los recupera en respuesta a consultas relacionadas.

Escenario 3: El hilo de correos en la base de conocimiento. Un equipo de soporte indexa su historial de correos electronicos para RAG. Los correos contienen nombres de clientes, direcciones de correo electronico, numeros de pedido y a veces detalles de pago en texto plano. Cada chunk de correo electronico recuperado contiene potencialmente PII de clientes.

Escenario 4: El PDF redactado-pero-no-realmente. Un documento fue "redactado" colocando rectangulos negros sobre el texto sensible en el visor de PDF. El texto subyacente nunca fue eliminado. El parser de PDF extrae el texto debajo de la redaccion visual, y la PII que supuestamente estaba redactada entra en el pipeline RAG.

Escenario 5: Datos entre inquilinos en sistemas multi-tenant. Un producto SaaS usa una base de datos vectorial compartida para todos los inquilinos. Una consulta del Inquilino A recupera chunks de los documentos del Inquilino B porque la capa de recuperacion no aplica aislamiento de inquilinos. Los nombres de empleados y datos internos del Inquilino B aparecen en las respuestas del Inquilino A.

Donde Colocar las Puertas de Redaccion

La prevencion de PII requiere puertas de redaccion en puntos especificos del pipeline. Una sola puerta es insuficiente — la defensa en profundidad es necesaria porque ninguna tecnica de redaccion individual detecta todo.

Puerta 1: Redaccion Pre-Chunking (Defensa Primaria)

Donde: Despues del analisis del documento, antes del chunking y embedding.

Que hace: Escanea el texto analizado completo en busca de patrones de PII y elimina, enmascara o reemplaza la PII detectada antes de que el texto entre en el pipeline de chunking.

Tecnicas de deteccion:

Patrones regex para PII estructurada (numeros de seguridad social, numeros de telefono, direcciones de correo electronico, numeros de tarjetas de credito)
Reconocimiento de entidades nombradas (NER) para nombres, organizaciones y ubicaciones
Diccionarios personalizados para identificadores especificos del dominio (IDs de empleados, MRNs de pacientes, numeros de cuenta)

Estrategias de redaccion:

Eliminacion: Borrar la PII por completo ("Contacte a Jane Doe en ext. 4521" se convierte en "Contacte en")
Enmascaramiento: Reemplazar con tokens de marcador de posicion ("Contacte a [NOMBRE_PERSONA] en [EXT_TELEFONO]")
Generalizacion: Reemplazar con etiquetas de categoria ("Contacte al representante de RRHH")

Por que esta puerta es la mas importante: Una vez que la PII entra en el vector store como parte del texto del chunk, eliminarla requiere reindexar todo el corpus afectado. Capturar la PII antes de que sea chunked y embebida es dramaticamente mas economico que capturarla despues.

Puerta 2: Auditoria a Nivel de Chunk (Defensa Secundaria)

Donde: Despues del chunking, antes del embedding y almacenamiento.

Que hace: Escanea cada chunk individual en busca de PII que sobrevivio a la Puerta 1. Esto captura PII que estaba fragmentada en el documento y solo se vuelve reconocible cuando se reensambla en un chunk, o patrones de PII que las reglas de deteccion de la primera puerta no detectaron.

Por que existe: Ningun sistema de deteccion de PII tiene 100% de recall. La Puerta 2 proporciona una segunda pasada con reglas de deteccion potencialmente diferentes (por ejemplo, un conjunto de regex mas agresivo, un modelo NER diferente, o una revision humana para documentos de alta sensibilidad).

Puerta 3: Filtrado en Tiempo de Recuperacion (Defensa Terciaria)

Donde: Despues de que la busqueda vectorial devuelve chunks candidatos, antes del ensamblaje de contexto.

Que hace: Escanea los chunks recuperados en busca de PII antes de que se ensamblen en el prompt del LLM. Si se detecta PII, el chunk se redacta sobre la marcha o se excluye del contexto.

Compensaciones: Esta puerta agrega latencia a cada consulta. Tambien significa que la PII aun existe en el vector store — solo se filtra en el momento de la lectura. Para fines de cumplimiento, esto puede no ser suficiente si las regulaciones requieren que la PII no se almacene en la base de datos vectorial en absoluto.

Cuando usarla: Como red de seguridad junto con las Puertas 1 y 2, o en situaciones donde heredaste un vector store que se indexo sin redaccion de PII y no puedes reindexar de inmediato.

Puerta 4: Filtrado de Salida (Ultimo Recurso)

Donde: Despues de la generacion del LLM, antes de que la respuesta se muestre al usuario.

Que hace: Escanea la respuesta generada por el LLM en busca de patrones de PII y los redacta antes de mostrarlos.

Limitaciones: Esta puerta no puede evitar que el LLM vea la PII — solo evita que el usuario la vea en la respuesta. La PII aun fue enviada a la API del LLM, lo que puede violar los acuerdos de procesamiento de datos. Si estas usando una API de LLM de terceros, la PII ya salio de tu entorno para cuando esta puerta se activa.

Cuando usarla: Como medida de doble seguridad, nunca como defensa primaria.

Control de Acceso en la Recuperacion

La redaccion de PII es necesaria pero no suficiente. Incluso con la PII redactada, la recuperacion debe respetar los controles de acceso a nivel de documento. Un documento marcado como "Confidencial de RRHH" no deberia ser recuperable por una consulta de un empleado general, incluso si toda la PII ha sido eliminada de sus chunks.

Implementa el control de acceso en la capa de recuperacion:

Filtrado basado en metadatos: Etiqueta cada chunk con metadatos de control de acceso (departamento, nivel de clasificacion, ID de inquilino) en el momento de la indexacion. Agrega filtros obligatorios a cada consulta de recuperacion basados en los permisos del usuario que consulta.
Aislamiento por namespaces: Usa namespaces o colecciones separadas del vector store para diferentes niveles de acceso. Una consulta de un usuario general solo busca en el namespace general.
Seguridad a nivel de fila: Si tu base de datos vectorial lo soporta, implementa politicas de seguridad a nivel de fila que restrinjan que chunks puede recuperar un usuario dado.

Lista de Verificacion de Implementacion Practica

Usa esta lista de verificacion al construir o auditar un pipeline RAG para la seguridad de PII:

Inventaria tus documentos fuente. Que tipos de documentos contienen PII? Que tipos de PII? Crea un mapa de datos de PII antes de construir el pipeline.
Implementa la Puerta 1 (redaccion pre-chunking). Esto es innegociable para cualquier pipeline que procese documentos que puedan contener PII.
Prueba la redaccion con documentos reales. Los documentos de prueba sinteticos no contienen los patrones de PII que tus documentos reales contienen. Prueba con datos reales (o realistas).
Verifica la redaccion en los chunks almacenados. Despues de indexar, muestrea chunks del vector store e inspeccionalos manualmente en busca de PII que sobrevivio la redaccion.
Implementa metadatos de control de acceso. Etiqueta los chunks con nivel de acceso y aplica filtrado en el momento de la recuperacion.
Agrega la Puerta 3 (filtrado en tiempo de recuperacion) para defensa en profundidad. Especialmente importante durante el periodo de transicion despues de corregir un pipeline que previamente carecia de redaccion.
Registra y audita. Registra que documentos fueron procesados, que PII fue detectada y redactada, y que chunks fueron servidos a que usuarios. Este rastro de auditoria es esencial para el cumplimiento.
Prueba con consultas adversariales. Intenta recuperar PII haciendo preguntas disenadas para obtener informacion sensible. "Quien maneja la inscripcion de beneficios?" no deberia devolver el nombre de una persona especifica si se suponia que ese nombre debia ser redactado.
Programa auditorias regulares de PII. Los nuevos documentos ingeridos despues de la configuracion inicial del pipeline pueden contener patrones de PII que tus reglas de deteccion no cubren. Audita trimestralmente como minimo.

Por Que Importa la Arquitectura del Pipeline

La mayoria de las filtraciones de PII en sistemas RAG no son causadas por ataques sofisticados. Son causadas por PII que entra en el pipeline porque nadie coloco una puerta de redaccion en el lugar correcto. El pipeline se construyo para optimizar la calidad de recuperacion — analisis, chunking, embedding, recuperacion — y el manejo de PII fue una ocurrencia tardia o se omitio por completo durante la fase de prototipo y nunca se agrego antes de produccion.

Ertas Data Suite incluye un nodo PII Redactor que se ubica entre el analisis y el chunking en el canvas visual del pipeline. Cuando construyes un pipeline de indexacion RAG en Ertas — Importacion de Archivos, Parser, PII Redactor, RAG Chunker, Embedding, Vector Store Writer — la puerta de redaccion es una etapa visible y auditable. Puedes inspeccionar lo que el redactor detecto, revisar casos limite y verificar que los chunks redactados esten limpios antes de que lleguen al vector store.

La redaccion no esta oculta en una funcion de utilidad. No es un script de post-procesamiento que alguien tiene que recordar ejecutar. Es un nodo en el canvas, con entradas y salidas registradas, posicionado exactamente donde necesita estar en el pipeline.

Cuando tu equipo de cumplimiento pregunta "Donde se redacta la PII?", puedes mostrarles el pipeline. Cuando un auditor pregunta "Puede probar que la PII fue eliminada antes del almacenamiento?", tienes los registros. Esa es la diferencia entre la prevencion de PII como principio de diseno y la prevencion de PII como ocurrencia tardia.

La Realidad Regulatoria

El Articulo 5 del GDPR requiere la minimizacion de datos — recopilar y procesar solo los datos personales necesarios para el proposito especificado. HIPAA requiere que la informacion de salud protegida sea desidentificada antes de poder ser utilizada para propositos mas alla del tratamiento, pago u operaciones. La Ley de IA de la UE impone obligaciones de transparencia a los sistemas de IA de alto riesgo que procesan datos personales.

Un pipeline RAG que ingiere documentos que contienen PII, almacena esa PII en una base de datos vectorial, la envia a una API de LLM de terceros y la muestra a usuarios no autorizados viola multiples disposiciones de multiples regulaciones simultaneamente. Las multas no son teoricas — la aplicacion del GDPR ha impuesto miles de millones de euros en sanciones.

La redaccion de PII en pipelines RAG no es algo deseable. Es un requisito de cumplimiento para cualquier sistema que procese documentos que contengan datos personales. Construye las puertas en el pipeline desde el inicio. Retrofitarlas despues de una brecha es mas costoso en todos los sentidos.