La tassa del difensore: un argomento di sicurezza a favore dell'AI aperta

Chiedi a un modello di frontiera di fare l’audit del tuo web-app in cerca di vulnerabilità e guarda cosa succede. Su certi sistemi la richiesta da sola fa scattare un cambio di marcia — il modello più capace si fa da parte in silenzio e ne subentra uno più piccolo e vincolato nel momento esatto in cui legge la parola audit; il tono passa da assistente a ufficio-conformità; a volte è un rifiuto secco. La capacità c’è. È solo stato deciso che tu non debba averla a piena potenza, di default, senza attrito.

Costruisco strumenti di sicurezza per lavoro, quindi contro questo muro ci sbatto di continuo. E mi ha fatto notare qualcosa di scomodo nel regime di safety che abbiamo costruito attorno all’AI di frontiera: tassa il difensore molto più dell’attaccante.

L’asimmetria

Il difensore gioca secondo le regole. Usa l’API ufficiale, con il suo account reale, per lavoro legittimo — pentesting dei propri sistemi, hardening del proprio codice. È esattamente lui che le guardrail rallentano.

L’attaccante non fa niente di tutto ciò. Fa jailbreak. Fa fine-tuning di un modello per togliergli i rifiuti. Usa un modello a pesi aperti senza alcuna guardrail. Oppure è uno Stato con il suo laboratorio e nessun termine di servizio. Ogni strato di safety che aggiungiamo al prodotto conforme è uno strato che l’attaccante semplicemente aggira.

Chi fa sicurezza ha un nome per questa forma: offense–defense balance. Quando alzi il costo di una capacità per tutti, lo alzi di più per chi la avrebbe usata dentro le regole — perché è l’unico che le regole riescono a raggiungere.

Non serve un complotto

È tentante leggerci un’intenzione — che qualcuno voglia tenere i dev comuni meno capaci. Non credo serva quella storia, e la versione senza cattivo è più devastante, perché è strutturale.

Bastano tre forze ordinarie a produrre l’effetto. Liability e PR: nessun lab vuole il titolo “la nostra AI ha scritto il malware”. Copertura regolatoria: le scaling policy pubblicate oggi mettono un gate netto sull’uplift CBRN e cominciano a scaglionare l’accesso alla capacità cyber, perché è quello che regolatori e opinione pubblica stanno guardando. Rischio reale: la capacità è davvero dual-use — lo stesso modello che trova una falla per correggerla la trova per sfruttarla.

Nessuno di questi attori deve essere malevolo. Il risultato aggregato è comunque un mondo in cui la capacità difensiva più potente sta dietro il massimo attrito, proprio per il difensore comune.

E allora — un complotto per tenerci insicuri? No. Ma resta lì la micro-verità sotto la smentita: un numero ristretto di attori decide ora chi può difendersi a piena potenza, e non sono loro a farsi bucare quando gli altri non ci riescono. Non serve l’intenzione perché sia un problema. Basta che resti vero.

Perché “usate i modelli aperti” oggi non è una risposta

Ecco la parte che gli ottimisti saltano. Oggi i modelli a pesi aperti che puoi far girare senza guardrail sono sensibilmente più deboli della frontiera gated — e farli girare bene vuole hardware che i più non hanno. Così il piccolo costruttore è tassato due volte: strozzato sulla frontiera che gli è concesso toccare, e sotto-potenziato sugli aperti che gli è concesso possedere.

La capacità difensiva di frontiera — quella che permetterebbe a una persona sola di mettere in sicurezza una codebase al ritmo con cui oggi si muovono gli attaccanti — resta concentrata in una manciata di API a pagamento e gated, e negli attori ben finanziati che possono usarle a piena potenza. È quella concentrazione, non il singolo rifiuto, il vero problema.

Questo esperimento l’abbiamo già fatto

Negli anni ‘90 gli Stati Uniti classificarono la crittografia forte come munizione e provarono a tenerla fuori dalle mani dei civili. La ragione dichiarata era la stessa di oggi: criminali, terroristi, catastrofe. L’effetto fu sicurezza più debole per tutti quelli che obbedivano, mentre la conoscenza si diffondeva comunque. Finì — Bernstein v. United States, PGP che usciva dalla porta — perché il campo riscoprì una legge che già conosceva: la sicurezza non nasce dal nascondere la capacità; nasce dal distribuirla in chiaro, dove può essere ispezionata e migliorata. Kerckhoffs lo disse nell’Ottocento. Le Crypto Wars lo dimostrarono di nuovo.

Stiamo combattendo Crypto Wars 2.0, con i pesi dei modelli al posto del codice del cifrario.

La conclusione a cui continuo ad arrivare

Non sono contro la safety. Sono contro un esito preciso: un mondo in cui la capacità difensiva di frontiera è un bene di lusso — di Stati e grandi piattaforme — mentre chi scrive e fa girare la maggior parte del software, la coda lunga di sviluppatori e piccoli team, è tenuta strutturalmente un passo dietro l’offesa. Quel mondo non è più sicuro. È più fragile, perché gran parte della superficie d’attacco finisce difesa da chi si è visto negare gli strumenti migliori.

La capacità prolifera comunque; è sempre così. Quindi il gating disarma soprattutto i conformi. La risposta onesta non è meno safety, è:

• Modelli aperti capaci — buoni abbastanza da difendersi davvero, non giocattoli.
• Compute accessibile — così che “puoi farlo girare” non finisca di nascosto con “…se possiedi un datacenter”.
• Safety che autentica il difensore invece di rifiutare tutti — prova-di-autorizzazione per il lavoro dual-use, non un no generalizzato che solo gli onesti rispettano.

Al mondo non serve un’AI potente solo in poche mani. Per la sicurezza, in particolare, è proprio la configurazione pericolosa. Al mondo serve un’AI capace e davvero aperta — e serve prima che il divario tra chi può difendersi e chi può attaccare si indurisca in qualcosa di permanente.

Ci ho skin in the game. Gli strumenti che costruisco — un memory layer, una piattaforma di security-audit — sono open source, MIT, self-hosted. Non come modello di business: come posizione. Se la capacità difensiva dev’essere gated, almeno una parte dovrebbe essere libera.

---

Basi: la Responsible Scaling Policy di Anthropic (soglie di capacità CBRN; il cyber gestito con accesso scaglionato) e il Preparedness Framework di OpenAI; il parallelo storico sono le Crypto Wars degli anni ‘90 — la crittografia classificata come munizione, Bernstein v. United States che stabilisce il codice sorgente come free speech, il caso dell’export di PGP, e l’allentamento dei controlli a fine decennio. Il divario capacità aperti-vs-frontiera è un’osservazione dalla pratica quotidiana, non un benchmark formale.