Base de conocimiento con IA: qué necesita tu empresa para implementar RAG

«Queremos montar algo con RAG, pero no sabemos si nuestros documentos están preparados.» Esta pregunta aparece cada vez con más frecuencia en empresas que han visto lo que puede hacer la IA generativa y quieren aplicarlo a su documentación interna: manuales, procedimientos, contratos, documentación técnica, normativa.

La pregunta es legítima. RAG no funciona igual con cualquier base documental, y lanzar un proyecto sin evaluar el estado de la documentación es una de las formas más rápidas de gastarse el presupuesto sin obtener resultados útiles. Este artículo explica qué necesita realmente tu empresa para que un proyecto de RAG funcione, sin entrar en la arquitectura técnica —que cubrimos en otro artículo— sino en la parte que depende de ti: la preparación.

¿Qué necesita RAG de tus documentos (y qué no)?

Hay un malentendido frecuente: que RAG necesita documentación perfecta, como si fuera una biblioteca ordenada con índices temáticos y metadatos completos. No es así. Lo que RAG necesita es documentación que sea legible por máquina, razonablemente actualizada y con contenido suficiente para responder las preguntas que le vas a hacer.

En la práctica, esto se traduce en tres condiciones básicas:

• Los documentos tienen que ser digitales y extraíbles. PDF con texto seleccionable, Word, páginas de wiki, Google Docs, Confluence, Notion. Un PDF escaneado sin OCR es opaco para el sistema.
• El contenido tiene que tener una estructura mínima. Títulos, secciones, párrafos identificables. No hace falta que esté en formato perfecto, pero sí que un programa pueda distinguir dónde empieza un tema y dónde acaba.
• La información tiene que ser relevante para las preguntas que se le van a hacer. Si el 80% de tu documentación es de hace cinco años y ya no refleja los procesos actuales, RAG devolverá respuestas obsoletas con total confianza.

Los 5 requisitos reales para un proyecto RAG

Más allá de la documentación, un proyecto de RAG necesita que la empresa cumpla ciertos requisitos organizativos y técnicos. Estos son los cinco que evaluamos antes de recomendar arrancar:

1. 1Un caso de uso concreto. «Queremos que la gente pueda preguntar cosas» no es un caso de uso. «Queremos que los técnicos de campo consulten los manuales de mantenimiento sin tener que buscar en 200 PDFs» sí lo es. Sin un caso de uso definido, no hay forma de medir si el proyecto funciona.
2. 2Volumen mínimo de documentación útil. No existe un número mágico, pero con menos de 50-100 documentos relevantes y actualizados, el sistema tendrá poco contenido para trabajar. No se trata de cantidad bruta, sino de densidad de información útil para las preguntas del caso de uso.
3. 3Documentación accesible técnicamente. Los documentos tienen que poder extraerse de forma programática. Si viven en un servidor compartido con estructura de carpetas razonable, en una wiki, en SharePoint o en un gestor documental con API, es viable. Si están repartidos en emails, chats y discos duros personales, primero hay que consolidarlos.
4. 4Un responsable funcional. Alguien de la empresa que conozca la documentación, que pueda validar si las respuestas del sistema son correctas y que tenga autoridad para decidir qué documentos entran y cuáles no. Sin esta figura, no hay forma de validar el sistema.
5. 5Expectativas realistas sobre la precisión. RAG no es infalible. En un escenario bien configurado, la precisión en las respuestas suele estar entre el 80% y el 95%, dependiendo de la calidad documental y de la complejidad de las preguntas. Si el caso de uso requiere el 100% de fiabilidad —por ejemplo, en contextos regulatorios o legales donde un error tiene consecuencias graves—, RAG puede ser un asistente de búsqueda, pero no un sustituto de la revisión humana.

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

Estas son las situaciones que encontramos con más frecuencia y que indican que antes de montar RAG hay que hacer trabajo de preparación documental:

• El conocimiento está en la cabeza de las personas, no en documentos. Si la respuesta a «¿dónde está el manual de este proceso?» es «pregúntale a Luis», no hay base documental que alimentar.
• Los documentos están en PDF escaneado sin OCR. Son imágenes, no texto. El sistema no puede leerlos hasta que se procesen.
• Hay múltiples versiones del mismo documento sin indicación de cuál es la vigente. El sistema no puede decidir cuál es la correcta si tú tampoco lo sabes.
• La documentación lleva años sin actualizarse. Si los procedimientos reales han cambiado pero los manuales no, las respuestas del sistema serán técnicamente correctas según la documentación pero funcionalmente incorrectas.
• No hay estructura de carpetas ni clasificación temática. Si todo está en una carpeta llamada «Documentos» con 3.000 archivos sin nombre descriptivo, la indexación funcionará pero la calidad de las respuestas será baja.

Cómo preparar tu documentación antes de un proyecto RAG

La buena noticia es que la preparación no tiene por qué ser un proyecto de meses. Con un enfoque pragmático y centrado en el caso de uso concreto, cuatro semanas suelen ser suficientes para dejar la documentación en un estado operativo:

1. 1Semana 1: inventario. Identifica qué documentos existen, dónde están y cuáles son relevantes para el caso de uso. Descarta lo que claramente está obsoleto o fuera de alcance.
2. 2Semana 2: consolidación y limpieza básica. Reúne los documentos relevantes en un único repositorio accesible. Elimina duplicados. Marca la versión vigente cuando haya varias.
3. 3Semana 3: procesamiento técnico. Pasa los PDFs escaneados por OCR. Convierte formatos propietarios a formatos abiertos si es necesario. Verifica que el texto es extraíble.
4. 4Semana 4: validación. Revisa una muestra representativa con el responsable funcional. ¿Los documentos reflejan la realidad actual? ¿Falta algo crítico? ¿Hay información sensible que no debería estar en el sistema?

Este trabajo no solo prepara la documentación para RAG: mejora el estado general de la gestión documental de la empresa. Es una inversión que tiene valor independientemente de si el proyecto de IA se ejecuta o no.

Cuándo tiene sentido empezar (y cuándo esperar)

Un proyecto de RAG tiene sentido cuando tu empresa tiene documentación digital suficiente, un caso de uso claro y personas que puedan validar las respuestas. Si cumples estas tres condiciones, el piloto puede arrancar en pocas semanas y dar resultados visibles en el primer mes.

Tiene sentido esperar cuando la documentación no existe o está tan desactualizada que primero hay que crearla o revisarla. En ese caso, el proyecto de RAG se convierte en un proyecto de gestión documental disfrazado de tecnología, y los plazos y costes se multiplican.

Si ya tienes la documentación y quieres evaluar si tu caso encaja, puedes ver cómo implementamos este tipo de proyectos en nuestra solución de base de conocimiento con IA. Y si además te interesa cómo se integra con un asistente que el equipo pueda usar a diario, consulta nuestra página sobre copilots de IA para empresas.

Tabla rápida de requisitos antes de indexar documentos

Permisos, trazabilidad y revisión humana

Una base de conocimiento útil para IA no es solo un repositorio de documentos. Es un sistema donde importa quién puede ver qué, de qué fuente sale la respuesta y cómo se corrige cuando algo queda ambiguo o desactualizado. Si eso no existe, el problema no es solo técnico: es de proceso y de gobierno del dato documental.

Por eso esta pieza encaja muy bien con qué es RAG en empresa, con una revisión del gobierno del dato y calidad y con la plataforma de datos. Cuando el objetivo final es un asistente interno usable, la página de copilot con RAG para empresa completa muy bien el mapa.

Preguntas frecuentes sobre requisitos para RAG

¿Hace falta tener todos los documentos perfectos antes de empezar?

No, pero sí un conjunto inicial suficientemente claro, vigente y con permisos razonables. RAG no arregla por arte de magia una base documental caótica.

¿Qué suele bloquear más: la IA o la documentación?

Casi siempre la documentación: versiones, estructura, permisos, ownership y calidad del contenido.

¿Esto es lo mismo que montar un chatbot?

No. Aquí el foco está en que las respuestas se apoyen en documentos internos recuperables y trazables, no en conversación genérica sin contexto.