Chatbots para empresas: por qué fallan y cómo evitarlo

El diagnóstico equivocado: no es la IA, es la arquitectura

Cuando un chatbot de empresa responde mal, lo primero que se culpa es al modelo. Casi nunca es el modelo. Los modelos de lenguaje actuales redactan bien, entienden preguntas mal escritas y resumen con soltura. Lo que falla es lo que hay alrededor: qué información le das, cómo se la das, qué hace cuando no la tiene y quién se entera cuando se equivoca.

He montado chatbots con RAG sobre documentación real: el asistente de esta web y, antes, un chatbot legal que ya no está en servicio. Los fallos que hunden un chatbot de empresa son bastante previsibles. Estos son siete frecuentes, y qué se hace con cada uno.

Error 1: montar el chatbot sobre documentación sin preparar

Se vuelcan PDFs escaneados, FAQs antiguas, un Excel con celdas combinadas y tres versiones de la misma política de devoluciones, y se espera que el sistema saque respuestas limpias. No las saca. Si dos documentos dicen cosas distintas, el chatbot usará una u otra según cómo esté formulada la pregunta.

La preparación del material es la parte menos vistosa del proyecto y la que más decide el resultado. Qué entra, en qué versión, troceado cómo y sin contradicciones. Lo desarrollo en antes de montar un chatbot RAG: preparar la documentación.

Error 2: un modelo sin RAG, o con un RAG de mentira

Un modelo general no sabe nada de tu empresa: ni tus precios, ni tus plazos, ni tus condiciones. Si le preguntan, rellena el hueco con lo que parece plausible. Eso es una alucinación, y es el comportamiento normal de un modelo al que no se le ha dado la información.

RAG (generación aumentada por recuperación) resuelve eso: antes de responder, el sistema busca en tus documentos los fragmentos relevantes y el modelo contesta a partir de ellos. El problema es que muchas soluciones llaman RAG a una búsqueda por palabras clave sobre un PDF mal estructurado. El nombre está; la recuperación no. Lo explico con detalle en RAG explicado: por qué tu chatbot alucina y cómo corregirlo.

Error 3: la recuperación mal calibrada

Aun con RAG de verdad, la recuperación puede fallar en silencio, y es el fallo más difícil de ver porque la respuesta sale igual de segura:

• Fragmentos mal cortados. Demasiado grandes y cada uno trae ruido; demasiado pequeños y la respuesta queda incompleta, así que el modelo rellena.
• Documentos que compiten. Si dos fragmentos parecidos responden a la misma pregunta, se desplazan entre sí y a veces gana el menos útil. En el asistente de esta web, la base está troceada por pregunta real: cada fragmento contesta una pregunta de principio a fin.
• Umbral de relevancia mal puesto. Si el sistema acepta fragmentos poco parecidos a la pregunta, contesta con información que no viene a cuento. Si es demasiado estricto, no encuentra nada y deriva todo.

Error 4: un chatbot sin memoria

El usuario pregunta por el plan mensual, luego escribe "¿y ese se puede cancelar?", y el chatbot no sabe a qué se refiere "ese". Tratar cada mensaje como si fuera el primero produce conversaciones rotas en las que el cliente tiene que repetir el contexto una y otra vez. La memoria de la conversación no es un extra: es lo mínimo para que una pregunta de seguimiento funcione.

Error 5: sin límites sobre lo que puede afirmar

Un modelo sin restricciones intentará responder a todo, tenga o no información. Los límites (qué responde, qué declina, cuándo pide aclaración, cuándo deriva) no son censura. Son el criterio de calidad del sistema.

Las cifras son donde más duele. Un precio inventado no es una imprecisión: es un compromiso que no has hecho. En el asistente de esta web, la última barrera antes de enviar una respuesta es una comprobación determinista: cada precio, porcentaje o cantidad de la respuesta tiene que estar en los fragmentos recuperados para esa pregunta, o ser un redondeo de una cifra que esté. Si sobra una, esa respuesta no se envía: el usuario recibe un mensaje que le pide confirmar el dato con una persona, y el rechazo queda registrado con la cifra que sobraba. Al principio esa comprobación la hacía otro modelo de lenguaje, que tumbaba respuestas correctas. Por qué lo cambié y qué me obligó a rediseñar lo cuento en la reja que no deja pasar cifras inventadas.

Error 6: sin paso a una persona

Hay preguntas que ningún chatbot debe resolver solo: casos fuera de su dominio, clientes enfadados, situaciones con consecuencias legales o médicas. Un chatbot sin salida hacia una persona convierte cada caso difícil en una mala experiencia. El paso a humano no es un fallo del chatbot; es una funcionalidad que se diseña: qué lo dispara, a qué canal va y quién recibe el aviso.

Error 7: desplegar y olvidarse, con métricas que mienten

Un chatbot en producción no está terminado. Los documentos se quedan viejos, aparecen preguntas que nadie previó y el proveedor del modelo lo actualiza. Si nadie mira los registros de conversación, el sistema puede pasarse semanas contestando mal a una categoría entera de preguntas sin que nadie se entere.

Y las métricas habituales no avisan:

• Tasa de resolución inflada. Se cuenta como resuelta la conversación que no acaba en ticket. Si el cliente se rinde y llama por teléfono, sigue contando como éxito.
• Satisfacción sin contexto. Una buena nota media no dice nada si el bot solo contesta lo trivial y deriva todo lo difícil.
• Volumen como éxito. Más conversaciones pueden significar que el chatbot no resuelve y la gente reformula la misma pregunta.

Lo que sí sirve: saber qué tipo de preguntas se resuelven sin escalar, y que cada rechazo del sistema deje escrito por qué se produjo.

Cuándo NO necesitas RAG

No todo chatbot necesita RAG, y venderlo siempre sería hacerte gastar de más:

• Flujos lineales. Si solo hay que guiar por un proceso fijo (pedir una cita, consultar el estado de un pedido contra una API), un flujo estructurado es más robusto y más barato.
• Pocas preguntas que no cambian. Si tu documentación son diez respuestas estables, caben en las instrucciones del sistema sin montar un índice.
• Cuando el problema es otro. Si falla porque nadie definió los casos de uso o porque la integración con tu CRM está rota, añadir RAG no arregla nada.

Lo desarrollo en cuándo RAG funciona y cuándo es ruido.

Cómo evaluar a un proveedor antes de firmar

Estas preguntas separan una implementación seria de una interfaz bonita encima de un modelo genérico. Si las respuestas son vagas, ya tienes la información que necesitas.

• ¿Cómo se trocean e indexan mis documentos, y qué pasa cuando cambio uno?
• ¿Qué hace el chatbot cuando la respuesta no está en mis documentos?
• ¿Qué comprueba antes de dar una cifra, un precio o un plazo?
• ¿Recuerda el contexto de la conversación?
• ¿Cuándo pasa la conversación a una persona, y a quién le llega?
• ¿Puedo ver ejemplos de respuestas malas que haya dado el sistema y qué se hizo con ellas?
• ¿Puedo exportar mis documentos y los registros si me voy a otro proveedor?

Y una prueba que puedes hacer tú: pregúntale algo cuya respuesta sabes que no está en sus documentos. Si contesta con detalle y seguridad, no tiene límites.

Qué cuesta hacerlo bien

Un chatbot con RAG sobre tus documentos tiene un coste de puesta en marcha (preparar el material, indexarlo, integrarlo en tu web) y un coste mensual de operación. Los precios de mi servicio están publicados: una prueba de concepto de 7 días por 158 € (deducible si después contratas), el setup desde 529 € y planes mensuales desde 84 €, todo con IVA incluido. El detalle, qué incluye cada plan y los plazos están en la página del chatbot para empresas.

La prueba de concepto existe para una cosa: comprobar con tus documentos, antes de invertir más, si tu caso necesita esto o no.

Daniel · Arquitecto Digital. Los sistemas los diseño y dirijo yo; la implementación la hago con asistentes de IA de programación.