Quando il codice viene prodotto più velocemente e alcune parti del sistema cessano di essere deterministiche, la verifica diventa essenziale: diventa l'unico modo per sapere se qualcosa funziona. L'intuizione opposta – "se l'IA scrive codice migliore, sarà necessario meno controllo qualità" – confonde due cose distinte: la correttezza sintattica di ciò che viene scritto e la sua idoneità per il business.
Un modello produce codice che si compila e fa qualcosa di ragionevole. Non sa se quel qualcosa è ciò di cui la tua azienda ha bisogno, perché quell'informazione non è nel codice: è nel processo, nei regolamenti e nelle eccezioni che nessuno ha scritto.
I sistemi attuali combinano componenti deterministiche e probabilistiche, e ciascuna viene verificata in modo diverso. Confonderle è la causa della maggior parte dei problemi di produzione.
|
Aspetto |
componente deterministica |
Componente probabilistica |
|---|---|---|
|
Cosa viene controllato? |
Che il risultato sia quello atteso. |
Che il risultato sia accettabile abbastanza spesso |
|
Risultato del test |
Superato o non superato |
Distribuzione della qualità su un insieme |
|
Quando funziona |
In ogni cambiamento |
Ad ogni modifica e periodicamente nella produzione |
|
Cosa rileva |
Regressioni |
Regressioni e deriva comportamentale |
|
Chi definisce i criteri? |
Il team tecnico |
Attività commerciali, con valutazione di casi di studio reali. |
La riga più importante è l'ultima. In termini di probabilità, il criterio "corretto" non può essere stabilito solo dal team tecnico, perché dipende da ciò che l'azienda considera accettabile: un riepilogo che omette un'informazione secondaria può essere perfetto in un contesto e inaccettabile in un altro.
Ecco perché la risorsa più preziosa di un progetto di IA non è il modello o il prompt: è l'insieme dei casi valutati, con la risposta che l'organizzazione ritiene corretta per ciascuno. Questo insieme resiste ai cambiamenti dei fornitori, consente un confronto obiettivo delle alternative e rileva se una nuova versione ha peggiorato qualcosa. È l'elemento che permette di cambiare modello senza timore.
Quando il team scriveva tutto il codice manualmente, la revisione tra pari copriva una buona parte della verifica. Con un volume maggiore, tale copertura si diluisce: non perché i revisori siano meno competenti, ma perché c'è più lavoro da svolgere nello stesso lasso di tempo.
Il rapporto DORA del 2024 ha misurato le conseguenze pratiche: con l'aumento dell'adozione dell'IA, la stabilità delle consegne è diminuita del 7,2%, a causa della crescente dimensione delle modifiche. Inoltre, il 39,2% degli sviluppatori ha dichiarato di avere poca o nessuna fiducia nel codice generato, introducendo un costo raramente considerato: il tempo impiegato per verificare manualmente qualcosa che avrebbe dovuto far risparmiare tempo.
La soluzione non è aumentare le ore dedicate alla revisione. È sostituire la revisione manuale con la verifica automatizzata laddove possibile e riservare l'attenzione umana a ciò che solo una persona può valutare: se questo è ciò di cui l'azienda ha bisogno.
Test unitari e integrazione. Sempre la solita storia, e ora ancora più necessaria perché c'è più codice. Scritto o almeno revisionato da una sola persona: se lo stesso sistema genera implementazione e test, il ciclo si chiude su se stesso.
Set di valutazione dei componenti di intelligenza artificiale. Scenari reali con risultati attesi, eseguiti con ogni modello, richiesta o modifica di configurazione. Senza questo, è impossibile sapere se un aggiornamento ha migliorato o peggiorato il sistema.
Prove delle eccezioni. I rari casi che si verificano durante il processo vengono utilizzati come test. In questo modo ci assicuriamo che il sistema si adatti alla singola persona quando necessario, anziché improvvisare.
Test di sicurezza specifici. Tentativi di iniezione tempestivi, verifica che il componente non possa superare i propri permessi e controllo che non esponga informazioni non consentite. OWASP include questi vettori nella sua Top 10 per le applicazioni LLM nel 2025.
Verifica continua in produzione. Campionamento periodico di casi reali, esaminati da un essere umano. Questo è l'unico modo per rilevare il degrado: un sistema può degradarsi senza che venga modificata una sola riga di codice, perché sono cambiati il modello, i dati o il contesto di utilizzo.
Il quinto livello è quello che quasi mai esiste e quello che previene il maggior numero di incidenti, per il motivo che abbiamo spiegato quando abbiamo parlato di osservabilità e automazione [link interno]Senza una misurazione continua, il segnale che qualcosa non va arriva tramite il cliente.
Non si tratta di un'argomentazione conservatrice. Il profilo del controllo qualità cambia sostanzialmente, e in meglio:
Si passa dal "verificare che funzioni" al "definire cosa significa che funzioni". Il secondo compito è più difficile, più prezioso e non può essere automatizzato.
Quando qualcuno propone di ridurre gli investimenti nella qualità perché "l'IA scrive codice migliore", la domanda che guida la conversazione è: Come faremo a sapere quando smetterà di funzionare?
Se la risposta è che qualcuno se ne accorgerà, l'organizzazione ha delegato il controllo qualità alla pazienza dei propri clienti. Se invece la risposta include test automatizzati, una suite di valutazione versionata e un campionamento continuo in produzione, allora si può realisticamente discutere di efficienza.
No, anzi, lo aumenta. Un modello produce codice che si compila e fa qualcosa di ragionevole, ma non sa se è ciò di cui l'azienda ha bisogno, perché quell'informazione è contenuta nel processo e nelle eccezioni, non nel codice stesso. Inoltre, il maggior volume di modifiche diluisce la copertura della revisione tra pari.
Valutando una serie di casi reali e la relativa risposta attesa, eseguita con ogni modifica del modello, richiesta o configurazione, il risultato non è "superato o non superato", ma una distribuzione di qualità. I criteri di accettazione dovrebbero essere definiti dal business, non solo dal team tecnico.
Si tratta di una raccolta di casi di studio reali con le risposte che l'organizzazione considera corrette. È la risorsa più duratura di un progetto di intelligenza artificiale: consente confronti oggettivi tra i fornitori, permette di individuare se una nuova versione ha peggiorato il sistema e di modificare i modelli senza correre rischi inutili.
Cinque: test unitari e di integrazione, suite di valutazione dei componenti di intelligenza artificiale, test delle eccezioni di processo, test di sicurezza specifici (iniezione di prompt, superamento dei permessi, esposizione delle informazioni) e verifica continua tramite campionamento in produzione.
Sì. La situazione può peggiorare a causa di modifiche alla versione del modello, ai dati di input o al contesto di utilizzo. Per questo motivo, la verifica non può concludersi con la distribuzione, ma deve proseguire con campionamenti periodici revisionati da personale qualificato.
Si passa dall'esecuzione manuale ripetitiva alla progettazione di casi, alla creazione e manutenzione di suite di valutazione e all'analisi dei risultati in produzione. Si passa dalla verifica del funzionamento alla definizione di cosa significhi il funzionamento.
Come si fa a capire se un sistema di intelligenza artificiale ha smesso di funzionare correttamente? Abbiamo progettato la suite di valutazione, i test di eccezione e la verifica continua in modo che la risposta non dipenda da un reclamo del cliente. Parliamone →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
