Il vostro framework di governance dell’AI, molto probabilmente, non lo sta usando nessuno.
Non perché sia scritto male. Perché è stato costruito nel modo sbagliato.
Ho visto documenti impeccabili — completi, giuridicamente inattaccabili, perfettamente allineati alla norma — restare fermi in una cartella condivisa mentre i team continuavano a rilasciare esattamente come prima. E ho visto framework molto più poveri cambiare davvero il modo in cui si costruiscono i prodotti.
La differenza non sta nel contenuto. Sta in chi lo scrive, quando e insieme a chi.
Questo articolo parte da una tesi precisa: la governance dell’AI non è un problema legale, è un problema di product design. Il framework è il prodotto, i team sono gli utenti, l’adozione è la metrica. Tutto il resto viene dopo.
Cosa ha cambiato l’AI Act
Fino a poco tempo fa darsi delle regole sull’AI era una scelta. Le aziende mature lo facevano, le altre no, e nessuno chiedeva conto.
Con l’AI Act è diventato un prerequisito.
Il cuore della norma è la classificazione del rischio: non tutti i sistemi di AI sono uguali e gli obblighi cambiano radicalmente a seconda della categoria in cui ricade quello che stai costruendo. Un motore di raccomandazione di contenuti e un sistema che incide su decisioni rilevanti per le persone non possono stare sullo stesso piano.
La conseguenza pratica la sottovalutano quasi tutti: la classificazione va fatta prima di costruire, non dopo.
Scoprire in fase di rilascio che il sistema ricade in una categoria ad alto rischio significa rimettere mano ad architettura, documentazione e processi con il prodotto già pronto. È il momento più sbagliato (costoso) possibile per accorgersene.
Il calendario però è cambiato: l’applicazione degli obblighi sui sistemi ad alto rischio è stata rinviata a dicembre 2027.
Ed è la ragione per cui conviene muoversi adesso. Un framework che i team adottano davvero non si costruisce in un trimestre — e chi userà il rinvio per aspettare arriverà alla scadenza con un numero maggiore di sistemi da classificare.
Classificare il rischio: quattro domande, non una tassonomia
In teoria è un esercizio di categorizzazione normativa. In pratica è un lavoro di traduzione.
La norma parla per categorie generali mentre l’azienda ha casi d’uso concreti. Il lavoro vero è costruire un ponte: un set di domande a cui chiunque stia costruendo un nuovo sistema di AI sappia rispondere senza essere un esperto legale.
Le quattro che funzionano meglio:
- Su cosa incide la decisione del sistema? Su un contenuto mostrato, su un prezzo, su una persona. Cambia tutto.
- C’è un essere umano all’interno del processo? E ha davvero il potere di ribaltare l’output o si limita a firmare?
- Che dati usa e da dove arrivano?
- Cosa succede se sbaglia? Non il caso medio: il danno peggiore realisticamente possibile.
Dalle risposte esce la categoria di rischio. Dalla categoria discendono gli obblighi.
Il vantaggio di questo approccio è che sposta la classificazione dal legale a chi costruisce — l’unico che le risposte le conosce davvero.
Perché i framework calati dall’alto vengono aggirati
Il fallimento ha sempre la stessa forma: un gruppo ristretto scrive le regole, le pubblica, organizza una sessione formativa, considera il lavoro chiuso.
Non funziona, e ci sono tre motivi precisi:
- Le regole scritte da chi non costruisce sono inapplicabili. Chiedono documentazione che nessuno sa produrre, controlli che non si incastrano nel ciclo di sviluppo, approvazioni che arrivano quando la decisione è già stata presa;
- La governance percepita come ostacolo viene aggirata. Non per cattiva volontà. Perché i team hanno obiettivi di consegna. Se il processo di compliance aggiunge tre settimane, qualcuno troverà il modo di non farlo scattare. Sempre.
- Senza owner non c’è adozione. Un documento che nessuno mantiene, interpreta nei casi dubbi e aggiorna quando la realtà cambia invecchia in sei mesi. Poi diventa folklore aziendale.
Chi coinvolgere, e soprattutto quando
Un framework che regge nasce dall’incrocio di quattro punti di vista. Coinvolti mentre si scrive, non alla fine per approvazione:
- Legal e compliance portano il vincolo normativo. Ma non possono decidere da soli come si applica al prodotto.
- Security porta la gestione del rischio tecnico e i controlli che esistono già — su cui conviene appoggiarsi invece di inventarne di nuovi.
- Business porta i casi d’uso reali e il senso della proporzione: quanto attrito l’organizzazione può sostenere.
- Engineering porta la fattibilità: quali controlli si possono automatizzare e quali diventeranno un modulo che nessuno compila.
Il momento giusto per chiamarli è il primo. Un framework scritto in isolamento e poi “condiviso per commenti” riceve commenti. Un framework scritto insieme riceve adozione.
Come si vede che sta funzionando
Un buon framework, una volta a regime, passa quasi inosservato. È esattamente il segnale che sta funzionando.
In concreto significa che:
- Proporre un nuovo sistema di AI passa da un check di classificazione breve e obbligatorio;
- La categoria di rischio attiva automaticamente i controlli previsti, senza trattativa caso per caso;
- La documentazione si produce durante lo sviluppo, non si ricostruisce alla fine;
- Esiste un registro dei sistemi in uso, aggiornato, con un responsabile che lo mantiene aggiornato.
Nessuno di questi punti preso da solo è entusiasmante. Tutti insieme distinguono un’azienda che sa dimostrare come governa l’AI da una che spera di non doverlo mai fare.
Tre errori che ho visto ripetersi
- Trattare la governance come un progetto. Ha una data di inizio ma non una data di fine. I sistemi cambiano, la norma si evolve, i casi d’uso si moltiplicano;
- Puntare alla completezza al primo giro. Un framework che copre il 70% dei casi ed è usato batte uno che li copre tutti e resta fermo. La versione uno deve essere volutamente incompleta;
- Confondere conformità e fiducia. Rispettare la norma è il minimo sindacale. La domanda che conta davvero — ci fideremmo di questo sistema se decidesse su di noi? — non è scritta in nessun regolamento.
Il punto
L’AI Act ha spostato la governance dell’AI da tema etico a requisito operativo. Ma la norma dice cosa serve. Non dice come farlo accadere dentro un’organizzazione con decine di team e obiettivi di consegna trimestrali.
Quel “come” è un problema di design, non di diritto.
Se nessuno usa il vostro framework, non avete un problema di consapevolezza. Avete un problema di prodotto.
