Valutare un agente AI: compito, strumenti e confini

Un agente dovrebbe raccogliere informazioni da più sistemi e preparare una pratica. Alcuni passaggi sono deterministici, altri richiedono scegliere quale fonte consultare. La verifica risponde a «Quando un agente aggiunge valore rispetto a un workflow esplicito?» per il compito «valutare autonomia, strumenti e verificabilità per un compito limitato», con un owner e un esito osservabile.

Un agente AI si valuta sul compito completo, includendo scelta degli strumenti, rispetto dei confini e stato lasciato dopo un errore. Estende l’evaluation dalla risposta testuale alla traiettoria di azioni e alle conseguenze nei sistemi.

Per «Quando un agente aggiunge valore rispetto a un workflow esplicito?» le precondizioni partono da «obiettivo e criterio di completamento». Una risposta vaga diventa «confrontare con un workflow tradizionale», con owner, evidenza richiesta e data di riesame.

Caso isolato: «azioni reversibili e non reversibili». Operazione osservata: «inserire conferme prima degli effetti». Deviazione forzata: «demo riuscita usata come affidabilità».

Criterio di firma: «azioni reversibili e non reversibili». Un esito orale o non ripetibile lascia aperta la voce. Perimetro della prova: «valutare autonomia, strumenti e verificabilità per un compito limitato».

Controprova: «obiettivo e criterio di completamento». Arresto: «strumenti con privilegi generali». Passo ammesso dopo il recupero: «confrontare con un workflow tradizionale». Verbale finale: «Quando un agente aggiunge valore rispetto a un workflow esplicito?»

Differenza decisiva: «Estende l’evaluation dalla risposta testuale alla traiettoria di azioni e alle conseguenze nei sistemi». Regola di chiusura: «La checklist deve verificare cosa l’agente ha tentato, cosa gli è stato impedito e come il sistema recupera dopo un’azione parziale».

La prova deve lasciare artefatti revisionabili, non soltanto impressioni. Il riferimento «Tool trace, sandbox, action budget, side-effect assertion e recovery test» va controllato su casi normali e su almeno un caso costruito per fallire.

Verificare che un’azione riesca non dimostra che venga negata nel contesto sbagliato; nel perimetro descritto conta «demo riuscita usata come affidabilità». I casi seguenti devono produrre un blocco comprensibile o una revisione, mai un successo silenzioso; il controesempio viene cercato in «inserire conferme prima degli effetti».

Alla chiusura servono: elenco dei casi, versione di dati e configurazione, esito per criterio, errori classificati e decisione dell’owner; la decisione resta collegata a «obiettivo non verificabile». Questo pacchetto permette di ripetere la valutazione dopo una modifica.

Le evidenze devono distinguere qualità del percorso e impatto dell’errore; qui la prova concreta è «demo riuscita usata come affidabilità». Una media positiva non può compensare un singolo comportamento non autorizzato o irreversibile; l’evidenza da conservare è «inserire conferme prima degli effetti».

La checklist deve verificare cosa l’agente ha tentato, cosa gli è stato impedito e come il sistema recupera dopo un’azione parziale. La scelta può essere pass, fail oppure una riduzione del perimetro: tutti e tre gli esiti sono utili se derivano dagli stessi criteri dichiarati prima della prova; il caso operativo si verifica con «azioni reversibili e non reversibili».

La checklist deve verificare cosa l’agente ha tentato, cosa gli è stato impedito e come il sistema recupera dopo un’azione parziale. Prima del pass, allegare l’esito di «richiedere piano e traccia delle azioni», il controllo «possibilità di verificare ogni passaggio» e il test negativo «autonomia senza perimetro»; ciò che manca resta fuori dal perimetro approvato.