Un RAG no es un chatbot con documentos pegados. Esa confusión sale cara. En muchas empresas de Donostia - San Sebastián, Gipuzkoa y Euskadi ya hay manuales, propuestas, contratos, fichas técnicas, tickets, procedimientos y correos con mucho valor. El problema es que encontrar la respuesta correcta sigue dependiendo de saber dónde buscar y a quién preguntar.
Ahí entran RAG y LLMs. Bien montados, permiten consultar conocimiento interno con lenguaje natural y recibir respuestas con fuentes. Mal montados, producen una demo vistosa que responde con seguridad a cosas que nadie puede verificar. La diferencia está en el diseño: permisos, trazabilidad, privacidad, evaluación y un proceso claro para mantener la base documental.
Esta guía está pensada para dirección, IT, operaciones, comercial e innovación. La pregunta no es "qué modelo usamos". La pregunta buena es otra: qué conocimiento interno está frenando al equipo y qué nivel de control necesita antes de poner IA encima.
Qué es RAG sin jerga innecesaria
RAG significa que el modelo no responde solo con lo que aprendió durante su entrenamiento. Antes de contestar, busca fragmentos relevantes en una base de documentos de la empresa y los usa como contexto. Por eso puede responder sobre políticas internas, catálogos, ofertas, manuales o procedimientos que no están en internet.
La idea parece sencilla: documentos dentro, preguntas fuera. En la práctica hay varias piezas que importan mucho:
- Qué documentos entran y cuáles se quedan fuera.
- Cómo se trocean, etiquetan y actualizan.
- Qué usuarios pueden consultar cada contenido.
- Qué fuentes se muestran junto a la respuesta.
- Qué pasa cuando no hay información suficiente.
Ese último punto separa un asistente útil de uno peligroso. Un buen sistema debe saber decir "no lo sé" cuando la documentación no alcanza.
Dónde aparece el valor en una empresa
Los primeros casos buenos suelen estar donde el equipo pierde tiempo buscando contexto. No hace falta empezar por el proceso más crítico. De hecho, casi siempre conviene evitarlo al principio.
En empresas industriales, un RAG puede ayudar a consultar manuales técnicos, instrucciones de mantenimiento, procedimientos de calidad o documentación de producto. En equipos comerciales, puede recuperar argumentos, condiciones estándar, fichas de servicio y respuestas aprobadas. En soporte, puede sugerir pasos de diagnóstico a partir de incidencias anteriores y documentación interna.
También hay un caso menos vistoso pero muy rentable: onboarding interno. Cuando una persona nueva entra en operaciones, administración o ventas, hace muchas preguntas repetidas. Un asistente sobre conocimiento interno puede reducir esa dependencia sin obligar a nadie a leerse veinte documentos desde cero.
El gancho de negocio no es "tener IA". Es que menos trabajo se atasque porque la información vive dispersa.
Permisos: si una persona no puede ver un documento, la IA tampoco
Este punto no admite demasiada creatividad. Si un usuario no tiene permiso para leer un contrato, un margen comercial o un documento de recursos humanos, el sistema RAG no debe recuperarlo para responderle.
La arquitectura debe aplicar permisos antes de enviar contexto al modelo. No después. Si el fragmento sensible ya salió hacia el LLM, el daño puede estar hecho aunque la respuesta final lo oculte.
Para una empresa de Euskadi con departamentos, clientes, delegaciones o proyectos distintos, conviene diseñar permisos desde el primer piloto:
- Por área o equipo.
- Por tipo de documento.
- Por cliente o proyecto.
- Por nivel de sensibilidad.
- Por usuario o rol.
No todos los proyectos necesitan una arquitectura compleja desde el día uno. Pero sí necesitan una regla básica: el asistente solo trabaja con contenido autorizado.
Trazabilidad: respuestas con fuente, no frases bonitas
Un RAG empresarial debe enseñar de dónde sale la respuesta. Si contesta sobre una política, debería citar el documento. Si resume un procedimiento, debería enlazar el fragmento usado. Si recomienda un paso técnico, debería mostrar la fuente que lo respalda.
Esto cambia mucho la adopción. Un usuario interno no confía porque la respuesta suene bien. Confía cuando puede comprobarla rápido.
La trazabilidad también ayuda a mejorar el sistema. Si una respuesta falla, se puede revisar qué documento recuperó, qué fragmento usó y si el problema estaba en la búsqueda, en el documento o en la pregunta. Sin esa pista, todo acaba en opiniones: "la IA no funciona" o "el usuario preguntó mal". Ninguna de las dos ayuda demasiado.
Privacidad y datos: decidir qué puede salir y qué debe quedarse dentro
No todo conocimiento interno tiene el mismo riesgo. Una ficha pública de servicio no exige el mismo cuidado que un contrato, una incidencia de cliente o un parte de fabricación.
Antes de implantar RAG y LLMs conviene clasificar los datos en grupos sencillos:
- Información pública o comercial.
- Documentación interna de bajo riesgo.
- Datos de cliente o proveedor.
- Información contractual, financiera o sensible.
- Propiedad intelectual y conocimiento técnico crítico.
A partir de ahí se decide arquitectura. Para algunos casos bastará una nube bien configurada, con proveedor europeo, registros y control de acceso. Para otros puede tener sentido una nube privada, un despliegue local o una arquitectura híbrida. La decisión no debería tomarse por moda. Debería salir del dato, del uso y del riesgo.
Evaluación: probar con preguntas reales, no con una demo amable
La demo típica funciona porque usamos preguntas fáciles. El sistema busca una política clara, responde bien y todo el mundo asiente. Luego llegan usuarios reales con preguntas ambiguas, documentos viejos, sinónimos, abreviaturas y excepciones.
Antes de escalar, hace falta un pequeño banco de pruebas. Preguntas frecuentes, casos límite, consultas que deberían rechazarse y ejemplos donde la respuesta correcta depende de permisos. No tienen que ser cientos al principio. Tienen que ser reales.
Métricas útiles para empezar:
- Porcentaje de respuestas con fuente correcta.
- Respuestas rechazadas cuando falta información.
- Documentos recuperados que no correspondían al usuario.
- Tiempo hasta encontrar una respuesta útil.
- Satisfacción de usuarios por área.
Si el sistema mejora en esas métricas, hay base. Si solo "parece listo" en una reunión, todavía no.
Arquitectura mínima para empezar bien
Un primer piloto serio de RAG no necesita convertirse en una plataforma eterna. Necesita las piezas justas:
- Un conjunto documental acotado y limpio.
- Un buscador semántico o híbrido bien configurado.
- Permisos aplicados antes de recuperar contexto.
- Respuestas con fuentes visibles.
- Registro de preguntas, documentos usados y errores.
- Un banco de evaluación con preguntas reales.
- Un responsable de negocio que revise resultados.
La tentación es cargar todos los documentos de golpe. Suele ser mala idea. Mejor empezar con un área donde el dolor sea claro: soporte técnico, documentación comercial, procedimientos internos o calidad. Si funciona ahí, se amplía.
Casos de negocio con buen punto de entrada
Para pymes y empresas medianas de Gipuzkoa y Euskadi, estos casos suelen tener sentido:
- Asistente interno para procedimientos de operaciones.
- Consulta de documentación técnica y manuales de producto.
- Soporte a comerciales para preparar respuestas y propuestas.
- Ayuda a atención al cliente con fuentes aprobadas.
- Búsqueda en contratos, políticas o documentación de proyecto con permisos.
- Onboarding de nuevas personas en áreas con mucho conocimiento disperso.
El patrón común es simple: mucha información, muchas consultas repetidas y riesgo controlable si una persona revisa las respuestas importantes.
Riesgos normales y cómo cerrarlos
El primer riesgo es la documentación sucia. Si hay versiones duplicadas, PDFs obsoletos y carpetas sin criterio, el RAG lo notará. No hace falta ordenar toda la empresa, pero sí el conjunto que entra en el piloto.
El segundo es la falsa confianza. Un LLM puede escribir una respuesta convincente aunque el contexto no alcance. Por eso importan las fuentes, los rechazos y la evaluación.
El tercero es la adopción. Si el asistente vive fuera del flujo de trabajo, el equipo lo probará dos días y volverá a preguntar por Slack, correo o pasillo. Mejor integrarlo donde ya trabaja la gente: intranet, CRM, helpdesk, Teams, Slack o portal interno.
El cuarto es el mantenimiento. Los documentos cambian. Los permisos cambian. Los productos cambian. Un RAG sin dueño se estropea poco a poco, aunque el primer día funcionara bien.
Primer paso recomendado
Si una empresa de Donostia - San Sebastián, Gipuzkoa o Euskadi quiere empezar con RAG y LLMs, yo no empezaría indexando toda la documentación. Empezaría eligiendo un área concreta y haciendo tres preguntas:
- Qué consultas se repiten cada semana.
- Qué documentos contienen la respuesta correcta.
- Qué permisos y trazas hacen falta para usarlo sin sustos.
Con eso se puede diseñar un piloto pequeño, medible y bastante honesto. Si el sistema responde con fuentes, respeta permisos y ahorra búsquedas reales, merece escalar. Si no, mejor detectarlo pronto.
En Umintia ayudamos a empresas de Euskadi a diseñar asistentes RAG y soluciones con LLMs pegadas a procesos reales: documentación interna, soporte, ventas, operaciones y conocimiento técnico. Si quieres revisar qué parte de tu conocimiento interno podría convertirse en un asistente fiable, escríbenos a info@umintia.com. Un diagnóstico inicial suele bastar para separar un buen caso de una demo bonita.