Un proyecto RAG rara vez fracasa por el modelo de lenguaje elegido. Fracasa por decisiones que se toman en las primeras semanas y que nadie vuelve a revisar: qué documentos entran en el índice, cómo se trocean, quién puede ver qué respuesta y qué debe contestar el sistema cuando no tiene la información. Ninguno de estos errores se nota en la demo, donde todo funciona con una carpeta de documentos limpios y un puñado de preguntas fáciles. Se nota meses después, cuando el índice ya tiene miles de documentos reales —duplicados, versiones antiguas, carpetas que nunca debieron mezclarse— y alguien toma una decisión apoyándose en una respuesta que sonaba bien pero estaba mal. Corregirlo entonces cuesta mucho más que haberlo diseñado bien desde el principio: hay que reindexar, renegociar accesos con el equipo técnico y, sobre todo, recuperar la confianza de quien dejó de usar la herramienta después del primer error. Este artículo se centra en los errores del propio sistema de recuperación (qué entra en el índice, cómo se trocea, quién puede consultarlo); si además el proyecto da a un agente autonomía para actuar sobre esos datos, esa capa tiene sus propios riesgos, que trataremos en un artículo aparte sobre los errores más caros al implantar agentes y LLM.
Por qué estos errores cuestan más de lo que parece en el presupuesto inicial
Cuando se presupuesta un proyecto RAG, es habitual calcular el coste del desarrollo y de la infraestructura del primer despliegue. Lo que casi nunca entra en esa cuenta es el coste de lo que ocurre después: las horas de un equipo técnico deshaciendo un índice mal construido, el tiempo de un responsable de calidad revisando documento por documento cuál está vigente y cuál no, o el coste silencioso de que la gente deje de usar la herramienta y vuelva a preguntarle a un compañero porque ya no se fía de la respuesta. Ese coste no aparece en ninguna factura, pero es el que de verdad determina si el proyecto sale rentable o se queda en un experimento caro que nadie quiere reconocer como tal.
El error más caro casi nunca es técnico en el sentido estricto. Es una decisión de diseño que se aplazó —qué documentos entran, quién puede verlos, qué pasa si no hay respuesta— y que sale más cara cuanto más tarde se corrige.
1. Meter toda la documentación en el índice sin depurarla antes
Un sistema RAG recupera por similitud semántica, no por veracidad, vigencia ni autoridad del documento. Si se indexan a la vez dos versiones de una misma tarifa, un contrato tipo que se sustituyó hace seis meses y la política de devoluciones que ya no está en vigor, el sistema no sabe cuál es la buena: solo sabe cuál se parece más a la pregunta. Puede devolver la desactualizada, puede mezclar fragmentos de las dos en una misma respuesta, y lo hará con el mismo tono de seguridad que si estuviera citando la fuente correcta.
La corrección después del lanzamiento no es una tarea técnica menor: exige auditar cada documento del índice, asignarle un propietario, un estado (vigente, sustituido, archivado) y una fecha de revisión, y eso es exactamente el trabajo que debía hacerse antes de generar el primer embedding, no después de que alguien haya tomado una decisión a partir de una respuesta equivocada. Antes de indexar conviene tratar la ingesta como una fase propia de procesamiento de documentos: extraer, normalizar y clasificar el contenido antes de convertirlo en vectores, no mezclar ambas tareas en el mismo paso.
2. Trocear los documentos con el tamaño de fragmento que trae el tutorial
El tamaño de fragmento —el parámetro que decide cómo se trocea cada documento (el chunking) antes de generar sus embeddings— se copia con demasiada frecuencia del valor por defecto de un tutorial, sin comprobar si tiene sentido para el tipo de documento real de la empresa. Un tamaño de fragmento pensado para artículos de blog parte por la mitad una cláusula contractual, separa una tabla de su cabecera o deja una frase como «el plazo es de quince días» sin el contexto que decía a qué trámite se refería. Sin solapamiento entre fragmentos, ese contexto se pierde al indexar y no se recupera después ajustando el prompt.
Contratos, manuales técnicos, documentos de preguntas frecuentes y hojas de cálculo no se deben trocear igual: cada tipo de documento necesita una estrategia probada con ejemplos reales, no un valor copiado de un ejemplo genérico. Este error es especialmente difícil de detectar porque el documento correcto sí está en el índice: lo que falla es que el fragmento recuperado no lleva la información necesaria, y en una demo con preguntas elegidas a propósito ese problema casi nunca aparece.
3. Dar por hecho que el RAG hereda los permisos que ya existían en los documentos
Antes del RAG, la carpeta de nóminas solo la veía Recursos Humanos y la de contratos con proveedores solo Compras. Cuando esos documentos se indexan en un único almacén vectorial sin replicar esos permisos por usuario o por rol en el momento de la consulta, cualquier persona con acceso al asistente puede recibir una respuesta construida, en parte, con información a la que antes no tenía acceso. No es un fallo hipotético: es la consecuencia directa de aplanar en un solo índice documentos que antes vivían en carpetas con permisos distintos.
Este error conecta directamente con un principio básico de protección de datos: cada persona debe poder acceder solo a la información que su función justifica, y un sistema que ignora esa frontera trabaja en contra de ese principio aunque nadie lo haya diseñado con esa intención. Si esto ocurre una sola vez con datos sensibles, el coste no se mide en horas de desarrollo: el proyecto entero suele paralizarse mientras se revisa qué pasó y quién tuvo acceso, y reconstruir después una capa de recuperación que respete permisos es mucho más trabajo que haberla diseñado así desde el principio. Para empresas que manejan información especialmente sensible, poder mantener el índice y los modelos bajo control propio, sin depender de un proveedor externo para procesar esos datos, es una de las razones por las que tiene sentido evaluar una arquitectura de IA soberana y on-premise.
4. Elegir el modelo de embeddings sin probarlo con el vocabulario propio de la empresa
No todos los modelos de embeddings entienden igual de bien la jerga interna de un sector: siglas propias del negocio, códigos de producto, terminología legal o técnica que rara vez está bien representada en los corpus generalistas con los que se entrenan los modelos multilingües de propósito general. El resultado es que preguntas con vocabulario real de la empresa recuperan fragmentos poco relacionados, aunque la pregunta tenga sentido para cualquier empleado del departamento.
Este error se descubre tarde precisamente porque en el piloto se prueba con preguntas «de manual», no con las preguntas reales que un empleado haría el primer día. Cambiar de modelo de embeddings después del lanzamiento no es un ajuste de configuración: obliga a volver a generar los vectores de todo el índice y reconstruirlo por completo, un trabajo que sale mucho más barato hacer una vez, con las pruebas correctas, que dos.
5. No decidir qué debe responder el sistema cuando no hay evidencia suficiente
Sin una instrucción explícita, un modelo de lenguaje tiende a rellenar los huecos con una respuesta plausible en lugar de admitir que no tiene información suficiente. En un asistente interno esto genera confusión; en un proceso de cara al cliente o vinculado a una decisión de negocio, una respuesta equivocada dicha con seguridad es peor que no tener respuesta, porque nadie la cuestiona hasta que el daño ya está hecho.
Diseñar este comportamiento significa decidir, antes del lanzamiento, que el sistema debe decir «no consta en la documentación disponible» y, si el caso lo permite, derivar a una persona en lugar de completar el vacío por su cuenta. Si el RAG alimenta un chatbot de atención al cliente, este punto deja de ser opcional: un cliente que recibe una respuesta inventada con el mismo tono de seguridad que una correcta no pierde la confianza solo en esa respuesta: la pierde en todo el canal.
6. Lanzar el proyecto sin haber medido la calidad de la recuperación
Sin un conjunto de preguntas de evaluación con la fuente correcta ya conocida de antemano, no hay forma de saber si el sistema recupera bien antes de ponerlo en manos de los usuarios reales. La decisión de lanzar termina apoyándose en «la demo funcionó», que es justo el escenario menos representativo de lo que ocurre después, con documentos reales, preguntas mal formuladas y casos límite que nadie anticipó al diseñar las pruebas.
El coste de saltarse esta medición no aparece el día del lanzamiento: aparece semanas después, cuando los problemas llegan por quejas puntuales o, peor todavía, cuando no llegan porque los usuarios simplemente dejaron de usar la herramienta y volvieron a preguntar a un compañero sin decírselo a nadie. Detectar ese abandono silencioso a tiempo es mucho más difícil que haber medido la calidad antes de exponer el sistema a todo el equipo.
7. Tratar el índice como algo que se construye una vez
Los precios cambian, las políticas se revisan, los proyectos se cierran y la persona que redactó un procedimiento hace dos años puede llevar meses sin trabajar en la empresa. Sin una rutina de reindexado —ya sea periódica o disparada por cambios— y sin un proceso claro para retirar documentos obsoletos del índice, la distancia entre lo que dice la realidad y lo que responde el RAG crece de forma silenciosa, documento a documento.
Nadie nota esa distancia hasta que una decisión se apoya en una respuesta que ya había caducado. Un proyecto RAG no termina el día del despliegue: el índice sigue vivo, y mantenerlo al día —o no hacerlo— es lo que decide si la respuesta de dentro de seis meses sigue siendo de fiar.
8. Presupuestar el proyecto como si terminara en el despliegue
El coste real de un RAG en producción incluye la infraestructura —almacenamiento, base de datos vectorial, cómputo para generar y actualizar embeddings— y también el tiempo de personas: quien revisa qué debe y qué no debe entrar en el índice, quien mide la calidad de las respuestas de forma periódica y quien decide cuándo retirar un documento. Los equipos que presupuestan el proyecto como un desarrollo puntual, con fecha de entrega y punto final, se quedan sin margen para ese trabajo continuo y el sistema se degrada poco a poco sin que nadie lo esté vigilando de forma activa.
Si el RAG se conecta además con otros sistemas internos, como el CRM, el ERP o una herramienta de gestión documental, esa integración añade preguntas propias sobre qué datos fluyen hacia dónde y quién los controla; es el terreno que cubre una integración MCP bien planteada, no un añadido improvisado sobre el índice ya construido. Y si el sistema participa en procesos con peso normativo real, como contratos o decisiones sujetas a auditoría interna o externa, conviene revisar desde el principio qué documentación técnica y qué nivel de gobernanza corresponde aplicar, un trabajo que encaja dentro de la gobernanza técnica de IA, no algo que se resuelve a posteriori con una nota interna.
Qué hay que decidir antes de indexar el primer documento
Evitar estos ocho errores no exige retrasar el proyecto meses ni contratar un equipo enorme: exige tomar desde el diseño inicial las decisiones correctas, que siempre salen más baratas que corregirlas cuando el error ya ha costado algo. En la práctica son siete: un propietario y un estado por cada documento antes de indexarlo, una estrategia de chunking probada con casos reales de la empresa, permisos que se respetan en cada consulta y no solo en la carpeta original, un modelo de embeddings probado con el vocabulario real de la empresa antes de generar el índice, una instrucción explícita sobre qué hacer sin evidencia suficiente, un conjunto de evaluación antes del primer usuario real y una rutina de mantenimiento presupuestada desde el primer día, no descubierta a los tres meses.
Preguntas frecuentes
¿Cuál es el error más caro en un proyecto RAG con datos de empresa?
Con diferencia, indexar documentos sin replicar los permisos que ya existían antes del proyecto. Cuando cualquier persona con acceso al asistente puede recibir una respuesta construida con información que su rol no debería ver, el proyecto suele paralizarse por completo mientras se revisa el alcance del problema, y reconstruir después una capa de recuperación que respete accesos es mucho más trabajo que haberla diseñado así desde el principio.
¿Por qué un RAG puede dar una respuesta que suena bien pero está mal?
Porque recupera por similitud semántica, no por veracidad ni por vigencia del documento. Si el índice tiene una versión antigua y una actual de un mismo documento, el sistema puede devolver la antigua con el mismo tono de seguridad que si fuera la correcta, porque para el motor de recuperación ambas son igual de «parecidas» a la pregunta.
¿Hay que volver a indexar todo el sistema cada vez que cambia un documento?
No necesariamente todo el índice, pero sí necesita una rutina —periódica o disparada por el propio cambio— que actualice al menos los documentos modificados y retire los que quedaron obsoletos. Sin esa rutina, la distancia entre lo que dice la realidad y lo que responde el sistema crece documento a documento sin que nadie lo note hasta que alguien toma una decisión a partir de una respuesta que ya no era cierta.
¿Qué hay que mantener en un RAG después de lanzarlo?
Como mínimo, un RAG en producción necesita revisión periódica de la calidad de sus respuestas, actualización del índice cuando cambian los documentos y monitorización de qué preguntas no está resolviendo bien; el esfuerzo concreto depende del volumen de documentación y de la criticidad del proceso. Tratarlo como un proyecto cerrado el día del despliegue es una de las causas más frecuentes de que un sistema que funcionaba bien al principio se vaya degradando sin que nadie lo esté vigilando.
Fuentes consultadas
Si reconoces alguno de estos errores en un proyecto que ya tienes en marcha, o quieres evitarlos antes de empezar, hablemos de cómo encaja un sistema RAG con la documentación real de tu empresa, empezando por el procesamiento de documentos que hace falta antes de indexar nada.