Cuando tu IA se equivoca frente a un cliente
Cómo diseñar rutas de escalada, disculpas y registros de auditoría antes de que su sistema de IA cometa su primer error público.
Se equivoca la IA: ¿Cómo evitar un fallo evitable
No todas las respuestas erróneas merecen la misma respuesta. Califícalas antes del lanzamiento, en lenguaje claro, con el nombre de cada persona responsable de cada calificación.
Un problema de tono —el sistema es brusco o excesivamente formal— es una cuestión de formación para la próxima semana. Un error fáctico sobre una política, un precio o una fecha de entrega se corrige al día siguiente y se contacta al cliente. Un error que afecta el dinero, la seguridad, un compromiso legal o los datos personales es un evento de parada: la característica se desactiva y permanece así hasta que comprendas qué sucedió.
Escribe estos tres niveles en una página. Asigna a cada nivel un responsable, un reloj de respuesta y la autoridad explícita para desactivar el sistema. La persona que pueda apagarlo no debería tener que buscar primero a un ejecutivo. Si tu único interruptor de apagado es el despliegue, no tienes un interruptor de apagado.
Ofrece a los clientes una persona, no un bucle
El patrón más dañino en los servicios con IA es el bucle cerrado: el cliente no está de acuerdo con el sistema, el sistema se explica a sí mismo nuevamente y no hay salida visible. La gente perdona una respuesta equivocada. No perdonan quedar atrapados.
Cada interacción con IA necesita una ruta hacia un humano disponible desde la primera solicitud, no desde la tercera. Hazlo visible en la interfaz, no oculto en una página de ayuda. Envíalo a alguien que pueda ver toda la conversación que el cliente acaba de tener, para que el cliente no tenga que contarla nuevamente. Y rastrea la tasa de escalamiento como una métrica principal: un sistema que nunca escala suele ser un sistema cuya salida nadie puede encontrar.
Establece un umbral que active la intervención humana de forma proactiva también. Si un cliente repite su pregunta dos veces, si una conversación dura más de lo previsto o si el tema se refiere a reembolsos o reclamaciones, entre sin esperar a ser pedido.
La disculpa es una decisión comercial
Cuando contactes a un cliente por una respuesta equivocada, tres cosas son importantes: la rapidez, la especificidad y qué ofreces para que no vuelva a suceder. Redacta el modelo ahora, mientras nadie esté bajo presión.
Di qué equivocó el sistema. Di cuál es la posición correcta. Di qué estás haciendo para evitarlo en el futuro. No culpes al modelo, no expliques la arquitectura y no uses la frase "halucinación de IA" con un cliente —suena como una excusa para una empresa que entregó algo que no controlaba.
Luego decide la política de remedios por adelantado. Si el sistema citó un precio equivocado, ¿lo honras? Si prometió una fecha de entrega que no puedes cumplir, ¿qué ofreces? Responde a estas preguntas en una sala una vez, no caso por caso bajo presión. El costo de una política consistente suele ser mucho menor que el de la improvisación.
Registra lo que desearás haber registrado
Un registro es lo que convierte un argumento en una investigación. Captura estos datos desde el primer día, porque no podrás reconstruirlos más tarde:
- La entrada y salida exactas con su hora y un ID de conversación que el cliente pueda citar
- Qué modelo y versión produjo la respuesta, y qué prompt o configuración estaba activa
- Los documentos o registros que el sistema consultó para poder diferenciar una mala fuente de una mala respuesta
- Toda intervención humana: quién escaló, quién sobrescribió, los cambios que hicieron
- El resultado —resuelto, reembolsado, reclamación, abandono—
Establece reglas de retención y acceso con estas consideraciones. Una revisión legal antes del lanzamiento es más barata que una después de una queja.
Ensaya una vez
Realiza un simulacro de treinta minutos antes de ir en vivo. Utiliza una respuesta equivocada plausible, pasa por la detección, la escalación, el contacto con el cliente y la solución. Descubrirás las lagunas inmediatamente: ningún responsable los fines de semana, ninguna forma de desactivar una característica sin desactivar todas, ningún registro de qué prompt versión estaba activa.
Todo lo anterior es poco glamuroso, pero determina si una respuesta equivocada se convierte en una única respuesta equivocada o en un problema continuo. Construimos estos caminos en los sistemas antes del lanzamiento, no después de la primera mala semana —el peso es más fácil de llevar cuando alguien ya ha planeado para ello.