RAG en sectores regulados: arquitectura para IA con datos sensibles
Retrieval-Augmented Generation permite usar IA sobre documentos internos sin exponer datos a terceros. Cómo funciona, cuándo conviene y qué subestiman las implementaciones.
Las organizaciones en sectores regulados — banca, seguros, energía, gobierno — enfrentan un dilema específico con la inteligencia artificial generativa. Por un lado, los modelos de lenguaje ofrecen capacidades que pueden transformar procesos intensivos en conocimiento: consulta de normativas, análisis de contratos, respuesta a clientes, generación de reportes. Por otro lado, enviar documentos regulatorios, datos de clientes o información estratégica a una API externa — ya sea de OpenAI, Anthropic o Google — presenta problemas de cumplimiento que van desde restricciones de la superintendencia bancaria hasta obligaciones contractuales de confidencialidad con clientes. La respuesta técnica a este dilema es Retrieval-Augmented Generation (RAG), una arquitectura que permite que un modelo de lenguaje responda preguntas basándose en documentos específicos de la organización sin necesidad de que esos documentos se usen para entrenar el modelo.
Lewis et al. (2020) formalizaron RAG como una arquitectura que combina un componente de recuperación de información (retrieval) con un modelo generativo. En términos operativos: cuando un usuario hace una pregunta, el sistema busca en una base de conocimiento los fragmentos de documentos más relevantes para esa pregunta, inyecta esos fragmentos como contexto en el prompt del modelo de lenguaje, y el modelo genera una respuesta basada en ese contexto. El modelo no “sabe” la información — la lee en el momento de la consulta, de manera similar a como una persona consultaría un manual antes de responder una pregunta técnica.
La ventaja de RAG sobre el fine-tuning para casos de uso en sectores regulados es estructural. El fine-tuning modifica los parámetros del modelo con datos de entrenamiento, lo que significa que los datos se incorporan al modelo y potencialmente pueden ser extraídos. RAG no modifica el modelo — los documentos permanecen en una base de datos vectorial que la organización controla, y el modelo solo los ve durante la inferencia. Cuando la regulación cambia, se actualiza la base de documentos sin necesidad de re-entrenar el modelo. Cuando se desea revocar acceso a cierta información, se elimina del índice vectorial. Esta separación entre el modelo y los datos es lo que hace a RAG particularmente apropiado para entornos donde la gobernanza de la información es un requerimiento, no una preferencia.
La implementación técnica de RAG involucra cuatro componentes: la ingesta de documentos (parsing, chunking, limpieza), la generación de embeddings (representaciones vectoriales de cada fragmento), el almacenamiento en una base de datos vectorial (Qdrant, Pinecone, Chroma, Weaviate), y la cadena de consulta (búsqueda semántica + generación). Cada componente tiene decisiones de diseño que afectan la calidad del resultado, y la mayoría de las implementaciones subestiman la importancia de las decisiones tempranas — particularmente el chunking.
El chunking — cómo se dividen los documentos en fragmentos para indexación — es probablemente la decisión más determinante y menos discutida de una implementación RAG. Un documento regulatorio de 200 páginas puede dividirse en fragmentos de 500 tokens, de 1,000 tokens, por párrafo, por sección, o por unidad semántica. Fragmentos demasiado pequeños pierden contexto — una respuesta sobre un artículo regulatorio que no incluye las excepciones mencionadas tres párrafos después es potencialmente incorrecta. Fragmentos demasiado grandes consumen ventana de contexto del modelo y diluyen la relevancia. No existe un tamaño óptimo universal; la estrategia de chunking debe calibrarse empíricamente para cada tipo de documento, lo cual requiere iteración y evaluación que las organizaciones rara vez presupuestan.
La calidad de la búsqueda semántica — la capacidad del sistema de encontrar los fragmentos realmente relevantes para una consulta — depende de los modelos de embedding utilizados. Los embeddings de propósito general (como los de OpenAI o sentence-transformers) funcionan razonablemente bien para texto general pero pueden fallar con terminología de dominio específica. Un embedding que no distingue entre “reserva técnica” en el sentido actuarial y “reserva técnica” en el sentido contable va a recuperar fragmentos irrelevantes. Los embeddings especializados o fine-tuneados para el dominio mejoran la precisión pero requieren datos de entrenamiento etiquetados y competencia técnica para entrenarlos.
Las alucinaciones — respuestas que el modelo genera con aparente confianza pero que no están respaldadas por los documentos recuperados — son el riesgo más significativo de RAG en contextos regulados. Un modelo que afirma que un artículo regulatorio dice algo que no dice, en un contexto donde esa respuesta puede informar una decisión de cumplimiento, es un riesgo operativo concreto. Las técnicas de mitigación incluyen prompts que instruyen al modelo a citar las fuentes específicas de cada afirmación, verificación automática de que las citas correspondan al contenido recuperado, y umbrales de confianza que derivan al usuario a revisión manual cuando la relevancia de los documentos recuperados es baja. Ninguna de estas técnicas elimina el riesgo completamente — lo reduce a un nivel que debe ser gestionado como cualquier otro riesgo operativo.
La decisión entre RAG sobre una API externa (OpenAI, Anthropic) y RAG sobre un modelo local (LLaMA, Mistral, Qwen ejecutado en hardware propio) tiene implicaciones de gobernanza que van más allá del costo. Con una API externa, los documentos se envían al proveedor durante la inferencia — aunque los proveedores ofrecen garantías de no retención, la transmisión misma puede constituir un problema regulatorio dependiendo de la jurisdicción y el tipo de datos. Con un modelo local, los documentos nunca salen de la infraestructura de la organización, pero la calidad del modelo local puede ser inferior a la del modelo comercial, y la operación requiere hardware y competencia técnica que la organización debe mantener. No existe una respuesta correcta universal — la decisión depende del perfil de riesgo regulatorio, la sensibilidad de los datos, el presupuesto de infraestructura y la competencia técnica disponible.
Un error frecuente en implementaciones de RAG es tratar la base de conocimiento como un repositorio estático. Los documentos regulatorios cambian, los manuales de proceso se actualizan, las políticas internas evolucionan. Si la base de conocimiento no se mantiene sincronizada con las fuentes de verdad, el sistema produce respuestas basadas en información desactualizada — que es potencialmente peor que no tener sistema, porque el usuario confía en la respuesta sin saber que la fuente está obsoleta. La cadencia de actualización, la verificación de versiones y la gestión del ciclo de vida de los documentos indexados son problemas de governance de datos aplicados a la infraestructura de RAG, y requieren los mismos mecanismos que cualquier sistema de gestión documental: ownership, cadencia de revisión y trazabilidad.
La evaluación de un sistema RAG en producción requiere métricas que la mayoría de las implementaciones no recolectan. La precisión de retrieval (¿los fragmentos recuperados son relevantes para la consulta?), la fidelidad de la generación (¿la respuesta refleja lo que dicen los documentos recuperados?), la cobertura (¿el sistema tiene documentos suficientes para responder las consultas que recibe?), y la tasa de alucinación (¿con qué frecuencia genera información no respaldada por las fuentes?) son métricas que deben monitorearse continuamente, no evaluarse una vez durante el desarrollo. Un sistema que tiene 95% de precisión durante el piloto puede degradarse a 80% en producción si los tipos de consultas que los usuarios reales hacen son diferentes a los que se usaron para evaluar.
Para organizaciones en Panamá y Centroamérica que operan en sectores regulados, RAG sobre modelos locales representa una arquitectura que resuelve el dilema de soberanía de datos sin renunciar a las capacidades de la IA generativa. Pero la implementación requiere inversión en tres dimensiones que frecuentemente se subestiman: infraestructura (hardware GPU, bases de datos vectoriales, pipelines de ingesta), datos (preparación, chunking, mantenimiento de la base de conocimiento), y capacidad humana (ingenieros que operen el sistema, expertos de dominio que validen la calidad, y un marco de gobernanza que defina responsabilidades). El costo total de ownership de un sistema RAG funcional en un banco mediano no es trivial — pero el costo de no tenerlo, cuando los competidores empiezan a usarlo para responder consultas regulatorias en minutos en lugar de horas, es un costo de oportunidad que crece con cada mes de retraso.
Referencias
- Carlini, N., Tramèr, F., Wallace, E., et al. (2021). Extracting training data from large language models. In 30th USENIX Security Symposium (pp. 2633-2650).
- Lewis, P., Perez, E., Piktus, A., et al. (2020). Retrieval-augmented generation for knowledge-intensive NLP tasks. Advances in Neural Information Processing Systems, 33, 9459-9474.