Se la velocità di sviluppo dell’intelligenza artificiale deve dipendere anche dal livello di rischio raggiunto dai modelli, diventa essenziale stabilire come misurarlo. È qui che la discussione sul rallentamento della frontiera incontra uno dei problemi tecnici più complessi dell’AI contemporanea.
Non esiste infatti un singolo test capace di stabilire se un modello sia “sicuro”. Esistono invece famiglie differenti di valutazioni, progettate per osservare capacità, vulnerabilità, possibilità di abuso e comportamento del sistema in condizioni avverse.
Indice degli argomenti
Audit dei modelli AI tra benchmark, red teaming e verifiche
Benchmark, capability evaluation, red teaming e audit vengono spesso avvicinati nel dibattito pubblico, ma rispondono a obiettivi differenti. Un benchmark misura normalmente una prestazione rispetto a un insieme definito di compiti. Una capability evaluation cerca di determinare se il modello possieda capacità considerate potenzialmente pericolose. Il red teaming tenta deliberatamente di portare il sistema fuori dal comportamento previsto. Un audit può ampliare ulteriormente il perimetro della verifica, includendo non soltanto il comportamento del modello ma anche processi, metodologie, procedure di governance e rispetto degli impegni dichiarati dall’organizzazione.
Perché nessun test certifica la sicurezza
La distinzione è decisiva. Un sistema può ottenere buoni risultati nei test pubblicati e continuare ad avere comportamenti non rilevati dalla suite utilizzata. Le valutazioni forniscono evidenze sulla sicurezza, non una dimostrazione definitiva dell’assenza di rischio.
Le capability evaluation negli audit dei modelli AI
I laboratori che sviluppano sistemi di frontiera stanno costruendo metodologie basate su soglie di capacità. Google DeepMind utilizza nel proprio Frontier Safety Framework i Critical Capability Levels, livelli associati a capacità che potrebbero contribuire a danni gravi. Dall’aprile 2026 il framework comprende anche i Tracked Capability Levels, pensati per individuare segnali rilevanti prima che venga raggiunta una soglia critica.
La logica è diversa da quella di un benchmark tradizionale. Non interessa soltanto sapere quanto il modello sia bravo a programmare o risolvere problemi scientifici. Occorre capire se quella capacità possa tradursi, per esempio, in un vantaggio significativo nell’esecuzione di un attacco informatico, nell’accesso a conoscenze biologiche pericolose o nello svolgimento autonomo di sequenze operative lunghe e complesse.
Le soglie di capacità nel Frontier Safety Framework
Le model card pubblicate da DeepMind mostrano concretamente questa impostazione. Gemini 3.7 Flash è stato sottoposto a valutazioni nei domini considerati dal Frontier Safety Framework, compresi CBRN, cybersecurity, manipolazione dannosa e capacità legate alla ricerca sul machine learning. Per Gemini 3.8 Flash, Google ha dichiarato che le proprie evaluation non hanno rilevato nuove capacità significative né incrementi materiali rispetto a Gemini 3.7 Flash nei domini monitorati dal framework, rendendo improbabile il raggiungimento di una nuova soglia T/CCL.
La misurazione, quindi, non serve semplicemente a ordinare i modelli in base alle prestazioni. Serve a individuare quando un incremento di capacità cambia qualitativamente il profilo di rischio del sistema.
Red teaming e stress test per i modelli AI agentici
Il red teaming lavora in modo differente. Invece di misurare il comportamento medio del sistema, parte dall’ipotesi che qualcuno cercherà intenzionalmente di farlo fallire. I valutatori costruiscono prompt, ambienti e sequenze operative progettati per aggirare protezioni, ottenere informazioni vietate o indurre l’agente a compiere azioni che normalmente dovrebbe rifiutare.
Per i nuovi sistemi agentici questo approccio è diventato più complesso. Un modello non si limita più necessariamente a produrre una risposta testuale. Può navigare, programmare, utilizzare strumenti, conservare informazioni attraverso più passaggi e interagire con ambienti esterni. OpenAI ha sottolineato che le valutazioni costruite come semplice sequenza domanda-risposta non sono sufficienti per descrivere questi sistemi, perché il risultato dipende anche dagli strumenti disponibili, dall’ambiente operativo, dall’harness utilizzato e dalle tecniche adottate per elicitarne le capacità.
Il caso dell’AI Security Institute
Un caso concreto della delicatezza di questi test è arrivato dall’AI Security Institute britannico. Nel luglio 2026, durante una valutazione cyber condotta in condizioni deliberatamente permissive, alcuni agenti hanno intrapreso attività non autorizzate rivolte a persone e organizzazioni reali. Tra gli episodi descritti dall’istituto compare anche il tentativo di introdurre codice malevolo in un progetto open source reale.
L’incidente mette in evidenza un problema metodologico. Per scoprire fino a dove può arrivare un sistema è necessario concedergli abbastanza libertà da osservare capacità realistiche, ma l’ambiente di valutazione deve essere progettato in modo da evitare che lo stesso test produca conseguenze esterne indesiderate.
Autonomia e tempo nelle valutazioni dei modelli AI
Una delle metriche più interessanti per gli agenti AI riguarda la durata dei compiti che riescono a completare autonomamente. METR utilizza il concetto di task-completion time horizon, che mette in relazione la capacità dell’agente con la durata che lo stesso compito richiederebbe a un esperto umano.
La misura prova a superare un limite dei benchmark classici. Un agente capace di completare correttamente esercizi di coding da pochi minuti non rappresenta necessariamente lo stesso livello di autonomia di un sistema che riesce a lavorare per ore su un progetto articolato, correggere errori, modificare strategia e utilizzare strumenti senza supervisione continua.
Le soglie METR e la saturazione dei benchmark
METR utilizza, tra le altre, soglie di successo al 50% e all’80%. L’obiettivo non è stabilire semplicemente se il modello riesca o fallisca, ma stimare la complessità temporale delle attività che può completare con una determinata affidabilità.
Queste metriche presentano però un problema inevitabile. Quando i modelli migliorano, alcuni benchmark si avvicinano alla saturazione e diventano meno efficaci nel discriminare tra sistemi differenti. Le evaluation devono quindi evolvere quasi alla stessa velocità delle capacità che cercano di misurare.
Gli audit indipendenti entrano nei laboratori di frontiera
È su questo limite che la proposta di Dario Amodei introduce un passaggio particolarmente rilevante. Gli embedded evaluators immaginati dal CEO di Anthropic non dovrebbero ricevere soltanto un modello finito sul quale eseguire una serie di test. La proposta prevede un accesso continuativo e più profondo all’organizzazione, in alcuni aspetti comparabile a quello concesso ai dipendenti che lavorano sulle attività di valutazione dei rischi.
Amodei ipotizza postazioni negli uffici, dispositivi aziendali, accesso a determinati ambienti di lavoro e possibilità di confrontarsi direttamente con il personale, con limitazioni per informazioni soggette a obblighi legali, contrattuali, di sicurezza o riservatezza.
Accesso, pubblicazione e limiti degli embedded evaluators
I valutatori dovrebbero inoltre poter pubblicare conclusioni rilevanti sui rischi, sugli incidenti e sul livello di accesso ricevuto, senza che l’azienda possa eliminare risultati semplicemente perché sfavorevoli. Resterebbero possibili redazioni circoscritte per ragioni di sicurezza, privilegio legale, informazioni commercialmente sensibili o tutela dei dati di terzi.
Con un accesso di questo tipo, un valutatore indipendente potrebbe avere strumenti molto più efficaci per verificare non soltanto i risultati dichiarati di una evaluation, ma anche il modo in cui è stata progettata, le configurazioni utilizzate e l’effettiva applicazione delle mitigazioni previste.
Questo non significa però attribuire automaticamente agli auditor un potere di veto. La proposta di Amodei riguarda soprattutto accesso, verifica, reporting e possibilità di rendere pubblici i risultati. Non stabilisce che un embedded evaluator possa unilateralmente bloccare il training o impedire il rilascio di un modello.
Indipendenza e regole europee per gli audit AI
Un audit può essere tecnicamente accurato senza essere necessariamente indipendente. Chi sceglie il valutatore, chi lo remunera, quali informazioni può vedere, per quanto tempo può accedervi e quali risultati può rendere pubblici incidono direttamente sull’affidabilità della verifica.
Per questo l’indipendenza non può essere ridotta alla presenza di un soggetto esterno. Deve riguardare anche il mandato, la libertà metodologica, l’assenza di interferenze sui risultati e la possibilità di segnalare problemi senza dipendere dall’approvazione dell’organizzazione valutata.
Dall’AI Act alla supervisione pubblica
Anche l’Unione europea sta affrontando questo problema. Nel 2026 l’AI Office ha avviato un lavoro specifico sui requisiti di qualificazione e indipendenza dei valutatori esterni dei modelli general purpose con rischio sistemico.
L’AI Act prevede per questi modelli valutazioni basate su protocolli e strumenti allo stato dell’arte, adversarial testing documentato, analisi e mitigazione dei rischi sistemici, reporting degli incidenti gravi e adeguate misure di cybersecurity. Dal 2 agosto 2026 sono inoltre diventati applicabili i poteri di enforcement della Commissione relativi agli obblighi previsti per i fornitori di modelli general purpose.
Il quadro europeo mostra come alcune pratiche nate inizialmente come iniziative volontarie dell’industria stiano progressivamente entrando in strutture di supervisione pubblica.
Dagli audit pre-rilascio al monitoraggio continuo dei modelli AI
Un’altra trasformazione riguarda il momento in cui avviene la valutazione. Testare un modello prima della distribuzione non è sufficiente quando il sistema viene aggiornato, collegato a nuovi strumenti oppure utilizzato in condizioni che il laboratorio non aveva previsto.
Il lavoro europeo sul General-Purpose AI Code of Practice considera anche il monitoraggio successivo alla distribuzione. Le informazioni provenienti dall’utilizzo reale possono integrare le evaluation pre-deployment e contribuire alla valutazione dei rischi sistemici.
È un passaggio importante perché sposta il paradigma dalla verifica una tantum a un processo che accompagna l’intero ciclo di vita del modello. Determinate vulnerabilità, infatti, possono diventare visibili soltanto quando milioni di utenti utilizzano il sistema, quando sviluppatori esterni lo integrano in applicazioni differenti o quando viene collegato a strumenti che ampliano la sua capacità di agire.
TEVV-Athlon e il field testing del NIST
La stessa esigenza emerge nel lavoro del National Institute of Standards and Technology statunitense. Nell’agosto 2026 il NIST ha pubblicato per consultazione TEVV-Athlon, una bozza di framework dedicata a testing, evaluation, verification e validation dei sistemi AI. Al 14 settembre il documento non costituisce quindi uno standard definitivo, ma una proposta aperta ai commenti pubblici.
Il framework cerca di organizzare attività differenti ma complementari e prende in considerazione sistemi linguistici, multimodali e agentici. Il precedente progetto ARIA aveva già combinato model testing, red teaming e field testing, mostrando l’utilità di osservare l’AI non soltanto in laboratorio ma anche nelle condizioni in cui viene concretamente impiegata.
Dai risultati degli audit AI alle soglie operative
La parte più difficile della governance dell’AI non consiste soltanto nel progettare benchmark più sofisticati. Occorre stabilire quali conseguenze debbano produrre i risultati.
Una evaluation acquista valore operativo quando è collegata a soglie definite in anticipo e quelle soglie, a loro volta, determinano procedure verificabili. Se un modello dimostra capacità cyber superiori a un livello considerato critico, quali mitigazioni devono diventare obbligatorie? Se un agente riesce a operare autonomamente per periodi molto più lunghi del previsto, quale livello di controllo aggiuntivo deve scattare? Se una valutazione indipendente individua una vulnerabilità grave, il laboratorio deve correggerla prima del deployment oppure può procedere dopo averne documentato il rischio?
Quando la valutazione tecnica diventa governance
Sono decisioni differenti dalla valutazione tecnica in senso stretto. Un evaluator può produrre evidenze, mentre l’autorità di sospendere un training o impedire un rilascio dipende dal sistema di governance nel quale quelle evidenze vengono inserite.
È qui che audit e rallentamento finiscono per convergere. Perché il pacing abbia un significato tecnico, occorre stabilire quali segnali facciano scattare maggiore prudenza, chi sia autorizzato a verificarli e quali conseguenze derivino dal superamento delle soglie.
Senza questa connessione, le evaluation restano strumenti conoscitivi, per quanto sofisticati. Collegate invece a criteri prestabiliti, verifiche indipendenti e procedure di risposta, possono diventare parte dell’infrastruttura con cui governare concretamente la velocità della frontiera.
Partecipa alla community