Preparar documentación para RAG y Copilot interno

Muchas empresas llegan a un proyecto de RAG o Copilot interno pensando que el reto principal es elegir modelo o proveedor. En la práctica, el cuello de botella suele estar antes: en la documentación. Según McKinsey (2025), el 60% de las implantaciones de IA generativa en empresas encuentran la calidad del dato como principal freno. Con RAG, ese problema se concentra en la base documental.

La pregunta que más repiten los equipos antes de arrancar es: "No sabemos si nuestros documentos están preparados." Este artículo responde esa pregunta de forma directa. Sin entrar en arquitectura técnica, sino en lo que depende del equipo: qué documentos sirven, cuáles generan ruido y cómo preparar la base documental antes del primer sprint.

Por qué la preparación documental determina el resultado del RAG

RAG (Retrieval-Augmented Generation) funciona en dos fases. Primero, el sistema busca en tu base documental los fragmentos más relevantes para la pregunta del usuario. Segundo, el modelo de lenguaje usa esos fragmentos como contexto para generar la respuesta. Si los fragmentos recuperados son obsoletos, ambiguos o contradictorios, la respuesta será mala aunque el modelo sea excelente. Según Azure AI Search (2025), la precisión del retrieval es el factor que más peso tiene en la calidad final de las respuestas.

El modelo no sabe distinguir entre un documento actualizado de esta semana y uno de hace cuatro años. Tampoco detecta que dos procedimientos internos se contradicen. Devuelve la información que encuentra con igual confianza. Por eso la calidad de la entrada determina directamente la calidad de la salida. No es una cuestión técnica: es una cuestión de gobierno documental.

Qué documentos funcionan bien en RAG y Copilot

Funcionan bien los documentos orientados a procesos, criterio y contexto operativo. Es decir, materiales que ya ayudan a una persona nueva o a un equipo transversal a entender cómo hacer algo, cuándo aplica una excepción y dónde mirar si hay dudas. Cuanto más operativo y mantenido esté el documento, más útil suele resultar para un sistema RAG o Copilot interno.

Documentos de proceso y criterio operativo

Los procedimientos operativos estándar (SOPs), manuales de proceso y guías paso a paso son el tipo de documento más útil para RAG. Contienen reglas, contexto y lenguaje de negocio. No obligan al sistema a improvisar: le permiten recuperar piezas concretas y apoyarse en ellas para responder. La condición es que estén versionados, con fecha de última revisión visible y con un responsable asignado.

FAQs internas y bases de conocimiento

Las bases de conocimiento de soporte, los repositorios de incidencias resueltas y las FAQs internas funcionan especialmente bien porque ya están estructuradas en torno a preguntas y respuestas. El sistema RAG puede recuperar la respuesta directamente sin necesidad de sintetizar. La condición es que el mantenimiento sea activo: una FAQ desactualizada genera más daño que no tenerla.

Políticas, procedimientos y normativas

Las políticas internas, normativas corporativas y documentos de compliance funcionan bien porque aterrizan qué se puede hacer, qué no y quién aprueba. La condición crítica aquí es que el texto sea vigente y que el owner esté identificado. Indexar una política de hace tres versiones puede generar respuestas incorrectas con apariencia de autoridad.

Documentos que generan problemas

No todos los documentos que existen en tu empresa son útiles para RAG. Algunos generan más ruido que valor. Indexarlos sin filtro previo puede empeorar la calidad de las respuestas respecto a no tenerlos. La regla general: si el documento no ayudaría a una persona nueva a hacer su trabajo, no ayudará al sistema RAG tampoco.

• Documentos duplicados o con múltiples versiones sin control: el sistema no sabe cuál es la vigente y puede mezclar información de distintas épocas.
• PDFs escaneados sin OCR: el texto no es extraíble y el sistema los ignora o genera errores.
• Correos electrónicos y chats exportados: contienen conversaciones sin contexto suficiente, ruido alto y escasa estructura.
• Documentos de hace más de tres años sin revisión: pueden ser técnicamente accesibles pero contener información obsoleta que el sistema devolverá con igual confianza que la actual.
• Ficheros con contenido mayoritariamente visual: presentaciones con gráficos sin texto alternativo, tablas en imagen o diagramas sin descripción.
• Documentación sin owner ni fecha: sin responsable asignado, no hay garantía de que el contenido sea fiable ni de que se actualizará.

Los 5 requisitos reales para que tu base documental funcione en RAG

1. 1Texto extraíble. Los documentos deben ser digitales y con texto seleccionable. PDF con texto real, Word, Markdown, páginas de wiki, Google Docs o Confluence. Un PDF escaneado sin OCR es opaco para el sistema y quedará fuera del índice.
2. 2Estructura mínima identificable. Títulos, secciones y párrafos que un programa pueda distinguir. No hace falta formato perfecto, pero sí que sea claro dónde empieza un tema y dónde acaba. Los documentos completamente planos sin jerarquía producen chunks de baja calidad.
3. 3Información actualizada y coherente. RAG no distingue entre documentos de esta semana y de hace cuatro años. Si hay versiones contradictorias indexadas a la vez, las respuestas serán inconsistentes. La regla práctica: si no puedes decir quién es el owner y cuándo fue la última revisión, no lo indexes todavía.
4. 4Densidad de información útil. Con menos de 50-100 documentos relevantes y actualizados, el sistema tendrá poco contenido para trabajar. No se trata de cantidad bruta, sino de cuántos documentos responden realmente las preguntas del caso de uso definido.
5. 5Accesibilidad técnica. Los documentos deben poder extraerse de forma programática. SharePoint, Confluence, Google Drive, un gestor documental con API o un servidor de archivos con estructura razonable son viables. Documentación repartida en emails, chats y discos duros personales requiere consolidación previa.

Señales de que tus documentos no están listos

• No sabes con certeza cuántos documentos activos tienes ni dónde están todos.
• Hay varios ficheros con el mismo nombre o contenido similar sin saber cuál es el definitivo.
• La documentación no se ha revisado en más de dos años de forma sistemática.
• No hay un responsable claro de cada área de documentación.
• Una parte significativa está en PDFs escaneados, imágenes o presentaciones sin texto alternativo.
• El equipo que usaría el copilot no confía en que la documentación existente refleje cómo se trabaja realmente hoy.

Cómo preparar la documentación en la práctica

Preparar la base documental para RAG no requiere una transformación documental completa antes de empezar. Requiere un enfoque pragmático: identificar el subconjunto de documentación que cubre el caso de uso, evaluarlo con criterios claros y corregir solo lo que impide el funcionamiento. No es necesario que todo esté perfecto para lanzar un piloto útil.

Auditoría documental previa

Antes de indexar nada, conviene hacer un inventario rápido: cuántos documentos existen, en qué formatos, cuándo fue la última actualización y quién los mantiene. No hace falta ser exhaustivo en toda la empresa: basta con el perímetro del caso de uso elegido. Esta auditoría tarda entre uno y tres días según el volumen, y evita semanas de trabajo desperdiciado en infraestructura sobre documentación inutilizable.

Estructuración y limpieza

Una vez identificados los documentos útiles, el siguiente paso es asegurar que el texto es extraíble, que las versiones duplicadas quedan fuera del índice y que los documentos obsoletos se archivan o eliminan. En paralelo, conviene añadir metadatos mínimos a los documentos clave: área, fecha de revisión y owner. Esos metadatos permiten filtrar por permisos y por vigencia en el momento de la consulta.

Mantenimiento continuo

Mantener la base de conocimiento al día requiere un proceso continuo de actualización, versionado y re-indexación. No es suficiente con preparar bien el corpus inicial. Si los documentos cambian y el índice no se actualiza, la calidad de las respuestas se degrada progresivamente. El proceso de mantenimiento debe estar definido antes del lanzamiento: quién actualiza, con qué frecuencia y cómo se valida que el índice refleja la documentación vigente.

Checklist antes de lanzar tu proyecto RAG

1. 1Tenemos un caso de uso concreto definido, no solo la idea de que sea útil en general.
2. 2Hemos identificado el subconjunto de documentación que cubre ese caso de uso.
3. 3Todos los documentos del perímetro tienen texto extraíble (sin PDFs escaneados sin OCR).
4. 4Hemos eliminado o archivado las versiones duplicadas o contradictorias.
5. 5Cada documento del índice tiene un owner identificado y una fecha de última revisión.
6. 6Los documentos más críticos tienen estructura mínima: secciones, títulos y párrafos distinguibles.
7. 7Contamos con al menos 50 documentos relevantes y actualizados para el caso de uso.
8. 8Sabemos cómo se va a actualizar el índice cuando cambie la documentación.
9. 9Hemos revisado los permisos de acceso: quién puede consultar qué y si el copilot debe respetar esos permisos.
10. 10El equipo que usará el copilot ha validado que la documentación actual refleja cómo se trabaja de verdad.

Si tu documentación supera este checklist, estás en condiciones de arrancar un piloto con garantías. Si detectas problemas en varios puntos, lo más eficiente es resolverlos antes de invertir en infraestructura. El siguiente paso natural es entender cómo conectar esa base documental a las fuentes que ya usas, o explorar directamente cómo desplegamos un Copilot RAG sobre documentación interna.