El problema no es ChatGPT. El problema es lo que le das de comer.
Gartner proyecta que el 30% de los proyectos de IA generativa en empresas serán abandonados antes de 2026, citando como causa principal la decepción con los resultados. La mayoría de esas decepciones no provienen de un modelo defectuoso: provienen de una arquitectura de contexto que nunca fue diseñada para responder preguntas reales de negocio.
¿Por qué los chatbots corporativos dan respuestas incorrectas?
Porque están conectados a los documentos equivocados, de la manera equivocada. Un chatbot que accede a un PDF de políticas internas desactualizado de 2021 va a responder con las políticas de 2021, con total confianza y sin ninguna advertencia. El modelo no miente; simplemente no sabe lo que no le mostraron.
Esto se llama el problema de contexto en RAG (Retrieval-Augmented Generation), y es el origen del 80% de las fallas en chatbots corporativos que llegan a producción. No es un bug del modelo; es un defecto de diseño del sistema que lo alimenta.
¿Qué es RAG y por qué importa más que el modelo que elijas?
RAG es la arquitectura que permite a un modelo de lenguaje responder usando tus documentos, en lugar de su conocimiento genérico. Sin RAG, el chatbot responde desde su entrenamiento base y alucina detalles específicos de tu negocio. Con RAG mal implementado, responde con documentos equivocados con total seguridad.
La elección entre GPT-4o o Claude 3.5 afecta la calidad de la redacción de la respuesta. La calidad del RAG determina si la respuesta es verdadera o no. Una empresa que gasta $50.000 dólares en una licencia de modelo premium pero conecta ese modelo a una base de documentos sin estructura, sin control de versiones y sin política de actualización, obtiene un sistema que confabula con elegancia.
El modelo es el motor. RAG es el combustible. Un Ferrari con combustible sucio no llega a ningún lado.
¿Puede un mal RAG destruir la confianza en IA dentro de una organización?
Sí. Y lo hace más rápido de lo que se construyó.
Una empresa de servicios profesionales implementó un asistente interno para que sus consultores respondieran preguntas sobre procedimientos de licitación y contratos con clientes. El modelo elegido era robusto. La implementación tomó cuatro meses. El equipo de TI estaba orgulloso del resultado.
Al tercer día de operación, el asistente entregó a tres consultores distintos las condiciones comerciales de un contrato antiguo que ya había sido renegociado. Los tres consultores usaron esas condiciones en propuestas enviadas a clientes.
El problema no fue técnico. Fue documental: la base RAG incluía versiones antiguas de contratos sin etiqueta de vigencia. El sistema no tenía forma de saber que esos documentos estaban obsoletos porque nadie le había dicho que lo estuvieran.
El costo no fue el reproceso de las propuestas. El costo fue que el director general prohibió el uso del asistente para cualquier propósito crítico. Un sistema que tardó cuatro meses en construirse perdió toda la confianza interna en 72 horas.
Ese es el verdadero riesgo de un RAG mal diseñado: no es técnico, es político. Mata los proyectos de IA antes de que demuestren su valor.
¿Cómo se diseña un RAG que funcione en producción?
No empieza por conectar documentos. Empieza por decidir qué preguntas debe responder el sistema y con qué nivel de certeza.
Un RAG confiable tiene tres capas que la mayoría de las implementaciones ignora:
1. Gobierno documental. Cada fuente tiene una fecha de vigencia, un propietario y un proceso de actualización. Si un documento vence, sale de la base automáticamente. Sin esto, el sistema responde con información caducada sin saberlo.
2. Recuperación con filtros de negocio. El sistema no busca el documento más parecido semánticamente; busca el documento correcto para el contexto del usuario. Un contrato del cliente A no debe aparecer como contexto para una pregunta sobre el cliente B, aunque sean semánticamente similares.
3. Umbral de confianza explícito. Cuando el sistema no encuentra contexto suficiente para responder con certeza, dice "no tengo información confiable sobre esto" en lugar de inventar una respuesta plausible. Este mecanismo se llama fallback controlado y es lo primero que se elimina en implementaciones rápidas para que el demo "se vea bien".
La IA no es el riesgo. El diseño del sistema sí lo es
Un modelo de lenguaje no puede ser más confiable que los datos que le das. Implementar IA sin gobernar el contexto es como contratar al mejor abogado del mundo y darle sólo los expedientes equivocados. El resultado no depende del abogado.
La pregunta que debes hacerte antes de implementar cualquier chatbot corporativo no es "¿qué modelo uso?" sino "¿quién es responsable de que los documentos que consulta ese modelo sean correctos, vigentes y suficientes?"
👉 Agenda una sesión de diagnóstico estratégico de 20 minutos con ETIIA y auditemos la arquitectura de contexto de tu próxima implementación de IA antes de que llegue a producción con los documentos equivocados.
Fuentes:
- Gartner. Predicts 2024: Generative AI Projects Face Reality Check. 2024.
- IBM Institute for Business Value. CEO's Guide to Generative AI: Retrieval-Augmented Generation. IBM IBV, 2024.