Un chatbot no falla porque la IA sea mala. Falla porque alguien tomó decisiones técnicas equivocadas antes de desplegarlo. Aquí están los errores concretos, sin excusas.
El chatbot no es el problema. El arquitecto sí.
Cuando un chatbot falla en producción —responde tonterías, se inventa datos, da respuestas genéricas que no sirven para nada— la reacción habitual es culpar a la IA. "Es que los LLMs alucinan." "Es que la tecnología todavía no está madura." Eso es cómodo y es falso.
La tecnología base funciona. Lo que no funciona es la arquitectura que alguien diseñó —o no diseñó— encima de ella. Este post disecciona los errores técnicos concretos que hacen que un chatbot se rompa en producción. No para señalar a nadie, sino para que sepas qué preguntar antes de que ocurra.
Error 1: desplegar un LLM sin RAG y llamarlo "chatbot de empresa"
Un LLM sin RAG es un modelo que responde con lo que aprendió durante su entrenamiento. Punto. No sabe nada de tu empresa, tus productos, tus precios ni tus procesos. Si le preguntas algo específico de tu negocio, improvisa. Y cuando improvisa con confianza, el resultado es peor que no tener chatbot.
RAG (Retrieval-Augmented Generation) es el mecanismo que conecta el modelo con una base de conocimiento real y actualizada. El modelo no "recuerda" tu documentación —la consulta en el momento de responder. Sin ese paso, estás desplegando un generador de texto plausible, no un asistente informado.
Es habitual ver integraciones que consisten en pegar el prompt de sistema con cuatro párrafos del "sobre nosotros" de la web. Eso no es RAG. Eso es un LLM con contexto mínimo que se rompe en cuanto la pregunta sale de ese párrafo.
Error 2: datos mal estructurados que envenenan las respuestas
Supongamos que sí hay RAG. El siguiente punto de fallo son los datos que alimentan ese sistema. Un pipeline de RAG es tan bueno como los documentos que indexa. Y en la mayoría de implementaciones que he visto, los documentos están en un estado que hace imposible recuperar información útil.
Problemas concretos que aparecen con frecuencia:
- PDFs escaneados sin OCR correcto: el sistema indexa ruido, no texto.
- Documentos sin estructura semántica: bloques de texto plano donde la información relevante está enterrada sin jerarquía ni etiquetas.
- Versiones mezcladas: documentación antigua y nueva conviviendo sin control de versiones, el modelo recupera la respuesta obsoleta.
- Chunking mal calibrado: si los fragmentos son demasiado grandes, el modelo recibe ruido; si son demasiado pequeños, pierde contexto. El tamaño del chunk no es un parámetro decorativo.
- Embeddings genéricos sobre dominio técnico específico: un modelo de embeddings entrenado en texto general puede no capturar bien la semántica de un catálogo técnico o un manual legal.
La preparación de datos es la parte más lenta y menos glamurosa de un proyecto de chatbot. También es la que más impacta en la calidad final. Si alguien te ofrece un chatbot en 48 horas sobre tu documentación existente, pregunta qué hicieron con esa documentación antes de indexarla.
Error 3: expectativas desalineadas desde el diseño
Este es el error más silencioso porque no produce un crash visible. Produce un sistema que funciona "más o menos" y que nadie sabe si está fallando o no.
Ocurre cuando el caso de uso no se definió con precisión antes de construir. Preguntas que deberían responderse en la fase de diseño y que suelen saltarse:
- ¿Qué tipo de preguntas va a recibir este chatbot? ¿Preguntas de catálogo, soporte técnico, onboarding de clientes, consultas legales?
- ¿Qué debe hacer cuando no sabe la respuesta? ¿Decirlo, escalar, derivar?
- ¿Quién valida que la respuesta es correcta? ¿Existe un proceso de revisión?
- ¿Cómo se mide si el chatbot está funcionando o fallando en silencio?
Sin respuestas claras a estas preguntas, el sistema se despliega con un scope implícito que nadie acordó. El chatbot responde lo que puede, el usuario espera lo que imaginó, y la diferencia entre ambos es el fracaso del proyecto.
"Actúa como auditor técnico. Voy a darte tres preguntas reales que han hecho usuarios a nuestro chatbot y sus respuestas. Para cada par pregunta-respuesta, evalúa: (1) si la respuesta usa información específica de la empresa o responde con conocimiento genérico, (2) si hay señales de alucinación o datos inventados, (3) si el chatbot indica correctamente cuándo no sabe algo. Sé directo y señala los problemas concretos."
Error 4: ausencia de mecanismo de fallback
Un chatbot bien construido sabe lo que no sabe. Uno mal construido responde siempre, aunque no tenga información suficiente. La diferencia está en si existe un mecanismo de fallback explícito: una instrucción clara de qué hacer cuando la confianza en la recuperación de información es baja.
Sin fallback, el modelo rellena el vacío con texto plausible. Eso en un contexto de soporte técnico o información de producto es directamente peligroso. Un cliente que recibe una respuesta inventada con tono seguro toma decisiones basadas en datos falsos.
El fallback no es un detalle de UX. Es una decisión de arquitectura que debe estar en el diseño inicial, no como parche posterior.
Error 5: cero observabilidad post-despliegue
Desplegar un chatbot sin sistema de logging es como poner un empleado a atender clientes y no volver a hablar con él nunca. No sabes qué preguntas recibe, qué responde, dónde falla ni qué patrones emergen.
La observabilidad mínima viable incluye: registro de conversaciones, identificación de preguntas sin respuesta satisfactoria, y algún mecanismo —aunque sea manual al inicio— para revisar una muestra de interacciones con regularidad.
Sin eso, el chatbot puede estar fallando sistemáticamente en una categoría de preguntas durante semanas y nadie lo detecta hasta que un cliente se queja.
Lo que diferencia un chatbot que aguanta de uno que se rompe
No es el modelo de lenguaje. Claude, GPT-4, DeepSeek —cualquiera de ellos puede producir un chatbot que falla si la arquitectura debajo es mala. Y cualquiera puede producir un sistema robusto si la base está bien construida.
La diferencia está en si quien lo construyó tomó decisiones explícitas sobre cada uno de estos puntos: RAG real con datos preparados, caso de uso definido con precisión, fallback documentado, y observabilidad desde el primer día.
Cuando evalúes un proveedor de chatbot, no preguntes qué modelo usa. Pregunta cómo trata los datos antes de indexarlos, qué pasa cuando el sistema no encuentra respuesta, y cómo vas a saber si está funcionando dentro de tres meses. Las respuestas a esas tres preguntas te dicen más que cualquier demo.