Registros de Auditoria para Pipelines RAG: Lo que el Articulo 30 de la Ley de IA de la UE Exige de su Sistema de Recuperacion

La Ley de IA de la UE entro en vigor en agosto de 2024. Para las empresas que ejecutan pipelines de generacion aumentada por recuperacion que alimentan aplicaciones de alto riesgo, el reloj del cumplimiento esta en marcha. Los articulos 11, 12, 13 y 30 establecen requisitos especificos para documentacion tecnica, registro automatico, transparencia y registro — y se aplican no solo al modelo que genera una respuesta, sino a cada sistema upstream que determina lo que el modelo ve.

Si su pipeline RAG ingiere documentos, los fragmenta, los integra, los almacena en una base de datos vectorial y recupera contexto para un modelo de lenguaje, cada uno de esos pasos esta ahora dentro del alcance regulatorio. La pregunta no es si necesita un registro de auditoria. La pregunta es si el que tiene hoy puede sobrevivir a una evaluacion de conformidad.

Que Hace que un Sistema Sea de "Alto Riesgo"

La Ley de IA de la UE define los sistemas de IA de alto riesgo en el Anexo III. La lista incluye sistemas utilizados en empleo y gestion de trabajadores, calificacion crediticia, suscripcion de seguros, aplicacion de la ley, procesamiento de migracion y asilo, acceso a servicios esenciales y administracion de justicia. Si su pipeline RAG alimenta cualquiera de estos casos de uso, se aplica todo el peso de los articulos 11 a 13.

La clasificacion esta impulsada por el proposito, no por la tecnologia. Un pipeline RAG que recupera preguntas frecuentes de productos para un chatbot no es de alto riesgo. La misma arquitectura de pipeline que recupera guias clinicas para una herramienta de apoyo a decisiones medicas probablemente lo es. La distincion importa porque los requisitos de documentacion y registro para sistemas de alto riesgo son detallados, prescriptivos y aplicables.

Las empresas a menudo subestiman cuantas de sus herramientas internas de IA califican. Una herramienta de seleccion de recursos humanos que utiliza RAG para extraer descripciones de puestos y documentos de politicas antes de clasificar candidatos cae directamente dentro del Anexo III. Lo mismo ocurre con una herramienta de cumplimiento que recupera texto regulatorio para ayudar a los analistas a redactar informes presentados a reguladores financieros.

Lo que los Articulos Realmente Exigen

Cuatro articulos forman el nucleo de la obligacion de registro de auditoria del pipeline RAG.

Articulo 11 — Documentacion Tecnica

El articulo 11 exige a los proveedores de sistemas de IA de alto riesgo elaborar documentacion tecnica antes de que el sistema se comercialice o ponga en servicio. Para un pipeline RAG, esto significa documentar las fuentes de datos utilizadas para la ingesta, la logica de fragmentacion y preprocesamiento, el modelo de embedding y su version, la configuracion del almacen vectorial, la estrategia de recuperacion (umbral de similitud, top-k, reordenamiento) y la plantilla de prompt que ensambla el contexto recuperado antes de pasarlo al modelo de generacion.

Este no es un ejercicio unico. La documentacion debe mantenerse actualizada durante todo el ciclo de vida del sistema. Cada vez que se cambia un modelo de embedding, se modifica una estrategia de fragmentacion o se anade una nueva fuente de datos, la documentacion tecnica debe reflejar el cambio.

Articulo 12 — Mantenimiento de Registros y Registro Automatico

El articulo 12 exige que los sistemas de IA de alto riesgo se disenen y desarrollen con capacidades que permitan el registro automatico de eventos (logs) mientras el sistema opera. Para pipelines RAG, esto se traduce en registro en cada etapa:

• Ingesta: Que documentos se ingirieron, cuando, por quien y que preprocesamiento se aplico
• Fragmentacion: Como se dividieron los documentos, que tamanos de fragmento y configuraciones de solapamiento se usaron, cuantos fragmentos resultaron
• Embedding: Que modelo y version de embedding produjo los vectores, marcas de tiempo para cada lote
• Almacenamiento: Cuando se escribieron los vectores en el almacen, cualquier operacion de deduplicacion o actualizacion
• Recuperacion: Para cada consulta, que fragmentos se recuperaron, sus puntuaciones de similitud, cualquier reordenamiento aplicado y la ventana de contexto final pasada al modelo
• Generacion: El prompt enviado al LLM, la respuesta recibida y cualquier posprocesamiento o filtrado

Los registros deben ser suficientes para reconstruir el comportamiento del sistema para cualquier salida dada. Si un regulador pregunta por que se recupero un fragmento de contexto en particular — o por que no se recupero — se necesita poder responder con evidencia con marca de tiempo.

Articulo 13 — Transparencia e Informacion a los Implementadores

El articulo 13 exige que los sistemas de IA de alto riesgo se disenen para garantizar que su operacion sea suficientemente transparente para permitir a los implementadores interpretar la salida del sistema. Para los pipelines RAG, esto significa que el usuario final o el implementador debe poder comprender que fuentes informaron una respuesta en particular.

Esto va mas alla de simplemente listar los documentos recuperados. Requiere trazabilidad: la capacidad de seguir una respuesta a traves del paso de recuperacion, a traves del almacen vectorial, a traves del embedding, a traves de la fragmentacion, hasta el documento fuente original y el pasaje especifico que contribuyo a la respuesta.

Articulo 30 — Registro en la Base de Datos de la UE

El articulo 30 exige a los proveedores e implementadores de sistemas de IA de alto riesgo registrar el sistema en la base de datos de la UE antes de comercializarlo. El registro incluye una descripcion del proposito previsto del sistema, las categorias de datos utilizados e informacion sobre el rendimiento y las limitaciones del sistema. Si su pipeline RAG es un componente de un sistema de alto riesgo registrado, su arquitectura y fuentes de datos pasan a formar parte del registro.

La Arquitectura Practica de Registro

Cumplir estos requisitos exige una arquitectura de registro que trate el pipeline RAG como un sistema auditable de primera clase, no como un complemento anadido a la inferencia.

Capa de Ingesta

Cada documento que entra en el pipeline necesita un registro de procedencia: URL de origen o ruta de archivo, marca de tiempo de ingesta, ID del operador, hash del archivo y cualquier transformacion aplicada (OCR, conversion de formato, extraccion de metadatos). Si un documento se actualiza, el sistema debe registrar el delta — que cambio, cuando y por que se activo la actualizacion.

Capa de Procesamiento

La fragmentacion y el embedding son donde la mayoria de los pipelines RAG pierden fidelidad de auditoria. Los equipos registran los vectores finales pero no los pasos intermedios que los produjeron. Un pipeline compatible registra los parametros de fragmentacion utilizados para cada documento, los fragmentos sin procesar antes y despues de cualquier limpieza o normalizacion, y la version del modelo de embedding con su configuracion. Cuando se reentrena o cambia un modelo de embedding, el registro debe capturar el estado anterior y posterior.

Capa de Recuperacion

Cada operacion de recuperacion produce un registro de auditoria: la consulta de entrada, los parametros de busqueda, los fragmentos candidatos con puntuaciones, cualquier reordenamiento o filtrado, y el contexto final pasado hacia abajo. Esta es la capa donde los requisitos de transparencia del articulo 13 son mas criticos. El registro debe soportar la respuesta a la pregunta: "Para esta salida especifica, que informacion considero el sistema y que excluyo?"

Capa de Calidad de Datos

El registro sin procesar es necesario pero no suficiente. Una evaluacion de conformidad preguntara no solo que datos entraron al pipeline, sino si los datos eran aptos para su proposito. Aqui es donde las verificaciones automatizadas de calidad se convierten en parte del registro de auditoria — puntuando fragmentos por relevancia, detectando anomalias en distribuciones de embedding y marcando documentos que caen fuera de los parametros esperados.

Como Se Ve Esto en Ertas

Ertas fue disenado con esta arquitectura de auditoria como una capa fundamental, no como un complemento de cumplimiento. Cada transformacion en el pipeline — desde la carga del archivo sin procesar hasta la entrada en el almacen vectorial — se registra con marcas de tiempo e IDs de operador. Se preserva el linaje completo de datos: se puede rastrear cualquier vector a traves de su embedding, su fragmento y su documento fuente.

El Evaluador de Calidad evalua los datos entrantes y produce metricas de calidad que pasan a formar parte del registro de auditoria. El Detector de Anomalias marca valores atipicos estadisticos en distribuciones de embeddings, longitudes de fragmentos y metadatos de origen — proporcionando evidencia documentada de que el pipeline monitoriza la calidad de los datos continuamente, no solo en el momento del despliegue.

Cuando una evaluacion de conformidad requiere demostrar que los datos de entrenamiento y recuperacion del sistema cumplieron con estandares de calidad, estos registros ya estan estructurados y son exportables. Ertas genera informes de auditoria que se mapean directamente a los requisitos de documentacion de los articulos 11 y 12, cubriendo procedencia de datos, parametros de procesamiento, puntuaciones de calidad y registros de recuperacion.

Brechas Comunes que No Superaran una Evaluacion

Basandose en los requisitos de los articulos 11 a 13, estas son las brechas con mayor probabilidad de surgir durante una evaluacion de conformidad de un pipeline RAG:

Sin versionado de modelos de embedding. Si no se puede demostrar que version del modelo de embedding produjo los vectores que estaban activos en una fecha especifica, no se puede reconstruir el comportamiento del sistema para ese periodo.

Parametros de fragmentacion no registrados. Muchos equipos codifican los ajustes de fragmentacion de forma fija y nunca los registran. Cuando los ajustes cambian, no hay registro de cual era la configuracion anterior ni cuando ocurrio el cambio.

Registros de recuperacion sin evidencia negativa. Registrar lo que se recupero es sencillo. Registrar lo que se considero y se excluyo — y por que — es mas dificil, pero los requisitos de transparencia del articulo 13 lo exigen.

Sin documentacion de calidad de datos. Ingerir documentos sin verificaciones de calidad significa que no hay evidencia de que los datos que alimentan el sistema de alto riesgo fueran apropiados. Una evaluacion de conformidad marcara esto como una brecha sistemica.

Procesos manuales sin registros de auditoria. Si un curador humano selecciona o elimina documentos del pipeline, esa decision debe registrarse con el mismo rigor que las operaciones automatizadas.

Avanzando

Los requisitos de la Ley de IA de la UE para registros de auditoria de pipelines RAG no son ambiguos. Si su sistema de recuperacion alimenta una aplicacion de alto riesgo, necesita registro automatico en cada etapa del pipeline, documentacion tecnica que se mantenga actualizada con los cambios del sistema, mecanismos de transparencia que permitan a los implementadores rastrear salidas hasta las fuentes, y evidencia de calidad de datos que demuestre la idoneidad para el proposito.

Las organizaciones que tratan esto como una restriccion de diseno — integrando registros de auditoria en la arquitectura del pipeline desde el inicio — encontraran el cumplimiento sencillo. Las que intenten adaptar el registro a un pipeline existente lo encontraran costoso, fragil y perpetuamente incompleto.

La regulacion no exige que se deje de construir sistemas RAG. Exige que se construyan de forma que cada paso quede registrado, cada transformacion sea rastreable y cada salida pueda explicarse. Eso no es solo buen cumplimiento. Es buena ingenieria.