Poner un LLM en atención al cliente: qué se rompe primero

La atención al cliente es el primer caso de uso de IA más popular en una empresa, y con razón: la demo es irresistible. Conectas un modelo a tu documentación de ayuda, le haces una pregunta y responde con fluidez. La distancia entre esa demo y un sistema que puedas operar de verdad es donde la mayoría de los proyectos tropiezan. Este artículo recorre lo que se rompe primero, más o menos en el orden en que los equipos lo encuentran, para que puedas planificar los fallos en lugar de descubrirlos en producción.

La demo es fácil; la operación es difícil

La demo funciona porque muestra el camino fácil: una pregunta clara con una respuesta limpia que vive en la documentación. El tráfico real de soporte no es así. Son preguntas ambiguas, información que falta, casos límite, clientes enfadados y peticiones que exigen una acción en lugar de una respuesta. El modelo que bordó la demo se enfrenta a todo esto desde el primer día. Planificar para la demo es planificar para el cinco por ciento del tráfico que nunca fue el problema.

Fallo n.º 1: responde cuando no debería saber

Lo primero que se rompe es la confianza. Un modelo de soporte responderá preguntas cuyas respuestas no están en tu documentación, inventando políticas, precios o pasos plausibles. Los clientes no pueden distinguir una respuesta fundamentada de una fabricada: ambas suenan igual de fluidas. Una sola respuesta segura pero equivocada sobre una política de reembolsos puede costar más de lo que ahorra todo el sistema.

La solución es fundamentación y honestidad: recupera de tu documentación real, instruye al modelo para que responda solo a partir de lo que recuperó y para que diga con claridad cuándo no sabe y derive el caso. La parte difícil no es la instrucción, sino aceptar que "no lo sé, déjame conectarte con alguien" es un buen resultado, no un fracaso.

Fallo n.º 2: la recuperación no encuentra el documento relevante

Una vez que fundamentas las respuestas en tu documentación, el siguiente fallo se desplaza aguas arriba: el modelo responde a partir del documento equivocado, o de ninguno, porque la recuperación no dio con el relevante. Es la misma lección que aprende todo sistema de recuperación: la mayoría de los fallos son fallos de recuperación. Si el artículo de ayuda correcto no está delante del modelo, ninguna cantidad de generación fluida producirá la respuesta correcta.

Aquí es donde rinde el trabajo poco glamuroso: mantener la base de conocimiento limpia y actualizada, fragmentar los artículos con sensatez y medir si realmente se está recuperando el artículo correcto para preguntas reales, por separado de si la respuesta final se lee bien.

Fallo n.º 3: la base de conocimiento está mal o desactualizada

Un modelo de soporte es tan bueno como los documentos que tiene detrás. La mayoría de las empresas descubren, al conectar un modelo, que su centro de ayuda se contradice, describe funciones que cambiaron o nunca documentó aquello que más preguntan los clientes. La IA no crea este problema; lo saca a la luz, a escala, delante de los clientes. Los equipos que tienen éxito tratan la limpieza de la documentación como parte del proyecto, no como un requisito previo que se ocupará otro.

Fallo n.º 4: no puede ejecutar acciones de forma segura

Responder preguntas es una cosa; hacer algo —emitir un reembolso, cambiar una dirección, cancelar un pedido— es otra. En cuanto un asistente de soporte puede ejecutar acciones, las apuestas cambian. Una respuesta equivocada es embarazosa; una acción equivocada mueve dinero o datos. Los despliegues reales trazan una línea cuidadosa: acciones de bajo riesgo que el modelo puede ejecutar directamente, las de mayor riesgo que exigen confirmación o un humano, y un rastro de auditoría claro para todas ellas. Este tipo de gestión de riesgos consciente del contexto es exactamente lo que fomentan marcos como el NIST AI Risk Management Framework: ajusta los controles a las consecuencias.

Fallo n.º 5: la transferencia es torpe

Ninguna IA de soporte lo resuelve todo, así que la transferencia a un humano es parte del producto, no una ocurrencia tardía. Donde se rompe: el modelo transfiere sin pasar el contexto, así que el cliente se repite y se enfada más; o se niega a transferir y atrapa al cliente en un bucle. Una buena transferencia es fluida: lleva consigo la conversación, la intención del cliente y lo que ya se intentó, para que el humano empiece informado.

Fallo n.º 6: nadie mide lo correcto

El fallo final es silencioso. Los equipos miden la tasa de desvío (cuántos tickets gestionó la IA) y lo celebran, sin medir si esas respuestas eran correctas o si los clientes volvieron más enfadados. Desvío sin calidad es solo esconder problemas. Los despliegues que perduran miden la calidad de la resolución y los resultados para el cliente, leen transcripciones reales con regularidad y tratan las peores respuestas como la señal, no el promedio.

Qué separa a los supervivientes

El patrón en los despliegues que funcionan: tratan al modelo como un componente de un sistema, no como el sistema. Fundamentan las respuestas, diseñan deliberadamente el camino del "no lo sé", mantienen honesta la base de conocimiento, limitan las acciones arriesgadas, hacen elegantes las transferencias y miden la calidad en lugar de solo el volumen. Nada de esto es exótico. Es la diferencia entre lanzar la demo y operar el servicio.

En resumen

Un chatbot de soporte es la demo de IA más fácil y una de las cosas más difíciles de operar bien. Se rompe, en orden, por exceso de confianza, recuperación, documentos desactualizados, acciones inseguras, transferencias torpes y las métricas equivocadas. Cada uno de esos fallos es previsible. Planifícalos por adelantado y una capa de soporte con IA se convierte en un activo genuino. Sáltate la planificación y lanza la demo, y tus clientes encontrarán los fallos por ti.