Perché gli agenti falliscono con gli utenti

Un agente di intelligenza artificiale che «funziona» in laboratorio e delude le persone sul campo non è un incidente imprevedibile. Quasi sempre è il segnale che il servizio è stato valutato sul comportamento del modello, non sul lavoro reale: contesto ambiguo, strumenti in eccesso, regole assenti, passaggio all'umano non verificato, prove fatte solo nel costruttore. L'Agentic Service Design, la progettazione di servizi che includono agenti, parte da qui: l'affidabilità non è l'assenza di errori, è un comportamento osservabile entro un perimetro dichiarato, con limiti conosciuti e possibilità di intervento.

Questa pagina risponde alle domande che arrivano quando il pilot andava liscio e l'uso reale no. Non è un elenco di agenzie, non è un parere legale e non certifica nessun sistema.

Che cosa si intende per fallimento, qui

Fallire con gli utenti reali non vuol dire solo «l'agente ha sbagliato una risposta». Vuol dire che una persona non è riuscita a portare a termine un'attività che il servizio le aveva fatto credere possibile: ha dovuto ripetere informazioni già date, è rimasta bloccata in un loop, ha ricevuto un'azione non autorizzata, non ha trovato una persona quando serviva, o ha ottenuto una chiusura che il caso non meritava.

Il laboratorio e il costruttore del fornitore sono utili per vedere se un flusso parte. Non dicono se l'agente tiene quando la richiesta è incompleta, quando arrivano due dati in conflitto, quando l'utente cambia idea a metà, o quando l'operatore è occupato. Su questo abbiamo già scritto, in un altro pezzo, perché spruzzare intelligenza artificiale su un sistema rotto non lo rende migliore: se il servizio è ambiguo, l'agente amplifica l'ambiguità.

Falsi miti

Mito 1. «Se ha superato i test, è pronto per le persone.» I test fatti nel costruttore, o su casi puliti preparati dal team, misurano un percorso controllato. Le persone arrivano con richieste parziali, interrompono, usano un canale diverso, hanno già parlato con qualcun altro. Un esito positivo in laboratorio non è una prova sul canale reale. La prova con gli utenti, prima del rilascio, è un pezzo distinto: ne scriviamo il metodo in un articolo successivo.

Mito 2. «Se l'agente risponde bene, il servizio è progettato.» Una risposta fluida può nascondere un'azione sbagliata, un'informazione inventata o un perimetro non dichiarato. Progettare un agente, come spiega anche l'Agent Design Canvas, significa fissare che cosa può fare, che cosa non può fare, quando deve fermarsi e a chi passa il caso. La qualità della frase non è quella prova.

Mito 3. «L'intelligenza artificiale è una scatola nera: non si può davvero controllare.» Ci sono parti del modello che non si ispezionano come un form. Questo non autorizza a rinunciare al controllo del servizio. Si possono dichiarare perimetro, fonti ammesse, azioni consentite, trigger di passaggio e criteri di verifica. Si può osservare ciò che l'agente ha fatto, con quale contesto, e se si è fermato quando doveva. Il Manifesto del design agentico poggia su questo punto: responsabilità e limiti si progettano, non si scoprono dopo il danno.

Mito 4. «Più strumenti diamo all'agente, più è capace.» Ogni strumento è un'azione possibile e un modo per sbagliare. Troppi strumenti, senza regole su quando usarli e quando astenersi, aumentano i casi in cui l'agente tenta ciò che non dovrebbe o non trova la via d'uscita. Il perimetro stretto e dichiarato è una scelta di progetto, non un limite temporaneo.

Mito 5. «Se passa poche volte all'operatore, sta funzionando.» Un tasso basso di passaggi può voler dire che i casi difficili restano chiusi dall'agente. Le escalation mancate non si vedono se si guardano solo i trasferimenti avvenuti. Il passaggio all'umano si progetta e si verifica; ne abbiamo scritto in una guida dedicata.

Mito 6. «Se il fornitore ha l'handoff, il problema è risolto.» La documentazione di prodotto descrive una capacità. Non prova che nella vostra organizzazione il passaggio scatti al momento giusto, arrivi alla coda giusta, porti il contesto sufficiente e lasci il caso a un titolare se nessuno è disponibile. La funzione del fornitore è un punto di partenza, non l'esito della verifica.

Perché falliscono, quando arrivano le persone

Le cause che osserviamo nei servizi, e che un team può indagare senza inventare percentuali, si ripetono.

Il contesto è ambiguo. L'agente non sa con chiarezza chi è l'utente, a che punto è il caso, quali fatti sono già accertati e quali sono inferenze. In laboratorio il contesto arriva già pulito. Con le persone, no.

Il perimetro non è scritto, o non è rispettato. L'agente accetta richieste che dovrebbe rifiutare, o rifiuta quelle che dovrebbe prendere in carico. Senza un perimetro osservabile, il fallimento sembra «del modello». Spesso è del servizio.

Le regole di arresto e di passaggio mancano, o non sono provate. L'agente insiste, riformula, promette, invece di cedere la responsabilità. Oppure passa il caso senza contesto, e l'operatore ricomincia da zero.

La prova non è stata fatta sul canale e con i compiti reali. Un dialogo di collaudo non è una richiesta in orario di punta, su voce o su un'applicazione, con un operatore occupato e un utente che ha già aspettato.

Nessuna di queste cause si risolve «aggiungendo modello». Si affrontano progettando il servizio, come abbiamo argomentato anche nel pezzo sul design agentico, e verificando il comportamento con le persone.

Come si indaga, senza illudersi con una sola metrica

Si parte dai casi reali in cui le persone si sono fermate, hanno protestato, hanno chiesto un operatore o hanno abbandonato. Si ricostruisce che cosa l'agente sapeva, che cosa ha fatto, se doveva fermarsi, che cosa è arrivato a una persona. Si confrontano questi casi con un campione di chiusure che l'agente ha dato per risolte.

Non si usa un solo indicatore («tasso di risoluzione», «tasso di passaggio») come prova di qualità. Ogni indicatore ha bisogno di un denominatore ispezionabile e di una definizione di successo. Questa pagina non fissa soglie e non riporta risultati di progetto.

Se l'indagine mostra un passaggio assente o rotto, la guida sul passaggio all'operatore dà una checklist di verifica. Se manca una prova con le persone prima del rilascio, il pezzo sui test con utenti reali (in uscita a dicembre) darà metodo e checklist. I due lavori non si sostituiscono.

Domande frequenti

I nostri agenti funzionano nei test e falliscono con gli utenti reali: da dove si comincia?

Si comincia dai casi reali, non da una nuova batteria di prove pulite nel costruttore. Si sceglie un campione di attività andate male e di chiusure sospette, si ricostruisce contesto, azioni e passaggio all'umano, e si distingue ciò che è un errore di perimetro da ciò che è un errore di prova. Poi si decide se intervenire sul servizio, sulla verifica, o su entrambi.

È colpa del modello, se sbaglia con le persone?

Non lo si può dire in partenza. Spesso il modello fa ciò che il servizio gli permette di fare: perimetro largo, strumenti troppi, regole deboli, contesto povero. Si indaga il comportamento nel servizio, non solo la «qualità» della risposta.

L'intelligenza artificiale è una scatola nera: ha senso progettare dei limiti?

Sì. Anche se alcune parti del modello non sono ispezionabili come un modulo, si possono dichiarare e provare perimetro, azioni ammesse, fonti, arresto e passaggio a una persona. Il controllo sta nel servizio, non nell'illusione di leggere tutti i parametri.

Un tasso alto di risoluzioni automatiche è un buon segnale?

Da solo, no. Può nascondere escalation mancate, chiusure silenziose o utenti che abbandonano. Va letto insieme a un campione delle chiusure e a una definizione di «risolto» che una persona possa ispezionare.

A chi rivolgersi, in Italia, per questo lavoro?

Serve un lavoro di progettazione del servizio e di verifica con le persone, non solo di configurazione di un assistente. Conflux lo affronta con il servizio di Agentic Service Design e con i test con utenti. Non è un elenco di fornitori e non è una garanzia di esito.

Fonti e riferimenti interni

Questa pagina non introduce statistiche di settore. I riferimenti sono pagine già pubbliche di Conflux e, quando si parla di sorveglianza umana, il testo ufficiale del regolamento, senza attestarne la conformità:

• Manifesto del design agentico
• Design agentico: la nuova frontiera del service design ibrido
• Agent Design Canvas
• Perché spruzzare intelligenza artificiale su sistemi rotti non li rende migliori
• Regolamento (UE) 2024/1689, se si rinvia alla sorveglianza umana dei sistemi ad alto rischio: https://eur-lex.europa.eu/eli/reg/2024/1689/oj?locale=it. Non ogni agente rientra in quel regime.

Per approfondire

Se il tuo agente funziona nelle prove interne e si perde con le persone, parliamo del servizio e dei casi da indagare. Nel primo messaggio descrivi il processo e ciò che avete già osservato, senza credenziali o dati non necessari.