Qué es RAG y cómo se usa en una empresa

El modelo no conoce tu empresa, y ese es el problema que casi nadie dimensiona a tiempo

El primer choque de una empresa con la IA casi siempre es el mismo. Alguien de dirección prueba el modelo con una pregunta interna: qué descuento aplica a un cliente antiguo, qué dice la política de devoluciones del canal mayorista, qué se hace cuando un proveedor incumple un plazo. El modelo responde rápido y con total seguridad. Y la respuesta está inventada, porque ese documento nunca formó parte de lo que aprendió.

A partir de ahí pasan dos cosas y ninguna es buena. La empresa concluye que “la IA no sirve para nuestro negocio”, o el equipo la usa igual pegando políticas internas en el chat para darle contexto, con información sensible saliendo por cuentas personales sin control. El problema de fondo es la distancia entre lo que el modelo sabe, que es todo lo público, y lo que tu operación necesita que sepa, que solo existe en tu Drive, tu ERP y la cabeza de tres personas.

Qué es RAG en criterio de negocio, no de ingeniería

RAG significa “generación aumentada por recuperación”, y el nombre técnico oculta una idea simple. Antes de responder, el sistema busca en las fuentes de la empresa los fragmentos que tienen que ver con la pregunta, se los pasa al modelo junto con la consulta, y recién ahí el modelo redacta. El modelo no memoriza nada tuyo: consulta cada vez, como un analista que antes de contestar va al archivo y saca los tres documentos que aplican.

Eso tiene tres consecuencias que sí importan al negocio. Cuando cambias un documento fuente, la respuesta cambia en la siguiente consulta. Se puede mostrar de dónde salió cada dato, lo que vuelve la respuesta auditable y no una opinión de la máquina. Y el conocimiento sigue viviendo en tus documentos, bajo tus permisos, en lugar de quedar disuelto dentro de un modelo que ya no puedes inspeccionar. La discusión de si conviene esto o reentrenar el modelo tiene su propia entrada acá: el resumen es que RAG resuelve que el modelo no conoce un dato, no que se comporte distinto.

Cómo se usa de verdad en la operación de una empresa

RAG no es un producto que se enciende, es una capa que se conecta a un proceso concreto. La pregunta correcta no es “¿montamos un RAG?”, es “¿qué pregunta interna se hace todos los días, la responde una persona buscando en documentos, y cuánto tiempo se va en eso?”. Si nadie puede nombrarlo con esa precisión, todavía no hay proyecto, hay entusiasmo.

Los usos que más veo funcionando en empresas reales

• Soporte interno de primera línea: el equipo consulta procedimientos, políticas de RR.HH. o condiciones comerciales en vez de interrumpir a quien “sabe cómo se hace”. El valor no es el chat, es dejar de depender de conocimiento atrapado en dos o tres personas.
• Atención al cliente asistida: el agente humano recibe la respuesta sugerida con la cita al manual que la respalda y decide si la usa. Esa trazabilidad es lo que hace que legal apruebe el proyecto.
• Documentación técnica extensa: manuales, fichas de producto, normativas. La respuesta existe, pero está en la página 340 de un PDF que nadie va a leer completo.
• Contratos e histórico de casos: encontrar rápido qué dice cada acuerdo sobre plazos o penalidades, y convertir años de tickets cerrados en una fuente consultable para que el equipo nuevo no resuelva desde cero lo ya resuelto.

El patrón es el mismo en todos: procesos donde ya hay una persona buscando en documentos todos los días y donde el tiempo perdido es medible. Un RAG montado “para tener IA en la empresa” termina siendo una demo que nadie usa en el segundo mes.

Lo que la empresa necesita tener antes de intentarlo

Esta es la parte que las propuestas comerciales suelen saltarse, porque no vende. RAG no crea conocimiento: recupera el que ya existe. Si lo que existe está desordenado, duplicado o encerrado en sistemas a los que nadie accede de forma automática, el sistema va a recuperar exactamente eso. Lista mínima que reviso con un cliente antes de firmar:

• Una fuente de verdad por tema: para cada pregunta que responderá el sistema, alguien debe poder decir cuál es el documento válido. Si hay tres versiones de la política de descuentos circulando, ese es el problema a resolver primero y no lo resuelve la IA.
• Documentos accesibles de forma programática: PDFs escaneados como imagen o conocimiento que solo vive en correos exigen una conversión previa que hay que presupuestar aparte.
• Un dueño del contenido con nombre y apellido: alguien responsable de mantener la fuente vigente. Sin esa figura, el sistema empieza bien y se degrada solo.
• Reglas de permisos claras: un RAG que ignora los permisos del sistema original vuelve accesible cualquier documento restringido para quien pregunte bien.
• Un caso de uso acotado y medible: un área, un tipo de pregunta, un conjunto de documentos. No “toda la empresa”: el alcance amplio es la forma más eficiente de gastar presupuesto sin demostrar nada.
• Un criterio de calidad acordado antes de empezar: qué considera el negocio una respuesta correcta y quién lo valida.

Ninguno de estos puntos es tecnología, todos son decisiones de orden interno. Por eso el trabajo de datos va antes que el de IA: el sistema no puede recuperar lo que la empresa no tiene ordenado.

Qué NO resuelve RAG, y por qué conviene saberlo antes de firmar

El entusiasmo con RAG viene de que resuelve un problema muy visible. El riesgo es asumir que resuelve todos los que están alrededor. Esto es lo que se le atribuye y no hace:

• No arregla documentación mala. Si el manual está incompleto o se contradice, el sistema responderá con esa contradicción, ahora citando la fuente. La calidad de la respuesta tiene un techo: la del documento.
• No decide por el negocio. Recupera y redacta. No evalúa la excepción de un cliente importante ni asume responsabilidad. Cuando hay juicio de por medio, sigue haciendo falta una persona.
• No reemplaza la integración con sistemas transaccionales. Saber qué dice la política de stock no es consultar el stock real. Para dato vivo del ERP hay que conectar el sistema, no indexar un documento que lo describe.
• No elimina las alucinaciones. Las reduce y las hace verificables, que es distinto. Si recupera el fragmento equivocado, el modelo responderá con seguridad sobre una base errónea.
• No resuelve la adopción. Que funcione no significa que el equipo lo use. Si la gente sigue preguntándole a la persona de siempre por WhatsApp, el proyecto no entrega valor aunque esté técnicamente impecable.

Decir esto en la propuesta cuesta reuniones, pero evita el momento incómodo del mes cuatro, cuando el cliente reclama algo que nunca estuvo en el alcance y que nadie se atrevió a aclarar al inicio.

Por qué la mayoría de proyectos de RAG falla por documentación y no por el modelo

Cuando un RAG no funciona, la primera reacción del equipo técnico es cambiar de modelo, ajustar cómo se parten los documentos o subir el presupuesto de infraestructura. En mi experiencia esas son las causas menos frecuentes. La dominante es más aburrida: la empresa no tenía la documentación en condiciones y nadie lo dijo en voz alta antes de arrancar.

Los síntomas se repiten con una regularidad que ya no es casualidad. Tres versiones de la misma política conviviendo, y el sistema recupera la más antigua porque estaba mejor redactada. Manuales que describen procesos que la operación cambió hace dos años. Conocimiento crítico que jamás se escribió. Archivos llamados “final_v3_revisado_ok” de los que nadie sabe cuál rige. El resultado es predecible: el sistema responde con confianza sobre la versión equivocada, se corre la voz de que “la IA se equivoca” y en tres semanas el uso cae a cero. Lo que falló no fue la tecnología: se automatizó el acceso a un archivo desordenado, y la IA lo hizo consultable, instantáneo y con apariencia de autoridad.

Cuándo tiene sentido montar un RAG y cuándo conviene esperar

No es una decisión de tamaño de empresa ni de presupuesto. Es una decisión sobre el estado real de tu conocimiento y sobre si existe un proceso concreto que hoy consume tiempo buscando información.

Señales de que tiene sentido ahora

• Hay volumen alto de preguntas repetidas cuya respuesta está en documentos que la empresa mantiene vigentes.
• La información cambia seguido (precios, condiciones, normativas) y cualquier alternativa que exija reentrenar sería insostenible.
• El negocio necesita mostrar de dónde salió cada respuesta, por auditoría, compliance o riesgo legal.
• Existe alguien identificable que ya es dueño de esos documentos como parte de su trabajo.
• El equipo puede nombrar el proceso, el área y las personas que lo van a usar el primer día.

Señales de que conviene ordenar antes

• Nadie sabe cuál es la versión válida de los documentos clave, y responder eso requiere una reunión con tres áreas.
• El conocimiento crítico no está escrito: vive en conversaciones y en la memoria de personas específicas.
• El objetivo declarado es “que la IA sepa todo sobre la empresa”, sin un proceso ni un área definida.
• Los documentos existen pero en formatos que no se pueden leer de forma automática, y ese costo no está presupuestado.
• El caso de uso real necesita dato transaccional en tiempo real, no contenido documental, y RAG se elige por inercia.

Cómo medir si el RAG funcionó de verdad

El indicador que casi todos presentan en la reunión de cierre es la cantidad de consultas hechas al sistema. Ese número no dice nada: sube solo con la curiosidad de las primeras semanas y baja igual de rápido. Lo que sí muestra si el sistema aporta es esto:

• Tasa de respuestas correctas sobre una muestra revisada por el negocio, no por el equipo técnico, midiendo cada mes el mismo set de preguntas reales definido al inicio.
• Porcentaje de respuestas que citan una fuente que existe y está vigente. Una cita a un documento derogado cuenta como error, no como acierto.
• Tiempo promedio para resolver la consulta que antes se respondía a mano, medido antes y después sobre el mismo tipo de caso.
• Caída de interrupciones a la persona experta: si la gente sigue yendo a preguntarle a quien “sabe cómo se hace”, el sistema no se está usando.
• Uso sostenido pasado el tercer mes, cuando ya no hay novedad ni presión de dirección. Es el único dato de adopción que significa algo.

Hay un efecto secundario que vale registrar aunque no entre en el tablero: un proyecto de RAG bien hecho obliga a la empresa a ordenar su documentación, y ese orden queda incluso si el sistema se apaga. En varios casos el mayor retorno no fue el asistente. Fue descubrir cuántos procesos críticos dependían de documentos que nadie mantenía.