Qué pasa si la IA da información incorrecta a un cliente

El cliente ya tomó una decisión con lo que la IA le dijo, y el error aparece después

El daño no se nota en el segundo en que el sistema se equivoca. Se nota después, cuando el cliente ya actuó con esa información: ya compró, ya programó una mudanza para el jueves que le prometieron, ya desconectó un equipo siguiendo una instrucción que sonaba segura. Para cuando alguien de la empresa revisa la conversación y confirma que sí, el sistema dijo eso, el cliente ya pagó el costo de haberle creído. No hay forma de adelantar el reloj.

La reacción instintiva de muchos equipos es técnica: buscar el registro, identificar qué salió mal en el modelo, redactar una explicación sobre por qué pasó. Todo eso es necesario, pero llega segundo. Lo primero que el cliente necesita escuchar no es una explicación de arquitectura, es que alguien de la empresa se hace cargo del problema que él tiene enfrente en ese momento. Confundir el orden, explicar antes de responder, es la forma más rápida de convertir un error operativo en una queja pública.

Quién responde cuando el error lo cometió el sistema, no una persona

Si un vendedor le dice a un cliente algo incorrecto sobre precio, plazo o cobertura, a nadie se le ocurre discutir si la empresa responde. Se asume. El cambio de canal no cambia esa lógica: que la respuesta incorrecta haya salido de un chat automatizado en vez de una persona con gafete no mueve la responsabilidad fuera de la empresa. El cliente compró o confió con base en algo que la marca le dijo, sin importar qué proceso interno generó esa frase.

Esto tiene una consecuencia práctica que conviene aceptar temprano: el sistema no es una parte independiente a la que se le pueda transferir la culpa. No existe, frente al cliente, un tercero llamado “el modelo” con el que la empresa pueda decir que no tiene relación. El contrato, la marca y la reputación son de la empresa, y el sistema es una herramienta que la empresa decidió poner a hablar en su nombre.

Los tres tipos de error frente a un cliente, y por qué no cuestan lo mismo

No todo error de un sistema conversacional pesa igual, y tratar los tres tipos como si fueran el mismo problema es lo que hace que el protocolo de respuesta salga mal calibrado. Antes de reaccionar conviene clasificar cuál de los tres pasó:

• Error de información: el sistema dio un dato objetivo incorrecto, un precio, un plazo, una especificación de producto. Si ese dato viene de una alucinación de IA, el sistema inventó algo que no estaba en ninguna fuente real. El costo suele ser reversible: se corrige el dato y se aclara, aunque repetirlo desgasta la confianza en el canal.
• Error de promesa: el sistema comprometió algo que la empresa nunca autorizó, un descuento, una garantía extendida, una condición especial. El costo ya no es solo aclarar un dato, es decidir si se paga lo prometido y qué precedente queda para el próximo cliente que pida lo mismo.
• Error de instrucción: el sistema le dijo al cliente que hiciera algo, y esa acción le generó una pérdida real, un paso técnico que dañó un equipo, un consejo que le costó dinero o tiempo. Es el más caro de los tres porque hay un daño concreto y atribuible, no solo una expectativa incumplida.

Clasificar el error primero evita dos errores peores: tratar una promesa cara como si fuera un dato menor que se corrige con un mensaje, o tratar un dato menor como si fuera una crisis que exige compensación.

El protocolo de respuesta: qué pasa en las primeras horas

Un protocolo que se inventa en la llamada con el cliente enojado ya llegó tarde. Lo que separa a una empresa que maneja bien este momento de una que lo empeora es tener decidido, antes de que pase, quién hace qué en las primeras horas:

• Confirmar el error real, revisando el registro exacto de la conversación, no la versión que recuerda el cliente ni la que asume el equipo de soporte.
• Frenar la exposición, si el error puede repetirse con otros clientes en ese mismo momento, un mensaje mal configurado, una respuesta que sale igual para todos, antes de responderle al primero.
• Asignar un dueño humano con nombre, que sea quien firma la respuesta. Nunca “el sistema” ni un genérico “equipo de soporte” sin responsable identificable.
• Fijar la postura antes de hablar con el cliente: honrar, compensar o corregir, decidido con calma y no en la conversación misma, para que la respuesta sea coherente y no se contradiga un día después.

Ese protocolo funciona mejor cuando ya existe una política de uso de inteligencia artificial en la empresa que defina de antemano montos, autoridad para decidir y límites de lo que el sistema puede prometer. Sin eso, cada caso se improvisa desde cero.

Cuándo conviene honrar lo que el sistema prometió, y cuándo no

Honrar la promesa no siempre es la respuesta correcta, y negarla tampoco. La decisión se toma mirando cuatro cosas:

• Si la promesa era razonable dentro de la política real, aunque el sistema la haya redactado distinto a como la habría dicho una persona. Ahí honrarla suele costar poco.
• El costo de cumplirla frente al costo de negarla, en un caso puntual y aislado, casi siempre es más barato pagar que perder al cliente en público.
• El precedente que deja: si honrarla abre la puerta a que miles de clientes reclamen la misma condición, el cálculo cambia por completo y deja de ser un caso individual.
• Si la promesa violaba una restricción real, de seguridad, de stock, de una condición que la empresa nunca podría cumplir, ahí no se honra: se explica con claridad y se compensa de otra forma.

Qué se le comunica al cliente, y qué nunca se le dice

Lo que el cliente necesita escuchar en los primeros minutos es distinto de lo que la empresa quiere explicar. Confundir ambos es lo que más quema la relación.

Lo que sí se comunica

• Reconocer el error sin rodeos, sin condicionar el reconocimiento a que el cliente insista o amenace con irse.
• Quién, dentro de la empresa, se hace responsable de resolverlo: una persona con nombre, no un departamento.
• La acción concreta que se va a tomar y el plazo real en el que va a pasar.

Lo que nunca se dice

• Culpar al algoritmo como si fuera un tercero ajeno a la empresa, algo así como “fue el sistema, no nosotros”.
• Prometer que “no va a volver a pasar” sin haber confirmado todavía la causa raíz del error.
• Explicar detalles técnicos que el cliente no pidió y que no le resuelven nada del problema que tiene enfrente.

El registro que necesitas para poder reconstruir qué pasó

Nada de lo anterior es posible sin un registro serio. La pregunta que decide si una empresa puede defender su versión de los hechos, o si se queda solo con la palabra del cliente contra la suya, es si guardó lo necesario para reconstruir la conversación completa:

• La conversación completa, no el resumen de tres líneas que quedó anotado en el ticket de soporte.
• La versión del modelo y del prompt vigente ese día, porque esas instrucciones cambian con el tiempo y lo que el sistema dice hoy no es necesariamente lo que decía hace un mes.
• El contexto que se le inyectó en ese momento: qué documentos, qué política, qué datos del cliente tenía disponibles para responder.
• Quién modificó esa configuración por última vez y cuándo, para saber si el error viene de un cambio reciente o es un patrón viejo que nadie corrigió.

Esto es, en la práctica, parte de la memoria organizacional de la empresa: si el conocimiento de qué respondió el sistema y por qué vive solo en la cabeza de quien lo configuró, cada incidente se investiga desde cero.

Cómo se corrige el sistema para que el error no se repita

Resolverle el caso a un cliente y corregir el sistema son dos trabajos distintos, y el primero no reemplaza al segundo. Si el error es de un tipo que puede repetirse, y no una anécdota aislada, corregirlo implica volver sobre el diseño del propio sistema, no solo sobre el caso puntual.

En la práctica, esto pasa por revisar cómo limitar las respuestas de un LLM que habla por tu empresa, para que el sistema deje de poder prometer o afirmar lo que generó el error, y por retomar cómo evaluar un modelo de lenguaje en la empresa de forma continua, no solo el día que se lanzó. Lo mismo aplica, con matices propios, cuando un agente de IA se equivoca al ejecutar una acción y no solo al responder una pregunta.

El error que se corrige una sola vez, en el caso del cliente que reclamó, vuelve a aparecer con el próximo cliente que no reclama y simplemente se va. La corrección real ocurre en el sistema, no en la conversación de soporte.

La responsabilidad legal, en términos prácticos de negocio

Aquí conviene ser honesto sobre los límites de este texto: esto no es asesoría legal, y no vas a encontrar acá una cita de una ley o de un artículo específico que resuelva tu caso. La regulación sobre qué responde una empresa por lo que dice su sistema de IA todavía se está escribiendo en la mayoría de países, y varía según dónde operes. Para eso se necesita un abogado que conozca tu jurisdicción, no un artículo de blog.

Lo que sí se puede tratar en términos prácticos es más simple de lo que parece: frente al cliente responde la empresa, no el proveedor del modelo ni el empleado que configuró el flujo a título personal. Lo que se documenta es lo que permite demostrar, después, que hubo un protocolo y no improvisación: el registro de la conversación, quién decidió qué, y qué se corrigió. Y cómo se decide honrar o no lo prometido ya quedó cubierto antes: es una decisión de negocio, tomada con criterio comercial, no un trámite legal que se resuelve solo.

La pregunta que de verdad importa no es si la ley ya contempla este escenario con precisión, porque en la mayoría de sitios todavía no. La pregunta es si tu empresa podría mostrar, hoy mismo, que tenía un protocolo antes de que el error pasara. Esa capacidad de mostrar orden es la defensa real, se construye antes del incidente y no se improvisa el día que un cliente amenaza con escalarlo.