El concepte de human-in-the-loop (HITL) ha guanyat popularitat amb l'arribada dels agents d'intel·ligència artificial. No obstant això, moltes implementacions es queden en la superficialitat: afegir un botó d'aprovació a una interfície i assumir que això garanteix seguretat i control. La realitat és que un botó no dissenya un camí d'aprovació; només captura un clic. Perquè la supervisió humana sigui realment efectiva, l'aprovació s'ha de convertir en un patró arquitectònic que defineixi abast, caducitat, encaminament, evidència i responsabilitat. Des de Q2BSTUDIO, com a empresa de desenvolupament de programari i tecnologia, sabem que la diferència entre una demo i un sistema productiu està en els detalls de disseny que sovint es passen per alt.
Quan un agent d'IA pot modificar un ticket, enviar un missatge a un client, reiniciar un servei, canviar una regla de tallafocs o eliminar dades, l'aprovació deixa de ser una característica d'interfície d'usuari i es converteix en part del pla de control. La pregunta correcta no és 'on posem el botó d'aprovar?', sinó 'quina decisió està prenent realment la persona?'. Si la sol·licitud d'aprovació és vaga —com 'l'agent vol actualitzar la configuració'— el revisor no està aprovant una acció, està aprovant un resum del que el sistema diu que farà. Això és un control feble i perillós.
Un camí d'aprovació seriós ha de respondre preguntes pràctiques com: què s'aprova exactament? Quant temps és vàlida l'aprovació? Què passa si ningú respon? On van les excepcions? Qui és el responsable de la decisió? Sense aquestes respostes, l'humà no està realment al bucle; està a prop del bucle, però no al comandament.
L'aprovació ha d'actuar com un límit entre l'acció proposada per l'agent i l'execució autoritzada. Aquest límit separa tres capes: la capa de raonament de l'agent (planifica, resumeix, recomana), la capa de política i aprovació (classifica risc, verifica abast, registra la decisió) i la capa d'execució d'eines (força els payloads aprovats, executa accions i registra resultats). L'agent no ha de ser l'autoritat final sobre si la seva pròpia acció és segura; l'humà no ha de tenir que reconstruir l'acció a partir d'un resum vague; l'eina no ha d'executar res fora del límit aprovat.
L'arbre de decisió d'aprovació s'ha de situar entre la proposta de l'agent i l'execució. Aquí és on el sistema classifica l'acció, verifica la política, valida l'evidència, gestiona els temps d'espera i encamina excepcions abans que l'eina toqui el sistema destí. És important notar que l'aprovació humana no ocorre primer. Abans que un revisor vegi res, el sistema ja ha classificat l'acció, verificat la política i determinat si l'aprovació és fins i tot apropiada. Això evita que l'aprovació es converteixi en un mer segell de goma i prevé un error comú: demanar a humans que aprovin coses que el sistema hauria d'haver denegat automàticament.
L'abast de l'aprovació és el punt més feble en molts dissenys. Una sol·licitud d'aprovació ha de definir amb precisió l'acció, l'entorn, l'eina i els paràmetres. Per exemple, 'aprovar que l'agent reiniciï api-worker-03 en producció durant l'incident INC-10482, utilitzant l'eina restart_service, en els pròxims 10 minuts, sense permetre canvis de configuració' és un abast clar i vinculant. En canvi, 'aprovar que l'agent arregli el problema de l'API' deixa massa marge d'interpretació. L'objectiu no és alentir tot, sinó assegurar que l'aprovació es correspongui amb una acció específica que el sistema pugui fer complir.
El moment de l'aprovació també és crític. Si ocorre massa d'hora, s'aprova un pla general abans de conèixer el payload real de l'eina. Si ocorre massa tard, l'agent ja pot haver recopilat dades sensibles o desencadenat efectes secundaris. El punt de major valor sol ser just abans de l'execució de l'efecte secundari, quan el revisor pot veure l'eina proposada, l'objectiu, el payload, la classificació de risc, l'evidència i l'impacte esperat. A Q2BSTUDIO, en implementar solucions d'IA, dissenyem aquests fluxos d'aprovació com a part integral de l'arquitectura, integrant-los amb sistemes de ticketing, gestió d'incidents i registre d'auditoria.
El comportament de temps d'espera és un altre aspecte que sovint es descuida. Un agent en pausa no és automàticament segur: pot estar retenint estat, bloquejant un flux de treball o preservant una acció que es torna obsoleta. Un bon camí d'aprovació defineix el TTL de la sol·licitud, la frescor de l'evidència, l'acció per defecte (denegar, expirar, escalar) i la ruta d'escalat. El valor per defecte rarament ha de ser 'continuar de totes maneres'. Depenent del context operatiu, un reemborsament en atenció al client pot expirar després de 30 minuts, mentre que una acció de contenció en seguretat pot escalar al comandant d'incidents després de cinc minuts.
L'encaminament d'excepcions no es pot limitar a 'enviar al cap'. Diferents excepcions necessiten diferents propietaris: un conflicte de política ha d'anar a seguretat o govern; una exposició de dades sensibles, al responsable de dades; una urgència en producció, al comandant d'incidents. La ruta s'ha de basar en el motiu pel qual l'aprovació no pot continuar normalment. Això connecta el HITL amb els models operatius empresarials existents, i és precisament on empreses com Q2BSTUDIO aporten valor, integrant l'aprovació en processos de canvi, identitat i compliment normatiu.
Un disseny feble d'aprovació crea una perillosa il·lusió de control. El sistema demana a un humà que aprovi alguna cosa vaga, aquest fa clic, l'agent actua, alguna cosa es trenca, i llavors tots assenyalen el registre d'aprovació dient que l'humà va acceptar el risc. Això no és governança; és transferència de culpa. Un bon camí d'aprovació fa que la decisió sigui significativa: mostra al revisor què passarà, proporciona evidència, imposa l'abast aprovat, registra la regla de política i captura el resultat. El sistema d'aprovació ha de provar quina acció es va proposar, quina política va requerir aprovació, quina evidència estava disponible, qui va aprovar o rebutjar, quin abast es va aprovar, quant de temps va ser vàlid, què es va executar realment i si el resultat va coincidir amb la intenció aprovada.
La maduresa en la implementació d'agents d'IA sol seguir una progressió: primer, anàlisi només lectura (sense aprovació); després, accions redactades que l'humà edita i envia manualment; després, execució acotada de baix risc amb política automàtica; més tard, execució d'alt impacte després de revisió amb evidència; després, autonomia basada en polítiques amb monitoratge continu; i finalment, fluxos d'emergència amb aprovació elevada i caducitat curta. L'objectiu no és mantenir humans a cada pas per sempre, sinó utilitzar el judici humà on realment canvia el resultat del risc, mentre s'utilitza política i automatització en la resta.
A Q2BSTUDIO, desenvolupem aplicacions a mida que integren agents d'IA amb camins d'aprovació robustos, aprofitant el núvol (AWS/Azure) per a escalabilitat, ciberseguretat per protegir els límits, i eines de BI com Power BI per monitoritzar i auditar cada decisió. El nostre enfocament combina la intel·ligència artificial amb l'experiència en desenvolupament de programari per crear sistemes on la supervisió humana no és un adorno, sinó un component dissenyat amb precisió. Perquè, al final, la pregunta pràctica no és 'vam posar un humà al bucle?', sinó 'pot aquest camí d'aprovació provar qui va aprovar què, sota quina política, per a quina acció, contra quin sistema, i què va passar després?' Si la resposta és sí, l'agent està llest per actuar. Si la resposta és no, el botó no és suficient.
