Cómo gestionar excepciones y el escalado a humanos con agentes de IA

Un agente que funciona bien no es el que resuelve todos los casos, sino el que sabe cuáles no debe resolver. Gestionar excepciones con agentes de IA es, en el fondo, diseñar el límite del mandato: la línea que separa lo que el agente ejecuta solo de lo que pasa a una persona. Trazar bien esa línea gobierna el riesgo real del sistema. Trazarla mal produce o un agente inútil que lo escala todo, o uno peligroso que decide lo que no debería. Aquí explico cómo la dibujo: qué cuenta como excepción, cómo se tipifican, qué escala y a quién, y cómo el conjunto mejora con el tiempo.

Qué es una excepción

Una excepción no es un error. Un error es que el agente haga mal lo que sabe hacer. Una excepción es un caso que cae fuera de lo que su mandato le permite decidir. Confundir ambos lleva a la trampa de tratar cada excepción como un fallo a corregir, cuando muchas son exactamente lo que el sistema debe hacer: reconocer un límite y pedir ayuda.

Distingo tres orígenes, porque cada uno se trata distinto:

• Baja confianza. El agente puede actuar pero no está lo bastante seguro. El dato es ambiguo, el caso se parece a varios patrones a la vez.
• Fuera de política. El caso es claro, pero excede lo que el mandato autoriza: un importe por encima del umbral, una operación sensible, un cliente marcado.
• Fuera de patrón. El caso no se parece a nada que el agente haya visto en sus reglas ni en sus ejemplos. Territorio nuevo.

Un agente bien diseñado escala los tres. El de baja confianza porque adivinar sería temerario, el de fuera de política porque no le corresponde decidir, el de fuera de patrón porque no tiene con qué.

Cómo se tipifican las excepciones

“Escalar a un humano” no puede ser una única puerta por la que entra todo lo raro. Si lo es, esa puerta se convierte en un cuello de botella y la persona que la atiende acaba viendo un revoltijo sin prioridad. Las excepciones se tipifican, igual que se tipifican los casos normales.

Tipificar significa darle a cada excepción una categoría, una causa y un destino. Imagina una empresa de servicios B2B de 60 M€ que pone un agente a procesar pedidos entrantes. Su tabla de excepciones podría empezar así:

Tipo de excepción	Causa típica	Destino
Cliente sin crédito aprobado	Fuera de política	Finanzas, con el caso preparado
Referencia de producto ambigua	Baja confianza	Operaciones, con las opciones probables
Pedido con condiciones no estándar	Fuera de patrón	Responsable comercial
Importe por encima del umbral	Fuera de política	Confirmación del supervisor

Esta tabla no se inventa entera el primer día. Se arranca con las excepciones que ya conoce quien hace el trabajo hoy, y crece a medida que la operación real revela casos que nadie había anticipado. Cada tipo nuevo que aparece se nombra, se le asigna un destino y deja de ser “lo raro” para convertirse en una categoría gestionada.

Qué escala y a quién

Dos decisiones que un comité debe tomar con los ojos abiertos, porque reparten responsabilidad.

Qué escala lo fija el umbral de cada tipo de excepción. Aquí hay una tensión real: cuanto más bajo pones el listón de confianza para actuar, más resuelve el agente solo y más riesgo asumes. Cuanto más alto, más seguro pero más carga sobre las personas. No hay un número universal. Se empieza conservador —el agente escala mucho— y se relaja donde los datos demuestran fiabilidad, nunca al revés. Esa gradación de la autonomía, y quién confirma qué, es un asunto de permisos que desarrollo en permisos y controles de agentes.

A quién escala se decide por competencia, no por jerarquía. La excepción de crédito va a finanzas, la de producto a operaciones, la comercial a quien lleva la cuenta. El objetivo es que el caso llegue a quien puede resolverlo en un paso, no a un buzón genérico del que alguien tenga que repartirlo. La frontera entre lo que decide el agente y lo que decide la persona —el patrón de supervisión, esté la persona dentro del bucle o vigilándolo— es una decisión de diseño con su propia disciplina. Aquí me quedo en su lado operativo.

El contexto que llega a la persona

Una excepción mal escalada es la que llega como “revisa este caso” y obliga a la persona a reconstruir desde cero qué pasó. Eso destruye la ventaja: si resolver la excepción cuesta más que haber hecho el caso a mano, el agente resta en vez de sumar.

Un escalado bien hecho entrega el caso preparado: qué recibió el agente, qué intentó, por qué se detuvo, qué opciones ve y qué información necesita la persona para decidir. La persona no investiga. Juzga. Y su decisión vuelve al sistema en un formato que se puede reutilizar, no como un correo suelto que se pierde. Todo ese rastro —qué llegó, qué se decidió, quién lo decidió— es la materia de la que vive la auditoría del sistema, y conecta con el marco de gobernanza de agentes.

Cómo el sistema mejora: excepciones que se vuelven reglas

Aquí está la parte que convierte la gestión de excepciones en una ventaja compuesta en lugar de un impuesto permanente.

Cuando un tipo de excepción se repite y las personas lo resuelven siempre de la misma forma, ha dejado de ser una excepción. Es una regla que todavía no estaba escrita. El proceso maduro captura ese patrón, lo formula como regla explícita, lo prueba contra los casos históricos para asegurarse de que la persona y la nueva regla coinciden, y a partir de ahí el agente lo resuelve solo. La cola de excepciones baja, no porque se ignore, sino porque se ha aprendido de ella.

Ese ciclo tiene una consecuencia estratégica: el mandato del agente se ensancha con el uso, de forma controlada y con evidencia detrás, en lugar de fijarse de una vez el primer día. Es también la razón por la que trato el despliegue como algo vivo y no como un proyecto con final. Muchos pilotos mueren precisamente porque nadie se ocupa de este ciclo y las excepciones se acumulan hasta ahogar la operación, un patrón que analizo en por qué fracasan los pilotos de IA.

El sitio de las excepciones en el conjunto

El diseño del límite del mandato depende de dos piezas que viven en sus propios artículos: los datos con los que el agente decide, en qué datos necesita un agente —recuerda que un dato peor obliga a un mandato más estrecho y por tanto a más excepciones—; y la conexión a los sistemas por donde llega y sale el caso, en integrar agentes con el ERP. Antes de arrancar, la revisión de madurez de preparar tu empresa para agentes incluye buena parte de este trabajo, que a su vez se enmarca en agentes de IA para empresas.

Preguntas frecuentes

¿Qué se considera una excepción en un agente de IA?

Un caso que cae fuera de lo que el mandato del agente le permite decidir. No es lo mismo que un error: distingo tres orígenes: baja confianza cuando el agente no está bastante seguro, fuera de política cuando el caso excede lo autorizado, y fuera de patrón cuando no se parece a nada conocido. Un agente bien diseñado escala los tres en lugar de adivinar.

¿Cómo se decide qué casos escala el agente y cuáles resuelve?

Con umbrales por tipo de excepción, empezando conservador. Al principio el agente escala mucho y se relaja el control solo donde los datos demuestran fiabilidad, nunca al revés. Bajar el listón hace que el agente resuelva más pero asuma más riesgo. Subirlo lo hace más seguro pero carga a las personas. No hay un número universal.

¿A quién debe escalar un agente una excepción?

A quien pueda resolverla en un paso, por competencia y no por jerarquía: la excepción de crédito a finanzas, la de producto a operaciones, la comercial a quien lleva la cuenta. El objetivo es que el caso no caiga en un buzón genérico del que alguien tenga que repartirlo después.

¿Cómo mejora un sistema de agentes con el tiempo?

Convirtiendo excepciones repetidas en reglas. Cuando un tipo de caso se resuelve siempre igual, ha dejado de ser una excepción y es una regla no escrita: se formula, se prueba contra el histórico y el agente pasa a resolverlo solo. Así el mandato se ensancha con evidencia y la cola de excepciones baja porque se ha aprendido de ella.