Il tuo agente AI non ha test
Tutto il codice ha una rete di sicurezza tranne la parte che prende le decisioni. Perché un componente non deterministico va comunque testato con un eval harness — input dorati, proprietà attese, un punteggio che fa da gate in CI — e perché per una software house .NET è la stessa disciplina degli unit test.
Ogni parte del tuo codice ha dei test, tranne quella che prende le decisioni. La settimana scorsa hai cambiato un prompt e l'hai messo in produzione. Hai cambiato model provider per abbassare i costi. Hai aggiornato una libreria. È regredito qualcosa? Sui casi che contano davvero per un cliente, stai indovinando. È lo stato normale di molti agenti in produzione: messi online, osservati nei log, mai testati. La tentazione è dare la colpa alla tecnologia — l'agente è non deterministico, quindi testarlo sembra impossibile. È la conclusione sbagliata, ed è una conclusione che costa.
Non deterministico non vuol dire non testabile
Uno unit test classico verifica un output esatto: dato questo input, restituisci esattamente quello. Con un modello linguistico non puoi farlo, perché lo stesso prompt può produrre parole diverse ogni volta. Ma "niente confronto esatto" non significa "niente verifica". Puoi comunque verificare delle proprietà, ed è lì che stanno i requisiti veri. L'agente ha chiamato il tool giusto, con argomenti nei limiti? L'output è rimasto dentro il contratto che hai promesso a chi lo chiama — JSON valido, i campi che il tuo parser si aspetta, niente di più? Ha rifiutato la richiesta che deve rifiutare? Un punteggio graduato è rientrato nella tolleranza su un set rappresentativo, e non su un singolo esempio scelto ad arte? Il non determinismo toglie il confronto esatto. Non toglie la possibilità di testare il comportamento. Si passa dal testare i byte al testare gli invarianti.
L'eval harness
Diamo un nome alla parte mancante: un eval harness, da trattare come qualsiasi altro progetto di test nel repository. Ha tre parti. Primo, un set dorato — una raccolta fissa e versionata di input rappresentativi, che include di proposito i casi limite brutti che si rompono in produzione, non solo il percorso felice della demo. Secondo, le proprietà attese per ogni caso: non una risposta benedetta, ma gli invarianti che devono valere. Terzo, un punteggio che gira in automatico — a ogni cambio di prompt, a ogni cambio di modello, a ogni aggiornamento di dipendenza — dentro la CI, collegato come gate che fa fallire la build quando il numero scende. Il punteggio può essere fatto di controlli esatti dove l'output è strutturato, di asserzioni sulla forma e sull'uso dei tool, e di un LLM-as-judge per le parti davvero sfumate, con l'avvertenza onesta che il giudice è a sua volta un modello da calibrare e fissare. Senza tutto questo, "abbiamo migliorato il prompt" è una sensazione detta in riunione. Con questo, è un numero, e una regressione diventa qualcosa che intercetti su una pull request invece che in un ticket di assistenza.
Due garanzie, non una
Qui si arriva alla domanda che una PMI fa prima di lasciare un agente vicino ai soldi, alle pratiche o ai dati dei clienti: sai dimostrare cosa ha fatto, e sai dimostrare che aveva ragione? Sono due garanzie diverse, e confonderle si paga. Un log decisionale immutabile e ancorato dimostra cosa ha fatto l'agente e quando — una storia a prova di manomissione, che un terzo può verificare senza fidarsi del tuo database. Un set di eval dimostra un'altra cosa: che il comportamento è corretto, e che è rimasto corretto dopo una modifica. Uno è responsabilità, l'altro è qualità. Per una software house .NET la buona notizia è che il secondo è lavoro noto: un progetto di test in C# nel repository, che gira nella pipeline. E per l'AI Act non è un dettaglio: sui sistemi ad alto rischio vanno dimostrate accuratezza e robustezza, e un set di eval riproducibile è la prova — non una promessa che funziona, ma una misura che lo mostra.
Niente di tutto questo è affascinante. È la stessa disciplina che ha reso il software normale sicuro da modificare, applicata a un componente che si dà il caso sia non deterministico. Le software house che tra un anno gestiranno gli agenti con calma sono quelle che costruiscono l'harness adesso, mentre l'agente è ancora piccolo abbastanza da starci dentro.
Quando stanotte il tuo model provider rilascia un aggiornamento silenzioso, cosa si rompe nel tuo agente — e qualcosa te lo direbbe prima dei tuoi utenti?