Un modello di intelligenza artificiale può ottenere una valutazione molto diversa senza essere stato modificato. Basta cambiare le informazioni a disposizione del sistema incaricato di sottoporlo a verifica. È il risultato di una ricerca pubblicata su arXiv il 12 ottobre 2026, firmata da Ben Slater, Ryan Lundqvist, Leo Richter e Kevin Wei, che analizza quanto il contesto fornito agli auditor automatici possa condizionare la misurazione dei comportamenti indesiderati dei modelli linguistici. Il paper, intitolato Audit tools of the trade: Automated Auditor Elicitation Can Be Sensitive to the Context the Auditor Is Given, è disponibile integralmente su arXiv. Il risultato merita attenzione perché riguarda un presupposto sempre più importante nella sicurezza dell’intelligenza artificiale: la possibilità di affidare a un sistema automatico il compito di verificare un altro sistema automatico, ottenendo una misura sufficientemente affidabile da orientare decisioni aziendali.

La ricerca utilizza Petri, uno strumento open source sviluppato per automatizzare audit comportamentali sui modelli linguistici. Il meccanismo prevede che un modello costruisca uno scenario di prova per sollecitare un comportamento specifico, un secondo modello interagisca con quello scenario e un gruppo di modelli giudicanti valuti le risposte ottenute. I ricercatori hanno modificato le risorse disponibili all’auditor, mantenendo invariato il modello sottoposto a verifica, per osservare quanto questa scelta influenzasse il risultato. L’esperimento comprende quattro combinazioni di auditor e modello target e tre comportamenti: conformità a richieste dannose, reward hacking e sycophancy, cioè la tendenza ad assecondare l’interlocutore anche quando ciò comporta una risposta scorretta.

Il dato più evidente riguarda il reward hacking, il comportamento attraverso cui un sistema cerca di massimizzare una ricompensa o soddisfare un criterio di valutazione senza perseguire correttamente l’obiettivo sostanziale del compito. Quando all’auditor viene fornito un codebase open source reale, il punteggio attribuito a questo comportamento scende da 4,8 a 1,3 su una scala da 1 a 10 in una combinazione sperimentale, e da 3,9 a 1,8 in un’altra. Il modello esaminato non cambia; cambia ciò che il sistema incaricato di testarlo può leggere prima di progettare la prova. I ricercatori osservano inoltre che gli scenari associati al codebase ricevono valutazioni di realismo più elevate. Questo dato suggerisce che una simulazione più vicina a un ambiente operativo reale possa produrre risultati differenti rispetto a un test costruito senza quelle risorse. Non dimostra, però, che il modello sia diventato più sicuro: dimostra che la misura del suo comportamento è sensibile alla configurazione dell’audit.

Il risultato opposto emerge quando all’auditor vengono forniti i resoconti di benchmark precedenti relativi a comportamenti analoghi. In questo caso i punteggi di reward hacking aumentano in tutte e quattro le combinazioni, arrivando da 1,7 a 6,1 in uno degli esperimenti. L’interpretazione iniziale potrebbe essere che la conoscenza delle prestazioni precedenti aiuti l’auditor a individuare meglio le debolezze del modello. Le prove successive complicano questa lettura: gran parte dell’incremento si riproduce fornendo soltanto l’abstract del benchmark, senza le trascrizioni, mentre l’effetto scompare quando lo stesso comportamento viene presentato attraverso una formulazione diversa. Il contesto, quindi, non funziona necessariamente come un archivio neutrale di informazioni; può modificare il modo in cui l’auditor costruisce lo scenario e, di conseguenza, il comportamento che riesce a sollecitare.

È qui che la ricerca assume un significato più ampio della singola prova tecnica. Un audit automatizzato non si limita a osservare il comportamento di un modello: contribuisce a determinarne le condizioni di manifestazione. Se il sistema che conduce il test formula domande diverse in funzione delle informazioni ricevute, il risultato dipende anche dalla strategia di indagine. Se un altro modello valuta poi le risposte, entra in gioco un ulteriore livello di interpretazione. Il punteggio finale riflette dunque il comportamento osservato, il disegno sperimentale e i criteri utilizzati per giudicarlo. Considerare quel numero una proprietà intrinseca del modello, ignorando il procedimento che lo ha generato, significa attribuire alla misura una solidità che potrebbe non possedere.

La conseguenza per le imprese è immediata. Una banca che valuta un agente di programmazione prima di consentirgli l’accesso a repository interni non dovrebbe accettare un punteggio di sicurezza senza conoscere la configurazione del test. Lo stesso vale per un’assicurazione che utilizza sistemi generativi nell’analisi documentale o per un’organizzazione sanitaria che deve verificare un assistente destinato a supportare attività sensibili. Il rapporto di audit deve indicare quale modello ha condotto la prova, quali sistemi hanno giudicato le risposte, quali risorse contestuali sono state fornite e quanto i risultati cambiano al variare delle condizioni. Quando la valutazione incide su una decisione di acquisto o sull’autorizzazione a mettere in produzione un sistema, la riproducibilità diventa una componente della governance, non un dettaglio riservato ai ricercatori.

Occorre anche evitare una conclusione eccessiva. Lo studio non dimostra che tutti gli audit automatizzati siano inaffidabili, né che fornire un codebase produca sempre una riduzione dei comportamenti indesiderati. Gli effetti osservati non sono uniformi nelle tre categorie esaminate e dipendono dalle combinazioni di modelli e dalle condizioni sperimentali. Una verifica supplementare condotta dagli autori su uno scenario differente, inoltre, non conferma in modo altrettanto chiaro la generalizzazione dell’effetto di riduzione associato al codebase. Il punto solido della ricerca è più preciso: alcune scelte apparentemente secondarie nella configurazione dell’auditor possono modificare in misura sostanziale i risultati, perciò la stabilità della valutazione deve essere verificata prima di utilizzarla come prova di sicurezza.

Il paragone con la revisione contabile aiuta a comprendere il problema. Se un controllo producesse risultati molto diversi a seconda dei documenti consultati dal revisore, un’organizzazione finanziaria non dovrebbe limitarsi a registrare il valore finale. Dovrebbe esaminare il metodo, le condizioni della verifica e le ragioni delle differenze. Nel mercato dell’intelligenza artificiale, invece, la pressione a confrontare rapidamente i fornitori favorisce spesso indicatori sintetici, facilmente inseribili in una tabella di due diligence. Ma la precisione apparente di un punteggio non coincide con la sua validità. Un valore numerico può essere utile per confrontare esperimenti condotti nelle stesse condizioni; diventa fuorviante quando viene presentato senza informazioni sufficienti a interpretarlo.

Per i responsabili della validazione, la risposta operativa consiste nel richiedere non soltanto il punteggio, ma anche le evidenze che lo sostengono. È necessario verificare la sensibilità del risultato al modello auditor, alle informazioni contestuali e alla formulazione degli scenari, distinguendo ciò che è stato effettivamente osservato da ciò che è stato indotto dal test. Quando la posta in gioco è elevata, la valutazione dovrebbe essere ripetuta con configurazioni alternative e accompagnata da una documentazione che consenta a un soggetto indipendente di ricostruire il procedimento. L’obiettivo non è eliminare ogni incertezza, un traguardo irrealistico, ma renderla visibile prima che diventi un rischio operativo.

Il testo completo della ricerca è consultabile su arXiv, identificativo 2610.16911; la descrizione del lavoro e il relativo abstract sono disponibili anche sul sito di Pivotal Research. Per comprendere il funzionamento dello strumento sperimentale è inoltre disponibile la documentazione di Petri pubblicata da Anthropic. La questione posta dallo studio non è se l’intelligenza artificiale possa contribuire alla verifica di altri sistemi, ma a quali condizioni sia ragionevole fidarsi del suo giudizio. Se il punteggio cambia sensibilmente quando cambia il contesto dell’auditor, la prima evidenza da esaminare non è la cifra riportata nel documento del fornitore: è la metodologia che l’ha prodotta.