Giudicate la proof of concept (POC) di un agente AI sulla base di criteri di successo scritti prima di costruirla, su un insieme fisso di casi reali che comprenda anche quelli difficili. Misurate accuratezza, costo per compito e latenza, verificate a quali dati e strumenti può accedere e come sbaglia, ed estendetela solo se i risultati reggono anche fuori dalla demo.
Una demo convincente non è una prova
Una demo mostra un agente AI al suo meglio, perché gira su esempi che chi l'ha costruito ha scelto e provato. Prima di scalare, la domanda è un'altra: quanto spesso l'agente svolge correttamente il lavoro reale, quanto costa ogni compito e che cosa succede nei giorni in cui sbaglia?
Trattate la POC come un esperimento che si chiude con una decisione: estendere, modificare o fermarsi. Questa decisione richiede criteri scritti prima che arrivino i risultati; altrimenti quasi qualsiasi risultato può sembrare promettente.
Scrivete i criteri di successo prima di costruire l'agente
Definite che cosa significa «abbastanza buono» per il business, poi traducetelo in numeri misurabili. Per un agente che smista le richieste di assistenza potrebbero essere la quota di richieste inviate al team giusto, la quota che rifiuta correttamente di gestire e il tempo che una persona impiega a controllarle una per una.
- Il tasso di successo su casi realistici, con una definizione scritta di risultato corretto
- Gli errori che potete tollerare e quelli che non potete accettare, come una risposta sbagliata inviata a un cliente
- Il costo per compito portato a termine, compresi l'uso del modello e il tempo della persona che controlla il lavoro
- Un tempo di risposta adatto al processo, a seconda che qualcuno stia aspettando la risposta o no
- Il punto di riferimento: quanto tempo richiede oggi il compito alle persone, e quanto spesso lo svolgono correttamente
Testate su un set di valutazione fisso costruito da casi reali
Raccogliete input reali dal vostro storico, annotate il risultato corretto per ciascuno e mantenete il set invariato. Includete casi facili, ambigui, rari e qualcuno che l'agente dovrebbe rifiutare. Un set più piccolo di casi ben scelti vi dice più di un set grande di casi facili.
Fate girare l'agente sull'intero set ogni volta che cambiano il prompt, il modello, gli strumenti o i dati, e confrontate i risultati con l'esecuzione precedente. Gli output di un modello variano da un'esecuzione all'altra: eseguite ogni caso più di una volta e guardate la costanza, non solo la risposta migliore. Tenete i casi fuori dal prompt e da qualsiasi esempio che l'agente vede, altrimenti il punteggio lo favorirà.
Controllate anche come assegnate i punteggi. I controlli automatici funzionano per gli output strutturati. Il testo libero di solito richiede una persona, oppure un secondo modello i cui giudizi avete confrontato con quelli di una persona su un campione.
Misurate costi e latenza ai volumi previsti
Una POC che gestisce qualche decina di richieste al giorno può nascondere costi che pesano quando le richieste diventano migliaia. Registrate le chiamate al modello, i token e le chiamate agli strumenti per compito, e il tempo richiesto da ogni compito. Gli agenti che vanno in loop, ritentano o leggono documenti lunghi possono costare molto più della media su certi input: studiate i casi più lenti e più costosi, non solo la media.
Poi proiettate il costo sui volumi previsti e confrontatelo con quanto costa oggi il lavoro, compreso il tempo che le persone continueranno a dedicare alla revisione. Fissate limiti rigidi per compito su passaggi, token e tempo, così un solo input problematico non può far lievitare la bolletta. L'OWASP Top 10 for LLM Applications classifica questo rischio come consumo illimitato (unbounded consumption).
Progettate la revisione umana con intenzione, poi misuratela
La revisione umana fa parte della progettazione, non è una rete di sicurezza temporanea. Decidete quali azioni l'agente può compiere da solo, quali può solo proporre e quali non deve compiere mai. Tutto ciò che è irreversibile o visibile ai clienti, come inviare un messaggio, modificare un record o spendere denaro, dovrebbe attendere l'approvazione di una persona finché l'agente non ha alle spalle una lunga esperienza affidabile.
Misurate la revisione stessa: quanto tempo richiede, quanto spesso chi revisiona modifica l'output e quanto spesso approva senza controllare davvero. Se revisionare richiede quasi lo stesso tempo che svolgere il compito, l'agente non fa ancora risparmiare tempo. Se il vostro caso d'uso potrebbe rientrare tra i sistemi ad alto rischio secondo il regolamento europeo sull'intelligenza artificiale (AI Act), una sorveglianza umana efficace è un obbligo di legge ai sensi dell'articolo 14, non una preferenza di progettazione: coinvolgete presto i vostri consulenti legali.
Fissate i limiti su dati e sicurezza prima di scalare
Scalare porta più dati, più utenti e più strumenti, ed è allora che i limiti deboli cominciano a pesare. L'OWASP Top 10 for LLM Applications mette al primo posto la prompt injection: un testo che l'agente legge, come un'email, un ticket o una pagina web, può contenere istruzioni che lo deviano. Elenca anche l'autonomia eccessiva (excessive agency), cioè più funzioni, permessi o autonomia di quanti ne richieda il compito. Chiarite questi punti prima che il progetto pilota cresca.
- Quali dati l'agente può leggere, e se dati personali o riservati finiscono presso un fornitore di modelli, con quale contratto e quali condizioni di conservazione
- Quali strumenti può chiamare, con i permessi più ristretti e credenziali separate per ogni agente
- Che cosa può modificare, e se ogni modifica può essere tracciata e annullata
- Che cosa viene registrato: ogni chiamata a uno strumento con i suoi input e output, senza far trapelare dati personali
- Come i dati di ogni cliente o team restano separati da quelli degli altri
Studiate come sbaglia, poi decidete
Prima di decidere, leggete gli errori, non solo il punteggio. Suddivideteli per tipo: risposte sbagliate date con sicurezza, rifiuti corretti, passaggi saltati, uso sbagliato di uno strumento, timeout. Un agente che sbaglia chiedendo aiuto è molto più facile da mettere in produzione di uno che sbaglia in silenzio con una risposta plausibile.
Poi decidete. Estendete se i criteri sono soddisfatti sul set di valutazione e se gli errori rimanenti sono di quelli che il vostro processo può assorbire. Restringete il perimetro se l'agente se la cava bene solo su una parte del compito. Fermatevi se non fa meglio del punto di riferimento, e conservate il set di valutazione per il prossimo tentativo. I nostri progetti di agenti AI seguono la stessa sequenza: un compito, esempi reali, revisione da parte del vostro team e più perimetro solo quando l'agente si è guadagnato la fiducia. Se avete una POC da valutare, potete descrivercela tramite il nostro modulo «Avviare un progetto».
Punti chiave
- Scrivete criteri di successo e punto di riferimento prima di costruire l'agente, così il risultato si può giudicare con onestà.
- Testate su un set fisso di casi reali, difficili e ambigui compresi, e rieseguitelo dopo ogni modifica.
- Misurate costo per compito e latenza ai volumi previsti, guardando i casi peggiori oltre alla media.
- Progettate con intenzione la revisione umana e misurate quanto tempo richiede e che cosa intercetta.
- Fissate i limiti su dati, strumenti e log prima di scalare, perché prompt injection e autonomia eccessiva sono rischi noti.
Domande frequenti
Quanti casi servono in un set di valutazione per un agente AI?
Non esiste un numero fisso. Servono abbastanza casi da coprire le principali varianti del compito, quelli difficili e ambigui, e quelli che l'agente dovrebbe rifiutare. Cominciate da ciò che riuscite ad annotare con cura, e aggiungete ogni errore reale che scoprite in seguito.
Un altro modello può valutare le risposte dell'agente?
Sì, per gli output in testo libero difficili da controllare in automatico, ma solo dopo aver confrontato i suoi giudizi con quelli di una persona su un campione di casi. Ricontrollate questa concordanza ogni volta che cambiate il modello o il prompt.
Quando conviene fermare la POC di un agente AI?
Quando, secondo i vostri criteri di successo, non fa meglio del modo attuale di svolgere il compito, oppure quando la revisione che richiede costa tanto tempo quanto ne fa risparmiare. Uno stop netto è un risultato utile: conservate il set di valutazione, perché un modello più recente o un compito più circoscritto potrebbero superarlo in futuro.