Ya publicamos una guía práctica para preparar los datos de tu empresa antes de montar un sistema RAG: inventario de fuentes, cumplimiento del RGPD, decisión sobre dónde vive el índice, extracción y troceado de documentos, herencia de permisos y automatización de la ingesta. Si tu proyecto todavía está en esa fase, esa guía sigue siendo el punto de partida.
Esta guía no repite el trabajo de preparación de datos: retoma donde aquella termina y cubre la parte que casi nunca aparece en las guías técnicas de RAG: qué ocurre una vez el sistema ya está montado. Quién decide a partir de entonces qué entra y qué sale del índice, cómo se mide si el sistema funciona de verdad y qué protocolo sigue la empresa cuando responde mal delante de un cliente o de un empleado. Es la capa organizativa del proyecto, no la técnica, y en la práctica suele decidir si un RAG sigue vivo pasado el primer año o se convierte en un sistema que nadie se atreve a tocar ni a apagar.
De montar el sistema a gobernarlo
La primera guía se centraba en preparar los documentos y llegaba hasta el despliegue con monitorización: «¿cómo preparo mis documentos para que un RAG pueda leerlos?». Esta responde a otra distinta y, en la práctica, más difícil de resolver: «¿quién decide, mes a mes, qué entra en el índice, qué sale de él y si la calidad de las respuestas sigue siendo suficiente?». Montar un RAG es un proyecto con fecha de entrega, como se explica en nuestro artículo sobre plazos y fechas clave de un proyecto RAG. Gobernarlo es una función continua, sin fecha de cierre, que necesita responsables nombrados, una cadencia de revisión fija y métricas que alguien mire con regularidad, no solo el día del lanzamiento.
Un RAG bien montado y sin gobierno se degrada igual que uno mal montado, solo que tarda más tiempo en notarse. La diferencia entre los dos casos rara vez está en la arquitectura: está en si alguien tiene la responsabilidad explícita de revisar el sistema pasado el primer mes de uso.
Paso 1 — Formar el comité de gobierno de datos del RAG
En una pyme no hace falta un comité formal con acta y calendario cerrado, pero sí hacen falta cuatro papeles cubiertos por personas concretas, con nombre y apellidos, no por «el departamento que corresponda»:
- Propietario de negocio del dominio. Decide qué preguntas debe poder responder el sistema en su área y revisa con regularidad si las respuestas son correctas y útiles.
- Responsable de fuentes. Mantiene actualizado el inventario, ejecuta las altas y las bajas de documentos y sabe, en todo momento, qué fuentes alimentan el índice.
- Persona de cumplimiento. Valida que las fuentes nuevas no incorporen datos personales o confidenciales sin la base jurídica y el control de acceso adecuados; en una pyme suele ser la misma persona que ya lleva el cumplimiento del RGPD en otros procesos.
- Validadores de negocio. Un grupo reducido de usuarios que revisa muestras de respuestas de forma periódica y señala las que fallan.
Qué decide el comité y con qué frecuencia
Una reunión mensual de treinta o cuarenta minutos suele bastar para revisar tres cosas: las incidencias abiertas desde la última revisión, las fuentes candidatas a entrar o salir del índice y las métricas de calidad del periodo. La clave no es la duración de la reunión, sino que exista con una cadencia fija y que alguien tenga la autoridad para decidir, ese mismo día, si una fuente entra, se pospone o se descarta.
Paso 2 — Definir el ciclo de vida de cada fuente: alta, revisión y baja
La guía de preparación de datos explica cómo clasificar y trocear una fuente antes de indexarla. Lo que falta después es un proceso repetible para gestionar esa fuente durante el resto de su vida útil, no solo el día en que se incorpora.
Alta: criterios de entrada
Antes de indexar una fuente nueva conviene comprobar, por escrito, que tiene propietario asignado, que su nivel de confidencialidad está clasificado y que no duplica una fuente ya existente. Sin estos tres requisitos cumplidos, la fuente se queda en una lista de pendientes hasta que alguien los resuelve, en lugar de entrar directamente en el índice porque ya esté lista desde el punto de vista técnico.
Revisión periódica: cadencia por tipo de fuente
No todas las fuentes envejecen al mismo ritmo. Las políticas internas y los procedimientos regulados conviene revisarlos cada trimestre; los manuales de producto y las condiciones comerciales, cada semestre; con el contenido de referencia que apenas cambia basta una revisión anual. Fijar esta cadencia por tipo de fuente, en lugar de aplicar la misma revisión anual a todo el corpus, evita que un procedimiento derogado siga citándose durante meses porque nadie tenía asignada su revisión.
Baja: retirar una fuente sin dejar huérfanos en el índice
Retirar un documento del repositorio de origen no lo retira automáticamente del índice vectorial si la automatización de ingesta no está preparada para detectar bajas, como se explica en la guía original. Antes de dar de baja una fuente conviene comprobar que el proceso de reindexado elimina también sus fragmentos del índice y que ninguna respuesta reciente sigue citando esa fuente como vigente.
Paso 3 — Medir calidad con métricas que sirvan para decidir, no solo para informar
Muchos proyectos de RAG se conforman con una impresión general de que «funciona bien», basada en unas pocas pruebas manuales. Esa impresión no sirve para decidir si hay que ampliar el acceso a más usuarios ni para detectar una degradación progresiva. Conviene medir, como mínimo, estas cuatro métricas de forma sistemática:
| Métrica | Qué mide | Umbral orientativo para ampliar acceso |
|---|---|---|
| Fidelidad (groundedness) | Si la respuesta se apoya únicamente en los fragmentos recuperados, sin añadir información que no está en las fuentes | Por encima del 90% en el banco de preguntas de referencia |
| Cobertura de citas | Porcentaje de respuestas que incluyen una fuente verificable y correcta | Por encima del 85% |
| Tasa de abstención correcta | Con qué frecuencia el sistema reconoce que no tiene información suficiente en lugar de inventar una respuesta | Cercana al 100% en preguntas sin respuesta en el corpus |
| Tiempo medio de corrección | Días que transcurren entre que se detecta una respuesta incorrecta y se corrige la fuente o el troceado que la causó | Por debajo de una semana para incidencias marcadas como críticas |
Estos umbrales son orientativos y conviene adaptarlos al riesgo de cada dominio: un RAG que responde dudas internas de recursos humanos puede tolerar umbrales algo más laxos que uno que atiende directamente a clientes.
Paso 4 — Montar el panel operativo y la cadencia de revisión
Las métricas anteriores solo sirven si alguien las revisa con regularidad. Un panel operativo sencillo, revisado cada semana por el responsable de fuentes, debería mostrar las consultas que no obtuvieron una respuesta útil, las que el sistema respondió sin citar fuente y las marcadas manualmente como incorrectas por algún usuario. La revisión semanal detecta problemas puntuales; el informe mensual que llega al comité de gobierno es el que detecta tendencias, como una fuente que empieza a generar más incidencias que el resto tras una actualización reciente.
Paso 5 — Protocolo de incidencias: qué hacer cuando el sistema se equivoca
Antes de lanzar a producción conviene tener escrito, no improvisado, qué pasos sigue la empresa cuando el RAG da una respuesta incorrecta:
- Detectar. Un usuario marca la respuesta como incorrecta, o el panel operativo la señala por falta de cita o baja confianza.
- Contener. Si el error viene de una fuente concreta, esa fuente se marca temporalmente como de baja confianza mientras se revisa, en lugar de dejarla activa mientras se investiga.
- Corregir. Se corrige el documento de origen, el troceado o los permisos, según cuál sea la causa real del error; la lista de errores más caros en un proyecto RAG repasa las causas técnicas más habituales.
- Comunicar. Si el error llegó a un cliente o afectó a una decisión de negocio, alguien debe decidir si hace falta avisar a las personas afectadas, no solo corregir el sistema en silencio.
- Registrar. La pregunta que falló se añade al banco de evaluación, para comprobar en cada revisión posterior que el mismo error no vuelve a producirse.
Sin este protocolo por escrito, cada incidencia se resuelve de forma distinta según quién la atienda ese día, y es habitual que el mismo tipo de error se repita varias veces antes de que alguien lo trate como un problema del sistema en lugar de un caso aislado.
Paso 6 — Conseguir que las personas usen el sistema y avisen cuando falla
Un RAG con buena arquitectura y sin usuarios activos no genera ningún valor, y un RAG con usuarios que no saben cómo avisar de un error tampoco mejora con el tiempo. Un botón visible de «esta respuesta no es correcta» en cada respuesta, revisado de verdad por alguien, suele aportar más señal de calidad que cualquier prueba automatizada. Conviene además nombrar a una persona de referencia por departamento, alguien que ya conoce bien el contenido de esa área, para que resuelva dudas de uso y traslade al comité de gobierno los patrones de preguntas que el sistema todavía no cubre.
Paso 7 — Presupuesto operativo: lo que sigue costando después del lanzamiento
El coste de un RAG no termina en la factura del proyecto inicial. Una vez en producción, la empresa sigue asumiendo el coste de la infraestructura del índice, las llamadas al modelo de lenguaje y las horas dedicadas a revisar fuentes y corregir incidencias. A medida que crece el número de dominios y usuarios, se añaden además herramientas de monitorización y evaluación continua, que conviene planificar desde el principio en lugar de improvisar cuando el sistema ya falla de forma visible. Esa capa de monitorización y evaluación continua es lo que trabajamos en LLMOps y evaluación de agentes IA, pensada para que la calidad del sistema se mida de forma sistemática y no dependa de que alguien se acuerde de revisarla.
Checklist de madurez operativa
Antes de dar por cerrada la fase de lanzamiento, conviene contrastar el estado real del proyecto frente a estos seis puntos:
| Elemento | Básico | Maduro |
|---|---|---|
| Comité de gobierno | No existe o es informal, sin cadencia fija | Reunión periódica con autoridad para decidir altas y bajas |
| Ciclo de vida de fuentes | Las fuentes se indexan pero nadie revisa si siguen vigentes | Cadencia de revisión definida por tipo de fuente y proceso de baja probado |
| Métricas de calidad | Solo hay impresión general de que «funciona bien» | Fidelidad, cobertura de citas y abstención se miden con regularidad |
| Panel operativo | No existe o solo se consulta ante una queja | Revisión semanal del responsable de fuentes, informe mensual al comité |
| Protocolo de incidencias | Cada error se resuelve de forma distinta según quién lo atienda | Pasos documentados: detectar, contener, corregir, comunicar, registrar |
| Canal de feedback | No hay forma sencilla de señalar una respuesta incorrecta | Botón visible, revisado por una persona con capacidad de actuar |
Cuantas más filas de esta tabla estén en la columna «básico», más probable es que el sistema funcione hoy pero pierda calidad en unos meses sin que nadie lo detecte a tiempo.
Preguntas frecuentes
¿En qué se diferencia esta guía de la guía práctica de preparación de datos ya publicada?
La guía original llega hasta el despliegue y el primer panel de consultas; esta edición desarrolla lo que viene después: quién gobierna las fuentes, qué se mide y qué protocolo se sigue cuando el sistema falla. Son complementarias, no alternativas.
¿Necesita una pyme un comité de gobierno de datos para un RAG, aunque sea pequeño?
Necesita los cuatro papeles descritos en el paso 1 cubiertos por personas concretas, aunque no exista un comité formal con ese nombre. En una empresa pequeña puede ser la misma persona quien asuma dos de esos papeles; lo importante es que la responsabilidad esté asignada y no dependa de que alguien se acuerde de revisarla.
¿Qué métrica hay que mirar primero si solo hay tiempo para revisar una?
La fidelidad de las respuestas, también llamada groundedness: si lo que dice el sistema se apoya de verdad en los fragmentos recuperados o añade información que no está en ninguna fuente. Es la métrica que más directamente predice si un usuario puede confiar en la respuesta, y suele degradarse antes de que el resto de indicadores lo reflejen.
¿Qué se hace en las primeras horas cuando el RAG da una respuesta incorrecta a un cliente?
Contener y corregir antes que explicar. Se marca la fuente implicada como de baja confianza mientras se revisa, se corrige el documento o el troceado que causó el error y, si el error llegó a afectar a una decisión del cliente, se decide de forma explícita si hace falta comunicárselo, en lugar de limitarse a arreglar el sistema en silencio.
¿Cada cuánto hay que revisar el estado del corpus una vez el sistema está en producción?
Depende de la criticidad de cada fuente, no de una única cadencia para todo el corpus: trimestral para políticas y procedimientos regulados, semestral para manuales y condiciones comerciales, anual para contenido de referencia que apenas cambia. Lo importante no es la frecuencia exacta, sino que cada fuente tenga una cadencia asignada por escrito, con alguien responsable de cumplirla.
Montar un RAG técnicamente correcto es, cada vez más, la parte fácil del proyecto. Mantenerlo gobernado, medido y corregido con el tiempo es lo que determina si sigue siendo útil pasado el primer año. Si ya tienes el sistema en marcha y quieres revisar si el gobierno de datos y las métricas de calidad están a la altura de lo que exige la producción, el equipo de RAG y búsqueda interna con IA de Summum IA puede acompañar ese diagnóstico junto con la capa de LLMOps y evaluación de agentes IA que sostiene la calidad en el tiempo.