Qué pasa si un agente de IA se equivoca (y qué hacer en el momento)

El momento en que el agente le dice algo que no debía a un cliente

Pasa siempre en el peor momento. Un viernes a última hora, un fin de semana largo, el día que el responsable técnico está fuera de la oficina. El agente que llevaba semanas respondiendo bien de repente le confirma a un cliente un precio que no corresponde, le asegura que un trámite ya quedó resuelto cuando sigue pendiente, o le da una instrucción que, si el cliente la sigue al pie de la letra, le genera un problema real. Al cliente no le importa si “fue el modelo”: para él respondió la empresa, con su nombre y su marca puestos encima de esa conversación.

Lo primero que se rompe no es el proceso, es la confianza de quien estaba adentro del proyecto. El gerente que aprobó el agente empieza a dudar si fue una buena idea meterlo en producción. El equipo que lo monitorea entra en pánico y busca a quién culpar antes de entender qué pasó. Y mientras tanto el reloj corre en contra: cuanto más tiempo pase entre el error y la respuesta de la empresa, más se parece el silencio a un intento de esconderlo, aunque nadie lo esté escondiendo de verdad.

Esa escena se puede prevenir en parte, pero no eliminar del todo. Ningún proveedor serio promete un agente que jamás falle, y quien lo promete no lo ha tenido en producción el tiempo suficiente para saber de qué habla. Lo que sí se puede tener resuelto antes de que suene el teléfono es qué se hace en la primera hora, quién decide y qué se documenta. Eso, y no la ausencia de errores, es lo que separa un incidente controlado de una crisis que termina en la mesa de un cliente enojado.

Qué significa que un agente de IA se equivoque de verdad

Antes de entrar al protocolo conviene ser precisos con el término, porque “error” se usa para cosas muy distintas y cada una pide una respuesta distinta. Un agente que redacta mal una fecha no es lo mismo que uno que autoriza una transacción que no debía autorizar. Confundir la gravedad es la forma más común de reaccionar mal: apagar todo por un error cosmético, o restarle importancia a uno que sí tenía consecuencias reales, sobre todo cuando se trata de agentes de IA empresariales que ya tienen permisos para actuar, no solo para conversar con alguien.

Esa idea, que responde la empresa y no “la tecnología”, es la que cambia cómo se diseña todo lo demás: el nivel de permisos que le diste al agente, quién lo supervisa en el día a día, y qué tan rápido se entera un humano de que algo salió mal antes de que se entere el cliente por segunda vez, ya molesto y sin respuesta.

Los 4 tipos de falla que puede tener un agente y qué hacer con cada uno

No todo error pide la misma respuesta ni la misma urgencia. Antes de reaccionar conviene ubicar la falla en una de estas cuatro categorías, porque de ahí sale qué tan rápido hay que moverse y quién tiene que enterarse primero.

• Error de información: el agente afirma algo falso o desactualizado (un precio, un plazo, un estado de trámite) con la misma seguridad que si fuera cierto. Es lo que en la práctica se conoce como una alucinación de IA: el sistema no miente, completa un patrón sin verificarlo contra la fuente real. Se corrige revisando la fuente de datos que consultó y, mientras tanto, avisando al cliente afectado.
• Error de alcance: el agente responde algo que sí es cierto, pero que no le correspondía decidir a él (una excepción comercial, la interpretación de un caso límite, una promesa que compromete a la empresa). El problema no es la respuesta, es que nadie le puso el límite correcto antes de soltarlo en producción. Se corrige ajustando qué decide solo y qué debe escalar a una persona.
• Error de acción: el agente ejecuta algo que no debía (envía un correo de más, procesa un reembolso que no correspondía, modifica un dato que no le tocaba tocar). Es el más caro de los cuatro porque ya produjo un efecto en el mundo real, no solo una frase incorrecta. Se corrige revirtiendo la acción si es reversible y, si no lo es, documentando el impacto exacto desde el primer minuto.
• Error de tono o de contexto: el agente dice algo técnicamente correcto pero en el momento o la forma equivocada, por ejemplo a un cliente ya enojado o en una situación sensible. No genera daño operativo directo, pero sí daño de marca, y se acumula si nadie lo revisa a tiempo.

La urgencia no es igual en los cuatro: un error de acción irreversible pide parar ya el flujo afectado; uno de tono pide ajustar el guion sin necesariamente detener nada. Tratarlos todos con el mismo nivel de alarma agota al equipo, y cuando de verdad importa, nadie reacciona a tiempo porque ya gastó la urgencia en algo menor. Vale la pena revisar también qué se hizo en el diseño para evitar que la IA se equivoque desde el inicio, porque baja la frecuencia de estos cuatro casos, aunque no los elimina del todo.

El protocolo de incidente en 5 pasos, para no improvisar en caliente

Un protocolo de incidente no es un documento largo que nadie lee, es la secuencia mínima que cualquier persona del equipo puede seguir a las once de la noche sin tener que pensarla desde cero. Estos son los cinco pasos que sostienen ese momento cuando ya está pasando.

• Contener: si el error puede seguir ocurriendo, en otras conversaciones o con otros clientes, lo primero es limitar el alcance. Pausar el flujo específico que falló, no necesariamente todo el agente ni todos los procesos que sí funcionan bien.
• Registrar: guardar la conversación completa, la hora exacta, el dato que el agente usó y la respuesta que dio, antes de que alguien la edite o la borre por vergüenza. Sin este registro, todo lo que sigue es memoria y opinión de quien lo vivió.
• Evaluar el impacto real: a cuántos clientes llegó el mismo error, si hubo de por medio una acción irreversible, y si compromete dinero, datos personales o salud, o si es una molestia recuperable con una disculpa y una corrección.
• Responder al afectado: contacto humano, con nombre propio, no otra respuesta automática del mismo sistema que produjo el error. Se comunica con lo que se sabe hasta ese momento, aunque la causa completa todavía se esté investigando.
• Decidir el estado del agente: seguir funcionando igual, degradar el flujo afectado a supervisión humana, o apagarlo del todo, según el criterio que se desarrolla en la siguiente sección de esta página.

Ninguno de estos cinco pasos exige más de media hora si ya está definido de antemano quién los ejecuta. Lo que consume horas, y a veces días, es discutir en caliente quién decide cada cosa, porque nadie lo conversó antes de que el agente saliera a producción con clientes reales delante.

Cuándo se apaga el agente y cuándo se degrada a supervisión humana

Apagar del todo un agente por el primer error es una reacción de pánico, no una decisión de riesgo bien pensada. También lo es el extremo contrario: dejarlo funcionando exactamente igual porque “ya se avisó al cliente” y se cree que con eso alcanza. Entre esos dos extremos hay un término medio que se usa poco y que resuelve la mayoría de los casos reales: degradar a supervisión humana, es decir, dejar que el agente siga bajo un monitoreo más cercano mientras propone la respuesta, y que una persona la apruebe antes de que salga al cliente.

Apago el flujo del todo cuando el error fue una acción irreversible con impacto en dinero, datos personales o salud, cuando se repite en menos de una hora con clientes distintos, o cuando todavía no sé si la causa fue el modelo, el dato que consultó o un cambio reciente en otro sistema conectado: mientras no conozco la causa, no puedo prometer que no se va a repetir en la próxima hora. Degrado a supervisión humana cuando el error fue puntual, identificable y de bajo impacto, y cuando el flujo exacto donde ocurrió se puede aislar sin apagar todo lo demás que sí viene funcionando bien.

La peor de las tres decisiones es la que se toma sin criterio escrito de antemano, porque termina dependiendo del humor de quien esté de guardia esa noche. Un cliente enojado en redes empuja a apagar todo sin evaluar nada; un jefe que no quiere “perder el avance del proyecto” empuja a no tocar nada aunque el riesgo siga activo. Ninguno de los dos está mirando el riesgo real, solo la presión inmediata que sienten encima.

Cómo se comunica el error al cliente afectado

La tentación más común es corregir el error puertas adentro y no decirle nada al cliente, con la esperanza de que no vuelva a preguntar por el tema. Es la decisión que más caro sale cuando se descubre, porque deja de ser “un agente se equivocó” y pasa a ser “la empresa lo supo y no avisó a tiempo”. Eso segundo es lo que de verdad rompe una relación comercial, mucho más que el error original.

La comunicación que funciona tiene tres partes, en este orden: qué pasó, sin tecnicismos ni excusas sobre “el modelo” o “el algoritmo” que nadie del otro lado necesita escuchar; qué se hizo ya, en concreto, para corregirlo; y qué cambia específicamente para que no le vuelva a pasar a esa persona. Lo que no funciona es responder con el mismo canal automatizado que produjo el error: en el momento del incidente, contesta una persona, con su nombre y su palabra puestos ahí.

Tampoco conviene sobreexplicar. El cliente no necesita entender qué es una alucinación ni cómo funciona el modelo por dentro, necesita saber que alguien se hizo cargo real de su problema. Cuanto más técnica se pone la respuesta, más suena a que la empresa se está protegiendo a sí misma en lugar de resolverle el problema a él, que es exactamente lo contrario de lo que esa persona busca en ese momento.

Quién responde legalmente cuando el agente falla

Aquí no hay atajo cómodo: si el agente actúa en nombre de la empresa, responde la empresa. Ningún proveedor de modelos ni de infraestructura asume la responsabilidad de lo que ese agente le dijo o le hizo a un cliente; esa responsabilidad la tiene quien lo puso en producción y quien se benefició de automatizar esa tarea. No es una interpretación legal elaborada, es la lógica comercial más básica: si el agente hubiera hecho bien su trabajo, la empresa se habría quedado con el resultado positivo, así que también se queda con el negativo.

En la práctica, lo que de verdad importa cuando hay que rendir cuentas (a un cliente, a un socio, o a quien corresponda dentro de la empresa) es lo que quedó documentado: qué permisos tenía el agente en el momento del error, quién aprobó darle esos permisos, qué monitoreo existía y qué tan rápido se detectó el problema. Una empresa que puede mostrar ese registro está en una posición completamente distinta a una que solo puede decir “no sabemos qué pasó”. Esta página no da asesoría legal ni reemplaza a un abogado: lo que sí puede decir, desde la práctica de implementar estos sistemas, es que la documentación del incidente es lo primero que se pide y lo último que la mayoría de los equipos tiene listo.

Por eso conviene tratar a cada agente que toma decisiones con algún peso real (dinero, datos, compromisos frente a terceros) con el mismo cuidado con el que se trataría a un empleado nuevo al que todavía no se termina de conocer del todo: permisos acotados, límites claros de lo que puede decidir solo, y alguien de la empresa, no del proveedor, con el nombre puesto sobre esa responsabilidad.

Mi criterio sobre la responsabilidad del error

La revisión posterior que evita que el error se repita

El error ya pasó, el cliente ya recibió una respuesta, y en ese momento aparece la tentación más dañina de todas: cerrar el caso y seguir como si nada. La revisión posterior, algunos la llaman post mortem y el nombre importa menos que hacerla de verdad, es la diferencia entre un incidente que enseña algo y uno que se va a repetir en tres meses con otro cliente distinto.

Una revisión que sirve responde tres preguntas concretas, por escrito: qué causó el error exactamente, no “el modelo falló” sino qué dato, qué permiso o qué instrucción faltó; qué cambió en el sistema o en el proceso como consecuencia directa de eso; y quién revisa, en un plazo definido, que ese cambio de verdad sostiene el resultado con el tiempo. Sin esa tercera pregunta, la revisión es un informe bien escrito que nadie vuelve a abrir.

Un servicio gestionado de agentes de IA que no incluye esta revisión como parte del contrato no está gestionando nada, está mirando una luz que parpadea de vez en cuando. Conviene exigir que lo que incluye un servicio gestionado de agentes de IA contemple este paso, no como extra. La empresa que usa agentes de IA en serio dentro de su operación no es la que nunca tuvo un incidente, esa empresa probablemente no los ha usado lo suficiente todavía. Es la que, después de cada incidente, queda mejor protegida que antes. Ese es el estándar real, y no la promesa de cero errores que ningún proveedor serio debería hacer nunca.