El mejor pipeline RAG con redacción de PII integrada: por qué la recuperación sin redacción es un riesgo de cumplimiento

La generación aumentada por recuperación se ha convertido en la arquitectura predeterminada para aplicaciones empresariales de IA que necesitan responder preguntas sobre documentos internos. El patrón es sencillo: fragmentar los documentos, incrustarlos en un almacén de vectores y recuperar el contexto relevante en tiempo de consulta para fundamentar las respuestas del LLM en sus propios datos.

El problema es que la mayoría de los pipelines RAG indexan documentos sin procesar con PII intacta. Nombres, direcciones de correo electrónico, números de seguridad social, identificadores de registros médicos, números de cuentas financieras — todo se incrusta junto al contenido empresarial. Una vez que esos datos están en el almacén de vectores, cualquier consulta que aterrice lo suficientemente cerca en el espacio de incrustación puede recuperarlos.

Las bases de datos vectoriales no fueron diseñadas con control de acceso a nivel de registro. Optimizan la búsqueda por similitud, no la autorización. Una consulta sobre "objetivos de ingresos del tercer trimestre" puede devolver fragmentos que contienen la dirección particular de un cliente porque ambos aparecieron en el mismo párrafo del contrato. Según una encuesta de IAPP de 2024, el 67% de las organizaciones informaron que sus sistemas de IA procesan datos personales sin las salvaguardas adecuadas, y los almacenes de vectores son un punto ciego creciente.

Este no es un riesgo teórico. Es una violación de cumplimiento bajo el Artículo 25 del GDPR (protección de datos por diseño), el estándar de mínimo necesario de HIPAA y los requisitos de transparencia y gobernanza de datos de la Ley de IA de la UE. La mejor manera de construir RAG con redacción de PII es eliminar los datos sensibles antes de que lleguen al paso de incrustación.

Por qué la redacción de PII debe ocurrir antes de la incrustación

Existe un error común de que se puede redactar PII después de la recuperación — filtrar el contexto antes de que llegue al prompt del LLM. Este enfoque falla por tres razones.

Las incrustaciones codifican PII semánticamente. Cuando se incrusta una oración como "Paciente John Smith, fecha de nacimiento 15/03/1982, fue diagnosticado con diabetes tipo 2", el vector de incrustación captura el significado semántico de toda la oración, incluidos los identificadores personales. El vector en sí se convierte en una representación de PII. Incluso si elimina el nombre del texto recuperado, el almacén de vectores aún contiene una incrustación que codifica la identidad de esa persona junto con su condición médica.

El filtrado posterior a la recuperación es incompleto. El reconocimiento de entidades nombradas en los fragmentos recuperados detecta patrones obvios — nombres, números de teléfono, SSN en formatos estándar. Pero no detecta PII incrustada en texto narrativo, nombres mal escritos, identificadores internos de empleados, formatos de identificación personalizados y contexto que es identificativo en combinación. Un fragmento que menciona "el VP de Ingeniería que se unió en marzo de 2024 proveniente del equipo DeepMind de Google" no contiene PII por coincidencia de patrones, pero identifica a exactamente una persona.

No se puede eliminar selectivamente de los almacenes de vectores. El Artículo 17 del GDPR otorga a las personas el derecho de supresión. Si un cliente solicita la eliminación y su PII está incrustada en 500 fragmentos vectoriales, no se puede eliminar quirúrgicamente sus datos sin volver a incrustar conjuntos completos de documentos. La redacción de PII antes de la indexación RAG elimina este problema por completo — no hay nada que eliminar porque la PII nunca se almacenó.

La arquitectura correcta realiza la redacción entre el análisis del documento y la fragmentación, de modo que el fragmentador y el modelo de incrustación solo ven texto redactado. Esta es la diferencia entre un pipeline RAG compatible con GDPR y uno que crea una responsabilidad continua de cumplimiento.

Cómo Ertas resuelve esto con un pipeline visual

Ertas Data Suite es una aplicación de escritorio local construida sobre Tauri 2.0 (Rust y React) que proporciona un constructor visual de pipelines basado en grafos de nodos con 25 tipos de nodos en 8 categorías. En lugar de escribir scripts de LangChain y agregar detección personalizada de PII, se construye todo el pipeline RAG conectando nodos en un lienzo.

El pipeline de indexación fluye de la siguiente manera: Importación de archivos para incorporar documentos desde directorios locales, luego Analizador para extraer texto estructurado de PDFs, DOCX y otros formatos, luego Redactor de PII para detectar y reemplazar entidades sensibles, luego Fragmentador RAG para dividir el texto en segmentos apropiados para la recuperación, luego Incrustación para generar vectores mediante un modelo local, y finalmente Escritor de almacén de vectores para persistir las incrustaciones limpias.

El pipeline de recuperación conecta: Endpoint de API recibe una consulta, Incrustador de consultas la vectoriza, Búsqueda vectorial encuentra fragmentos relevantes, Ensamblador de contexto construye el contexto del prompt, y Respuesta de API devuelve la respuesta fundamentada.

La decisión de diseño crítica es que el nodo Redactor de PII se sitúa entre el análisis y la fragmentación. Cada documento pasa por la detección y reemplazo de entidades antes de que ocurra cualquier procesamiento posterior. El fragmentador nunca ve PII sin procesar. El modelo de incrustación nunca ve PII sin procesar. El almacén de vectores nunca contiene PII sin procesar. Cómo redactar PII antes de incrustar documentos se convierte en una operación visual de arrastrar y soltar en lugar de un proyecto de scripts personalizados.

Dado que Ertas se ejecuta completamente en las instalaciones del cliente, los documentos, los modelos de redacción, las incrustaciones y el almacén de vectores permanecen dentro de su infraestructura. Ningún dato sale del edificio.

Comparación: tres enfoques para RAG seguro en cuanto a PII

La mejor herramienta para un pipeline RAG seguro en cuanto a PII depende de sus restricciones, pero el diferenciador clave es si la redacción de PII es una etapa del pipeline de primera clase o una solución improvisada agregada con código personalizado.

El caso de cumplimiento

Tres marcos regulatorios hacen que la redacción de PII antes de la indexación RAG sea un requisito en lugar de una mejor práctica.

GDPR (Artículos 5, 25 y 35). La minimización de datos requiere que solo se procesen los datos personales necesarios para su propósito. Si el propósito de su sistema RAG es responder preguntas empresariales, los identificadores personales en el almacén de vectores son datos innecesarios. El Artículo 25 exige la protección de datos por diseño — incorporar PII en su arquitectura de recuperación por defecto viola este principio. Las organizaciones que procesan datos personales a gran escala a través de sistemas RAG probablemente necesitarán una Evaluación de Impacto de Protección de Datos bajo el Artículo 35.

HIPAA (Estándar de mínimo necesario y Safe Harbor). Las organizaciones de salud que utilizan RAG sobre notas clínicas, resúmenes de alta o registros de seguros deben aplicar el estándar de mínimo necesario: acceder solo a la PHI necesaria para el propósito específico. Un pipeline RAG que incrusta registros completos de pacientes y los recupera basándose en similitud semántica proporciona mucha más PHI de la necesaria. El método Safe Harbor de HIPAA identifica 18 tipos específicos de identificadores que deben eliminarse para la desidentificación — un nodo Redactor de PII se puede configurar para apuntar exactamente a estos.

Ley de IA de la UE (Artículos 10 y 15). La Ley de IA de la UE requiere que los datos de entrenamiento y operación para sistemas de IA cumplan con estándares de calidad y gobernanza. El Artículo 10 aborda específicamente la gobernanza de datos, incluyendo el examen de sesgos y la idoneidad de los datos utilizados. El Artículo 15 exige registro y trazabilidad. Un pipeline RAG con redacción de PII integrada y registro de auditoría aborda ambos requisitos. Las organizaciones que despliegan sistemas de IA de alto riesgo — lo que incluye muchas aplicaciones empresariales — deben demostrar cumplimiento antes de agosto de 2027.

Construcción de un pipeline RAG seguro en cuanto a PII en Ertas: paso a paso

Este es el flujo de trabajo concreto para configurar un pipeline RAG con redacción de PII en Ertas Data Suite.

Paso 1: nodo de Importación de archivos. Arrastre un nodo de Importación de archivos al lienzo. Apúntelo al directorio que contiene sus documentos fuente. Los formatos compatibles incluyen PDF, DOCX, TXT, HTML y Markdown. El nodo indexa el directorio y lista los archivos disponibles.

Paso 2: nodo Analizador. Conecte la salida de Importación de archivos a un nodo Analizador. El analizador extrae texto estructurado, preservando los límites de párrafo y los metadatos (números de página, encabezados, títulos de documentos). Para PDFs con diseños complejos, el analizador maneja texto multicolumna y tablas incrustadas.

Paso 3: nodo Redactor de PII. Conecte la salida del Analizador a un nodo Redactor de PII. Configure qué tipos de entidades detectar: nombres de personas, direcciones de correo electrónico, números de teléfono, SSN, números de registro médico, números de cuentas financieras, fechas de nacimiento, direcciones físicas y más. Establezca la estrategia de redacción — reemplazo con marcadores del tipo de entidad (por ejemplo, "[PERSON_NAME]") o eliminación completa. Ajuste los umbrales de confianza por tipo de entidad si es necesario.

Paso 4: nodo Fragmentador RAG. Conecte la salida del Redactor de PII a un Fragmentador RAG. Configure el tamaño de fragmento (típicamente 256-512 tokens para recuperación) y la superposición (10-15% para continuidad de contexto). El fragmentador opera sobre texto ya redactado, por lo que cada fragmento está libre de PII por construcción.

Paso 5: nodo de Incrustación. Conecte el fragmentador a un nodo de Incrustación. Seleccione un modelo de incrustación local — el nodo ejecuta la inferencia en su hardware. Ningún texto de documento se envía a APIs externas.

Paso 6: nodo Escritor de almacén de vectores. Conecte las incrustaciones a un Escritor de almacén de vectores. Las incrustaciones limpias y libres de PII se persisten en su base de datos vectorial local.

Paso 7: cadena de recuperación. En un área separada del lienzo, construya la ruta de consulta: Endpoint de API a Incrustador de consultas a Búsqueda vectorial a Ensamblador de contexto a Respuesta de API. El lado de recuperación se conecta al mismo almacén de vectores pero solo lee contenido libre de PII.

Todo el pipeline es visible en un solo lienzo. Puede inspeccionar los datos en cada punto de conexión — verificar que la PII fue detectada y redactada antes de que llegue al fragmentador. El enfoque visual hace que el pipeline sea auditable por equipos de cumplimiento que no leen Python.

Trabajando con socios de diseño

Ertas está trabajando actualmente con socios de diseño para validar estos flujos de trabajo en industrias que incluyen salud, servicios financieros y legal. Si su organización está construyendo sistemas RAG sobre documentos sensibles y luchando con las implicaciones de cumplimiento, Ertas Data Suite proporciona el mejor pipeline RAG con redacción de PII integrada — una solución visual y local donde los datos sensibles nunca entran en el almacén de vectores y nunca salen de su infraestructura.

Lectura adicional

• El 80% de los datos empresariales no están estructurados — Por qué los datos no estructurados dominan los entornos empresariales y qué significa eso para los pipelines de IA.
• Redacción de PII y PHI en instalaciones locales en múltiples industrias — Cómo los flujos de trabajo de redacción en instalaciones locales abordan los requisitos de cumplimiento en salud, finanzas y legal.