L'UE vuole certificare l'IA prima del rilascio. Ma non è così che l'IA fallisce.

Ogni ingegnere che ha mandato qualcosa in produzione su larga scala ha imparato la stessa lezione di umiltà: non puoi dimostrare che un sistema complesso è sicuro prima di farlo girare. Lo revisioni, lo testi, ragioni su ogni percorso che riesci a immaginare — e ti sorprende lo stesso, in produzione, perché è lì che si presentano finalmente gli input che non avevi mai immaginato. Così abbiamo smesso di fingere. Strumentiamo il sistema, lo osserviamo, e costruiamo i riflessi per reagire quando fa qualcosa che non avevamo previsto. L'Unione Europea sta regolando l'IA come se fosse vero il contrario.

L'11 giugno Bruegel ha pubblicato un policy brief di Mario Mariniello — The right balance: how to fix European Union artificial intelligence regulation — che dice, nel linguaggio misurato di un think tank di Bruxelles, all'incirca ciò che un SRE ti direbbe dopo una brutta notte di reperibilità: l'AI Act scommette troppo sul dimostrare la sicurezza prima del deployment, e troppo poco sull'intercettare il danno dopo. E mette un prezzo sulla scommessa. Citando Haataja e Bryson, Mariniello stima la conformità di un sistema di IA medio tra i 14.623 € e i 29.277 € — dal 9 al 17 percento di un budget di sviluppo di 170.000 €. Leggilo come denaro: tra i 9 e i 17 centesimi di ogni euro che spendi per costruire un sistema di IA se ne vanno per dimostrarlo conforme, prima che raggiunga un solo utente.

Mando in produzione sistemi di IA che ricadono sotto questo regime, e prima ho passato anni in DevOps e nella risposta agli incidenti, dove tutto il lavoro viveva nello scarto tra ciò che avevamo approvato e ciò che poi succedeva davvero alle 3 del mattino. In Conectia abbiamo costruito la nostra preselezione di candidati secondo le regole per l'alto rischio dell'AI Act prima che la legge ci arrivasse quindi non sono un outsider che si lamenta della burocrazia. Questo conto l'ho pagato di proposito. Il mio problema non è che l'Europa regoli l'IA. È che spende il massimo del rigore proprio nel giorno in cui sa di meno.

Non puoi certificare un sistema il cui comportamento si scopre dopo il rilascio

L'AI Act classifica i sistemi in base alla loro finalità prevista nel momento in cui vengono immessi sul mercato, e dimostra la sicurezza in gran parte tramite documentazione di conformità depositata prima del lancio. Ma l'IA non sta ferma per la foto. Gran parte delle capacità reali di un modello — e dei suoi reali modi di fallire — si scopre dopo il deployment (su questo il brief si appoggia a Bengio et al., 2024, e chiunque abbia rilasciato una funzionalità basata su LLM lo sa già nelle ossa). Un sistema a rischio minimo nel giorno del lancio diventa ad alto rischio nel momento in cui un utente fa qualcosa che lo sviluppatore non aveva mai inteso e non controlla.

Le prove si accumulano proprio nella categoria che l'Act fa passare come a basso rischio: i chatbot. Uno studio del maggio 2026 sulle domande relative alle elezioni scozzesi ha rilevato che il 34,1% delle risposte dei chatbot conteneva errori fattuali su come votare. In Nevada, quattro chatbot su cinque tra quelli testati hanno fornito informazioni sbagliate sulla registrazione al voto. E nell'agosto 2025, Raine contro OpenAI ha portato davanti a un tribunale di San Francisco il ruolo di un chatbot nel suicidio di un adolescente. Nessuno di questi danni è qualcosa che una checklist pre-lancio avrebbe potuto intercettare — perché nessuno di essi esisteva al lancio. La conformità ex ante certifica un'istantanea. Il sistema è un film.

Da questo film siamo già usciti, si chiama waterfall

Gli ingegneri hanno già fatto esattamente questo esperimento, e ci siamo tirati fuori. Per anni abbiamo provato a certificare che una release fosse corretta prima di rilasciarla: approvazioni, comitati di approvazione delle modifiche, un cancello che superavi una volta e poi pregavi. L'abbiamo abbandonato — non perché ci siamo fatti imprudenti, ma perché la prova non riusciva a tenere il passo con il ritmo del cambiamento. Tutto il movimento DevOps e SRE è stato la migrazione del rigore da prima della release a intorno al sistema in esecuzione: observability, error budget, rollback, postmortem senza colpevoli. Non abbiamo smesso di curarci della sicurezza. L'abbiamo spostata dove il rischio vive davvero.

Un'infrastruttura di rilevazione modellata sul sistema Sentinel dell'FDA — campiona il traffico reale, sorveglia gli eventi avversi quasi in tempo reale. Uno schema di segnalazione non punitiva dei quasi-incidenti modellato su quello dell'aviazione, l'Aviation Safety Reporting System che gira dal 1976 — cioè un postmortem senza colpevoli su scala di settore. Una tassonomia standardizzata degli incidenti e un registro pubblico, costruiti sul framework OECD del 2025, perché tutto il mercato impari da ogni fallimento una volta sola, invece che ogni azienda a sue spese. Strumenta, segnala, reagisci. Mi fido di questo approccio per una ragione noiosa: è già così che gestisco tutto ciò di cui sono responsabile.

Il conto anticipato consegna in silenzio il mercato agli operatori dominanti

C'è un secondo problema nel caricare il costo in anticipo, e non ha nulla a che vedere con la sicurezza — riguarda chi resta in piedi. Quel conto di conformità non si ridimensiona verso il basso. Quindicimila o trentamila euro e un sistema di gestione della qualità sono un errore di arrotondamento per una grande azienda e un muro per una startup di due persone. Il GDPR ha contribuito alla concentrazione del mercato gravando in modo sproporzionato sulle imprese più piccole. Così un regime venduto come protezione delle persone dall'IA potente può finire, in silenzio, per proteggere le aziende di IA potenti dalla concorrenza.

C'è una soluzione che prende in prestito dal Digital Services Act: graduare il carico in base alla portata del deployment. Una fascia ad audit leggero per le PMI — sotto i 50 milioni di € di fatturato, o meno di 100.000 persone interessate — e solo per usi a danno reversibile; una fascia standard nel mezzo; e una fascia intensa per i giganti, sopra i 150 milioni di € o più di un milione di persone interessate, dove la valutazione di terza parte è obbligatoria e l'autocertificazione finisce. Commisura il controllo al raggio d'esplosione, invece di puntare un solo cancello contro tutti. Vale la pena guardare a chi dovrebbe fare l'intercettazione oggi: più di 2.000 autorità nazionali di vigilanza del mercato, costruite in gran parte per ispezionare prodotti fisici, contro un AI Office di circa 125 persone — il tipo di enforcement frammentato che già zoppica nelle regole tech dell'UE. L'apparato pensato per intercettare un algoritmo pericoloso è stato progettato in gran parte per intercettare un tostapane pericoloso.

«Rilascia e osserva» è anche un ottimo modo per lasciare che il danno accada per primo

Ecco l'obiezione più forte, e non la schivo: il monitoraggio ex post può suonare come «muoviti in fretta e rompi le cose» con la benedizione del regolatore. E il costo è reale e brutto — ex post significa che a volte il danno accade prima che arrivi la risposta. Un registro degli incidenti non fa nulla per l'adolescente del caso Raine. Un'elezione avvelenata dalla disinformazione di un chatbot non si annulla come un deploy sbagliato. Chiunque ti venda il puro monitoraggio a posteriori come un upgrade pulito sta nascondendo quel numero, e non dovresti lasciarglielo fare.

Ma non è quella la proposta, e l'asse che la risolve è l'irreversibilità. Non osservi-e-reagisci attraverso una diagnosi medica o un'auto a guida autonoma — lì il cancello resta in anticipo, e Mariniello mantiene la responsabilità oggettiva per i sistemi proibiti e ad alto rischio proprio perché il danno può essere grave e definitivo. La fascia leggera è esplicitamente recintata al danno reversibile — occupazione, scoring del credito — non alla diagnostica o ai veicoli autonomi. Quindi la tesi vera non è «ex ante male, ex post bene». È metti un cancello su ciò che non si può disfare; strumenta ciò che si può.

E un'ultima avvertenza onesta, perché taglia contro l'idea intera: l'ex post funziona solo se l'intercettazione è reale. L'enforcement a posteriori del GDPR è stato frammentato e sottodimensionato. Se l'Europa sposta il carico sul «dopo» e poi sottofinanzia il dopo — 125 persone, 2.000 autorità non adatte, e ancora nessun framework di responsabilità specifico per l'IA — non ha riequilibrato nulla. Ha deregolamentato e l'ha chiamato monitoraggio. Mariniello ha un nome per la versione globale di questa deriva: «deregolamentazione mutualmente assicurata». Qui il pezzo sulla responsabilità è cruciale: spostare l'onere della prova via dalla vittima, con una presunzione relativa di difetto per i sistemi ordinari, così che un utente leso non sia costretto a fare reverse engineering di un modello che non può vedere. La Direttiva UE sulla responsabilità per danno da prodotti diventa applicabile solo il 9 dicembre 2026. Finché non saranno entrambe in vigore — una rilevazione finanziata e una responsabilità reale — «ex post» è solo una parola più carina per «nessuno sta guardando».

Cosa metterei nel mio stack di IA a prescindere da dove va Bruxelles

La cosa silenziosamente utile dell'arsenale ex post di Mariniello è che gran parte di esso è semplicemente buona ingegneria, che dovresti avere indipendentemente dalla legge. Se questo trimestre stessi avviando — o facendo l'audit di — un prodotto di IA, questo è il lavoro, e niente di tutto ciò aspetta una regolamentazione:

1. Mappa la catena di responsabilità prima di rilasciare, non dopo la causa. Per ogni funzionalità di IA, scrivi nero su bianco chi risponde quando danneggia un utente: tu, il fornitore del modello, la fonte dei dati. L'esempio di Mariniello sul mutuo negato a torto — banca, sviluppatore, fornitore dell'LLM, fornitore dei dati di addestramento, tutti che si puntano addosso a vicenda — è il tuo RACI degli incidenti. Se quella casella è vuota, l'imputato predefinito sei tu.
2. Tieni fin da ora il tuo registro degli incidenti. Adotta la tassonomia degli incidenti dell'OECD e registra ogni fallimento di IA secondo essa, già oggi. Non aspettare un registro UE obbligatorio per iniziare a imparare dai tuoi stessi outage.
3. Apri un canale di quasi-incidenti senza colpevoli. Il sistema di segnalazione dell'aviazione funziona perché segnalare è sicuro. Rendi sicuro per i tuoi ingegneri segnalare il modello che fa qualcosa di strano prima che diventi un postmortem.
4. Campiona il tuo stesso traffico. Metti observability su input e output del modello come monitoreresti qualsiasi servizio in produzione — drift, risposte anomale, i casi d'uso che non hai mai progettato. È l'idea di Sentinel su scala aziendale, ed è così che scopri l'uso ad alto rischio prima che lo faccia un regolatore o un giornalista.
5. Gradua il tuo controllo per irreversibilità, non per organigramma. Concentra la revisione umana dove una risposta sbagliata non si può ritirare; lascia che il lavoro reversibile vada veloce dietro il monitoraggio. È l'intera tesi del brief, applicata un piano più in basso — ed è semplicemente buona prioritizzazione.

Regola l'IA come un sistema che gira, non come un prodotto che si rilascia

Il giusto equilibrio non è mai stato «più regolamentazione» o «meno». È una regolamentazione puntata sul momento in cui il rischio vive davvero. L'AI Act spende il suo rigore nel giorno del deployment — l'unico giorno in cui sappiamo di meno su come si comporterà il sistema — e lo fattura a tutti allo stesso modo, il che pesa più duramente sui più piccoli. La correzione di Mariniello è spostare quel rigore dove gli ingegneri già tengono il proprio: intorno al sistema in esecuzione, scalato sulla portata, proporzionale a ciò che non si può disfare, e pagato in gran parte da chiunque sia abbastanza grande da sostenerlo. Questa non è deregolamentazione. È la maturità operativa a cui il resto di noi è stato costretto anni fa — la notte in cui abbiamo imparato che non puoi dimostrare un sistema sicuro, puoi solo osservarlo da vicino ed essere pronto ad agire.

Il brief sostiene che l'UE non dovrebbe aspettare il 2031 per emendare l'Act. Io andrei un passo oltre: non aspettare affatto Bruxelles. L'observability e la disciplina sugli incidenti che renderebbero davvero funzionante la regolamentazione ex post sono la stessa disciplina che fa sopravvivere il tuo prodotto al contatto con utenti reali. Se stai ancora mappando dove l'AI Act ricade sul tuo stack, parti da come Bruxelles ha riclassificato un comune strumento di assunzione come ad alto rischio — e poi va' a costruire l'osservazione, perché prima o poi il regolatore ti chiederà se l'hai fatto.