Handoffs d'agents d'IA: dissenyar l'escalat a humans

Tots els desplegaments d'agents en què hem treballat han acabat girant al voltant de la mateixa pregunta, i mai no és la que el client esperava. No és què pot fer l'agent. És què fa quan arriba a alguna cosa que no hauria de decidir.

Aquesta pregunta s'ajorna perquè no és atractiva. Una demostració mostra el camí ideal: l'agent llegeix el document, quadra la transacció, envia el recordatori. Ningú no demostra el cas ambigu, així que ningú no el dissenya, i l'agent surt a producció amb l'escalat com una cosa secundària: una cua, un avís per correu, una marca en un registre. Al cap d'un mes aquesta cua té uns centenars d'elements, cap responsable i cap temps de resolució definit. Tècnicament, l'agent funciona. El procés, no.

El disseny del handoff és la diferència entre un agent que redueix feina i un que la trasllada de lloc. El trasllat és pitjor que la situació original, perquè almenys un procés manual tenia algú amb responsabilitat a cada pas.

Per què importa

Una cua d'escalats sense resoldre falla de tres maneres alhora, i les tres es reforcen entre si.

La feina no es fa. Els elements d'una cua sense responsable envelleixen. En els processos financers, envellir té conseqüències: una excepció de conciliació sense resoldre es converteix en un retard del tancament, una consulta sobre una factura sense resoldre es converteix en un compte a pagar vençut, una excepció de comanda sense resoldre es converteix en un client que no ha rebut la seva mercaderia.

La confiança en l'agent s'ensorra a partir de les proves equivocades. Quan alguna cosa va mal, la fallada s'atribueix a l'agent tot i que l'agent es va comportar correctament escalant. Qui va fallar va ser el handoff. Però la memòria de l'organització registra "la IA es va equivocar", i això fa més difícil finançar el desplegament següent.

Ningú no aprèn res. Un handoff ben dissenyat produeix informació: quins casos no ha pogut resoldre l'agent, per què, com els ha resolt una persona i si aquesta resolució es podria codificar. Un handoff mal dissenyat produeix una cua. El primer millora l'agent cada mes; el segon garanteix que les mateixes excepcions es repeteixin indefinidament.

Hi ha també una dimensió de governança que importa en entorns regulats i auditats. Si no pot demostrar on és la frontera entre la decisió automatitzada i la humana, i evidenciar que aquesta frontera s'ha mantingut, té una debilitat de control, independentment de si l'agent s'ha equivocat mai.

D'un cop d'ull: els quatre disparadors de handoff

La majoria de les implementacions construeixen el primer i descuiden els altres tres. Els llindars de confiança són els més fàcils de raonar i els menys suficients per si sols. Un agent pot estar completament segur d'una acció que no li correspon gens: pagar una factura per damunt d'un límit delegat, canviar les dades bancàries d'un proveïdor, alliberar una comanda a un client amb el crèdit bloquejat. Això és una frontera d'autoritat, i la confiança hi és irrellevant.

El disparador de conseqüència és el que genera més resistència en els clients, perquè implica escalar deliberadament casos que l'agent probablement resoldria bé. D'això es tracta. Quan el perjudici d'una acció equivocada és gran i asimètric, "probablement bé" no és l'estàndard.

Què funciona i sobre què cal ser honest

Què funciona:

Un responsable humà amb nom per tipus d'escalat, no per cua. "Finances revisa les excepcions" no és responsabilitat. Una persona, amb un suplent, i un temps de resposta definit. Quan el volum ho justifiqui, un torn rotatiu, però sempre resolent-se en un individu.

Escalats que arriben amb el raonament de l'agent adjunt. El determinant individual més gran de la velocitat de resolució. Què intentava fer l'agent, què ha trobat, què ha considerat, per què s'ha aturat i les resolucions candidates ordenades. Un escalat que diu "cal revisió manual" malbarata la feina que l'agent ja havia fet.

Un camí de resolució definit, no només una destinació. Cada tipus d'escalat necessita un responsable, un temps objectiu, un conjunt d'accions i una regla per a què passa quan no es compleix l'objectiu. Sense aquest últim punt, la cua absorbeix les fallades en silenci.

Resolucions retornades com a senyal d'entrenament. Cada resolució humana és o bé un cas que l'agent hauria pogut gestionar amb regles millors, o bé un judici genuí que sempre hauria d'escalar. Classificar les resolucions en aquests dos grups cada mes és el que fa que un agent millori. La majoria dels desplegaments no ho fan mai.

El volum d'escalats com a mètrica monitorada. Importen les dues direccions. Un volum creixent significa que l'agent es degrada o que la distribució de les entrades ha canviat. Un volum decreixent no és automàticament bo: pot significar que els llindars s'han relaxat més enllà del punt segur.

Sobre què cal ser honest:

El disseny de l'escalat costa més que la lògica de quadrament. Sovint és la major part de la construcció. Els clients ho subestimen de manera sistemàtica i és on aterra primer la pressió sobre l'abast. Protegir-ho és el principal factor que distingeix els desplegaments que sobreviuen al segon any.

La detecció d'anomalies és genuïnament difícil. Detectar una fallada és senzill; detectar que un cas no s'assembla a res vist abans no ho és, i cap enfocament actual no és fiable. La mitigació pràctica són fronteres conservadores d'autoritat i de conseqüència, que capturen els casos nous com a efecte secundari.

Les persones deixen de llegir les cues en què no confien. Si una cua conté una proporció alta de no problemes, els revisors comencen a buidar-la mecànicament, i l'excepció genuïna en la posició quaranta es despatxa amb la resta. La precisió de la cua importa més que la seva exhaustivitat.

Alguns escalats no haurien d'anar enlloc. No cal resoldre totes les excepcions. Alguns casos és millor donar-los de baixa, tolerar-los o agrupar-los trimestralment. Enviar-ho tot a una persona tracta totes les excepcions com si mereixessin igualment temps humà, i no és així.

La frontera necessita renegociar-se periòdicament. A mesura que un agent acumula evidència, algunes decisions poden passar de la persona a l'agent, però això ha de ser un canvi deliberat, documentat i revisable, no una deriva de llindars que ningú no ha aprovat.

Marc de decisió: dissenyar el handoff

Recorri'l en ordre. Aturi's a la primera coincidència.

1. Ha deixat per escrit quines decisions no pot prendre mai l'agent?
Comenci aquí, abans de construir. Les fronteres d'autoritat es deriven de la política de delegació, no de la capacitat tècnica, i s'han d'aplicar en la configuració perquè no es puguin creuar amb un canvi de llindar.

2. Té cada tipus d'escalat un responsable individual amb nom i un temps objectiu de resolució?
Si no, assigni tots dos. Un camí d'escalat que acaba en una bústia compartida o en el nom d'un equip no és un camí.

3. Porten els escalats el raonament de l'agent i les resolucions candidates?
Si no, corregeixi la presentació abans d'afinar el quadrament. Sol ser la millora més gran disponible en el temps total de procés i habitualment es passa per alt en favor de la taxa de quadrament.

4. Té una regla definida per quan no es compleix el temps objectiu de resolució?
Si no, defineixi-la: escalar a un segon responsable, avisar un gestor o aplicar una acció per defecte. Sense això, el seu camí d'escalat no té terra.

5. Està classificant les resolucions en "s'hauria d'haver automatitzat" i "escalat correctament"?
Si no, posi en marxa una revisió mensual. Aquest és el mecanisme pel qual millora l'agent, i saltar-se'l vol dir pagar eternament per les mateixes excepcions.

6. Està monitorant el volum i la precisió dels escalats en ambdues direccions?
Instrumenti tots dos. Afegeixi una alerta davant de qualsevol canvi material en qualsevol d'ells, en qualsevol direcció.

7. Té tot l'anterior al seu lloc i la cua continua creixent?
El seu problema és aigües amunt. Una cua que creix de manera persistent significa que la qualitat de les entrades s'està deteriorant o que l'abast de l'agent excedeix el que les seves regles poden suportar; cap dels dos no es resol afegint revisors.

Cost i esforç indicatius

Assumeix un únic agent sobre un procés. Els desplegaments amb diversos agents requereixen una capa addicional que decideixi de quin agent és un escalat, cosa que hi afegeix de manera significativa. Sol·liciti un pressupost per a una estimació delimitada.

Preguntes freqüents

Quin és el llindar de confiança correcte?
No hi ha una resposta general, perquè depèn de l'asimetria de cost entre els seus dos tipus d'error. Quan una acció equivocada és costosa i una acció endarrerida és barata —pagaments a proveïdors, comunicació amb el client—, fixi'l alt. Quan passa el contrari, abaixi'l. Derivi el número de les conseqüències, no de les estadístiques de rendiment de l'agent.

Pot un agent escalar a un altre?
Sí, i sovint és sensat: un agent de documents que passa una discrepància de preu a un agent de comandes. Però tota cadena ha d'acabar en una persona en un nombre limitat de passos, i la cadena ha de quedar registrada d'extrem a extrem. L'escalat circular entre agents és un mode de fallada real i necessita una salvaguarda explícita.

Com evitem que els revisors validin la cua sense mirar-la?
Mantingui la precisió alta perquè la cua sigui majoritàriament genuïna, mantingui el volum dins de la capacitat real, faci visible la responsabilitat individual i auditi una mostra de resolucions. Validar sense mirar és un símptoma d'una cua massa gran o massa sorollosa, no de gent distreta.

Ho ha de veure un auditor?
En entorns auditats, sí: esperi preguntes sobre on és la frontera automatitzat/humà, com s'aplica i com evidencia que s'ha mantingut. Documenti la frontera, el mecanisme d'aplicació i la pista d'auditoria abans que arribi la pregunta.

I si al principi l'agent escala gairebé tot?
Aquest és l'estat inicial correcte. Comenci conservador, reculli evidència i mogui la frontera de manera deliberada. Els desplegaments que comencen permissius i s'ajusten després d'un incident perden una confiança organitzativa difícil de recuperar.

Amb quina rapidesa es pot construir la part de sistemes d'un traspàs com aquest?
Normalment més ràpid que la feina de disseny d'amunt. Un partner certificat com Stacksync pot posar en producció en setmanes la sincronització en temps real de la qual depèn un traspàs d'escalat. La part més lenta és decidir, com cobreix aquest article, exactament quan ha d'aturar-se un agent i a qui traspassa — això és una decisió de política, no d'integració.

Tancament — Passos següents

L'instint amb els agents és mesurar quant gestionen de manera autònoma. La mesura més útil és què passa amb la resta, perquè aquí és on hi ha el risc, d'on ve l'aprenentatge i on el procés o se sosté o es desfà en silenci.

Un punt de partida pràctic sobre un agent que ja està en marxa: prengui una setmana d'escalats i, per a cadascun, identifiqui el responsable, el temps fins a la resolució i si aquesta resolució hauria pogut ser una regla. Si no pot posar nom a un responsable en tots ells, aquesta és la troballa, i importa més que la taxa de quadrament de l'agent.

Sobre l'autor

Bruno Galo és el fundador d'Atypical Tech, una consultora de NetSuite que dona servei a clients mid-market de tota la península Ibèrica. Està especialitzat a connectar sistemes CRM i ERP per a fluxos order-to-cash sense friccions, i a construir pipelines automatitzats de gestió de comandes que eliminen l'entrada manual de dades entre els equips comercials i financers. Com a partner oficial d'implementació de Stacksync, Bruno dissenya i desplega agents d'IA sobre plataformes d'integració per gestionar l'encaminament d'excepcions, el processament de documents i la conciliació, convertint fluxos de comandes fragmentats en sistemes fiables que es supervisen a si mateixos.

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

Fonts

Els URL són a nivell d'editor i s'haurien de verificar abans de la publicació.

• NIST, AI Risk Management Framework — supervisió humana i responsabilitat — https://www.nist.gov/itl/ai-risk-management-framework
• Comissió Europea, EU AI Act — obligacions de supervisió humana — https://digital-strategy.ec.europa.eu
• Comitè Europeu de Protecció de Dades, orientacions sobre decisions automatitzades — https://www.edpb.europa.eu
• COSO, Internal Control — Integrated Framework — disseny de controls i delegació d'autoritat — https://www.coso.org
• Experiència de projectes d'Atypical Tech, desplegaments d'agents en mid-market a la península Ibèrica
• Stacksync, blog de la plataforma d'integració i sincronització en temps real — https://www.stacksync.com/blog