I modelli di frontiera stanno sviluppando capacità offensive che nessun test standardizzato riesce più a catturare. Lo segnala Axios, e la notizia cade in un momento delicato: le agenzie federali statunitensi hanno tempo fino al 1° agosto per mettere in piedi un’infrastruttura classificata dedicata proprio alla verifica dei rischi dell’intelligenza artificiale. Il paradosso è lampante: gli strumenti che dovrebbero guidare le decisioni di sicurezza sono obsoleti prima ancora di essere adottati.

La dinamica è nota a chi lavora sulla sicurezza informatica: quando l’attaccante evolve più in fretta del difensore, il gap si allarga in modo esponenziale. Qui l’attaccante non è un malware tradizionale, ma un sistema che può generare exploit, scrivere codice malevolo o individuare vulnerabilità in modo automatico. E lo fa senza lasciare le tracce comportamentali di un umano, il che rende i classici benchmark – spesso basati su challenge statiche – drammaticamente insufficienti.

Per le organizzazioni che valutano un deployment on-premise, questo scenario cambia i termini del problema. Chi gestisce dati sensibili o opera in contesti regolati (difesa, finanza, infrastrutture critiche) sa che testare un LLM significa eseguirlo in un ambiente controllato, spesso air-gapped. Ma se i benchmark pubblici non riescono a predire le capacità reali di un modello, l’intero processo di validazione perde efficacia. Non è più sufficiente far girare una suite di test su hardware locale: bisogna costruire internamente scenari di attacco che simulino un avversario adattivo, qualcosa che richiede competenze rare e, non di rado, potenza di calcolo dedicata.

L’impatto strutturale si vede già nella domanda di hardware per inference on-premise. Le GPU con ampia VRAM diventano necessarie non solo per il serving dei modelli, ma anche per condurre red teaming automatizzato, dove si eseguono istanze multiple del modello contro reti virtualizzate. È un costo operativo che entra direttamente nel TCO e che spinge verso architetture ibride: l’addestramento puoi farlo in cloud, ma il test offensivo lo tieni dentro casa, per evitare fughe di dati e rispettare requisiti di sovranità digitale.

C’è anche un effetto di secondo ordine sul fronte regolatorio. Se i benchmark non sono più attendibili, gli enti di controllo rischiano di basare le loro decisioni su metriche fuorvianti. Questo potrebbe rallentare l’adozione dell’AI in settori regolamentati (perché manca un metodo condiviso per dimostrare che un modello è “sicuro”) e allo stesso tempo accelerare investimenti in piattaforme on-premise da parte di chi non vuole dipendere da valutazioni esterne incerte. Il risultato è un mercato che si polarizza: da un lato chi corre con modelli sempre più potenti ma poco verificati, dall’altro chi costruisce fortezze digitali dove l’unica certificazione è quella che fai da te.

La scadenza federale americana del 1° agosto agisce da acceleratore: mette in evidenza che anche a livello governativo la definizione di “pericoloso” per un’AI è un terreno scivoloso, e che i test di hacking vanno ridefiniti con logiche più simili ai capture the flag che ai quiz a risposta multipla. In questo scenario, l’infrastruttura locale smette di essere una scelta di comodo e diventa l’unico modo per mantenere la sovranità sui dati e sulle valutazioni di sicurezza, senza dover delegare a terzi il compito di dire cosa sa fare davvero un modello.