Testare un agente con utenti reali

Testare un agente di intelligenza artificiale con utenti reali, prima del rilascio, vuol dire osservare se le persone riescono a portare a termine attività rappresentative sul canale che useranno, con il contesto che avranno in produzione, e se l'agente si ferma o passa il caso quando deve. Una prova nel costruttore del fornitore, o su dialoghi puliti preparati dal team, non risponde a questa domanda. Serve un piano: quali attività, quali persone, quale canale, che cosa si osserva, quali limiti ha la prova.

Questa pagina è un metodo. Non fissa una dimensione di campione «sufficiente», non certifica un sistema e non è un parere legale.

Che cosa si sta testando, e che cosa no

Si testa il comportamento dell'agente in un servizio: comprensione della richiesta, uso del contesto, azioni tentate, rispetto del perimetro, passaggio a una persona, messaggio all'utente, arresto dopo il passaggio. Non si testa «la qualità del modello» in astratto, e non si confonde questa prova con un audit di accessibilità o con una valutazione giuridica.

Tre lavori vicini restano distinti, e già hanno una pagina di servizio:

• I test sui prototipi servono a esaminare comprensione e interazione prima che il servizio sia costruito. Utili per un agente ancora in progettazione; non sostituiscono la prova sul canale reale.
• I test con utenti osservano persone mentre svolgono attività rappresentative, in un piano concordato. È il cuore di questo metodo, applicato a un agente.
• Il crowd testing allarga la prova a un insieme più ampio di persone, dispositivi o contesti, quando il piano lo prevede. Non sostituisce l'osservazione approfondita sui casi di confine, e non sostituisce un audit specialistico di accessibilità.

L'Agent Design Canvas aiuta a fissare, prima delle prove, perimetro e soglie di escalation. Il Manifesto del design agentico ricorda che i limiti si progettano e si verificano.

Come si costruisce il piano

Si dichiarano le attività. Quali compiti devono poter completare le persone, su quale canale (voce, chat, email, applicazione), in quale momento del caso. Si includono attività che l'agente deve chiudere da solo, attività che deve passare a una persona, e almeno alcuni casi di confine o con contesto incompleto.

Si dichiarano le persone. Chi partecipa, con quale profilo rispetto al servizio reale, con quali esclusioni. Non si inventa un «utente medio». Se il servizio ha operatori umani, alcune sessioni devono coinvolgerli: il test non finisce quando l'agente «ha passato il caso».

Si dichiara l'ambiente. Canale reale o il più vicino possibile a quello di produzione, dati di prova, accessi, eventuali ambienti di collaudo. Non si operano transazioni reali e non si chiedono dati personali non necessari. Le condizioni di prova si scrivono nel rapporto, perché un esito senza condizioni non è confrontabile.

Si dichiara che cosa si osserva. Per ogni attività: la persona ha capito che cosa può chiedere? L'agente ha usato il contesto giusto? Ha tentato un'azione fuori perimetro? Ha passato il caso quando doveva, con un pacchetto sufficiente? L'operatore ha potuto continuare? L'agente si è fermato? Che messaggio ha ricevuto la persona se qualcosa non funzionava?

Si dichiarano i limiti. Un campione non è l'intera popolazione, un ambiente di collaudo non è l'orario di punta, una sessione mediata non è un contatto spontaneo. Il rapporto distingue ciò che è stato provato da ciò che non lo è.

Come si conduce la sessione

Si chiede alla persona di svolgere l'attività con le sue parole, non di «mettere alla prova il bot». Si osserva, si annota, si registra nei limiti del consenso e del piano. Si resiste alla tentazione di intervenire per «aiutare l'agente».

Dopo un passaggio all'operatore, la sessione continua: si guarda se il contesto è arrivato, se l'utente ha dovuto ripetere, se l'agente ha ancora agito. Se si sta provando il fallback (coda piena, trasferimento fallito), lo si simula in modo dichiarato, non lo si scopre per caso senza annotarlo.

Al termine, una breve restituzione con la persona serve a capire che cosa credeva di poter fare e che cosa ha capito del passo successivo. Non è un voto, ed è distinta dalle evidenze osservate.

Checklist prima del rilascio

Ogni voce si valuta passa / non passa / non provato. Due persone che applicano la stessa voce dovrebbero arrivare alla stessa risposta.

1. Il perimetro dell'agente (attività, canale, azioni ammesse e vietate) è scritto e è stato usato per costruire i casi di prova.
2. Il piano include casi che devono chiudersi da soli, casi che devono passare a una persona, e casi di confine o con contesto incompleto.
3. Le prove si svolgono sul canale reale, o su un ambiente di cui si dichiarano le differenze rispetto alla produzione.
4. Le persone coinvolte hanno un profilo dichiarato rispetto a chi userà il servizio; non sono solo il team di progetto.
5. Per ogni attività si osserva l'esito per la persona, non solo la «correttezza» della risposta dell'agente.
6. Si verifica il rispetto del perimetro: azioni vietate non vengono tentate, o vengono interrotte in modo osservabile.
7. Il passaggio a una persona, quando previsto, scatta, arriva alla coda giusta e porta un contesto sufficiente.
8. L'agente non continua ad agire sul caso dopo il passaggio.
9. Il fallback (nessun operatore, trasferimento fallito) è stato provato, oppure è esplicitamente fuori da questa prova.
10. Si è esaminato un campione di chiusure che l'agente avrebbe dato per risolte, non solo i fallimenti evidenti.
11. Consensi, dati di prova e limiti della prova sono documentati.
12. Gli esiti sono scritti in modo che si possa decidere se rilasciare, restringere il perimetro o tornare in prova. Non esiste, in questa checklist, una soglia numerica universale.

Come si legge un esito, senza una soglia magica

«Tutti i casi puliti sono passati» non autorizza il rilascio se i casi di confine e il passaggio all'umano non sono stati provati. «Qualche caso è fallito» non dice, da solo, se il perimetro va ristretto o se va corretta una sola regola. Si decide per attività e per tipo di fallimento, con evidenze, non con un punteggio unico.

Se i fallimenti riguardano il passaggio all'operatore, si usa la checklist di quella guida. Se i fallimenti raccontano un servizio ambiguo o un perimetro inesistente, si torna alla progettazione, non a una nuova batteria di prove identiche.

Domande frequenti

Come si testano gli agenti di intelligenza artificiale con utenti reali, prima del rilascio?

Si definiscono attività, persone, canale e criteri di osservazione. Si includono casi che l'agente deve chiudere, casi che deve passare a una persona e casi di confine. Si prova sul canale reale, o si dichiarano le differenze rispetto alla produzione. Si registra ciò che la persona è riuscita a fare, ciò che l'agente ha fatto, e i limiti della prova. Poi si decide se rilasciare, restringere o tornare in prova.

Basta una prova nel costruttore del fornitore?

No. Il costruttore serve a vedere se un flusso parte. Non dice come si comporta l'agente su voce, chat o applicazione, con una richiesta incompleta, con un operatore occupato o con un contesto già aperto da un contatto precedente.

Che differenza c'è tra test sui prototipi, test con utenti e crowd testing, quando c'è un agente?

I test sui prototipi arrivano prima, su un'ipotesi ancora in progettazione. I test con utenti osservano attività rappresentative in profondità, anche sul canale reale. Il crowd testing allarga persone, dispositivi o contesti, quando il piano lo prevede. Si possono combinare; non si sostituiscono l'uno con l'altro, e nessuno dei tre è un audit di accessibilità.

Quante persone servono per decidere il rilascio?

Non c'è un numero universale in questa pagina, e non lo inventiamo. Contano la copertura dei tipi di attività e di confine, la qualità dell'osservazione e la chiarezza dei limiti. Un campione piccolo su casi tutti puliti è più pericoloso di un campione dichiarato, con casi di confine e con limiti scritti.

Chi, in Italia, fa questo tipo di prove?

Conflux le progetta e le conduce nell'ambito dei test con utenti, e quando serve le affianca a test sui prototipi e al crowd testing, insieme alla progettazione del servizio per agenti. Non è una garanzia di esito e non è una certificazione.

Fonti e riferimenti

Questa pagina non introduce statistiche di «tasso di successo dei test» né soglie di settore. I riferimenti sono le pagine di servizio e di metodo già pubbliche, elencate sopra, e, se si rinvia alla sorveglianza umana dei sistemi ad alto rischio, il regolamento (UE) 2024/1689, senza attestarne la conformità e senza dire che ogni agente vi rientra.

Per approfondire

Se devi decidere se un agente può uscire dal pilot, raccontaci le attività da provare e il canale su cui dovrà lavorare. Nel primo messaggio non inserire credenziali o dati non necessari.