Como prevenir las alucinaciones de IA en el soporte al cliente

Preferiria que la IA no diga nada a que diga algo incorrecto

Trabajo en el equipo de soporte de eesel, por lo que me dedico a leer respuestas de IA, las nuestras y las que los clientes nos reenvian de herramientas de las que estan escapando. El patron que me quita el sueno no es el agente que se equivoca y hace una pregunta aclaratoria. Es el agente que inventa una respuesta limpia, confiada, completamente incorrecta y la envia antes de que alguien mire.

Un ejemplo me ha quedado grabado. Un equipo de telematica de vehiculos B2B en Dinamarca, usando Zendesk y escalando de unos cientos de tickets al mes hacia unos miles, nos dijo que su bot seguia diciendoles a los clientes "si, admitimos tu modelo de auto" para marcas que no estaban en su base de datos. Por que? Su base de conocimiento tenia una amigable linea que decia que "admitian todos los modelos". La IA lo creia. No estaba mintiendo, estaba repitiendo un documento escrito para marketing, no para un agente autonomo respondiendo preguntas reales. Su propio resumen de los primeros dias: "prueba y error".

Eso es lo que pasa con las alucinaciones en soporte: raramente es el modelo yendose por las ramas. Es el modelo repitiendo fielmente un vacio en tu configuracion. Hemos estado poniendo agentes de IA en colas de soporte en vivo durante anos, a traves de miles de tickets reales, y casi cada respuesta incorrecta que he rastreado tiene una causa raiz aburrida y solucionable. Empecemos por ahi.

Por que una alucinacion de soporte cuesta mas que una alucinacion de chatbot

Cuando un chatbot general inventa algo, encoges los hombros y reformulas. Cuando un agente de soporte lo hace, el cliente actua en consecuencia. Esperan una fecha de entrega que no prometiste. Siguen pasos de configuracion para una funcion que no tienes. En trabajos regulados las apuestas suben rapidamente: el cofundador de una empresa de tecnologia legal nos dijo que no podian permitirse cometer ningun error, porque hay una fina linea entre ser util y adentrarse silenciosamente en dar asesoramiento legal.

Puedes ver el mismo miedo en resenas publicas. Un Analista de Negocios de Salesforce que revisa un agente de soporte de IA en G2 lo expreso directamente en la version de calidad de datos:

"Si tus archivos de Content Version (Knowledge Articles) no se han actualizado desde 2021, el agente de IA le dara con confianza a los clientes informacion desactualizada."

Muhammad O., Analista de Negocios de Salesforce, resenando Agentforce Service en G2

Y la version sin anclar, de otro revisor de la misma familia de herramientas:

"Ademas de eso, la alucinacion es realmente mala, ya que no entrenamos, y funciona con un modelo general, a veces simplemente da informacion que no es nuestra."

Arjun G., Consultor Asociado de Salesforce, resenando Salesforce Agentforce en G2

Ambas resenas llegan al mismo punto desde extremos opuestos: un agente es tan veridico como lo que se le permite leer y si se le obliga a leerlo. Ese es todo el juego. Asi es como lo aseguraria.

Las cinco barreras que detienen a una IA de soporte de alucinar

Piensalo menos como una configuracion y mas como una serie de barreras por las que pasa una pregunta antes de llegar a un cliente. Cada barrera captura un modo de falla diferente, y las que sobreviven las cinco son las respuestas que realmente puedes confiar en enviar por su cuenta.

Barrera 1: limitar el conocimiento, luego limitarlo de nuevo

La primera y mayor palanca es lo que el agente puede leer. Un agente de soporte de IA debe responder desde tu propia fuente de verdad: tu centro de ayuda, tus tickets resueltos pasados, tu base de conocimiento interna, y nada mas. En el momento en que se le permite recurrir al "conocimiento general" para llenar un vacio, le has dado permiso para adivinar.

Aqui es donde tambien importa la higiene aburrida de documentos. Esa linea de "admitimos todos los modelos" es una alucinacion esperando ocurrir, no porque la IA sea tonta, sino porque es una declaracion confiada y sin calificativos sentada en una fuente que el agente trata como verdad. Cuando entrenas una IA en tu base de conocimiento, no solo la apuntas a los documentos, estas auditando si esos documentos son seguros de repetir textualmente a un extrano.

eesel aprende de tus tickets pasados, documentos de ayuda y flujos de trabajo del equipo desde el primer dia, para que anos de conversaciones resueltas se conviertan en conocimiento en el que el agente puede apoyarse en lugar de inventar. Se conecta directamente a tus fuentes de conocimiento existentes y mesas de ayuda, para que el agente lea los mismos articulos en los que tu equipo ya confia.

Si un tema genuinamente no esta cubierto, el comportamiento correcto es decirlo o transferir, no improvisar. Un buen agente tambien deberia marcar los vacios que sigue encontrando para que puedas escribir el articulo faltante, en lugar de taparlos con una suposicion. Esto es la mitad del valor de un chatbot de base de conocimiento de IA: te dice lo que tus documentos aun no cubren.

Barrera 2: forzar una cita en cada respuesta

Las citas son una trampa para alucinaciones. Si el agente tiene que apuntar al documento especifico del que proviene su respuesta, suceden dos cosas buenas: un revisor humano puede verificarlo con un clic, y el agente no puede responder en absoluto cuando no hay fuente que citar. Sin fuente, sin respuesta confiada.

El cofundador de tecnologia legal que mencione antes se sintio comodo precisamente porque podia establecer barreras exactas sobre las fuentes y el agente siempre mostraba citas transparentes. Eso no es un complemento para ellos, es lo que les permitio activar la IA. Bajo el capo, esto es para lo que sirve una configuracion de recuperacion aumentada: la respuesta se ensambla a partir de pasajes recuperados, y los pasajes viajan con ella.

Una verificacion rapida para cualquier herramienta que estes evaluando: pide ver una respuesta con sus fuentes adjuntas. Si el proveedor no puede mostrarte de donde provino una respuesta determinada, tampoco puede tu equipo, y tampoco puede tu cliente.

Barrera 3: enrutar por confianza (esta es la mas importante)

Si solo haces una cosa de esta publicacion, haz esto. Un umbral de confianza permite que el agente responda las preguntas de las que esta seguro y deje todo lo demas en paz. Alta confianza, responde y envia. Media, redacta una respuesta para que un humano la apruebe. Baja, no toca el ticket y lo enruta a una persona.

Esto surgio en la llamada de ventas mas memorable que he revisado. Un lider de CX en una marca DTC de suplementos en Gorgias y Shopify, con alrededor de 7,000 tickets al mes, nos dijo que el trato dependia exactamente de esto. Sus palabras, aproximadamente: la IA nunca respondera el 100% de las preguntas, pero si lo intenta y simplemente responde "lo siento, no se", no puede revisar los 7,000 tickets para ver si la respuesta fue buena, asi que el objetivo se pierde. Necesitaba una IA que solo manejara los tickets de los que estaba segura y dejara el resto en paz. Esa es toda la tesis de la prevencion de alucinaciones en una oracion frustrada.

El enrutamiento por confianza es tambien lo que marca la diferencia entre un agente de IA y un chatbot basado en reglas: el agente sabe cuando no sabe. eesel viene con esto listo para usar, y comienzas completamente supervisado, luego otorgas autonomia en los tipos de tickets faciles a medida que generas confianza, categoria por categoria. La mayoria de los helpdesks exponen alguna version de esto; si estas en Zendesk, vale la pena entender el umbral de confianza de intenciones y el mensaje de respaldo al que recurre el agente.

Barrera 4: mantener a un humano en los tickets dificiles, con una transferencia limpia

El enrutamiento por confianza solo ayuda si la transferencia que sigue es limpia. Cuando el agente se retira, el ticket debe llegar a un humano con contexto completo: la conversacion, el cliente, en que no estaba seguro el agente; no un reinicio frio que haga que el cliente se repita.

Aqui es tambien donde le das a tu equipo control explicito sobre lo que toca la IA. Muchos equipos quieren ciertos tipos de tickets completamente fuera de la automatizacion: disputas de facturacion, cancelaciones, cualquier cosa legal. Eso es una funcion, no una limitacion. Una buena configuracion te permite excluir tipos de tickets, establecer que el agente solo actue cuando se le invoque explicitamente, y definir cuando debe escalar. Si estas cartografiando esto, nuestra guia sobre escalaciones de agentes de IA cubre los patrones que funcionan. La mecanica de una transferencia a un humano limpia importa tanto como el desencadenante que la activa.

Hay una trampa relacionada que vale la pena nombrar: prometer de mas. Un gerente de soporte de eCommerce con el que trabajamos tenia que seguir diciendole a su chatbot de IA de ecommerce que dejara de asegurarles a los clientes que los "solucionaria" y que dejara de prometer entrega antes del viernes, porque nadie podia garantizar eso. La alucinacion no es solo inventar hechos, tambien es inventar compromisos. Las barreras de tono y promesas pertenecen al mismo cubo que las barreras de hechos.

Barrera 5: aprender de cada correccion

La ultima barrera es la que se acumula. Cada vez que un humano edita o rechaza un borrador, esa senal deberia mejorar la siguiente respuesta, no desaparecer en el vacio. Un agente que aprende de las correcciones se vuelve mas preciso y confiado con el tiempo, lo que significa que mas tickets pasan la barrera 3 honestamente en lugar de bajar el listón.

Con eesel ajustas esto en lenguaje sencillo: le dices al agente cuando intervenir, que tono usar, y que nunca prometer, y las correcciones se retroalimentan en su comportamiento. Sin proyecto de reentrenamiento, sin equipo de ciencia de datos. Puedes revisar lo que esta haciendo en los registros de conversacion y ajustar desde ahi, el mismo bucle alrededor del que se construye un centro de entrenamiento de Zendesk.

No confies en las barreras a ciegas: simula primero

Este es el paso que la mayoria de los equipos omite, y el que nunca lanzaria sin el. Antes de que salga una sola respuesta en vivo, ejecuta el agente contra tus tickets historicos reales y ve como habria respondido.

La simulacion convierte "creo que esto es seguro" en un numero. Le apuntas el agente a miles de conversaciones pasadas y te muestra como habria respondido, donde es confiante, donde habria adivinado, y que parte del volumen habria podido manejar por si solo. Encuentras los vacios, los llenas y vuelves a ejecutar, todo antes de que participe cualquier cliente. Es la diferencia entre esperar que tus barreras aguanten y verlas aguantar contra tu historial de tickets real.

Esta es tambien la forma honesta de pronosticar tu tasa de resolucion en lugar de confiar en el numero destacado de un proveedor. Un lider de CX que cite antes hizo el mismo punto de otra manera: no queria esperar a un informe mensual para descubrir que la IA estaba equivocada, queria saberlo de antemano. La simulacion es como sabes de antemano. El modo de simulacion de eesel corre contra tus tickets pasados y reporta cobertura por tema, para que vayas en vivo en los tipos de tickets que demostro que podia manejar, y solo esos.

Sere directo sobre el compromiso, ya que el optimismo uniforme es su propia especie de senal. Hacer esto correctamente significa que no accionas un interruptor y lo automatizas todo el primer dia. Comienzas estrecho, en los tipos de tickets que la simulacion avalo, y amplias a medida que el agente lo merece. Si quieres un agente que resuelva el 100% de los tickets desde la primera hora con cero supervision, ninguna herramienta honesta puede darte eso, y las que lo afirman son las que alucinan. La ventaja es que el camino mas lento y anclado es tambien el que los clientes realmente llegan a confiar.

Donde el modelo en si ayuda

He insistido mucho en "es tu configuracion, no el modelo", porque ahi es donde estan las soluciones. Pero el modelo subyacente no es irrelevante. Los modelos mas nuevos son mejores para decir "no estoy seguro" en lugar de blufear, mejores para ceirse a las fuentes recuperadas, y mejores para seguir instrucciones como "nunca prometas una fecha de entrega". Una configuracion de anclaje fuerte en un modelo fuerte supera a una configuracion fuerte en uno debil. Es tambien lo que separa una verdadera herramienta de asistencia de agentes de IA de un seleccionador de macros glorificado.

La conclusion practica: no tienes que elegir el modelo tu mismo ni vigilar las actualizaciones. El trabajo de una buena plataforma de soporte es ejecutar un modelo capaz y envolverlo en las cinco barreras anteriores, para que obtengas las mejoras del modelo sin tener que redisenar nada. Esa es la capa en la que se situa eesel, y es por eso que el mismo agente se comporta de manera consistente en mas de 100 integraciones. Ya sea que tu pila este construida sobre un agente de IA de Gorgias o uno de HubSpot, las capas de anclaje y confianza viajan con el.

Prueba eesel

Soy parcial, trabajo aqui, y nos integramos con los helpdesks que he mencionado, asi que pondera mi opinion con eso en mente. Pero la prevencion de alucinaciones es exactamente el problema alrededor del que fue construido el agente de helpdesk de IA de eesel. Aprende de tus tickets y documentos pasados desde el primer dia, cita sus fuentes, enruta por confianza para que las respuestas inseguras vayan a un humano en lugar de a tu cliente, y te permite simular contra tu historial de tickets real antes de ir en vivo: las cinco barreras, incorporadas en lugar de anadidas. Los equipos lo ejecutan a escala real en esto: un cliente resuelve el 73% de las solicitudes de nivel 1 en el primer mes, y otro ejecuta un agente completamente automatizado en mas de 100,000 tickets en aleman al mes.

El precio es basado en uso sin tarifas por asiento, para que no estes pagando por un agente sentado ahi adivinando. Puedes ver los planes o iniciar una prueba gratuita y ejecutar primero una simulacion en tus propios tickets. Esa simulacion es la forma mas rapida de ver, en tus propios datos, exactamente donde un agente de IA ayudaria y donde habria alucinado, antes de que hable con un cliente.