Governance dell'AI in una PMI: i controlli che rendono un caso d'uso difendibile

C'è una domanda che viene prima di scegliere lo strumento e una che viene dopo. La prima — «devo adeguarmi all'AI Act? sono obbligato?» — l'abbiamo affrontata nell'articolo sull'EU AI Act per le PMI, e per la maggior parte delle imprese la risposta è più tranquilla del previsto. Questa è l'altra: una volta che hai deciso di mettere in produzione un caso d'uso — un copilota per le vendite, un bot di supporto, un'automazione in amministrazione — come lo governi perché regga? Regga a un controllo del Garante, a una richiesta di un cliente, a un incidente, alla domanda scomoda di un revisore.

È una domanda diversa dalla conformità formale, ed è quella su cui vediamo più leggerezza. Non «sono a posto con la legge?», ma «se qualcosa va storto, cosa posso mostrare?». La differenza tra le due è tutta la governance. Proviamo a metterla in ordine, in lingua piana, senza allarmismi e senza trasformarla nel solito documento di venti pagine che nessuno legge.

La governance non è un documento: è un blocco che accompagna ogni caso d'uso

L'errore più comune è pensare alla governance dell'AI come a una policy generale — un PDF che dichiara principi e finisce in una cartella. Non funziona così, perché il rischio non vive nell'azienda in astratto: vive nel singolo workflow. Un copilota che suggerisce risposte al supporto e un sistema che filtra i CV in ingresso hanno lo stesso «livello di attenzione aziendale», ma un profilo di rischio incomparabile. La governance seria si aggancia al caso d'uso, non all'organizzazione.

Quello che usiamo — ed è la struttura che consigliamo a qualunque PMI, anche senza di noi — è un blocco breve e ripetibile che accompagna ogni disegno di workflow. Cinque righe, sempre le stesse:

• Livello di rischio — dove ricade il caso d'uso nella scala dell'AI Act (quasi sempre minimo o limitato; alto solo per personale, credito, biometria).
• Serve una DPIA? — il controllo GDPR sul trattamento dei dati personali coinvolti (vedi sotto: quando scatta e perché quella «standard» non basta).
• Etichette di rischio — una classificazione dei modi in cui quel workflow può fallire, con un vocabolario condiviso invece che a parole (vedi la tassonomia MIT più avanti).
• Mitigazioni — cosa mettiamo attorno al rischio: soglie, limiti di autonomia, revisione umana, minimizzazione dei dati.
• Sorveglianza e tracciabilità — chi vigila sull'operatività e cosa resta registrato, per quanto tempo.

Il valore di questo blocco non è formale: è operativo. Quando il Garante, un cliente o un revisore chiede «come gestite questo sistema?», non rispondi con una filosofia — apri il blocco del workflow specifico e mostri le cinque righe. È la differenza tra dichiarare di essere governati ed esserlo per davvero.

La DPIA per l'AI: quando serve, e perché quella «standard» non basta

La valutazione d'impatto sulla protezione dei dati (DPIA, art. 35 GDPR) è il primo strumento concreto della governance, ma è anche il più frainteso. Non serve sempre: diventa obbligatoria quando il trattamento è «probabilmente ad alto rischio». Ci sono tre casi che la rendono automatica — decisioni automatizzate con effetti giuridici o significativi sulla persona, trattamento su larga scala di dati particolari (salute, opinioni, biometria), e monitoraggio sistematico di aree accessibili al pubblico — a cui l'EDPB aggiunge nove criteri supplementari (profilazione, valutazione, uso di tecnologie innovative). La maggior parte dei deployment AI aziendali ne tocca almeno uno.

Fin qui è GDPR classico. Il punto che quasi nessun modello prende in considerazione è che una DPIA generica, pensata per un database o un gestionale, manca i rischi propri dell'AI. Un modello non è una tabella: ha comportamenti che una valutazione tradizionale non prevede. In una DPIA per l'AI vanno aggiunte, come sezione dedicata, almeno quattro voci che altrove non esistono:

• Opacità del modello — la decisione può non essere spiegabile riga per riga. Se il workflow incide su una persona, «non so perché ha deciso così» è un problema di conformità, non solo tecnico.
• Deriva (drift) — un modello che funzionava bene degrada nel tempo se i dati d'ingresso cambiano. Un controllo fatto una volta al lancio non basta: va rifatto.
• Memorizzazione dei dati di addestramento — un modello può rigurgitare frammenti dei dati con cui è stato addestrato, comprese informazioni personali. È un vettore di violazione che un database non ha.
• Conflitto con il diritto all'oblio — cancellare un dato personale da un database è banale; «disimparare» un dato da un modello già addestrato spesso non lo è. La DPIA deve dire cosa si fa quando arriva quella richiesta.

Se il tuo consulente ti propone la DPIA che userebbe per qualunque software, senza questa sezione, ti sta dando un modulo, non una valutazione. E se la DPIA rileva un rischio alto che non riesci a mitigare, il GDPR (art. 36) chiede di consultare l'autorità di controllo prima di procedere: raro per una PMI, ma va previsto come ramo di escalation, non scoperto a incidente avvenuto.

Un vocabolario condiviso per il rischio, invece delle parole

«Questo sistema è rischioso» non è un'informazione utile: è un'impressione. Il salto di qualità nella governance è passare da una prosa vaga a un'etichetta ripetibile e citabile, la stessa per tutti i workflow, così che due casi d'uso diversi si possano confrontare. Per questo usiamo come vocabolario di riferimento l'AI Risk Repository del MIT, che classifica il rischio su due assi:

• Come nasce il rischio (asse causale): l'entità che lo genera (umano / AI / altro), l'intenzione (intenzionale / non intenzionale), il momento (prima o dopo il rilascio).
• Che tipo di rischio è (asse di dominio): sette domini — discriminazione, privacy e sicurezza, disinformazione, uso doloso, interazione uomo-macchina, effetti socioeconomici, guasti e limiti del sistema.

Un esempio rende concreto il metodo. Un copilota per le vendite che ogni tanto «inventa» un dettaglio su un prodotto — la classica allucinazione — si etichetta come (entità: AI · intenzione: non intenzionale · momento: dopo il rilascio) × (dominio: disinformazione). Non è un vezzo accademico: quell'etichetta ti dice dove agire (a valle, con una verifica umana sull'output prima che arrivi al cliente) e ti dà una parola comune per parlarne con chi il modello non lo capisce. La prosa non lo fa: l'etichetta sì.

I due controlli operativi che contano più di tutti gli altri

Si può scrivere una governance elaborata e restare esposti; oppure tenerne una snella con due controlli solidi ed essere davvero difendibili. In quasi ogni caso d'uso di una PMI, questi due fanno la differenza.

Il primo è l'umano nel processo. Non come slogan, ma come architettura: chi vigila sull'operatività del sistema, con quale autorità di fermarlo, e su quali decisioni è obbligatorio il suo passaggio. È lo stesso principio che rende difendibile un agente in amministrazione e finanza — dove l'esito è irreversibile perché muove denaro — ma vale ovunque una decisione tocchi una persona. La regola pratica che diamo: concedi autonomia al sistema solo dove l'esito è reversibile e verificabile; tutto il resto passa da una persona.

Il secondo è la tracciabilità. Per gli usi ad alto rischio l'articolo 26 dell'AI Act chiede al deployer di conservare i log per almeno sei mesi e di segnalare gli incidenti seri; ma anche fuori da quel perimetro, tenere traccia di cosa ha deciso il sistema, su quali dati e chi ha approvato è ciò che trasforma «ci fidiamo» in «possiamo dimostrarlo». Un registro a prova di controllo, non un prompt. È il controllo più economico da mettere e il più costoso da non avere quando serve.

Il quadro italiano: la conformità è un'area viva, non una casella

Chi ti vende una governance «una volta e per sempre» non guarda cosa succede in Italia. La Legge 132/2025 ha introdotto i principi generali del Paese sull'AI ed estende l'ambito della DPIA per gli usi di intelligenza artificiale oltre la base del GDPR — il che significa che vanno verificati i requisiti attuali prima di citarli a un cliente, perché il testo è recente e la materia si muove. Sul fronte controlli, con la deliberazione del 30 dicembre 2025 il Garante per la protezione dei dati personali ha programmato per il periodo gennaio/luglio 2026 almeno 40 accertamenti ispettivi, e fra le aree elencate compaiono espressamente le verifiche sull'utilizzo di strumenti di intelligenza artificiale in ambito scolastico. Anche se il tuo caso d'uso è lontano dalla scuola, dice una cosa che conta: l'attività ispettiva sull'AI è già messa a programma, non è un'ipotesi. La pagina del Garante sull'AI è la fonte canonica da ricontrollare a ogni progetto, perché gli orientamenti si aggiornano spesso.

La lettura pratica: la governance non è un documento che firmi e archivi, è una pratica che si rivede. Un modello deriva, una norma cambia, un caso d'uso si estende — e il blocco delle cinque righe va riaperto. Chi te la vende come una casella spuntata una volta ti sta rassicurando, non proteggendo.

Da orientarsi a fare, in pratica

Se stai per mettere in produzione un caso d'uso e vuoi che regga, il percorso è corto e ordinato:

• Aggancia il blocco al workflow, non all'azienda — livello di rischio, DPIA sì/no, etichette, mitigazioni, sorveglianza. Cinque righe per ogni caso d'uso, non un PDF per l'intera impresa.
• Se serve una DPIA, usane una con la sezione AI — opacità, deriva, memorizzazione, diritto all'oblio. Senza quelle voci non è una valutazione dell'AI, è un modulo.
• Dai un'etichetta al rischio, non un aggettivo — un vocabolario condiviso rende i casi confrontabili e le mitigazioni ovvie.
• Metti umano-nel-processo e tracciabilità dal primo giorno — non rallentano il progetto: lo rendono difendibile. Sono i due controlli che valgono più di tutta la policy scritta.
• Trattala come viva — ricontrolla il modello, la norma italiana e il perimetro d'uso a intervalli, non una volta al lancio.

Prima ancora, però, conviene sapere dove sei: la nostra valutazione di AI-readiness aiuta a capire da quale reparto partire con più ritorno e meno attrito, e quali controlli mettere attorno al primo workflow. È esattamente questo blocco di governance che il nostro overlay di conformità aggancia a ogni disegno che progettiamo — non un documento a parte, ma i controlli dentro il flusso.

Abbiamo trasformato il primo passo in una valutazione self-serve e gratuita: poche domande e un'indicazione su da dove partire, con quali controlli attorno. Fai la valutazione di AI-readiness — e se il tema è la governance di un caso d'uso che stai per adottare, scrivici e ne parliamo.

Questo articolo ha scopo orientativo e non costituisce consulenza legale. Il quadro normativo su AI Act, GDPR e legge italiana è in evoluzione — in particolare scadenze, ambito della DPIA e orientamenti del Garante possono cambiare: vanno verificati sul testo vigente per il caso concreto della singola azienda.