RAG en empresa: cómo conectar un LLM a tus datos sin filtrarlos

Casi todas las empresas medianas españolas con las que hablamos quieren lo mismo: “queremos algo tipo ChatGPT, pero que conozca nuestros documentos, contratos, manuales, tickets y conversaciones internas”. Eso, traducido a arquitectura, es RAG en empresa: Retrieval-Augmented Generation. Y es probablemente el patrón con mejor relación coste/impacto que existe hoy para implantar IA real sobre datos propios. El problema es que la mayoría de proyectos RAG fracasan, no por la tecnología, sino porque se montan como demos y no como sistemas de producción. Este artículo es para que el tuyo no caiga en el mismo agujero.

En Everglow entramos como implantadora de IA en empresas y RAG es, desde hace dos años, el caso de uso que más volumen mueve en nuestros squads. Hemos visto montar RAGs sobre Notion, sobre SharePoint, sobre carpetas de Google Drive con quince años de basura, sobre bases de tickets de Zendesk, sobre Confluence, sobre PDFs escaneados que ni el dueño del documento sabía que existían. Y en todos los casos, el éxito o el fracaso se decide en cuatro o cinco decisiones de arquitectura que casi nadie toma a tiempo.

Qué es RAG y por qué importa en empresa

RAG es un patrón sencillo en su descripción y traicionero en su implementación. La idea: en lugar de fine-tunear un modelo con tus datos —caro, lento, opaco y casi siempre innecesario—, le das al LLM tus datos en tiempo de consulta. Cuando un usuario pregunta algo, un sistema de búsqueda recupera los fragmentos relevantes de tu base de conocimiento y se los pasa al modelo como contexto. El modelo responde usando esa información, no su memoria entrenada.

RAG no es una tecnología, es un contrato: el modelo solo puede afirmar lo que has recuperado. Si tu retrieval es malo, tu IA es malo. Si tu retrieval filtra datos que no debe, tu IA filtra datos que no debe.

Por qué esto importa en empresa:

• Tus datos no salen del modelo, salen de tu sistema de búsqueda. Controlas qué entra como contexto.
• Las respuestas son trazables: cada afirmación del modelo se puede atar a un documento concreto.
• No dependes del conocimiento congelado del modelo: si actualizas un manual, la IA lo sabe a la siguiente consulta.
• Coste operativo razonable: hablamos de céntimos por consulta en la mayoría de implantaciones reales, no de los miles de euros que cuesta un fine-tuning.

Lo que NO te da RAG: razonamiento profundo sobre tu negocio, juicio estratégico, ni magia. Te da un buscador semántico con un narrador delante. Asumir más que eso es la primera causa de pilotos fallidos.

La arquitectura mínima que funciona en producción

Una arquitectura RAG seria tiene cinco capas. Si te saltas alguna, lo pagarás. En orden:

1. Ingesta y normalización: cómo entran los datos al sistema. PDFs, Word, Notion, Confluence, tickets, correos, transcripciones. Cada fuente requiere su propio extractor y limpiador. Aquí se decide la calidad del 70% del proyecto.
2. Chunking inteligente: cómo se trocea cada documento. Trozos demasiado pequeños pierden contexto, demasiado grandes diluyen la búsqueda. La estrategia depende del tipo de contenido (legal, técnico, conversacional).
3. Embeddings y vector store: el modelo de embeddings convierte cada chunk en un vector y se almacena en una base vectorial (Qdrant, Weaviate, pgvector, Pinecone). Aquí se decide la latencia y el coste por consulta.
4. Retrieval con permisos: el corazón del sistema. Cuando un usuario pregunta, recuperas los chunks más relevantes filtrando por lo que ese usuario puede ver. Esto es la frontera entre un RAG corporativo y una bomba de filtraciones.
5. Generación con citas: el LLM responde basándose solo en el contexto recuperado, citando la fuente. Si no hay contexto suficiente, dice que no sabe. Punto.

Cualquiera de estas cinco capas mal montada hace que el sistema parezca funcionar en demo y reviente en producción. Las dos que más fallan son la 1 (ingesta) y la 4 (permisos).

Por qué se filtran datos en un RAG mal montado

La pesadilla de cualquier responsable de TI o cumplimiento: un comercial junior pregunta al copiloto interno “¿cuánto cobra el director financiero?” y obtiene una respuesta correcta. No porque el modelo “sepa”, sino porque alguien indexó en el RAG la nómina del CFO sin filtros de acceso. El modelo no falló: hizo exactamente lo que le pediste.

Las filtraciones de datos en RAG vienen casi siempre de tres errores:

• Indexar todo lo que encuentras sin auditar primero qué fuentes contienen información sensible. Carpetas de Drive con seis años de antigüedad esconden barbaridades.
• Ignorar los permisos de la fuente original. Si en SharePoint solo el comité de dirección ve el archivo X, tu RAG debe replicar ese permiso. La mayoría de implementaciones rápidas indexan con un único usuario de servicio que tiene acceso a todo, y luego sirven las respuestas a cualquiera.
• Confiar en el prompt para limitar el modelo. “No reveles información confidencial” no es una protección. Es una sugerencia que el modelo puede ignorar si el contexto recuperado contiene esa información. Lo que no recuperas, no se filtra. Lo que recuperas, está expuesto.

La regla operativa: el control de acceso vive en el retrieval, nunca en el prompt. Cada consulta debe ejecutarse con la identidad del usuario final, y el filtro de permisos debe aplicarse antes de que los chunks lleguen al LLM. Si tu vector store no soporta multi-tenancy con metadata filtering, cambia de vector store antes de seguir.

Decisiones de arquitectura que casi nadie toma a tiempo

Estas son las preguntas que en Everglow ponemos sobre la mesa en la primera reunión de cualquier proyecto RAG. Si llegas al desarrollo sin respuesta clara, vas a tener que rehacer:

• ¿Qué fuentes entran y cuáles no, y quién lo decide? No “todas las fuentes posibles”. Empieza por una, máximo tres. Mejor un RAG sobre el manual de operaciones que sirve, que uno sobre todo el conocimiento corporativo que falla en cada consulta.
• ¿Cuál es el modelo de permisos? Por usuario, por rol, por departamento, por proyecto. Tiene que mapear el modelo real de la empresa, no inventar uno nuevo.
• ¿Qué pasa cuando un documento se actualiza, se borra o cambia de permisos? Necesitas un pipeline de re-indexación que no dependa de que alguien se acuerde de pulsar un botón.
• ¿Qué LLM usas y dónde corre? Modelo cerrado vía API (más calidad, datos salen del perímetro), modelo abierto en infraestructura propia (más control, más coste de operación), o híbrido. La respuesta depende de tu sector, no de la moda del mes.
• ¿Cómo mides que funciona? Tasa de respuestas con cita, tasa de “no lo sé” justificadas, satisfacción del usuario, ticket time saved. Si no defines métricas antes de construir, no sabrás si el proyecto vale lo que cuesta.

Casos de uso donde RAG aporta retorno real

No todo problema se resuelve con RAG. Pero estos cuatro son donde lo hemos visto pagar el proyecto en menos de seis meses, repetidamente:

• Copiloto interno de soporte: el equipo de atención al cliente consulta procedimientos, casos resueltos previos, condiciones contractuales por cliente. Reduce el tiempo medio de respuesta entre un 30% y un 50%, y baja la curva de onboarding de agentes nuevos de meses a semanas.
• Asistente comercial sobre catálogo y casos: un comercial pregunta condiciones, referencias parecidas, objeciones tratadas en otros deals. Multiplica la productividad del equipo sin contratar.
• Q&A sobre normativa interna y compliance: legal, RRHH, financiero, operaciones. Lo que antes era “mándale un email a Marta” ahora es una consulta con cita al artículo concreto.
• Búsqueda semántica sobre histórico de proyectos: el activo más infrautilizado de cualquier consultora, ingeniería o estudio. Diez años de propuestas, especificaciones, lecciones aprendidas, accesibles en lenguaje natural.

Lo que NO recomendamos como primer RAG: chatbots de cara al cliente final, casos donde la respuesta tiene consecuencias legales directas sin revisión humana, o cualquier proceso que requiera razonamiento multi-paso complejo (eso es agentes, no RAG; ya escribimos sobre agentes IA vs automatizaciones clásicas).

Errores que vemos repetidos en empresas españolas

Por orden de frecuencia y dolor causado:

• Empezar por la herramienta y no por el caso de uso. “Queremos montar un RAG con Pinecone” no es un proyecto, es una compra. El proyecto es “queremos reducir el tiempo medio de resolución de tickets de nivel 1 en un 40% en seis meses”.
• Indexar PDFs sin OCR ni limpieza. La mitad de los manuales de operaciones de empresas industriales en España son PDFs escaneados de los años 2000. Sin OCR decente y limpieza, tu RAG es ruido.
• No medir ground truth. Sin un set de preguntas con respuestas correctas conocidas, no puedes saber si tu RAG mejora o empeora con cada cambio. Es como hacer SEO sin Search Console.
• Pilotos eternos sin criterio de cierre. Tres meses de POC en Slack del equipo de innovación, cero usuarios reales del negocio. Si no llega a producción con usuarios que dependen de él, no existe.
• Ignorar el coste por consulta a escala. Funcionar para 50 personas y para 5.000 son problemas distintos. La arquitectura barata para el primero te arruina en el segundo.

Cómo abordamos un RAG en Everglow

Sin recetas mágicas. Cuatro fases, calendario realista, criterios de salida claros:

1. Auditoría de fuentes y caso de uso (1-2 semanas): qué problema real resolvemos, qué fuentes entran, qué permisos aplican, qué métricas miden el éxito. Si no hay caso de uso con dueño y métrica, no construimos.
2. Prototipo evaluable (2-3 semanas): arquitectura mínima viable con una fuente, set de evaluación con 50-100 preguntas reales, métricas de retrieval y generación. Decisión go/no-go con datos.
3. Implantación productiva (4-8 semanas): pipeline de ingesta robusto, control de permisos por usuario, observabilidad, integración con la herramienta donde el usuario ya trabaja (Slack, Teams, intranet, CRM). Sin usuarios reales no hay producción.
4. Acompañamiento y mejora continua: medición semanal, ajuste de chunking, ampliación de fuentes según demanda real. La IA no se “termina”; se opera.

Si tu empresa lleva meses dando vueltas a un proyecto RAG que no acaba de despegar —o lo está montando a ciegas y empiezas a oler problemas—, escríbenos por contacto. Una conversación de media hora suele bastar para saber si el proyecto que tienes en la cabeza está bien planteado o si te van a cobrar tres veces más por algo que no va a llegar a producción.

RAG no es la solución a todo. Pero cuando el caso de uso encaja —y en empresas medianas españolas encaja más de lo que se cree—, es el patrón con más retorno por euro invertido que hay hoy en IA aplicada. La diferencia entre el RAG que cambia cómo trabaja un equipo y el RAG que acaba en una carpeta de pilotos olvidados es, casi siempre, una cuestión de criterio en cinco decisiones tempranas. Si las tomas bien, el resto es ingeniería.