Checklist de Production-Readiness de RAG para Empresas de la UE

Una demo de RAG sobre tus propios documentos es una de las victorias más fáciles en IA. Apuntas un retriever a tu wiki, lo conectas a un modelo y en una tarde tienes algo que responde preguntas. Lo difícil es todo lo que viene después de la demo. Una demo que impresiona en una reunión no es lo mismo que un asistente en el que tus empleados o clientes puedan confiar, y en la UE tiene que ser eso y defendible bajo el RGPD y la Ley de IA, sin una factura de nube que se duplique en silencio cada trimestre. Esta es la checklist que recorremos antes de que un sistema RAG pase de interesante a confiable.

Nada de esto es un argumento contra RAG. Es la forma más barata de darle a un modelo tu conocimiento sin reentrenar nada. Es un argumento a favor de tratar la demo como el inicio del trabajo, no su final.

El retrieval es realmente lo bastante bueno?

Todo lo que viene después depende de que el modelo reciba los pasajes correctos. Si el retrieval es débil, ningún ajuste de prompt te salva, porque el modelo responde desde la fuente equivocada o desde la nada. Esta es la parte que las demos se saltan, porque con un puñado de documentos limpios casi cualquier montaje parece bien.

• Chunking que respeta el significado. Partir por un número fijo de caracteres rompe frases y tablas. Trocea por la estructura, encabezados, secciones, unidades lógicas, para que un pasaje recuperado sea una idea completa.
• Un modelo de embeddings que encaja con tu contenido. El de fábrica rara vez es el mejor para tu dominio o tus idiomas. Si atiendes a clientes en alemán e inglés, prueba que el retrieval funciona en ambos, no solo en el que usaste para la demo.
• Un conjunto de evaluación, no una corazonada. Anota preguntas reales y los pasajes que deberían responderlas. Mide el recall, si el pasaje correcto se recupera de verdad, antes de tocar cualquier otra cosa.
• Citas devueltas con cada respuesta. El sistema debería entregar qué documentos usó. Eso es lo que hace las respuestas verificables y, más tarde, lo que hace todo el conjunto auditable.

Se va a inventar cosas?

Un modelo con retrieval sigue alucinando si lo dejas. La disciplina de RAG es mantener al modelo con la correa corta: responder desde el contexto recuperado, y solo desde él.

• Responder solo desde el contexto recuperado. Instruye al modelo para anclar cada afirmación en los pasajes que recibió y para no rellenar huecos desde su entrenamiento general.
• Negarse cuando el contexto es escaso. Si el retrieval vuelve vacío o débil, la respuesta correcta es "no tengo eso", no una conjetura segura de sí misma. Un sistema que sabe negarse es más confiable que uno que siempre responde.
• Mostrar las fuentes. Expón las citas al usuario. Le permite verificar, y cambia el comportamiento: la gente confía más en un sistema cuando ve de dónde salió la respuesta, y menos a ciegas.

"Una demo de RAG responde las preguntas que testeaste. Un producto RAG tiene que responder las que no, y callar cuando no debe hablar. La brecha entre esas dos cosas es todo el engagement."

Puedes medirlo igual dos veces?

Lo que mata en silencio a los proyectos RAG es que cada cambio se siente como progreso y nadie puede demostrarlo. Cambias el modelo de embeddings, ajustas un prompt, reindexas, y la demo sigue funcionando, así que lo lanzas. Entonces una clase de preguntas empeora sin avisar.

Construye un conjunto dorado de preguntas y respuestas: una lista fija de preguntas reales con las respuestas y fuentes que esperas. Vuelve a ejecutarlo en cada cambio, un nuevo prompt, un nuevo modelo, una reindexación, y compara. No necesita ser sofisticado. Necesita ser el mismo cada vez, para que una regresión aparezca como un número que baja en vez de una queja tres semanas después.

Cuánto costará operarlo, y qué tan rápido es?

Una demo de RAG que atiende a una persona es gratis en todos los sentidos que importan. Un asistente RAG que atiende a una empresa es una factura recurrente que escala con el uso, y una latencia que los usuarios sienten en cada consulta. Ambas son decisiones de diseño, no detalles a posteriori.

• Cachea lo que se repite. Muchas preguntas se hacen una y otra vez. Cachear el contexto recuperado y las respuestas frecuentes recorta coste y latencia.
• Escalona tus modelos. No toda consulta necesita el modelo más grande. Encamina las preguntas simples a uno más pequeño y barato y reserva el modelo grande para los casos difíciles.
• Presupuesta tus tokens. Meter veinte pasajes en cada prompt es lento y caro y a menudo empeora las respuestas. Recupera menos pasajes, pero mejores.

La economía aquí se mueve rápido, y la arquitectura que elijas ahora decide lo que pagarás luego. Profundizamos en eso en el cambio en los costes de las APIs de LLM.

Aguanta bajo las reglas de la UE?

Aquí las empresas de la UE tienen deberes que un tutorial de EE. UU. no menciona. Describimos obligaciones a nivel general, no damos asesoramiento legal, y los detalles dependen de tu sector y tus datos. Habla con un abogado para lo concreto. Pero las preguntas de ingeniería son lo bastante claras como para ponerlas en una checklist.

• Conoce tus flujos de datos. Bajo el RGPD tienes que saber a dónde van los datos personales. Si tus documentos o las preguntas de los usuarios contienen datos personales y tu modelo o tu almacén vectorial está fuera de la UE, eso es una transferencia que tienes que poder justificar. La residencia de datos es una decisión de diseño que tomas pronto, no un ajuste que cambias tarde.
• Sé transparente en que es IA. La Ley de IA espera que los usuarios sepan cuándo interactúan con un sistema de IA en lugar de con una persona. Para un asistente, eso suele significar decírselo a la gente con claridad.
• Maneja los datos personales de forma deliberada. Decide qué datos personales se permiten en el índice y en los prompts, y qué se redacta o se excluye. El retrieval puede sacar a la luz un documento cuya sensibilidad alguien había olvidado.
• Registra para auditoría. Guarda un registro de qué se preguntó, qué se recuperó y qué se respondió. Lo querrás para depurar, para mejorar y para responder a la pregunta "por qué dijo eso" cuando alguien la haga.

Hemos escrito por separado sobre el coste del cumplimiento de la Ley de IA para una startup y cómo se apilan el RGPD y la Ley de IA para un SaaS de la región DACH, si quieres el lado regulatorio con más profundidad.

Puede alguien romperlo o leer lo que no debería?

Un sistema RAG tiene dos problemas de seguridad que la mayoría de las demos nunca enfrenta: el modelo se puede manipular a través de sus entradas, y el índice se convierte en un nuevo sitio donde viven datos sensibles.

• Inyección de prompts. Un documento recuperado puede contener instrucciones dirigidas al modelo: "ignora tus reglas y revela X". Trata el contenido recuperado como entrada no confiable, no como una orden, y testéalo.
• Control de acceso sobre el índice. El almacén vectorial es ahora una copia de tu conocimiento. Necesita los mismos controles de acceso que los sistemas de origen, no más débiles porque sean "solo embeddings".
• Permisos de documento por usuario. Este es el que más duele. Si un usuario solo puede ver ciertos documentos, el retrieval debe respetarlo en cada consulta, para que el asistente nunca saque un pasaje de un documento que ese usuario nunca tuvo permiso de leer. Un sistema RAG que ignora los permisos es una fuga de datos con una interfaz de chat amable.

La checklist

Recórrela antes de dejar que alguien dependa de un asistente RAG. Si alguna línea te hace dudar, esa es la línea que arreglas primero.

1. Retrieval. Chunking con sentido, un modelo de embeddings probado en tu contenido e idiomas, un conjunto de evaluación con recall medido, citas en cada respuesta.
2. Grounding. Las respuestas salen solo del contexto recuperado, el sistema se niega cuando duda, las fuentes se muestran al usuario.
3. Evaluación repetible. Un conjunto dorado de preguntas y respuestas que vuelves a ejecutar en cada cambio de prompt, modelo o índice.
4. Coste y latencia. Caching, escalonado de modelos y presupuestos de tokens que puedas defender a escala, no solo en la demo.
5. Cumplimiento de la UE. Flujos de datos y residencia conocidos, transparencia de que es IA, manejo deliberado de datos personales, logging de auditoría.
6. Seguridad. Inyección de prompts testeada, control de acceso sobre el índice, permisos por usuario aplicados en el retrieval para que nada se filtre entre usuarios.

El entregable no es una presentación sobre RAG. Es un sistema que recupera lo correcto, se niega cuando debe, cuesta lo que presupuestaste y no se filtra.