«¿Cuánto tarda esto?» suele ser la primera pregunta que hace cualquier responsable de negocio cuando se plantea un proyecto de RAG (Retrieval-Augmented Generation) con los datos de su empresa. Es una pregunta legítima y, a la vez, una de las más difíciles de responder con una fecha única: el calendario de un RAG depende mucho menos del modelo de lenguaje elegido que del estado real de los datos que va a consultar. Este artículo recoge las fases, los hitos y los factores que marcan el calendario de un proyecto RAG empresarial, para que la planificación se apoye en algo más sólido que una estimación optimista de venta.
Por qué «¿cuánto tarda un RAG?» no tiene una respuesta única
Dos empresas del mismo tamaño y sector pueden tardar plazos muy distintos en poner en marcha un proyecto de RAG y búsqueda interna con IA. La diferencia rara vez está en la tecnología —los componentes de recuperación, indexado y generación son, a grandes rasgos, los mismos en cualquier proyecto— sino en el punto de partida de sus datos: cuántas fuentes hay que conectar, en qué formato están, quién tiene permiso para verlas y si existe alguien capaz de decir, fuente por fuente, si sigue vigente.
Por eso conviene tratar el calendario de un RAG como una sucesión de fases con hitos de salida, no como una fecha de entrega fija anunciada antes de conocer el estado de los datos. En nuestro artículo sobre cómo construir un RAG empresarial fiable explicamos por qué la calidad y el gobierno de las fuentes condicionan el resultado; aquí nos centramos en cómo esa misma variable condiciona el tiempo que hace falta para llegar a producción.
El calendario de un RAG no lo marca la tecnología, lo marca el estado de los datos: cuántas fuentes hay, quién es su propietario, cómo de sensibles son y si el negocio dispone de tiempo para validar las respuestas antes de ampliar el alcance.
Los cuatro factores que fijan el calendario real
Antes de fijar cualquier fecha, conviene revisar estos cuatro puntos. Son, en la práctica, los que más mueven el calendario de un extremo a otro.
1. Volumen y heterogeneidad de las fuentes
No es lo mismo indexar un manual de producto en PDF bien maquetado que un conjunto de correos, hojas de cálculo, escaneos y wikis internas acumulados durante años. Cada formato adicional añade trabajo de ingestión, y cada fuente sin propietario claro añade una conversación previa que hay que tener antes de escribir una sola línea de código. El procesamiento inteligente de documentos puede acelerar la extracción de texto y tablas, pero no sustituye la tarea de decidir qué fuentes entran en el proyecto y cuáles se descartan.
2. Complejidad de permisos y sensibilidad de los datos
Cuando la información que va a consultar el sistema incluye datos de clientes, contratos, condiciones económicas o cualquier otro contenido restringido a ciertos perfiles, el proyecto necesita definir y probar el control de acceso antes de ampliar el alcance a más usuarios. Cuantos más departamentos y niveles de confidencialidad conviven en el mismo repositorio, más tiempo exige esta fase, porque los permisos deben aplicarse antes de recuperar el contenido, no después de generar la respuesta.
3. Disponibilidad de las personas que validan
Un RAG necesita que alguien del negocio revise si las respuestas son correctas, no solo si «suenan bien». Si esas personas están disponibles pocas horas a la semana, el calendario se alarga aunque el equipo técnico vaya sobrado de tiempo: la validación humana es, casi siempre, el cuello de botella real de un proyecto de este tipo, más que la infraestructura o el modelo elegido.
4. Si ya existe un conjunto de evaluación o hay que crearlo desde cero
Contar de antemano con un listado de preguntas reales, con su respuesta correcta y sus fuentes válidas, adelanta semanas de trabajo. Si no existe, hay que construirlo desde cero junto con las personas expertas del negocio, y eso no se puede comprimir sin perder fiabilidad en las pruebas posteriores: un conjunto de evaluación improvisado en un par de días suele detectar muchos menos problemas que uno construido con calma.
Calendario orientativo por fases
Las duraciones que siguen son orientativas: varían según el alcance, el número de fuentes, la sensibilidad de los datos y la disponibilidad del equipo del cliente. Sirven como punto de partida para planificar, no como un compromiso cerrado antes de conocer el proyecto concreto.
| Fase | Semanas orientativas | Qué debe estar cerrado para avanzar |
|---|---|---|
| 0 · Alcance y caso de uso | 1-2 | Dominio acotado, propietario del proyecto y criterio de éxito por escrito |
| 1 · Inventario y gobierno de fuentes | 2-4 | Listado de fuentes con propietario, estado y nivel de confidencialidad |
| 2 · Arquitectura, ingestión y permisos | 3-6 | Ingestión funcionando sobre un subconjunto real, control de acceso probado |
| 3 · Conjunto de evaluación | 2-4 (en paralelo con la fase 2) | Preguntas reales con respuesta y fuente válida acordadas con el negocio |
| 4 · Piloto controlado | 3-5 | Umbrales de calidad superados, revisión humana activa en respuestas de alto impacto |
| 5 · Producción ampliada | a partir de la semana 9-17 | Plan de mantenimiento y calendario de revisión de fuentes aprobado |
Fase 0: Alcance y caso de uso
Antes de tocar una sola fuente de datos, conviene acotar el dominio (un departamento, un tipo de consulta, un grupo de usuarios concreto) y nombrar a la persona responsable de decidir sobre el contenido. En esta fase también se fija por escrito qué significa que el proyecto ha funcionado: qué porcentaje de respuestas debe tener fuente verificable, qué tipo de consultas quedan fuera del alcance inicial y quién revisa los resultados del piloto.
Fase 1: Inventario y gobierno de fuentes
Se identifican los repositorios candidatos, se asigna un propietario a cada uno y se decide qué queda dentro y qué queda fuera del proyecto. Esta fase suele revelar el primer desajuste entre el calendario deseado y el real: es habitual descubrir fuentes sin dueño claro, versiones duplicadas o documentos que nadie sabe si siguen vigentes. Resolver esas dudas antes de indexar nada evita tener que rehacer el trabajo más adelante.
Fase 2: Arquitectura, ingestión y permisos
Se diseña la ingestión, la segmentación de los documentos y la recuperación sobre un subconjunto representativo de fuentes, y se implanta el control de acceso desde el principio. Cuando el proyecto necesita conectar varios sistemas de origen —un gestor documental, un CRM, una intranet—, conviene evaluar si una integración MCP simplifica esas conexiones frente a desarrollar un conector distinto para cada sistema.
Fase 3: Conjunto de evaluación
En paralelo a la arquitectura, se construye el conjunto de preguntas reales con las que se medirá la calidad del sistema: preguntas simples, preguntas que combinan varias fuentes, preguntas sin respuesta disponible y casos con documentos contradictorios. Cuanto antes empiece esta fase, menos presión sufre al final del proyecto, porque construir un buen conjunto de evaluación con el negocio lleva tiempo de coordinación, no solo de redacción.
Fase 4: Piloto controlado
El sistema se despliega a un grupo reducido de personas, con revisión humana de las respuestas de mayor impacto. Aquí se miden de forma sistemática las métricas definidas en la fase 0: fidelidad de las respuestas, calidad de las citas, porcentaje de abstención correcta y consultas que requieren corrección manual. El alcance solo se amplía cuando el piloto supera los umbrales acordados, no cuando se cumple la fecha inicialmente prevista.
Fase 5: Producción ampliada
Una vez superado el piloto, el sistema se abre a más usuarios o más dominios de forma progresiva, con el mismo criterio de medición que en el piloto. Esta fase no tiene una fecha de cierre real: el proyecto entra en un ciclo continuo de mantenimiento que conviene planificar desde el principio, como se explica más abajo.
Hitos que conviene fijar por escrito antes de arrancar
Cada cambio de fase debería depender de un hito comprobable, no de que haya pasado un número determinado de semanas en el calendario. Algunos hitos habituales:
- El inventario de fuentes tiene propietario asignado en el cien por cien de los casos antes de empezar la ingestión.
- El control de acceso se ha probado con usuarios de distintos perfiles antes de indexar contenido sensible.
- El conjunto de evaluación ha sido revisado por al menos una persona experta del negocio, no solo por el equipo técnico.
- El piloto ha superado los umbrales de calidad acordados antes de ampliar a más usuarios.
- Existe un responsable designado para el mantenimiento de las fuentes una vez el sistema está en producción.
Avanzar de fase sin cerrar estos hitos suele generar el efecto contrario al buscado: se gana unos días en el calendario a corto plazo y se pierden varias semanas más adelante corrigiendo problemas que el hito habría detectado a tiempo.
Qué suele alargar el calendario en la práctica
Más allá de la lista de factores anterior, hay causas concretas que aparecen una y otra vez en proyectos reales:
- Fuentes sin propietario identificable. Nadie puede confirmar si un documento sigue vigente, así que la decisión se retrasa hasta encontrar a la persona adecuada.
- Cambios de alcance a mitad de proyecto. Añadir un nuevo departamento o un nuevo tipo de consulta después de haber cerrado el conjunto de evaluación obliga a rehacer parte del trabajo de validación.
- Ausencia de conjunto de evaluación al inicio. Empezar a construirlo solo cuando el piloto ya está listo para lanzarse retrasa la fecha real de salida.
- Formatos heterogéneos sin digitalizar. Escaneos de baja calidad, documentos sin estructura o archivos en formatos poco comunes multiplican el tiempo de ingestión.
- Poca disponibilidad del negocio para validar. Si las personas que deben revisar las respuestas solo pueden dedicar una hora a la semana, el piloto se alarga aunque el sistema esté técnicamente listo.
El calendario no termina en el lanzamiento
Un error habitual es tratar la fecha de salida a producción como el final del proyecto. Las fuentes de una empresa cambian: se publican políticas nuevas, se sustituyen manuales, se cierran productos. Por eso conviene incluir desde el principio un calendario de mantenimiento con, al menos, estos elementos:
- una cadencia de revisión para las fuentes más críticas, distinta de la de los documentos de consulta ocasional;
- un proceso claro para dar de baja fuentes obsoletas y evitar que compitan con las vigentes;
- una revisión periódica del conjunto de evaluación, para que siga representando las consultas reales de los usuarios;
- un canal para que las personas que usan el sistema señalen respuestas incorrectas o desactualizadas.
Sin este calendario de mantenimiento, la calidad del sistema tiende a degradarse con el tiempo aunque el diseño inicial fuera sólido: no por un fallo técnico, sino porque las fuentes que respaldan las respuestas dejan de reflejar la realidad de la empresa.
Cómo comunicar un calendario realista
De cara al equipo directivo, suele funcionar mejor comunicar un rango con hitos verificables que una fecha única cerrada de antemano. En lugar de «el proyecto estará listo el día X», resulta más honesto y más útil plantear algo como: «el piloto empieza cuando el inventario de fuentes esté cerrado y el conjunto de evaluación aprobado por el negocio; a partir de ahí, necesitamos entre tres y cinco semanas de piloto antes de decidir si ampliamos el alcance». Ese formato traslada la responsabilidad del calendario a los hitos, no a una fecha que puede incumplirse por causas ajenas al equipo técnico.
Si tu empresa está valorando un proyecto de RAG y quiere partir de un calendario realista en lugar de una fecha comercial optimista, el equipo de RAG y búsqueda interna con IA de Summum IA puede ayudar a mapear el estado real de las fuentes antes de comprometer ninguna fecha.
Preguntas frecuentes
¿Cuánto tarda de media un proyecto RAG con datos de empresa?
No hay una cifra universal: depende del número y estado de las fuentes, de la complejidad de los permisos y de la disponibilidad de las personas que validan las respuestas. Un dominio acotado con fuentes ya digitalizadas puede llegar a piloto a partir de unas seis semanas; un repositorio grande, disperso y sin propietario claro necesita bastante más tiempo solo para la fase de inventario.
¿Se puede acortar el calendario empezando por un dominio pequeño?
Sí. Acotar el alcance a un dominio con pocas fuentes, un propietario claro y un grupo reducido de personas que validan es la palanca más eficaz para adelantar el piloto, y además reduce el riesgo de tener que rehacer trabajo si el alcance inicial resulta demasiado ambicioso.
¿Qué alarga más el calendario: la tecnología o los datos?
En la mayoría de proyectos, los datos. La arquitectura de recuperación e indexado suele montarse en poco tiempo; lo que consume semanas es encontrar al propietario de cada fuente, resolver formatos heterogéneos y definir permisos, además de conseguir que el negocio dedique horas a validar respuestas.
¿Cuándo conviene fijar una fecha de salida a producción?
Solo después del piloto, cuando ya se dispone de datos reales sobre fidelidad, cobertura de fuentes y volumen de correcciones necesarias. Fijar una fecha de producción antes del piloto obliga a menudo a bajar los umbrales de calidad para cumplir el plazo.
¿Hay que seguir revisando el calendario después del lanzamiento?
Sí. Las fuentes cambian, se añaden documentos y se sustituyen políticas, así que el calendario debe incluir ciclos de revisión y reindexado periódicos, no solo las fases previas al lanzamiento.
Un calendario de RAG bien planteado no promete una fecha única desde el primer día: define hitos comprobables, se apoya en el estado real de los datos y sigue vivo después del lanzamiento. Si quieres revisar el estado de tus fuentes antes de fijar una fecha, el equipo de Summum IA puede acompañar el diagnóstico inicial y el diseño del procesamiento de documentos y la integración de sistemas que suele condicionar el calendario.