Quando un'azienda decide di tenere i propri LLM on-premise per questioni di sovranità dei dati o conformità normativa, il collaudo di sicurezza non è un optional: è il passaggio che trasforma un modello da promessa a strumento affidabile. Ma se il collaudo stesso fosse costruito su fondamenta fragili? Un nuovo studio solleva esattamente questo dubbio, mostrando che gli audit di validità basati su perturbazioni — oggi tra le prove più richieste dai framework di governance per l'AI — possono restituire conclusioni inaffidabili, manipolabili da dettagli di implementazione che nessun report numerico lascia intravedere.

I ricercatori hanno identificato cinque modalità di fallimento (etichettate come F1-F5) all'interno della pipeline di audit e le hanno dimostrate in un auto-audit su benchmark di sicurezza e modelli open-weight addestrati con istruzioni. Applicando un rigoroso protocollo di due diligence a sei punti, nessuna configurazione ha raggiunto la soglia di conferma: tutti i risultati sono finiti in un limbo di non confermabilità. Lo studio, basato su un singolo caso con due modelli e cinque benchmark, non pretende di fornire una tassonomia esaustiva, ma un punto di partenza illustrativo. E il messaggio è chiaro: gli audit di validità, così come vengono comunemente condotti, sono essi stessi fragili.

Perché la fragilità degli audit colpisce chi fa on-premise

Chi gestisce LLM in locale si assume l'intera responsabilità della conformità, specialmente in settori regolamentati o sotto GDPR. Un audit che produce un falso senso di sicurezza non è solo un errore tecnico: può trasformarsi in un rischio legale e reputazionale. Se i benchmark di safety dichiarano un modello “sicuro” solo perché la pipeline di test nasconde una scelta di quantization o un pre-processing che attenua certe risposte, il decisore aziendale prende decisioni su dati fuorvianti.

La ricerca mette a nudo un difetto strutturale: le evidenze documentali richieste dai framework di governance si appoggiano su numeri la cui genesi resta opaca. Per un deployment on-premise, questo significa che non basta controllare il punteggio finale. Occorre invece audire il processo di audit, scavando nelle scelte implementative che spesso restano fuori dalla reportistica. Il protocollo di due diligence a sei punti proposto dagli autori non è una scorciatoia per ottenere verdetti di validità, ma un meccanismo di trasparenza supplementare pensato per rafforzare l'affidabilità delle evidenze, non per sostituire le classiche prove di validità.

Questo cambio di prospettiva ha conseguenze profonde. Da un lato, sposta l'attenzione dai vendor di modelli verso chi costruisce gli strumenti di valutazione interni: le organizzazioni che investono in stack on-premise dovranno integrare controlli più granulari, andando oltre le metriche sintetiche offerte dai framework più diffusi. Dall'altro, ridisegna gli equilibri del settore: se gli audit diventano più costosi e complessi da falsificare, i fornitori di soluzioni “chiavi in mano” potrebbero trovarsi in difficoltà, mentre chi offre infrastrutture trasparenti e auditabili guadagna credibilità.

A livello strutturale, la fragilità dei benchmark-validity audits segnala che la governance dell'AI, per essere credibile, ha bisogno di protocolli di revisione aperti e riproducibili. Non a caso, lo studio posiziona il proprio gate come protocollo di divulgazione e trattenimento delle prove. Per le aziende che valutano il TCO di uno stack locale, questo introduce una nuova voce di costo: quella della validazione continua e approfondita dei propri strumenti di test. Non è un dettaglio da poco, ma è la condizione per trasformare la sovranità dei dati in un vantaggio reale, anziché in un azzardo regolatorio.