Una arquitectura práctica para conectar documentos, datos y sistemas corporativos con inteligencia artificial sin perder permisos, trazabilidad ni criterio humano. Porque el cuello de botella de un asistente empresarial casi nunca es encontrar: es decidir quién puede ver qué.
Qué es realmente un RAG empresarial
Imagina la biblioteca de una empresa. No una biblioteca silenciosa con libros ordenados, sino una construida durante veinte años: manuales duplicados, contratos con anexos, presentaciones que contienen decisiones importantes, tablas que solo tienen sentido con su encabezado, documentos vencidos y carpetas que cada área organizó a su manera.
Ahora imagina que contratas al mejor bibliotecario del mundo para ese caos. Ha leído absolutamente todo: contratos, actas, tickets de soporte, correos, evaluaciones de desempeño, la carpeta de nómina. Escucha una pregunta, encuentra las páginas relevantes y las explica en lenguaje natural.
Esa es la promesa de RAG. Y funciona.
Hasta que un analista junior pregunta, con toda inocencia, “¿cuánto ganan en promedio los directores del área comercial?”, y el bibliotecario —que es servicial pero no tiene criterio— se lo dice.
Ese momento incómodo no es un caso extremo. Es el modo de fallo por defecto de casi todas las arquitecturas que se están desplegando hoy en las empresas.
La mecánica, sin jerga
Un modelo de lenguaje es como alguien que estudió muchísimo hace un año y luego dejó de leer. Sabe mucho, pero no sabe nada de tu empresa y no puede citarte la cláusula 14 de un contrato que nunca vio.
La Generación Aumentada por Recuperación —RAG, por Retrieval-Augmented Generation— resuelve eso convirtiendo el examen de memoria en un examen a libro abierto. El artículo fundacional de Patrick Lewis y sus coautores (NeurIPS 2020) lo planteó como la combinación de una memoria paramétrica —lo que el modelo aprendió— y una memoria no paramétrica —documentos recuperados desde una fuente externa—.
En la práctica, un sistema RAG ejecuta cinco acciones:
- Ingiere información desde documentos, bases de datos y aplicaciones.
- Representa ese contenido para que pueda encontrarse por palabras, significado, estructura o relaciones.
- Recupera la evidencia más relevante para una pregunta.
- Genera una respuesta usando esa evidencia como contexto.
- Evalúa y registra qué recuperó, qué respondió y con qué nivel de confianza.
La diferencia entre una demostración y una capacidad empresarial aparece en cada uno de esos verbos. Porque en una empresa el bibliotecario también debe saber quién pregunta, qué estanterías puede consultar, cuál versión está vigente, qué contenido puede estar manipulado, qué parte de la respuesta es evidencia y qué parte es interpretación, y cuándo simplemente no hay información suficiente para responder.
El salto empresarial ocurre cuando dejamos de preguntar “¿puede responder?” y empezamos a preguntar: “¿puede responder correctamente, con la información que ese usuario está autorizado a ver, citando la versión vigente y dejando evidencia suficiente para auditar el resultado?”. Parece un cambio técnico. En realidad es un cambio de responsabilidad.
Por qué el RAG ingenuo falla cuando sale del laboratorio
El RAG ingenuo sigue una receta conocida:
Esa línea concentra casi toda la jerga del campo, así que vale la pena traducirla entera:
- Los fragmentos (o chunks) son los pedazos en que se parte cada documento, porque un contrato de 80 páginas no cabe entero en la respuesta.
- Un embedding es la traducción de un texto a una lista de números que representa su significado. Textos que hablan de lo mismo quedan cerca entre sí en ese espacio numérico, aunque no compartan ni una palabra. Es lo que permite que el sistema encuentre “vacaciones” cuando preguntas por “días libres”.
- La base vectorial es el almacén de esos números, optimizado para responder rápido a la pregunta “¿qué hay cerca de esto?”.
- El top-k son los k fragmentos más cercanos que se recuperan —típicamente cinco o diez— y que se le entregan al modelo junto con la pregunta.
La receta es útil para aprender y para construir un prototipo. El problema aparece cuando se asume que también es una arquitectura de producción. Falla en cinco puntos.
1. Divide documentos sin comprenderlos
Un PDF no es una secuencia neutra de palabras. Contiene títulos, notas al pie, tablas, diagramas, columnas, anexos y referencias cruzadas. Cuando se fragmenta solo por cantidad de caracteres, una política queda separada de su excepción, una cifra de la unidad que la explica, una tabla de su encabezado. El sistema recupera texto parecido y pierde el significado documental.
2. Confunde similitud con relevancia
Los embeddings encuentran proximidad semántica. Eso no garantiza que el fragmento sea vigente, autorizado, completo o suficiente. Una respuesta puede construirse con el párrafo “más parecido” y aun así ser incorrecta.
3. Recupera primero y pregunta por permisos después
Este es el error más peligroso, y merece una sección propia más adelante. Si un fragmento confidencial entra en el contexto del modelo, intentar ocultarlo en la respuesta final llega demasiado tarde.
4. No sabe decir “no sé”
Los prototipos se optimizan para responder. Los sistemas confiables también deben aprender a abstenerse. Una respuesta elegante sin evidencia suficiente sigue siendo una respuesta peligrosa.
5. Mide el modelo y no el sistema
Cambiar de LLM puede mejorar la redacción. No corrige una mala recuperación, permisos incompletos, documentos rotos ni conocimiento obsoleto.
| Dimensión | RAG ingenuo | RAG empresarial |
|---|---|---|
| Contenido | Texto plano | Documentos, tablas, imágenes, datos y metadatos |
| Recuperación | Vectorial de un paso | Híbrida, filtrada, reordenada por relevancia y adaptable |
| Seguridad | Filtros posteriores | Identidad y permisos desde el origen |
| Respuestas | Texto plausible | Respuesta citada, trazable y capaz de abstenerse |
| Evaluación | Pruebas manuales | Conjunto dorado, métricas continuas y pruebas de ataque simulado |
| Operación | Índice estático | Actualización, versionado, auditoría y monitoreo |
| Complejidad | Igual para toda consulta | Enrutamiento según el tipo de pregunta |
Desliza la tabla →
La IA no corrige el desorden de una organización: lo amplifica. Si existen cinco versiones de una política, el RAG no elimina esa ambigüedad —puede recuperarla con mucha velocidad—. Si cada área interpreta los permisos de manera diferente, el asistente convierte una inconsistencia silenciosa en una fuga visible. Por eso la idea de La IA no hace inteligente a tu empresa: solo amplifica lo que ya es aplica de forma literal: antes de construir un asistente corporativo hay que decidir qué conocimiento merece convertirse en referencia.
Identidad antes que similitud: el error de orden
Aquí está el hallazgo que debería reordenar la conversación entera.
La forma intuitiva de resolver la seguridad es esta: buscamos en toda la base, traemos los diez fragmentos más relevantes y luego —con un filtro, o pidiéndole al propio modelo que se abstenga— quitamos lo que el usuario no debería ver.
Ese orden es estructuralmente inseguro. Un trabajo de 2024 sobre Authorization-First Retrieval (Namboothiri et al., TechRxiv) lo formaliza con una propiedad clásica de seguridad informática, la no interferencia: si un fragmento no autorizado llega a entrar en la ventana de contexto, esa información ya influyó en la salida. Puede que no aparezca citada. Puede que el modelo no la mencione. Pero cambió la respuesta. Y con la pregunta adecuada, vuelve a salir.
Los autores reportan que las fugas estructurales caen del 96,8 % al 0 % cuando el filtrado de permisos se aplica antes de la búsqueda vectorial. Con una salvedad importante: es un preprint —un borrador publicado antes de pasar por revisión de otros investigadores—. Explico por qué eso matiza la cifra más adelante.
No es un hallazgo aislado. Investigadores de Microsoft llegaron por otra vía a la misma conclusión en Enterprise AI Must Enforce Participant-Aware Access Control (arXiv:2509.14608): los filtros de salida, la sanitización de prompts y los firewalls perimetrales no detienen la exfiltración cuando los tokens sensibles ya se combinaron en las capas internas del modelo. Y van un paso más allá: en un asistente que resume correos no basta con verificar los permisos de quien pregunta; hay que verificar los de todos los participantes de esa conversación antes de alimentar el contexto.
Del lado de la ingeniería aplicable, Jeong y Lee (Permission-Aware RAG, IEEE Access, 2025) muestran cómo validar los permisos en tiempo real preguntándoselos al sistema que ya los administra —lo que en TI se llama IAM, la gestión de identidades y accesos: quién eres y qué puedes abrir—, en lugar de intentar la fantasía de copiar todas las reglas de la organización a una base paralela. Su punto de partida es que las fuentes corporativas tienen modelos de autorización distintos y no deberían convertirse en un repositorio donde “todos los fragmentos se parecen iguales”.
Cómo se suele plantear
“Los permisos los resolvemos en la capa de aplicación, antes de mostrar la respuesta.”
Cómo debería plantearse
“Un contenido no autorizado no debe convertirse siquiera en candidato semántico para ese usuario.”
En la práctica: cada fragmento del índice tiene que llevar sus permisos heredados del sistema de origen —lo que en TI se llama una ACL, la lista que dice quién puede abrir un documento y quién no— y la consulta tiene que estar acotada por la identidad de quien pregunta antes de que se ejecute la búsqueda.
El prefiltrado exhaustivo degrada el rendimiento de los algoritmos de búsqueda aproximada a gran escala. Es un compromiso real de latencia. Pero es el tipo de compromiso que se negocia con arquitectura, no el que se resuelve con una disculpa después de una fuga.
Envenenar la biblioteca: las otras superficies de ataque
Hay una asimetría curiosa en cómo se construyen estos sistemas. Los equipos validan obsesivamente lo que escribe el usuario, por miedo a las inyecciones de prompt. Y luego confían ciegamente en el texto que recuperaron de su propia base de datos. Ammann y colegas lo llaman la paradoja de la confianza en RAG (IEEE SDS, 2025).
1. Envenenamiento de la base de conocimiento
PoisonedRAG (Zou et al., USENIX Security 2025) formula el envenenamiento como un problema de optimización. Inyectando cinco textos por pregunta objetivo en una base con 2,68 millones de documentos limpios, los autores inducen la respuesta que quieren con tasas de éxito en torno al 90 % de media, y de hasta el 97 % en los escenarios más favorables.
Cinco documentos entre dos millones y medio. Piensa en cuántas fuentes de tu empresa son editables por cualquier empleado: la wiki interna, los tickets, los comentarios en documentos compartidos, el correo. Cada una es superficie de ataque.
- Procedencia verificada y, cuando sea posible, firma del contenido.
- Lista explícita de fuentes autorizadas; cuarentena para documentos nuevos o editables.
- Deduplicación y detección de anomalías sobre los vectores.
- Separación estricta entre contenido e instrucciones.
- Pruebas de ataque simulado sobre la recuperación, y capacidad de retirar y reindexar rápido.
2. Inyección indirecta de prompts
Un documento puede incluir instrucciones dirigidas al modelo aunque para el usuario parezca contenido normal. La arquitectura debe tratar los documentos recuperados como datos no confiables, nunca como instrucciones. El modelo no debería obedecer órdenes encontradas dentro del corpus.
3. Exceso de confianza en la cita
La cita no convierte automáticamente una afirmación en verdadera. Puede citarse un documento incorrecto, desactualizado o insuficiente. Por eso seguridad y calidad están conectadas: verificar el soporte de cada afirmación es tan importante como verificar el permiso.
| Riesgo | Efecto de primer orden | Efecto de segundo orden | Control prioritario |
|---|---|---|---|
| Permisos mal aplicados | Exposición de un documento | Pérdida de confianza y sanciones | Autorización previa y pruebas de no fuga |
| Documento envenenado | Respuesta manipulada | Decisiones contaminadas a escala | Procedencia, cuarentena y detección de manipulación |
| Inyección indirecta | Cambio de instrucciones | Acciones no autorizadas del agente | Aislamiento de instrucciones y guardrails |
| Fuente obsoleta | Respuesta incorrecta | Institucionalización de una práctica vencida | Vigencia, propietario y versionado |
| Cita débil | Apariencia de evidencia | Confianza injustificada | Verificación de soporte por afirmación |
Desliza la tabla →
Y aquí lo más honesto que puedo decir: las defensas son mucho menos maduras que los ataques. Existen propuestas —filtrado por perplejidad, arquitecturas centinela-estratega, auditoría activa de afirmaciones envenenadas—, pero ninguna con validación a escala empresarial. Hoy este riesgo se gestiona limitando la superficie, no neutralizándolo.
En Alfabetización en IA: no es saber prompts, es saber juzgar propuse distinguir entre delegar, cocrear y proteger. Un RAG empresarial necesita la misma lógica. Consultar un manual de vacaciones no equivale a interpretar una cláusula contractual, recomendar una decisión clínica o evaluar a una persona. La arquitectura debe reconocer esa diferencia y elevar la revisión humana cuando la consecuencia del error lo exige.
Lo que sí funciona (y tiene números)
Después de tanto riesgo, conviene ser justos: hay un núcleo técnico con evidencia sólida y reproducible. Y es más aburrido de lo que la industria querría.
Búsqueda híbrida más reranking
Son dos términos que conviene traducir antes de seguir, porque aparecen en todas las propuestas técnicas y casi nunca se explican.
Búsqueda híbrida es combinar dos formas de buscar que fallan en cosas distintas. La semántica entiende el significado: si preguntas por “días libres”, encuentra el documento que habla de “vacaciones”. La léxica es la de toda la vida —el algoritmo BM25 de los buscadores clásicos—: busca la palabra exacta y es la única capaz de encontrar el código “NCF-2214-B” o el apellido de un proveedor. Cada una por separado deja huecos; juntas se tapan mutuamente.
Reranking es un segundo filtro de calidad. La primera búsqueda es rápida pero tosca: devuelve, digamos, cincuenta candidatos razonables. El reranker es un modelo más lento y más fino que lee esos cincuenta con calma y los reordena por relevancia real, para que los cinco que finalmente llegan al modelo sean los mejores y no solo los que más se parecían. Es la diferencia entre el vistazo rápido de un buscador y la lectura atenta de un bibliotecario.
Esa combinación es el consenso más robusto de toda la literatura, y es el baseline del que se habla más adelante: la versión mínima y bien hecha contra la que hay que comparar cualquier cosa más sofisticada que se quiera añadir.
Anthropic publicó números reproducibles en Contextual Retrieval, añadiendo una idea sencilla y potente: antes de indexar cada fragmento, anteponerle un par de frases que expliquen de dónde viene y de qué trata.
Dos tercios menos de fallos sin grafos, sin agentes y sin reentrenar nada. Es la mejor relación evidencia/costo del campo.
El resultado no debe leerse como una garantía universal —es un informe de un proveedor de modelos, aunque la técnica es reproducible con el cookbook público—, pero sí confirma una idea importante: la calidad del contexto que rodea al fragmento importa tanto como el embedding.
Grafos de conocimiento: potentes, pero no para todo
Antes de decidir si los necesitas, conviene saber qué son. Un grafo de conocimiento es un mapa de relaciones. En lugar de guardar los documentos como trozos de texto sueltos, guarda qué está conectado con qué: este incidente afectó a este producto, que depende de este componente, que ya había fallado en este otro caso. Donde una base vectorial responde “¿qué texto se parece a mi pregunta?”, un grafo responde “¿qué camino conecta estas cosas?”.
Esa diferencia importa cuando la respuesta no está dentro de un documento, sino en la relación entre varios.
El caso de producción más convincente es el de LinkedIn (Xu et al., SIGIR ’24, arXiv:2404.17723). Construyeron un grafo sobre su histórico de tickets de soporte —la estructura interna de cada ticket y las relaciones entre tickets— y consultan subgrafos completos en lugar de fragmentos sueltos. La precisión de recuperación casi se duplicó, pero el número que justificó el proyecto fue otro: el tiempo mediano para resolver una incidencia bajó de 7 a 5 horas, un 28,6 % menos, tras unos seis meses en producción. Eso no es una métrica de laboratorio: son horas de ingeniero.
Ahora fíjate en las dos condiciones que hicieron funcionar ese caso. La pregunta era relacional —“¿este incidente se parece a alguno anterior y cómo se resolvió?”— y el dato ya venía con relaciones ricas: tickets que se referencian entre sí. Sin esas dos condiciones, el grafo es costo sin retorno.
“¿Cuál es la política de viáticos?” se responde con un documento. “¿Por qué este cliente escaló tres veces el mismo problema en seis meses?” se responde con el camino entre muchos. La primera pregunta no justifica construir ni mantener un grafo. La segunda, probablemente sí. Y esa es toda la regla de decisión.
Cuándo la complejidad se gana el derecho a existir
Una de las discusiones más útiles del campo es también una de las menos cómodas: ¿necesitamos RAG para todo? La respuesta es no.
Li y sus coautores (EMNLP 2024, Industry Track) compararon sistemáticamente RAG contra modelos de contexto largo: los que pueden leer de una sola vez un texto enorme —cientos de páginas— sin necesidad de buscar nada previamente. Con recursos suficientes, el contexto largo supera a RAG en calidad promedio; RAG gana en costo. Su propuesta, Self-Route, dirige cada consulta al camino más adecuado. Anthropic va más lejos: si tu corpus cabe en menos de unos 200.000 tokens, mételo completo en el prompt y olvídate del pipeline.
Traducido a la práctica: si el conocimiento de un dominio concreto —digamos, todas las políticas de recursos humanos— cabe en unas 300 páginas, montar fragmentación, embeddings, base vectorial y reranker para eso es sobreingeniería. Y cada componente que añades es una superficie más de fallo y de ataque.
Esto sugiere una arquitectura router-first: en lugar de mandar todas las preguntas por el mismo camino caro, un enrutador decide para cada consulta cuál es el camino adecuado. La complejidad se activa bajo demanda.
| Tipo de necesidad | Enfoque inicial recomendado | Razón |
|---|---|---|
| Corpus pequeño y estable | Contexto largo con caching | Reduce componentes y errores de recuperación |
| Preguntas factuales sobre gran volumen | RAG híbrido + reranking | Mejor equilibrio entre precisión, costo y latencia |
| Códigos, nombres, referencias exactas | Búsqueda léxica + filtros | La coincidencia exacta supera a los embeddings |
| Preguntas relacionales o multi-salto | KG-RAG o GraphRAG | Conserva entidades, relaciones y caminos |
| Preguntas globales sobre todo el corpus | GraphRAG jerárquico | Resume comunidades y temas amplios |
| Investigación iterativa | RAG agéntico | Permite buscar, abrir, contrastar y cambiar de estrategia |
| Métricas y cálculos corporativos | SQL o capa semántica + LLM | Evita “calcular” desde fragmentos de texto |
| Documentos visuales complejos | Recuperación multimodal | Preserva tablas, diseño, gráficos e imágenes |
| ¿Dónde está el documento X? | Búsqueda empresarial + LLM ligero | El motor maduro ya tiene los permisos implementados |
Desliza la tabla →
GraphRAG no es “RAG mejorado” para todo
GraphRAG aporta valor cuando la estructura importa. El trabajo de Microsoft Research (arXiv:2404.16130) aborda preguntas globales que un buscador de fragmentos locales resuelve mal. Pero construir y mantener un grafo cuesta: extracción de entidades, resolución de duplicados, actualización de relaciones, generación de resúmenes y evaluación de la calidad estructural. El costo de indexación es alto porque cada paso requiere muchísimas llamadas al modelo.
Y la sofisticación no garantiza mejores resultados: HippoRAG (arXiv:2405.14831), pese a su elegancia conceptual, rinde peor que un buscador denso convencional en las pruebas de HotpotQA: encuentra el documento correcto en el 60,5 % de los casos frente al 64,7 % de ColBERTv2.
Los agentes tampoco son gratuitos
Un agente puede buscar, abrir documentos, reformular la consulta y verificar hallazgos. Eso amplía la cobertura, pero aumenta la latencia, el consumo de tokens, la superficie de ataque, la dificultad para reproducir una respuesta y la necesidad de gobernar herramientas y permisos.
La pregunta correcta no es “¿podemos usar agentes?”, sino: ¿qué clase de consulta mejora lo suficiente para justificar el costo y el riesgo adicionales?
En mis artículos sobre agentes de IA y sobre organizaciones AI-Native he insistido en una idea: la autonomía útil no aparece cuando una herramienta hace más cosas, sino cuando existe un workflow capaz de gobernar lo que hace. Con RAG ocurre lo mismo. Un agente que investiga sin límites no es inteligencia empresarial: es incertidumbre automatizada. Y casi nadie presupuesta el mantenimiento, que es donde muere la mayoría de estos proyectos.
La inteligencia documental: el problema que se esconde antes del retriever
Muchas organizaciones creen que su problema es escoger embeddings. En realidad, todavía no han logrado leer bien sus documentos.
Informes financieros, manuales técnicos y documentos regulatorios contienen información visual: jerarquías, tablas, diagramas, columnas, celdas combinadas, notas al pie y relaciones espaciales. Nada de eso sobrevive a una fragmentación por caracteres.
Hay dos caminos, y no compiten entre sí. Herramientas como Docling (IBM Research, arXiv:2408.09869) convierten documentos en representaciones estructuradas preservando el orden de lectura y las tablas. En la otra dirección, ColPali (Faysse et al., ICLR 2025, arXiv:2407.01449) abandona la extracción de texto por completo: trata cada página como una imagen y la incrusta con un modelo de visión-lenguaje. En el benchmark ViDoRe recupera con más precisión que un pipeline clásico —81,3 frente a unos 75 en la métrica estándar del campo, nDCG@5— a cambio de una huella de memoria bastante mayor.
- Para documentos principalmente textuales, una conversión estructurada suele ser suficiente.
- Para colecciones con tablas, formularios y diagramas, la recuperación visual añade valor real.
- Para datos críticos, conviene conservar ambas representaciones y evaluar cuál recupera mejor.
Si tu conocimiento vive en PDF con tablas financieras, planos o infografías —y en la mayoría de empresas latinoamericanas vive exactamente ahí—, este es el punto donde más información se pierde.
El contenido también debe diseñarse para ser recuperado
Un sistema RAG hereda la calidad editorial de su base de conocimiento. Los procedimientos con títulos vagos, siglas sin definir, tablas sin descripción o excepciones escondidas producen peores respuestas. Mejorar la documentación puede elevar la calidad sin cambiar el modelo.
Eso implica crear una disciplina de ContentOps para IA: propietario por documento, fecha de vigencia, definiciones explícitas, encabezados informativos, tablas acompañadas de explicación, separación clara entre regla, excepción y ejemplo, historial de cambios y política de retiro del contenido obsoleto.
En La Aldea de los Datos usé la imagen de una biblioteca, un lago, tiendas especializadas, vecindarios y un telar para explicar una arquitectura de datos moderna. RAG añade un personaje nuevo a esa aldea: un intérprete que conversa con todos esos lugares. Pero el intérprete no puede compensar una biblioteca sin catálogo, un lago convertido en pantano o un telar donde nadie conoce el origen de los hilos.
La arquitectura de referencia: seis planos que deben trabajar juntos
Una arquitectura empresarial no debería organizarse alrededor de una herramienta, sino alrededor de responsabilidades. El principio rector: gobernanza primero, complejidad bajo demanda.
Identidad y autorización — el cimiento, no un añadido
Cada consulta transporta el contexto del usuario, su rol, sus atributos y las restricciones de la fuente. Conviene heredar las reglas del sistema original en lugar de reconstruirlas de forma aproximada en una base paralela. Esta capa se diseña antes de indexar el primer documento.
Conocimiento e ingesta
Conecta gestores documentales, wikis, CRM y ERP, bases relacionales, almacenes analíticos y APIs; también correos, tickets y transcripciones cuando exista base legal para usarlos. Ingerir no es copiar archivos: hay que conservar procedencia, propietario, fecha, vigencia, sensibilidad y permisos.
Memoria e indexación
Una sola representación rara vez basta. Índice léxico para nombres y códigos exactos; índice vectorial para significado y paráfrasis; metadatos para permisos, fechas y estado documental; grafo cuando las relaciones entre entidades son parte de la pregunta; SQL o capa semántica cuando la respuesta depende de cálculos.
Recuperación y reranking
Búsqueda híbrida que combina señales léxicas y densas, fusión por rango recíproco y un reranker que reordena los candidatos con un análisis más preciso. Este es el baseline contra el que se mide todo lo demás.
Enrutamiento y generación
No todas las preguntas merecen el mismo pipeline. Un router decide entre búsqueda empresarial, RAG híbrido, contexto completo, GraphRAG, consulta SQL o recuperación agéntica. La respuesta final debe separar hechos, inferencias y ausencia de evidencia, con citas suficientemente precisas para abrir la fuente.
Evaluación y observabilidad
Toda respuesta deja rastro: identidad y política aplicada, consulta original y reescrita, documentos candidatos y utilizados, versión del índice, del retriever, del reranker y del modelo, citas producidas, latencia, costo, feedback y alertas de acceso o comportamiento anómalo.
El orden importa. Casi todos los proyectos que he visto empiezan por el plano 4, porque es el divertido.
En AI Studios en 2026 propuse pensar las plataformas como talleres: no basta con elegir la mejor máquina; importan las reglas, las herramientas, el control de calidad y la operación. RAG confirma esa tesis. El LLM es una máquina del taller. La capacidad empresarial aparece en todo lo que lo rodea.
Cómo evaluar un RAG sin enamorarse de la demo
Una buena demostración elige preguntas que el sistema puede responder. Una buena evaluación busca también las que deberían hacerlo fallar.
Marcos como RAGAS (EACL 2024) y ARES (NAACL 2024) permiten evaluar sin necesidad de respuestas correctas escritas a mano, separando dimensiones como relevancia del contexto, fidelidad de la respuesta y relevancia final. Un umbral operativo razonable: si la fidelidad está por debajo de 0,7 tras optimizar, el problema está en la fragmentación o en los embeddings. Arregla eso antes de añadir grafos o agentes; añadir complejidad sobre una base rota solo la hace más cara de diagnosticar.
Y ahora la dosis de humildad. El benchmark CRAG (Yang et al., NeurIPS 2024) midió el techo real del campo:
| Sistema | Respuestas correctas sin alucinar |
|---|---|
| LLM sin RAG | ~34 % |
| RAG simple | ~44 % |
| Soluciones industriales de referencia | 63 % |
Con tasas de alucinación del 16 % al 25 % y latencias de 3,4 a 11,6 segundos. La cifra no debe extrapolarse a cualquier empresa, pero elimina una ilusión: RAG no convierte automáticamente al LLM en una fuente confiable.
Si tu proyecto se presentó al comité prometiendo un asistente que “responde con precisión sobre toda la documentación corporativa”, ese número debería estar en la diapositiva dos. No para matar el proyecto, sino para diseñar el flujo correcto: un sistema que acierta dos de cada tres veces y siempre cita su fuente es enormemente útil. Uno que acierta dos de cada tres veces y se presenta como oráculo es un pasivo.
Un cuadro de mando mínimo
| Dimensión | Pregunta que responde | Ejemplos de métrica |
|---|---|---|
| Recuperación | ¿Encontró la evidencia necesaria? | Recall@k, MRR, context recall |
| Precisión contextual | ¿Recuperó demasiado ruido? | Precision@k, context precision |
| Fundamentación | ¿La respuesta está soportada? | Faithfulness, entailment por afirmación |
| Citación | ¿La cita respalda exactamente el texto? | Citation precision y coverage |
| Abstención | ¿Sabe rechazar lo que no puede responder? | Tasa de rechazo correcto |
| Seguridad | ¿Evita recuperar contenido no autorizado? | Leakage rate, policy violations |
| Robustez | ¿Resiste contenido malicioso o contradictorio? | Attack success rate, detección de conflictos |
| Operación | ¿Funciona dentro de los límites reales? | Latencia p95, costo por consulta, disponibilidad |
| Negocio | ¿Mejora una actividad importante? | Tiempo de resolución, retrabajo, adopción |
Desliza la tabla →
El conjunto dorado pertenece a la empresa
Los benchmarks públicos ayudan a comparar técnicas. No sustituyen un conjunto de pruebas internas. Un golden set debería incluir preguntas frecuentes, complejas, ambiguas y sin respuesta; documentos obsoletos y conflictos entre fuentes; usuarios con permisos diferentes; intentos de extraer información sensible; consultas en los idiomas reales de la organización; y casos donde la respuesta correcta es escalar a una persona.
La analítica no termina en un modelo: termina cuando cambia una decisión, una acción o un resultado. Ese principio, desarrollado en Analítica de Datos en 5 Niveles, también debe gobernar un RAG. Mejorar dos puntos de recall es irrelevante si el usuario sigue sin confiar en la respuesta.
Una hoja de ruta de 90 días: construir evidencia antes que infraestructura
El error más común es intentar conectar “todo el conocimiento corporativo” desde el primer día. Es mejor escoger un dominio donde exista una necesidad frecuente, el conocimiento esté delimitado, haya un propietario claro, el impacto pueda medirse, el riesgo sea manejable y los usuarios estén disponibles para probar.
Días 1–30: gobierno y línea base
Fase 1 de 3- Define una pregunta de negocio concreta y selecciona el corpus con sus propietarios.
- Mapea los permisos reales de cada fuente, no los que dice la documentación. Descubrirás permisos rotos antes de que los descubra el asistente.
- Clasifica sensibilidad y vigencia de cada fuente.
- Diseña el conjunto dorado: 50–100 preguntas reales con su respuesta correcta.
- Mide el proceso actual sin IA y establece criterios de abstención y escalamiento.
- Crea el modelo de amenazas de ingesta antes de conectar nada editable.
Entregable: una especificación de producto y gobierno, no una demo.
Días 31–60: baseline seguro
Fase 2 de 3- Mide el corpus en tokens. Si cabe en menos de 200.000, evalúa contexto largo antes de construir el pipeline.
- Implementa parsing estructurado y crea índices léxico y vectorial.
- Aplica la autorización en la recuperación, desde el primer día.
- Incorpora reranking y citas verificables.
- Registra cada paso del pipeline para auditoría.
- Ejecuta pruebas funcionales, de permisos y de ataque simulado; compara contra búsqueda tradicional y contexto largo.
Entregable: un baseline medible.
Días 61–90: piloto y decisión de escala
Fase 3 de 3- Prueba con usuarios reales y mide calidad, latencia, costo y utilidad.
- Analiza los errores por causa, no por síntoma.
- Mejora el contenido antes de añadir complejidad.
- Activa GraphRAG, SQL o agentes solo para las consultas que lo necesiten y con retorno medido contra el baseline.
- Define operación, soporte y ownership.
- Decide si se escala, se rediseña o se detiene.
Entregable: evidencia para una decisión de inversión.
Elegir el modelo de lenguaje. Es la decisión que más tiempo consume en los comités y la que menos determina el resultado.
La mejor prueba de concepto no es la que impresiona más en una reunión: es la que reduce incertidumbre. Un piloto debe responder tres preguntas —¿funciona?, ¿es seguro?, ¿vale la pena operarlo?—. Si solo responde la primera, todavía no es una decisión empresarial.
Diez errores frecuentes al implementar RAG empresarial
Empezar por el modelo
El caso de uso, el corpus y el riesgo deberían venir primero.
Indexar todo
Más documentos pueden reducir la precisión y ampliar la superficie de ataque.
Copiar los permisos como metadatos estáticos
Los roles cambian; la autorización debe validarse en origen.
Usar solo búsqueda vectorial
Los códigos, nombres y referencias exactas necesitan señales léxicas.
Fragmentar por tamaño fijo
La estructura semántica y visual del documento importa.
Confundir cita con verdad
La cita puede ser irrelevante, obsoleta o insuficiente.
Añadir GraphRAG porque está de moda
Debe resolver preguntas que el baseline no resuelve.
Convertir toda consulta en un agente
La autonomía innecesaria aumenta costo y riesgo.
Evaluar solo respuestas conocidas
Hay que probar abstención, permisos, ambigüedad y ataques.
No asignar propietarios
Sin ownership, el índice se degrada y nadie responde por la calidad.
Dónde la evidencia es floja (y por qué importa)
Un artículo que solo cita los números buenos es marketing. Estas son las grietas que encontré, y son tan importantes como los hallazgos.
Ningún benchmark público modela permisos corporativos. Natural Questions, HotpotQA, CRAG: todos son de dominio abierto. Ninguno tiene usuarios con roles distintos viendo subconjuntos distintos del corpus. La validez externa de casi toda la evidencia experimental, para el caso concreto de un asistente organizacional seguro, es baja. Es el vacío más grande del campo.
La brecha laboratorio-mercado está cuantificada. La revisión sistemática de Akbulut (Applied Sciences, 10.3390/app16010368) analiza 63 estudios primarios: el 63,6 % usa modelos GPT, el 80,5 % depende de FAISS o Elasticsearch y menos del 15 % aborda la integración en tiempo real que exige producción. La mayoría son prototipos evaluados sobre conjuntos estáticos.
Los números más impactantes son de proveedores. Anthropic, NVIDIA, Databricks, Snowflake, Glean: todos publican cifras excelentes, en hardware y condiciones elegidos por ellos. No son benchmarks neutrales. Los uso porque las técnicas son reproducibles, no porque las cifras sean independientes.
El trabajo de Authorization-First Retrieval, del que depende buena parte de la sección sobre el orden, es un preprint en TechRxiv, no un artículo revisado por pares. Su cifra de 96,8 % → 0 % es una demostración formal más una evaluación propia, no una replicación independiente. El razonamiento —que el contexto contaminado no se puede descontaminar— me parece sólido y está corroborado por el trabajo de Microsoft. La magnitud exacta, no la defendería.
A eso se suman cuatro huecos que la investigación aún no ha cubierto:
- Defensas contra envenenamiento. Los ataques están mejor demostrados que las defensas. Falta evidencia independiente y a escala.
- Coste total de propiedad. Muchos trabajos reportan precisión; pocos cuantifican indexación, reindexación, mantenimiento del grafo, deriva de embeddings, operación de permisos, revisión humana y deuda documental.
- Riesgo acumulativo multi-turno. Una conversación puede combinar información autorizada de varios turnos y producir una inferencia que ninguna respuesta individual revelaba. Está poco estudiado.
- Impacto longitudinal. Faltan estudios que observen durante meses si el asistente reduce trabajo y mejora decisiones, o si solo desplaza el esfuerzo hacia validación y corrección.
Qué información cambiaría mi conclusión: benchmarks empresariales con permisos heterogéneos y resultados reproducibles; defensas contra envenenamiento validadas a escala; estudios independientes del costo total de propiedad de GraphRAG en producción; o saltos en contexto largo que lo abaraten hasta hacer innecesario el RAG para corpus medianos.
Lo que cambia en la organización
Un asistente corporativo no es solamente una nueva interfaz. Cuando funciona, cambia quién puede encontrar una respuesta, cuánto depende la organización de expertos específicos, cómo se documentan las decisiones, qué conocimiento se vuelve visible, qué errores se propagan y quién responde por una recomendación.
Aquí es donde RAG se encuentra con la gobernanza de datos
Cuando hablamos de gobernanza de datos, casi todo el mundo piensa en tablas: un catálogo, un diccionario de campos, un dueño por cada base. Esa definición se quedó corta.
En el momento en que una norma interna, una ley, un contrato, un procedimiento o un acta de comité se convierten en contexto para un modelo, pasan a ser datos en el sentido más estricto: alimentan una respuesta que alguien va a usar para decidir. Y si son datos, necesitan exactamente lo mismo que siempre le exigimos a una tabla —dueño, definición, vigencia, linaje, control de acceso y calidad auditada— con un agravante: el error de una tabla mal gobernada aparece en un tablero, donde alguien puede detectarlo. El de un contrato mal gobernado aparece directamente en una decisión.
Esto cierra un círculo que llevo años dibujando por partes. La analítica avanzada y la inteligencia artificial no son dos disciplinas vecinas: son la misma conversación mirada desde dos lados. La analítica gobierna los datos estructurados para que las cifras sean confiables; el RAG gobierna los datos no estructurados para que las respuestas lo sean. El marco de gobierno es el mismo, y la organización que ya lo construyó para sus tablas tiene medio camino hecho —siempre que acepte extender el perímetro—.
En la práctica, eso significa nombres y apellidos detrás de cada responsabilidad:
- Knowledge owner: responde por la vigencia y la calidad del contenido.
- Product owner de datos e IA: prioriza casos de uso y resultados.
- Responsable de seguridad e IAM: define y prueba el acceso.
- Responsable de evaluación: mantiene los conjuntos dorados y los umbrales.
- Revisor de dominio: valida las respuestas de alto impacto.
- Equipo de plataforma: opera modelos, índices, observabilidad y costos.
Y significa cerrar el ciclo completo. Si el sistema termina en la respuesta, se queda corto: las preguntas no resueltas, las citas rechazadas y los patrones de uso deben retroalimentar la documentación, los procesos y la formación.
La IA suele presentarse como una tecnología que elimina trabajo. En estos sistemas, gran parte del trabajo simplemente cambia de lugar: disminuye el tiempo de búsqueda, pero aumenta la necesidad de curar conocimiento, gobernar permisos, diseñar evaluaciones y revisar excepciones. La productividad no desaparece; se redistribuye hacia tareas de mayor criterio.
Conclusión: la ventaja no está en recuperar mejor
Durante los últimos dos años, la conversación sobre IA corporativa se ha organizado alrededor de una pregunta técnica: ¿cómo hacemos que el sistema encuentre la información correcta?
Esa pregunta ya tiene una respuesta suficientemente buena. Híbrido, reranking, contexto en los fragmentos, medición continua. Funciona, es reproducible y no es glamoroso.
La que sigue abierta es otra: ¿cómo hacemos que el sistema no encuentre lo que no debe? Y esa no es una pregunta de recuperación. Es una pregunta de identidad, de procedencia y de auditoría —tres cosas que la mayoría de organizaciones no tenían resueltas antes de la IA y que ya no pueden seguir posponiendo—.
Reconocerlo cambia quién debe estar en la mesa desde el primer día: no solo el equipo de datos, también seguridad, legal y los dueños de cada fuente. La mejor arquitectura no será la que tenga más componentes, sino la que use la mínima complejidad necesaria para responder con evidencia, preservar la seguridad y mejorar una actividad real.
Puede resumirse en cinco principios:
- Gobernanza antes que ingesta.
- Identidad antes que similitud.
- Búsqueda híbrida antes que complejidad avanzada.
- Evaluación antes que escala.
- Workflow antes que herramienta.
RAG empresarial no debería convertirse en una carrera por construir el chatbot que “lo sabe todo”. Debería convertirse en una disciplina para que cada respuesta importante tenga tres propiedades.
Preguntas frecuentes
¿Qué es RAG en términos simples?
¿Por qué no basta con pedirle al modelo que no revele información confidencial?
¿Necesito un grafo de conocimiento para mi asistente empresarial?
¿Qué tan fiables son estos sistemas hoy?
¿Puede alguien manipular las respuestas de nuestro asistente?
¿Cuándo conviene no usar RAG?
¿Por dónde empiezo si quiero hacerlo bien?
Referencias y lecturas recomendadas
En este blog
- La IA no hace inteligente a tu empresa: solo amplifica lo que ya es
- AI-Native no es tener más IA: es aprender a rediseñar el trabajo
- Alfabetización en IA: no es saber prompts, es saber juzgar
- Agentes de IA: guía completa para 2025
- Analítica de Datos en 5 Niveles
- AI Studios en 2026: el taller donde se construye la IA
- La Aldea de los Datos: arquitectura de datos moderna
Fundamentos y arquitecturas
- Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS.
- Gao, Y. et al. (2023). Retrieval-Augmented Generation for Large Language Models: A Survey.
- Anthropic (2024). Contextual Retrieval.
- Edge, D. et al. (2024). From Local to Global: A Graph RAG Approach to Query-Focused Summarization. Microsoft Research.
- Xu, Z. et al. (2024). RAG with Knowledge Graphs for Customer Service Question Answering. SIGIR.
- Jiménez Gutiérrez, B. et al. (2024). HippoRAG. NeurIPS.
- Guo, Z. et al. (2025). LightRAG: Simple and Fast Retrieval-Augmented Generation. Findings of EMNLP.
- Li, Z. et al. (2024). Retrieval Augmented Generation or Long-Context LLMs? EMNLP Industry Track.
Seguridad y control de acceso
- Zou, W. et al. (2025). PoisonedRAG: Knowledge Corruption Attacks to RAG. USENIX Security.
- Bhatt, S. S. et al. (2025). Enterprise AI Must Enforce Participant-Aware Access Control. Microsoft.
- Jeong, J. y Lee, S.-G. (2025). Permission-Aware RAG. IEEE Access.
- Ammann, L. et al. (2025). Securing RAG: A Risk Assessment and Mitigation Framework. IEEE SDS.
- Namboothiri, R. et al. (2024). Authorization-First Retrieval. TechRxiv (preprint).
Documentos y evaluación
- Auer, C. et al. (2024). Docling Technical Report. IBM Research.
- Faysse, M. et al. (2025). ColPali: Efficient Document Retrieval with Vision Language Models. ICLR.
- Es, S. et al. (2024). RAGAS: Automated Evaluation of Retrieval Augmented Generation. EACL.
- Saad-Falcon, J. et al. (2024). ARES: An Automated Evaluation Framework for RAG Systems. NAACL.
- Yang, X. et al. (2024). CRAG: Comprehensive RAG Benchmark. NeurIPS.
- Akbulut, A. (2026). RAG and LLMs for Enterprise Knowledge Management: A Systematic Literature Review. Applied Sciences.
¿Hablamos de tu asistente de conocimiento?
Si estás diseñando —o rescatando— un asistente de IA sobre los datos de tu organización y quieres empezar por la capa correcta, escríbeme.
Escríbeme por WhatsApp →Nota de transparencia: Este artículo fue escrito con asistencia de inteligencia artificial generativa, a partir de una síntesis crítica de tres revisiones de literatura independientes sobre RAG empresarial (2023–2026). Las cifras provienen de las fuentes primarias enlazadas y se han marcado explícitamente los casos de sesgo de proveedor y de evidencia preliminar. La interpretación, el enfoque editorial y el punto de vista final corresponden al autor.
Enterprise RAG: it isn’t a search problem, it’s a permissions problem
A practical architecture for connecting corporate documents, data and systems to artificial intelligence without losing permissions, traceability or human judgement. Because the bottleneck in an enterprise assistant is almost never finding: it’s deciding who gets to see what.
What enterprise RAG really is
Picture a company’s library. Not a quiet library with neatly ordered books, but one built over twenty years: duplicate manuals, contracts with annexes, presentations that contain important decisions, tables that only make sense with their header, expired documents and folders each department organised its own way.
Now imagine hiring the best librarian in the world for that chaos. They have read absolutely everything: contracts, board minutes, support tickets, email, performance reviews, the payroll folder. They hear a question, find the relevant pages and explain them in natural language.
That’s the promise of RAG. And it works.
Until a junior analyst innocently asks, «what’s the average salary of the commercial directors?» — and the librarian, helpful but without judgement, tells them.
That uncomfortable moment isn’t an edge case. It’s the default failure mode of almost every architecture being deployed in companies today.
The mechanics, without jargon
A language model is like someone who studied intensively a year ago and then stopped reading. They know a lot, but they know nothing about your company and can’t quote clause 14 of a contract they never saw.
Retrieval-Augmented Generation — RAG — solves that by turning the memory exam into an open-book exam. Patrick Lewis and his co-authors (NeurIPS 2020) framed it as combining parametric memory — what the model learned — with non-parametric memory — documents retrieved from an external source.
In practice, a RAG system performs five actions:
- Ingests information from documents, databases and applications.
- Represents that content so it can be found by words, meaning, structure or relationships.
- Retrieves the most relevant evidence for a question.
- Generates an answer using that evidence as context.
- Evaluates and logs what it retrieved, what it answered, and with what confidence.
The gap between a demo and an enterprise capability shows up in every one of those verbs. Because in a company the librarian also has to know who is asking, which shelves they may consult, which version is current, which content may have been tampered with, which part of the answer is evidence and which is interpretation — and when there simply isn’t enough information to answer.
The enterprise leap happens when we stop asking «can it answer?» and start asking: «can it answer correctly, using only what that user is authorised to see, citing the current version, and leaving enough evidence to audit the result?». It looks like a technical shift. It’s really a shift in accountability.
Why naive RAG fails once it leaves the lab
Naive RAG follows a familiar recipe:
That single line carries most of the field’s jargon, so it’s worth translating in full:
- Chunks are the pieces each document is split into, because an 80-page contract won’t fit whole into an answer.
- An embedding is the translation of a piece of text into a list of numbers representing its meaning. Texts about the same thing end up close together in that numeric space even if they share no words. That’s what lets the system find «holiday» when you ask about «time off».
- The vector database is the store for those numbers, optimised to answer «what’s near this?» very fast.
- Top-k is the set of k nearest chunks retrieved — typically five or ten — and handed to the model along with the question.
The recipe is useful for learning and for building a prototype. The problem starts when it’s assumed to be a production architecture too. It fails in five places.
1. It splits documents without understanding them
A PDF isn’t a neutral sequence of words. It has headings, footnotes, tables, diagrams, columns, annexes and cross-references. Chunk by character count alone and a policy gets separated from its exception, a figure from the unit that explains it, a table from its header. The system retrieves similar text and loses the documentary meaning.
2. It confuses similarity with relevance
Embeddings find semantic proximity. That’s no guarantee the chunk is current, authorised, complete or sufficient. An answer can be built from the «most similar» paragraph and still be wrong.
3. It retrieves first and asks about permissions later
This is the most dangerous mistake, and it deserves its own section below. Once a confidential chunk enters the model’s context, trying to hide it in the final answer is already too late.
4. It doesn’t know how to say «I don’t know»
Prototypes are optimised to answer. Reliable systems must also learn to abstain. An elegant answer without sufficient evidence is still a dangerous answer.
5. It measures the model, not the system
Swapping LLMs may improve the prose. It won’t fix poor retrieval, incomplete permissions, broken documents or stale knowledge.
| Dimension | Naive RAG | Enterprise RAG |
|---|---|---|
| Content | Plain text | Documents, tables, images, data and metadata |
| Retrieval | Single-step vector | Hybrid, filtered, reranked and adaptive |
| Security | Downstream filters | Identity and permissions from the source |
| Answers | Plausible text | Cited, traceable, able to abstain |
| Evaluation | Manual testing | Golden set, continuous metrics, adversarial tests |
| Operations | Static index | Refresh, versioning, audit and monitoring |
| Complexity | Same for every query | Routed by question type |
Swipe the table →
AI doesn’t fix an organisation’s disorder: it amplifies it. If five versions of a policy exist, RAG doesn’t remove that ambiguity — it can retrieve it very fast. If each department interprets permissions differently, the assistant turns a silent inconsistency into a visible leak. That’s why the idea in AI doesn’t make your company smart — it only amplifies what it already is (in Spanish) applies literally: before building a corporate assistant, decide which knowledge deserves to become the reference.
Identity before similarity: the ordering mistake
Here is the finding that should reorder the entire conversation.
The intuitive way to handle security is this: search the whole base, bring back the ten most relevant chunks, and then — with a filter, or by asking the model itself to abstain — remove what the user shouldn’t see.
That ordering is structurally insecure. A 2024 paper on Authorization-First Retrieval (Namboothiri et al., TechRxiv) formalizes it using a classic computer-security property, non-interference: if an unauthorized chunk makes it into the context window, that information has already shaped the output. It may not be cited. The model may never mention it. But it changed the answer. And with the right question, it comes back out.
The authors report structural leaks dropping from 96.8% to 0% when permission filtering runs before vector search. With one important caveat: this is a preprint — a draft published before other researchers have reviewed it. I explain below why that qualifies the figure.
This isn’t an isolated finding. Microsoft researchers reached the same conclusion by a different route in Enterprise AI Must Enforce Participant-Aware Access Control (arXiv:2509.14608): output filters, prompt sanitization and perimeter firewalls do not stop exfiltration once sensitive tokens have been combined in the model’s internal layers. And they go further: in an assistant that summarises email, checking the permissions of the person asking isn’t enough — you have to check those of every participant in that conversation before feeding the context.
On the applied engineering side, Jeong and Lee (Permission-Aware RAG, IEEE Access, 2025) show how to validate permissions in real time by asking the system that already manages them — what IT calls IAM, identity and access management: who you are and what you’re allowed to open — rather than attempting the fantasy of copying every organizational rule into a parallel store. Their starting point: corporate sources have different authorization models and shouldn’t collapse into a repository where «every chunk looks alike».
How it’s usually framed
«We’ll handle permissions in the application layer, before showing the answer.»
How it should be framed
«Unauthorized content shouldn’t even become a semantic candidate for that user.»
In practice: every chunk in the index has to carry its permissions inherited from the source system — what IT calls an ACL, the list that says who may open a document and who may not — and the query has to be scoped by the asker’s identity before the search runs.
Exhaustive prefiltering degrades approximate nearest-neighbour performance at large scale. It’s a real latency trade-off. But it’s the kind you negotiate with architecture, not the kind you resolve with an apology after a leak.
Poisoning the library: the other attack surfaces
There’s a curious asymmetry in how these systems get built. Teams obsessively validate what the user types, out of fear of prompt injection. And then they blindly trust the text retrieved from their own database. Ammann and colleagues call this the RAG trust paradox (IEEE SDS, 2025).
1. Knowledge-base poisoning
PoisonedRAG (Zou et al., USENIX Security 2025) formulates poisoning as an optimization problem. By injecting five texts per target question into a base of 2.68 million clean documents, the authors induce their chosen answer with success rates around 90% on average, and up to 97% in the most favourable scenarios.
Five documents out of two and a half million. Think about how many of your company’s sources are editable by any employee: the internal wiki, tickets, comments on shared documents, email. Each one is attack surface.
- Verified provenance and, where possible, content signing.
- An explicit allowlist of sources; quarantine for new or editable documents.
- Deduplication and anomaly detection over the vectors.
- Strict separation between content and instructions.
- Adversarial testing of retrieval, and the ability to withdraw and reindex fast.
2. Indirect prompt injection
A document can carry instructions aimed at the model while looking like normal content to the user. The architecture must treat retrieved documents as untrusted data, never as instructions. The model shouldn’t obey orders found inside the corpus.
3. Over-trusting the citation
A citation doesn’t automatically make a claim true. The cited document may be wrong, outdated or insufficient. That’s why security and quality are connected: verifying the support for each claim matters as much as verifying the permission.
| Risk | First-order effect | Second-order effect | Priority control |
|---|---|---|---|
| Misapplied permissions | A document is exposed | Loss of trust and penalties | Prior authorization and no-leak testing |
| Poisoned document | Manipulated answer | Contaminated decisions at scale | Provenance, quarantine, adversarial detection |
| Indirect injection | Instructions overridden | Unauthorized agent actions | Instruction isolation and guardrails |
| Stale source | Incorrect answer | An expired practice becomes institutional | Validity dates, ownership, versioning |
| Weak citation | Appearance of evidence | Unjustified confidence | Claim-level support verification |
Swipe the table →
And here’s the most honest thing I can say: defenses are far less mature than attacks. Proposals exist — perplexity filtering, sentinel-strategist architectures, active auditing of poisoned claims — but none validated at enterprise scale. Today this risk is managed by limiting the surface, not by neutralizing it.
In AI literacy: it’s not knowing prompts, it’s knowing how to judge (in Spanish) I proposed distinguishing between delegating, co-creating and protecting. Enterprise RAG needs the same logic. Looking up a holiday policy isn’t the same as interpreting a contract clause, recommending a clinical decision or evaluating a person. The architecture must recognise that difference and raise human review when the consequence of an error demands it.
What actually works (and has numbers)
After so much risk, let’s be fair: there is a technical core with solid, reproducible evidence. And it’s more boring than the industry would like.
Hybrid search plus reranking
Two terms worth translating before we go on, because they appear in every technical proposal and are almost never explained.
Hybrid search means combining two ways of searching that fail at different things. Semantic search understands meaning: ask about «time off» and it finds the document that says «holiday». Lexical search is the old-fashioned kind — the BM25 algorithm behind classic search engines: it matches the exact word, and it’s the only one that will ever find the code «NCF-2214-B» or a supplier’s surname. Each leaves gaps on its own; together they cover for each other.
Reranking is a second quality filter. The first pass is fast but crude: it returns, say, fifty plausible candidates. The reranker is a slower, finer model that reads those fifty carefully and reorders them by actual relevance, so the five that finally reach the model are the best ones and not merely the most similar. It’s the difference between a search engine’s quick glance and a librarian’s close reading.
That combination is the most robust consensus in the whole literature, and it’s the baseline referred to later on: the minimum well-built version against which anything more sophisticated has to be compared.
Anthropic published reproducible numbers in Contextual Retrieval, adding a simple and powerful idea: before indexing each chunk, prepend a couple of sentences explaining where it came from and what it’s about.
Two-thirds fewer failures with no graphs, no agents and no retraining. It’s the best evidence-to-cost ratio in the field.
The result shouldn’t be read as a universal guarantee — it’s a model vendor’s report, though the technique is reproducible with the public cookbook — but it does confirm something important: the quality of the context around a chunk matters as much as the embedding.
Knowledge graphs: powerful, but not for everything
Before deciding whether you need one, it helps to know what it is. A knowledge graph is a map of relationships. Instead of storing documents as loose pieces of text, it stores what is connected to what: this incident affected this product, which depends on this component, which had already failed in this other case. Where a vector database answers «what text resembles my question?», a graph answers «what path connects these things?».
That difference matters when the answer doesn’t sit inside a document, but in the relationship between several.
The most convincing production case is LinkedIn’s (Xu et al., SIGIR ’24, arXiv:2404.17723). They built a graph over their historical support tickets — the internal structure of each ticket and the relationships between tickets — and query whole subgraphs instead of loose chunks. Retrieval accuracy nearly doubled, but the number that justified the project was a different one: median incident resolution time fell from 7 to 5 hours, 28.6% less, after roughly six months in production. That isn’t a lab metric: those are engineer hours.
Now note the two conditions that made that case work. The question was relational — «does this incident resemble a previous one, and how was it resolved?» — and the data already carried rich relationships: tickets referencing one another. Without both, a graph is cost without return.
«What’s the travel expense policy?» is answered by one document. «Why has this client escalated the same problem three times in six months?» is answered by the path between many. The first question doesn’t justify building or maintaining a graph. The second probably does. That’s the whole decision rule.
When complexity earns the right to exist
One of the most useful debates in the field is also one of the least comfortable: do we need RAG for everything? The answer is no.
Li and colleagues (EMNLP 2024, Industry Track) systematically compared RAG against long-context models: the ones that can read an enormous text — hundreds of pages — in a single pass, with no prior search. With sufficient resources, long context beats RAG on average quality; RAG wins on cost. Their proposal, Self-Route, sends each query down the more suitable path. Anthropic goes further: if your corpus fits in under ~200,000 tokens, put all of it in the prompt and forget the pipeline.
Translated into practice: if the knowledge of a specific domain — say, all HR policies — fits in about 300 pages, building chunking, embeddings, a vector database and a reranker for it is over-engineering. And every component you add is one more failure and attack surface.
This points to a router-first architecture: instead of sending every question down the same expensive path, a router decides per query which path fits. Complexity is activated on demand.
| Type of need | Recommended starting approach | Why |
|---|---|---|
| Small, stable corpus | Long context with caching | Fewer components and fewer retrieval errors |
| Factual questions over high volume | Hybrid RAG + reranking | Best balance of accuracy, cost and latency |
| Codes, names, exact references | Lexical search + filters | Exact matching beats embeddings |
| Relational or multi-hop questions | KG-RAG or GraphRAG | Preserves entities, relationships and paths |
| Global questions across the corpus | Hierarchical GraphRAG | Summarises communities and broad themes |
| Iterative research | Agentic RAG | Lets the system search, open, compare and change strategy |
| Corporate metrics and calculations | SQL or semantic layer + LLM | Avoids «computing» from text fragments |
| Visually complex documents | Multimodal retrieval | Preserves tables, layout, charts and images |
| «Where is document X?» | Enterprise search + lightweight LLM | A mature engine already enforces the permissions |
Swipe the table →
GraphRAG isn’t «better RAG» for everything
GraphRAG adds value when structure matters. Microsoft Research’s work (arXiv:2404.16130) tackles global questions that a local-chunk retriever handles poorly. But building and maintaining a graph costs: entity extraction, duplicate resolution, relationship updates, summary generation and structural quality evaluation. Indexing is expensive because each step requires a great many model calls.
And sophistication doesn’t guarantee better results: HippoRAG (arXiv:2405.14831), for all its conceptual elegance, underperforms a conventional dense retriever on HotpotQA: it finds the right document 60.5% of the time versus ColBERTv2’s 64.7%.
Agents aren’t free either
An agent can search, open documents, reformulate the query and verify findings. That broadens coverage, but it increases latency, token consumption, attack surface, the difficulty of reproducing an answer, and the need to govern tools and permissions.
The right question isn’t «can we use agents?» but: what class of query improves enough to justify the extra cost and risk?
In my articles on AI agents and on AI-Native organisations I’ve insisted on one idea: useful autonomy doesn’t appear when a tool does more things, but when a workflow exists that can govern what it does. RAG is no different. An agent that researches without limits isn’t enterprise intelligence: it’s automated uncertainty. And almost nobody budgets for maintenance, which is where most of these projects die.
Document intelligence: the problem hiding upstream of the retriever
Many organisations believe their problem is choosing embeddings. In reality, they still haven’t managed to read their own documents properly.
Financial reports, technical manuals and regulatory documents carry visual information: hierarchies, tables, diagrams, columns, merged cells, footnotes and spatial relationships. None of that survives character-count chunking.
There are two paths, and they don’t compete. Tools like Docling (IBM Research, arXiv:2408.09869) convert documents into structured representations preserving reading order and tables. In the other direction, ColPali (Faysse et al., ICLR 2025, arXiv:2407.01449) abandons text extraction entirely: it treats each page as an image and embeds it with a vision-language model. On the ViDoRe benchmark it retrieves more precisely than a classic pipeline — 81.3 versus roughly 75 on the field’s standard metric, nDCG@5 — at the cost of a considerably larger memory footprint.
- For mostly textual documents, structured conversion is usually enough.
- For collections with tables, forms and diagrams, visual retrieval adds real value.
- For critical data, keep both representations and evaluate which retrieves better.
If your knowledge lives in PDFs with financial tables, blueprints or infographics — and in most Latin American companies it lives exactly there — this is where the most information is lost.
Content must also be designed to be retrieved
A RAG system inherits the editorial quality of its knowledge base. Procedures with vague headings, undefined acronyms, undescribed tables or hidden exceptions produce worse answers. Improving the documentation can raise quality without changing the model.
That means building a ContentOps for AI discipline: an owner per document, validity dates, explicit definitions, informative headings, tables accompanied by explanation, a clear separation between rule, exception and example, change history, and a retirement policy for stale content.
In The Village of Data (in Spanish) I used the image of a library, a lake, specialised shops, neighbourhoods and a loom to explain modern data architecture. RAG adds a new character to that village: an interpreter who talks to all those places. But the interpreter can’t compensate for a library with no catalogue, a lake turned into a swamp, or a loom where nobody knows where the threads came from.
The reference architecture: six planes that must work together
An enterprise architecture shouldn’t be organised around a tool, but around responsibilities. The guiding principle: governance first, complexity on demand.
Identity and authorization — the foundation, not an add-on
Every query carries the user’s context, role, attributes and the source’s restrictions. Inherit the original system’s rules rather than approximating them in a parallel store. This layer is designed before the first document is indexed.
Knowledge and ingestion
Connect document managers, wikis, CRM and ERP, relational databases, analytical warehouses and APIs; also email, tickets and transcripts where there’s a legal basis to use them. Ingesting isn’t copying files: preserve provenance, owner, date, validity, sensitivity and permissions.
Memory and indexing
One representation is rarely enough. Lexical index for exact names and codes; vector index for meaning and paraphrase; metadata for permissions, dates and document status; a graph when entity relationships are part of the question; SQL or a semantic layer when the answer depends on calculations.
Retrieval and reranking
Hybrid search combining lexical and dense signals, reciprocal rank fusion, and a reranker that reorders candidates with finer analysis. This is the baseline everything else is measured against.
Routing and generation
Not every question deserves the same pipeline. A router chooses between enterprise search, hybrid RAG, full context, GraphRAG, a SQL query or agentic retrieval. The final answer must separate facts, inferences and absence of evidence, with citations precise enough to open the source.
Evaluation and observability
Every answer leaves a trail: identity and policy applied, original and rewritten query, candidate and used documents, versions of the index, retriever, reranker and model, citations produced, latency, cost, feedback, and alerts for access or anomalous behaviour.
The order matters. Almost every project I’ve seen starts at plane 4, because it’s the fun one.
In AI Studios in 2026 (in Spanish) I proposed thinking of platforms as workshops: choosing the best machine isn’t enough; the rules, the tools, quality control and operations all matter. RAG confirms that thesis. The LLM is one machine in the workshop. The enterprise capability lives in everything around it.
Evaluating RAG without falling for the demo
A good demo picks questions the system can answer. A good evaluation also looks for the ones that should make it fail.
Frameworks like RAGAS (EACL 2024) and ARES (NAACL 2024) allow evaluation without hand-written correct answers, separating dimensions such as context relevance, answer faithfulness and final relevance. A reasonable operational threshold: if faithfulness sits below 0.7 after optimization, the problem is in chunking or embeddings. Fix that before adding graphs or agents; adding complexity on a broken foundation only makes it more expensive to diagnose.
Now the dose of humility. The CRAG benchmark (Yang et al., NeurIPS 2024) measured the field’s real ceiling:
| System | Correct answers without hallucinating |
|---|---|
| LLM without RAG | ~34% |
| Simple RAG | ~44% |
| Leading industrial solutions | 63% |
With hallucination rates of 16% to 25% and latencies from 3.4 to 11.6 seconds. The figure shouldn’t be extrapolated to any given company, but it removes an illusion: RAG doesn’t automatically turn an LLM into a reliable source.
If your project was pitched to the committee promising an assistant that «answers accurately across all corporate documentation», that number belongs on slide two. Not to kill the project, but to design the right workflow: a system that’s right two times out of three and always cites its source is enormously useful. One that’s right two times out of three and presents itself as an oracle is a liability.
A minimum scorecard
| Dimension | Question it answers | Example metrics |
|---|---|---|
| Retrieval | Did it find the necessary evidence? | Recall@k, MRR, context recall |
| Context precision | Did it retrieve too much noise? | Precision@k, context precision |
| Grounding | Is the answer supported? | Faithfulness, per-claim entailment |
| Citation | Does the citation support that exact text? | Citation precision and coverage |
| Abstention | Can it refuse what it can’t answer? | Correct refusal rate |
| Security | Does it avoid retrieving unauthorized content? | Leakage rate, policy violations |
| Robustness | Does it resist malicious or contradictory content? | Attack success rate, conflict detection |
| Operations | Does it work within real limits? | p95 latency, cost per query, availability |
| Business | Does it improve something that matters? | Resolution time, rework, adoption |
Swipe the table →
The golden set belongs to the company
Public benchmarks help compare techniques. They don’t replace an internal test set. A golden set should include frequent, complex, ambiguous and unanswerable questions; stale documents and conflicts between sources; users with different permissions; attempts to extract sensitive information; queries in the organisation’s real languages; and cases where the correct answer is to escalate to a person.
Analytics doesn’t end at a model: it ends when a decision, an action or an outcome changes. That principle, developed in Data Analytics in 5 Levels (in Spanish), should govern RAG too. Gaining two points of recall is irrelevant if users still don’t trust the answer.
A 90-day roadmap: build evidence before infrastructure
The most common mistake is trying to connect «all corporate knowledge» from day one. It’s better to pick a domain with a frequent need, bounded knowledge, a clear owner, measurable impact, manageable risk, and users available to test.
Days 1–30: governance and baseline
Phase 1 of 3- Define a concrete business question and select the corpus with its owners.
- Map each source’s real permissions, not the ones the documentation claims. You’ll find broken permissions before the assistant does.
- Classify sensitivity and validity for each source.
- Design the golden set: 50–100 real questions with their correct answers.
- Measure the current process without AI and set abstention and escalation criteria.
- Build the ingestion threat model before connecting anything editable.
Deliverable: a product and governance specification, not a demo.
Days 31–60: a secure baseline
Phase 2 of 3- Measure the corpus in tokens. If it fits under 200,000, evaluate long context before building the pipeline.
- Implement structured parsing and create lexical and vector indexes.
- Enforce authorization at retrieval, from day one.
- Add reranking and verifiable citations.
- Log every step of the pipeline for audit.
- Run functional, permission and adversarial tests; compare against traditional search and long context.
Deliverable: a measurable baseline.
Days 61–90: pilot and scaling decision
Phase 3 of 3- Test with real users and measure quality, latency, cost and usefulness.
- Analyse errors by cause, not by symptom.
- Improve the content before adding complexity.
- Enable GraphRAG, SQL or agents only for the queries that need them, with return measured against the baseline.
- Define operations, support and ownership.
- Decide whether to scale, redesign or stop.
Deliverable: evidence for an investment decision.
Choosing the language model. It’s the decision that consumes the most committee time and determines the least about the outcome.
The best proof of concept isn’t the one that impresses most in a meeting: it’s the one that reduces uncertainty. A pilot must answer three questions — does it work? is it safe? is it worth operating? If it only answers the first, it isn’t yet a business decision.
Ten common mistakes when implementing enterprise RAG
Starting with the model
The use case, the corpus and the risk should come first.
Indexing everything
More documents can lower precision and widen the attack surface.
Copying permissions as static metadata
Roles change; authorization must be validated at source.
Using vector search only
Codes, names and exact references need lexical signals.
Chunking by fixed size
The document’s semantic and visual structure matters.
Confusing citation with truth
A citation can be irrelevant, stale or insufficient.
Adding GraphRAG because it’s fashionable
It must solve questions the baseline can’t.
Turning every query into an agent
Unnecessary autonomy raises cost and risk.
Evaluating only known answers
Test abstention, permissions, ambiguity and attacks.
Assigning no owners
Without ownership the index degrades and nobody answers for quality.
Where the evidence is thin (and why it matters)
An article that only cites the good numbers is marketing. These are the cracks I found, and they matter as much as the findings.
No public benchmark models corporate permissions. Natural Questions, HotpotQA, CRAG: all open-domain. None has users with different roles seeing different subsets of the corpus. The external validity of nearly all the experimental evidence, for the specific case of a secure organizational assistant, is low. It’s the field’s biggest gap.
The lab-to-market gap is quantified. Akbulut’s systematic review (Applied Sciences, 10.3390/app16010368) analyses 63 primary studies: 63.6% use GPT models, 80.5% depend on FAISS or Elasticsearch, and fewer than 15% address the real-time integration production requires. Most are prototypes evaluated on static hold-out sets.
The most impressive numbers come from vendors. Anthropic, NVIDIA, Databricks, Snowflake, Glean: all publish excellent figures, on hardware and under conditions they chose. These aren’t neutral benchmarks. I use them because the techniques are reproducible, not because the figures are independent.
The Authorization-First Retrieval work that much of the ordering section depends on is a TechRxiv preprint, not a peer-reviewed paper. Its 96.8% → 0% figure is a formal proof plus the authors’ own evaluation, not an independent replication. The reasoning — that contaminated context cannot be decontaminated — strikes me as sound and is corroborated by the Microsoft work. The exact magnitude, I wouldn’t defend.
To that, add four gaps research hasn’t closed:
- Poisoning defenses. Attacks are better demonstrated than defenses. Independent, at-scale evidence is missing.
- Total cost of ownership. Many papers report accuracy; few quantify indexing, reindexing, graph maintenance, embedding drift, permission operations, human review and documentation debt.
- Cumulative multi-turn risk. A conversation can combine authorized information across turns and produce an inference no single answer revealed. Barely studied.
- Longitudinal impact. We lack studies observing over months whether the assistant reduces work and improves decisions, or merely shifts effort toward validation and correction.
What information would change my conclusion: enterprise benchmarks with heterogeneous permissions and reproducible results; poisoning defenses validated at scale; independent studies of GraphRAG’s total cost of ownership in production; or long-context advances that make RAG unnecessary for mid-sized corpora.
What changes in the organisation
A corporate assistant isn’t just a new interface. When it works, it changes who can find an answer, how much the organisation depends on specific experts, how decisions get documented, which knowledge becomes visible, which errors propagate, and who answers for a recommendation.
This is where RAG meets data governance
When we talk about data governance, almost everyone pictures tables: a catalogue, a field dictionary, an owner per database. That definition has fallen short.
The moment an internal policy, a law, a contract, a procedure or a committee’s minutes become context for a model, they become data in the strictest sense: they feed an answer someone will use to decide. And if they are data, they need exactly what we’ve always demanded of a table — an owner, a definition, a validity date, lineage, access control and audited quality — with one aggravating factor: a badly governed table shows up on a dashboard, where someone can catch it. A badly governed contract shows up directly in a decision.
This closes a circle I’ve been drawing in pieces for years. Advanced analytics and artificial intelligence aren’t neighbouring disciplines: they’re the same conversation seen from two sides. Analytics governs structured data so the figures can be trusted; RAG governs unstructured data so the answers can be. The governance framework is the same, and an organisation that already built one for its tables is halfway there — provided it accepts extending the perimeter.
In practice, that means names attached to each responsibility:
- Knowledge owner: accountable for content validity and quality.
- Data and AI product owner: prioritises use cases and outcomes.
- Security and IAM owner: defines and tests access.
- Evaluation owner: maintains golden sets and thresholds.
- Domain reviewer: validates high-impact answers.
- Platform team: operates models, indexes, observability and costs.
And it means closing the full loop. If the system stops at the answer, it falls short: unresolved questions, rejected citations and usage patterns should feed back into documentation, processes and training.
AI is usually presented as a technology that removes work. In these systems, much of the work simply moves: search time drops, but the need to curate knowledge, govern permissions, design evaluations and review exceptions rises. Productivity doesn’t disappear; it redistributes toward tasks requiring more judgement.
Conclusion: the advantage isn’t in retrieving better
For the past two years, the corporate AI conversation has organised itself around a technical question: how do we make the system find the right information?
That question already has a good enough answer. Hybrid, reranking, context in the chunks, continuous measurement. It works, it’s reproducible, and it isn’t glamorous.
The one still open is different: how do we make sure the system doesn’t find what it shouldn’t? And that isn’t a retrieval question. It’s a question of identity, provenance and audit — three things most organisations hadn’t resolved before AI and can no longer keep postponing.
Recognising that changes who needs to be at the table from day one: not just the data team, but security, legal and the owners of each source. The best architecture won’t be the one with the most components, but the one that uses the minimum complexity needed to answer with evidence, preserve security and improve something real.
It comes down to five principles:
- Governance before ingestion.
- Identity before similarity.
- Hybrid search before advanced complexity.
- Evaluation before scale.
- Workflow before tooling.
Enterprise RAG shouldn’t become a race to build the chatbot that «knows everything». It should become a discipline that gives every important answer three properties.
Frequently asked questions
What is RAG in simple terms?
Why isn’t it enough to tell the model not to reveal confidential information?
Do I need a knowledge graph for my enterprise assistant?
How reliable are these systems today?
Can someone manipulate our assistant’s answers?
When is it better not to use RAG?
Where do I start if I want to do this properly?
References and further reading
On my blog (in Spanish)
- La IA no hace inteligente a tu empresa: solo amplifica lo que ya es
- AI-Native no es tener más IA: es aprender a rediseñar el trabajo
- Alfabetización en IA: no es saber prompts, es saber juzgar
- Agentes de IA: guía completa para 2025
- Analítica de Datos en 5 Niveles
- AI Studios en 2026: el taller donde se construye la IA
- La Aldea de los Datos: arquitectura de datos moderna
Foundations and architectures
- Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS.
- Gao, Y. et al. (2023). Retrieval-Augmented Generation for Large Language Models: A Survey.
- Anthropic (2024). Contextual Retrieval.
- Edge, D. et al. (2024). From Local to Global: A Graph RAG Approach to Query-Focused Summarization. Microsoft Research.
- Xu, Z. et al. (2024). RAG with Knowledge Graphs for Customer Service Question Answering. SIGIR.
- Jiménez Gutiérrez, B. et al. (2024). HippoRAG. NeurIPS.
- Guo, Z. et al. (2025). LightRAG: Simple and Fast Retrieval-Augmented Generation. Findings of EMNLP.
- Li, Z. et al. (2024). Retrieval Augmented Generation or Long-Context LLMs? EMNLP Industry Track.
Security and access control
- Zou, W. et al. (2025). PoisonedRAG: Knowledge Corruption Attacks to RAG. USENIX Security.
- Bhatt, S. S. et al. (2025). Enterprise AI Must Enforce Participant-Aware Access Control. Microsoft.
- Jeong, J. and Lee, S.-G. (2025). Permission-Aware RAG. IEEE Access.
- Ammann, L. et al. (2025). Securing RAG: A Risk Assessment and Mitigation Framework. IEEE SDS.
- Namboothiri, R. et al. (2024). Authorization-First Retrieval. TechRxiv (preprint).
Documents and evaluation
- Auer, C. et al. (2024). Docling Technical Report. IBM Research.
- Faysse, M. et al. (2025). ColPali: Efficient Document Retrieval with Vision Language Models. ICLR.
- Es, S. et al. (2024). RAGAS: Automated Evaluation of Retrieval Augmented Generation. EACL.
- Saad-Falcon, J. et al. (2024). ARES: An Automated Evaluation Framework for RAG Systems. NAACL.
- Yang, X. et al. (2024). CRAG: Comprehensive RAG Benchmark. NeurIPS.
- Akbulut, A. (2026). RAG and LLMs for Enterprise Knowledge Management: A Systematic Literature Review. Applied Sciences.
Shall we talk about your knowledge assistant?
If you’re designing — or rescuing — an AI assistant over your organisation’s data and want to start at the right layer, get in touch.
Message me on WhatsApp →Transparency note: This article was written with the assistance of generative AI, based on a critical synthesis of three independent literature reviews on enterprise RAG (2023–2026). Figures come from the primary sources linked throughout, and cases of vendor bias or preliminary evidence are flagged explicitly. The interpretation, editorial focus and final point of view are the author’s. This English version is a localization of the Spanish original.
Deja una respuesta