Handoffs de agentes de IA: diseñar el escalado a humanos

Todos los despliegues de agentes en los que hemos trabajado han acabado girando en torno a la misma pregunta, y nunca es la que el cliente esperaba. No es qué puede hacer el agente. Es qué hace cuando llega a algo que no debería decidir.

Esa pregunta se aplaza porque no resulta atractiva. Una demostración muestra el camino ideal: el agente lee el documento, cuadra la transacción, envía el recordatorio. Nadie demuestra el caso ambiguo, así que nadie lo diseña, y el agente sale a producción con el escalado como algo secundario: una cola, un aviso por correo, una marca en un registro. En un mes esa cola tiene varios cientos de elementos, ningún responsable y ningún tiempo de resolución definido. Técnicamente, el agente funciona. El proceso, no.

El diseño del handoff es la diferencia entre un agente que reduce trabajo y uno que lo traslada de sitio. El traslado es peor que la situación original, porque al menos un proceso manual tenía a alguien con responsabilidad en cada paso.

Por qué importa

Una cola de escalados sin resolver falla de tres maneras a la vez, y se refuerzan entre sí.

El trabajo no se hace. Los elementos de una cola sin responsable envejecen. En los procesos financieros, envejecer tiene consecuencias: una excepción de conciliación sin resolver se convierte en un retraso del cierre, una consulta sobre una factura sin resolver se convierte en una cuenta a pagar vencida, una excepción de pedido sin resolver se convierte en un cliente que no recibió su mercancía.

La confianza en el agente se hunde por las pruebas equivocadas. Cuando algo va mal, el fallo se atribuye al agente aunque el agente se comportara correctamente al escalar. Lo que falló fue el handoff. Pero la memoria de la organización registra "la IA se equivocó", y eso hace más difícil financiar el siguiente despliegue.

Nadie aprende nada. Un handoff bien diseñado produce información: qué casos no pudo resolver el agente, por qué, cómo los resolvió una persona y si esa resolución podría codificarse. Uno mal diseñado produce una cola. El primero mejora el agente cada mes; el segundo garantiza que las mismas excepciones se repitan indefinidamente.

Hay además una dimensión de gobierno del dato que importa en entornos regulados y auditados. Si no puede demostrar dónde está la frontera entre la decisión automatizada y la humana, y evidenciar que esa frontera se mantuvo, tiene una debilidad de control, con independencia de que el agente se haya equivocado alguna vez.

De un vistazo: los cuatro disparadores de handoff

La mayoría de las implementaciones construyen el primero y descuidan los otros tres. Los umbrales de confianza son los más fáciles de razonar y los menos suficientes por sí solos. Un agente puede estar completamente seguro de una acción que no le corresponde en absoluto: pagar una factura por encima de un límite delegado, cambiar los datos bancarios de un proveedor, liberar un pedido a un cliente con el crédito bloqueado. Eso es una frontera de autoridad, y la confianza es irrelevante para ella.

El disparador de consecuencia es el que más resistencia genera en los clientes, porque implica escalar deliberadamente casos que el agente probablemente resolvería bien. De eso se trata. Cuando el perjuicio de una acción equivocada es grande y asimétrico, "probablemente bien" no es el estándar.

Qué funciona y sobre qué conviene ser honesto

Qué funciona:

Un responsable humano con nombre por tipo de escalado, no por cola. "Finanzas revisa las excepciones" no es responsabilidad. Una persona, con un suplente, y un tiempo de respuesta definido. Donde el volumen lo justifique, un turno rotatorio, pero siempre resolviéndose en un individuo.

Escalados que llegan con el razonamiento del agente adjunto. El mayor determinante individual de la velocidad de resolución. Qué intentaba hacer el agente, qué encontró, qué consideró, por qué se detuvo y las resoluciones candidatas ordenadas. Un escalado que dice "requiere revisión manual" desperdicia el trabajo que el agente ya había hecho.

Una ruta de resolución definida, no solo un destino. Cada tipo de escalado necesita un responsable, un tiempo objetivo, un conjunto de acciones y una regla para lo que ocurre cuando no se cumple el objetivo. Sin esto último, la cola absorbe los fallos en silencio.

Resoluciones devueltas como señal de entrenamiento. Cada resolución humana es o un caso que el agente podría haber gestionado con mejores reglas, o un juicio genuino que siempre debería escalar. Clasificar las resoluciones en esos dos grupos cada mes es lo que hace que un agente mejore. La mayoría de los despliegues nunca lo hacen.

El volumen de escalados como métrica monitorizada. Importan las dos direcciones. Un volumen creciente significa que el agente se está degradando o que la distribución de entradas ha cambiado. Un volumen decreciente no es automáticamente bueno: puede significar que los umbrales se han relajado más allá del punto seguro.

Sobre qué conviene ser honesto:

El diseño del escalado cuesta más que la lógica de cuadre. Con frecuencia es la mayor parte de la construcción. Los clientes lo subestiman de forma sistemática y es donde primero aterriza la presión sobre el alcance. Protegerlo es lo principal que distingue a los despliegues que sobreviven a su segundo año.

La detección de anomalías es genuinamente difícil. Detectar un fallo es sencillo; detectar que un caso no se parece a nada visto antes no lo es, y ningún enfoque actual es fiable. La mitigación práctica son fronteras conservadoras de autoridad y de consecuencia, que capturan los casos novedosos como efecto secundario.

Las personas dejan de leer las colas en las que no confían. Si una cola contiene una proporción alta de no problemas, los revisores empiezan a vaciarla mecánicamente, y la excepción genuina en la posición cuarenta se despacha con el resto. La precisión de la cola importa más que su exhaustividad.

Algunos escalados no deberían ir a ninguna parte. No toda excepción necesita resolverse. Algunos casos es mejor darlos de baja, tolerarlos o agruparlos trimestralmente. Enviar todo a una persona trata todas las excepciones como si merecieran por igual tiempo humano, y no es así.

La frontera necesita renegociarse periódicamente. A medida que un agente acumula evidencia, algunas decisiones pueden pasar de la persona al agente, pero eso debe ser un cambio deliberado, documentado y revisable, no una deriva de umbrales que nadie aprobó.

Marco de decisión: diseñar el handoff

Recórralo en orden. Deténgase en la primera coincidencia.

1. ¿Ha dejado por escrito qué decisiones no puede tomar nunca el agente?
Empiece aquí, antes de construir. Las fronteras de autoridad se derivan de la política de delegación, no de la capacidad técnica, y deben aplicarse en la configuración para que no puedan cruzarse con un cambio de umbral.

2. ¿Tiene cada tipo de escalado un responsable individual con nombre y un tiempo objetivo de resolución?
Si no, asigne ambos. Una ruta de escalado que termina en un buzón compartido o en el nombre de un equipo no es una ruta.

3. ¿Llevan los escalados el razonamiento del agente y las resoluciones candidatas?
Si no, arregle la presentación antes de afinar el cuadre. Suele ser la mayor mejora disponible en el tiempo total de proceso y se pasa por alto habitualmente en favor de la tasa de cuadre.

4. ¿Tiene una regla definida para cuando no se cumple el tiempo objetivo de resolución?
Si no, defínala: escalar a un segundo responsable, avisar a un gestor o aplicar una acción por defecto. Sin esto, su ruta de escalado no tiene suelo.

5. ¿Está clasificando las resoluciones en "debería haberse automatizado" y "escalado correctamente"?
Si no, ponga en marcha una revisión mensual. Este es el mecanismo por el que mejora el agente, y saltárselo significa pagar eternamente por las mismas excepciones.

6. ¿Está monitorizando el volumen y la precisión de los escalados en ambas direcciones?
Instrumente los dos. Añada una alerta ante cualquier cambio material en cualquiera de ellos, en cualquier dirección.

7. ¿Todo lo anterior está en su sitio y la cola sigue creciendo?
Su problema está aguas arriba. Una cola que crece de forma persistente significa que la calidad de las entradas se está deteriorando o que el alcance del agente excede lo que sus reglas pueden soportar; ninguno de los dos se arregla añadiendo revisores.

Coste y esfuerzo indicativos

Asume un único agente sobre un proceso. Los despliegues con varios agentes requieren una capa adicional que decida qué agente es dueño de un escalado, lo que añade de forma significativa. Solicite un presupuesto para una estimación acotada.

Preguntas frecuentes

¿Cuál es el umbral de confianza correcto?
No hay una respuesta general, porque depende de la asimetría de coste entre sus dos tipos de error. Cuando una acción equivocada es costosa y una acción retrasada es barata —pagos a proveedores, comunicación con el cliente—, fíjelo alto. Cuando ocurre lo contrario, bájelo. Derive el número de las consecuencias, no de las estadísticas de rendimiento del agente.

¿Puede un agente escalar a otro?
Sí, y a menudo tiene sentido: un agente de documentos que pasa una discrepancia de precio a un agente de pedidos. Pero toda cadena debe terminar en una persona en un número acotado de pasos, y la cadena debe quedar registrada de extremo a extremo. El escalado circular entre agentes es un modo de fallo real y necesita una salvaguarda explícita.

¿Cómo evitamos que los revisores validen la cola sin mirar?
Mantenga la precisión alta para que la cola sea en su mayoría genuina, mantenga el volumen dentro de la capacidad real, haga visible la responsabilidad individual y audite una muestra de resoluciones. Validar sin mirar es un síntoma de una cola demasiado grande o demasiado ruidosa, no de gente distraída.

¿Necesita verlo un auditor?
En entornos auditados, sí: espere preguntas sobre dónde está la frontera automatizado/humano, cómo se aplica y cómo evidencia que se mantuvo. Documente la frontera, el mecanismo de aplicación y la pista de auditoría antes de que llegue la pregunta.

¿Y si al principio el agente escala casi todo?
Ese es el estado inicial correcto. Empiece conservador, reúna evidencia y mueva la frontera de forma deliberada. Los despliegues que empiezan permisivos y se ajustan después de un incidente pierden una confianza organizativa difícil de recuperar.

¿Con qué rapidez se puede construir la parte de sistemas de un traspaso como este?
Normalmente más rápido que el trabajo de diseño de arriba. Un partner certificado como Stacksync puede poner en producción en semanas la sincronización en tiempo real de la que depende un traspaso de escalado. La parte más lenta es decidir, como cubre este artículo, exactamente cuándo debe detenerse un agente y a quién traspasa — eso es una decisión de política, no de integración.

Cierre — Próximos pasos

El instinto con los agentes es medir cuánto gestionan de forma autónoma. La medida más útil es qué ocurre con el resto, porque ahí es donde está el riesgo, de donde viene el aprendizaje y donde el proceso o se sostiene o se desmorona en silencio.

Un punto de partida práctico sobre un agente ya en funcionamiento: tome una semana de escalados y, para cada uno, identifique el responsable, el tiempo hasta la resolución y si esa resolución podría haber sido una regla. Si no puede poner nombre a un responsable en todos ellos, ese es el hallazgo, y importa más que la tasa de cuadre del agente.

Sobre el autor

Bruno Galo es el fundador de Atypical Tech, una consultora de NetSuite que da servicio a clientes mid-market en toda la península ibérica. Está especializado en conectar sistemas CRM y ERP para flujos order-to-cash sin fricción, y en construir pipelines automatizados de gestión de pedidos que eliminan la entrada manual de datos entre los equipos comerciales y financieros. Como partner oficial de implementación de Stacksync, Bruno diseña y despliega agentes de IA sobre plataformas de integración para gestionar el enrutamiento de excepciones, el procesamiento de documentos y la conciliación, convirtiendo flujos de pedidos fragmentados en sistemas fiables que se supervisan a sí mismos.

LinkedIn: https://www.linkedin.com/in/brunogd

Fuentes

Las URL son a nivel de editor y deberían verificarse antes de la publicación.

• NIST, AI Risk Management Framework — supervisión humana y responsabilidad — https://www.nist.gov/itl/ai-risk-management-framework
• Comisión Europea, EU AI Act — obligaciones de supervisión humana — https://digital-strategy.ec.europa.eu
• Comité Europeo de Protección de Datos, directrices sobre decisiones automatizadas — https://www.edpb.europa.eu
• COSO, Internal Control — Integrated Framework — diseño de controles y delegación de autoridad — https://www.coso.org
• Experiencia de proyectos de Atypical Tech, despliegues de agentes en mid-market en la península ibérica
• Stacksync, blog de la plataforma de integración y sincronización en tiempo real — https://www.stacksync.com/blog