Nella parte precedente della nostra serie abbiamo risposto alla domanda, quando l'AI può agire in autonomia e quando ha bisogno dell'uomo.
Abbiamo mostrato che il livello di autonomia dovrebbe dipendere, tra l'altro, da:
- rischio,
- costo dell'errore,
- reversibilità della decisione,
- impatto sulla persona,
- qualità dei dati,
- capacità di monitorare il sistema.
Sappiamo anche che l'aggiunta dell'uomo al processo non garantisce automaticamente la sicurezza.
Si può avere un dipendente che approva le decisioni dell'AI ma non dargli tempo sufficiente per analizzarle. Si può richiedere una approvazione senza mostrare perché il sistema ha preso una determinata decisione. Si può costruire un sistema che funziona correttamente per un anno e poi comincia a generare risultati errati perché i dati, i comportamenti degli utenti o le condizioni di mercato sono cambiati.
Per questo, a un certo punto sorge una domanda più ampia di: "L'AI funziona correttamente?"
La domanda diventa: "Come organizzazione, riusciamo a controllare l'AI che abbiamo implementato?"
Ed è proprio a questo che si occupa l'AI Governance.
Cos'è l'AI Governance?
L'AI Governance può essere descritta, nel modo più semplice, come un sistema di regole, processi, responsabilità e meccanismi di controllo relativi all'uso dell'intelligenza artificiale in un'organizzazione.
Non è un solo documento. Non è una sola procedura. Non è solo una questione legale.
Una AI Governance matura comprende molte aree:
- strategia di utilizzo dell'AI,
- sicurezza,
- protezione dei dati,
- gestione del rischio,
- conformità normativa,
- responsabilità,
- monitoraggio dei modelli,
- controllo degli accessi,
- audit,
- gestione delle modifiche,
- risposta agli incidenti.
Si può dunque dire che l'AI Governance risponde alla domanda: "Come fare in modo che l'intelligenza artificiale operi in linea con gli obiettivi dell'organizzazione, le regole vigenti e un livello di rischio accettabile?"
Questo è particolarmente importante quando l'AI smette di essere uno strumento usato da un singolo dipendente e diventa parte integrante dei processi aziendali.
L'AI Governance non è un freno all'innovazione
Uno dei malintesi più frequenti è considerare la governance come burocrazia.
In questo approccio nasce la paura: "Se creiamo troppe regole, nessuno vorrà implementare l'AI."
Il problema è che l'assenza di regole ha anch'essa un costo.
Immaginiamo un'azienda in cui:
- ogni dipendente può usare qualsiasi strumento AI,
- nessuno sa quali dati finiscono nei modelli,
- non è chiaro quali processi siano automatizzati,
- non esiste un inventario dei modelli usati,
- nessuno monitora i risultati,
- nessuno è responsabile degli errori.
All'inizio tutto può funzionare benissimo. Fino a quando non accade qualcosa di imprevisto.
L'AI Governance non dovrebbe bloccare l'AI. Dovrebbe creare quadri sicuri in cui l'AI possa crescere più rapidamente.
Una governance ben progettata permette di rispondere a domande come:
- cosa possiamo fare,
- cosa non possiamo fare,
- chi prende le decisioni,
- chi è responsabile del sistema,
- come monitoriamo il rischio,
- cosa facciamo quando qualcosa va storto.
Non è un freno. È una cintura di sicurezza.
Chi è responsabile della decisione dell'AI?
Questa è una delle domande più difficili.
Supponiamo che un sistema AI consigli di respingere la richiesta di un cliente. Chi è responsabile di quella decisione? Lo sviluppatore? Il fornitore del modello? L'azienda che ha implementato il sistema? La persona che ha approvato la raccomandazione? Il manager responsabile del processo? O forse il consiglio di amministrazione?
La risposta non è sempre semplice...
Proprio per questo la responsabilità deve essere definita prima dell'implementazione del sistema, non dopo l'insorgere del problema.
In pratica, l'organizzazione dovrebbe definire chiaramente:
- chi è il proprietario del processo,
- chi è il proprietario del sistema,
- chi è responsabile dei dati,
- chi è responsabile del modello,
- chi approva le modifiche,
- chi monitora il funzionamento,
- chi può fermare il sistema,
- chi prende decisioni in emergenza.
Nel caso di sistemi AI complessi non basta dire: "L'ha fatto l'intelligenza artificiale."
L'AI non è un soggetto responsabile di un processo aziendale. La responsabilità resta con le persone e con l'organizzazione.
L'AI Governance inizia dall'inventario
Uno dei primi passi dovrebbe essere la creazione di un AI Inventory, cioè il registro dei sistemi e degli usi dell'AI presenti nell'organizzazione.
Sembra banale? In molte aziende può rivelarsi sorprendentemente difficile.
I dipendenti usano:
- ChatGPT,
- strumenti per generare contenuti,
- AI nei CRM,
- strumenti di analisi documentale,
- assistant per sviluppatori,
- automazioni,
- agenti AI.
Alcune di queste soluzioni possono essere ufficialmente adottate dall'azienda. Altre possono essere usate dai dipendenti senza la conoscenza formale dell'organizzazione.
Questo fenomeno è spesso definito Shadow AI.
Shadow AI - quando l'AI opera fuori dal controllo aziendale
Shadow AI è l'equivalente del noto concetto di Shadow IT. Un dipendente trova uno strumento che lo aiuta a lavorare più velocemente e comincia ad usarlo.
Nessuno verifica:
- quali dati vengono inviati,
- dove vengono elaborati,
- chi ha accesso ad essi,
- per quanto tempo vengono conservati,
- se le informazioni possono essere usate per addestrare modelli.
Dal punto di vista del dipendente tutto sembra funzionare bene. Dal punto di vista dell'azienda può nascere un rischio serio.
Per questo vietare l'uso dell'AI non è sempre la soluzione migliore. Un approccio molto più efficace è creare regole chiare.
Il dipendente dovrebbe sapere:
- quali strumenti può utilizzare,
- quali dati non possono essere inviati,
- quando è richiesta un'approvazione,
- quali soluzioni sono raccomandate dall'azienda.
Meglio creare un percorso sicuro per l'uso dell'AI che fingere che i dipendenti non la useranno.
Dati - il fondamento dell'AI responsabile
Non si può parlare di governance senza parlare di dati. Un sistema AI può essere molto buono.
Ma se i dati sono:
- errati,
- obsoleti,
- incompleti,
- incoerenti,
- male descritti,
i risultati del sistema possono diventare problematici.
In azienda dovrebbero esistere regole chiare riguardo a:
- fonti dei dati,
- qualità dei dati,
- accesso,
- conservazione,
- retention,
- cancellazione,
- anonimizzazione,
- pseudonimizzazione,
- controllo sull'uso dei dati.
Particolare importanza ha la protezione dei dati personali.
Non tutte le informazioni in possesso di un'azienda dovrebbero finire in un modello AI.
E anche se possono essere trattate, è necessario sapere:
- perché?
- su quale base giuridica?
- in che modo?
- per quanto tempo?
- chi vi ha accesso?
Per questo motivo l'implementazione dell'AI dovrebbe essere progettata congiuntamente dai team tecnologici, business, legali e di sicurezza.
AI Act - perché le aziende dovrebbero interessarsene?
Nell'Unione Europea lo sviluppo dell'intelligenza artificiale è anche oggetto di regolamentazione.
Il caso più importante è l'AI Act, il regolamento UE sull'intelligenza artificiale. Uno degli elementi chiave di questo approccio è la classificazione dei sistemi AI in base al livello di rischio.
In termini semplificati possiamo parlare di:
- sistemi che rappresentano un rischio inaccettabile,
- sistemi ad alto rischio,
- sistemi soggetti a obblighi di trasparenza,
- sistemi a rischio limitato o minimo.
Questo non significa che ogni azienda debba creare un enorme reparto compliance.
Significa però che le organizzazioni dovrebbero sapere che tipo di sistemi AI utilizzano e quali obblighi potrebbero derivarne.
È utile ricordare che le normative non riguardano solo il modello in sé. È importante anche il modo in cui l'AI viene usata.
Lo stesso modello può essere usato per generare la descrizione di un prodotto o per supportare un processo che incide sui diritti umani. La tecnologia è la stessa, il rischio è completamente diverso.
Per questo la governance dovrebbe analizzare soprattutto l'uso del sistema, non solo il suo nome o il suo produttore.
Explainable AI - perché il sistema dovrebbe essere in grado di spiegarsi?
Se l'AI prende decisioni che influenzano il business o le persone, è naturale chiedersi: "Perché?"
Perché il sistema ha ritenuto una transazione sospetta?
Perché ha respinto un documento?
Perché ha suggerito un prezzo specifico?
Perché ha indirizzato un cliente a un determinato processo?
È qui che entra in gioco l'Explainable AI (XAI). Si tratta di metodi e approcci che aiutano a capire come il modello è arrivato a un certo risultato. Non sempre significa poter mostrare l'intero processo interno del modello.
A volte è sufficiente fornire:
- i fattori chiave che hanno influenzato il risultato,
- i dati usati per l'analisi,
- il livello di confidenza,
- le principali assunzioni,
- scenari alternativi.
Per un utente business questo spesso è più importante di una descrizione tecnica del modello.
Logging - la memoria del sistema AI
Se l'AI prende decisioni, l'organizzazione dovrebbe poter ricostruire cosa è successo. Per questo il logging è cruciale.
A seconda del tipo di sistema è opportuno registrare:
- quando è stata eseguita l'operazione,
- quale modello è stato usato,
- quale versione del modello era attiva,
- quali dati in ingresso sono stati usati,
- quale risultato è stato generato,
- quale decisione è stata presa,
- l'uomo ha approvato il risultato?,
- la decisione è stata modificata?,
- chi ha effettuato la modifica.
Questo permette di rispondere alla domanda: "Cosa è esattamente accaduto nel sistema?"
Senza un adeguato logging l'analisi di un incidente può essere molto difficile. E in sistemi autonomi può diventare impossibile.
Monitoring - l'AI non è un "deploy e dimentica"
Questo è uno degli elementi più importanti dell'intero puzzle.
Un modello può funzionare correttamente il giorno del rilascio. Questo non significa che funzionerà altrettanto bene tra un anno.
Cambiano:
- i dati,
- i comportamenti degli utenti,
- le condizioni di mercato,
- i prodotti,
- i processi,
- la legge.
Può anche cambiare il comportamento del sistema stesso. Perciò bisogna monitorare non solo l'infrastruttura tecnica, ma anche la qualità delle decisioni.
A seconda dell'uso è utile osservare:
- accuratezza,
- numero di errori,
- livello di confidenza,
- percentuale di decisioni inoltrate all'uomo,
- numero di interventi umani,
- numero di reclami,
- scostamenti tra la raccomandazione AI e la decisione dell'esperto.
Se improvvisamente l'uomo inizia a respingere il 40% delle raccomandazioni dell'AI invece del precedente 5%, potrebbe essere un segnale che qualcosa è cambiato.
Il modello funziona ancora. Ma la sua qualità business non lo è più necessariamente.
Model Drift - quando il mondo cambia più veloce del modello
Uno dei problemi importanti è il model drift, cioè il peggioramento delle prestazioni del modello a causa di cambiamenti nei dati o nell'ambiente.
Un esempio?
Un modello prevede la domanda di prodotti basandosi sui dati degli ultimi cinque anni.
Improvvisamente cambiano i comportamenti dei consumatori.
Compare una nuova tendenza.
Cambia la situazione economica.
Il modello continua a usare pattern storici.
Il problema è che la realtà non è più la stessa.
L'AI non "sa" che la realtà è cambiata.
Per questo il sistema deve essere monitorato e i modelli valutati periodicamente e, se necessario, aggiornati.
Guardrails - confini che l'AI non può superare
Nella parte precedente abbiamo menzionato i guardrails. Nel contesto dell'AI Governance la loro importanza è ancora maggiore.
I guardrails possono definire:
- quali dati l'AI può usare,
- quali azioni può compiere,
- quali azioni non può compiere,
- quali valori può modificare,
- quando è richiesta l'approvazione umana,
- quando il sistema deve fermarsi.
Ad esempio un agente AI può avere accesso al sistema ordini. Può verificare la disponibilità di un prodotto. Può preparare un ordine. Ma non può approvare un acquisto superiore a 10.000 PLN. Se la somma supera il limite, il sistema passa il caso a un essere umano.
Questo è un esempio di confine di autonomia ben progettato.
Kill Switch - il sistema deve avere un pulsante STOP
Sembra banale. Ma è estremamente importante.
Ogni sistema autonomo dovrebbe avere un meccanismo di arresto d'emergenza.
Se:
- il modello inizia a generare decisioni errate,
- il sistema compie operazioni atipiche,
- si verifica un incidente di sicurezza,
- i dati in ingresso sono scorretti,
l'organizzazione deve poter fermare il funzionamento del sistema. Non domani. Non dopo aver aperto un ticket al supporto. Ma immediatamente!
A seconda dell'architettura questo può significare:
- spegnere l'agente,
- bloccare l'accesso agli strumenti,
- fermare il flusso di lavoro,
- passare in modalità manuale,
- rollback a una versione precedente.
L'autonomia senza la possibilità di arresto è molto rischiosa.
Incident Response per l'AI
Le organizzazioni da anni hanno procedure per reagire alle interruzioni di sistema.
Nel caso dell'AI abbiamo bisogno anche di scenari specifici relativi a decisioni errate dei modelli.
Cosa facciamo se:
- l'AI inizia a generare raccomandazioni scorrette?
- un agente compie azioni errate?
- il modello mostra comportamenti indesiderati?
- i dati in ingresso si rivelano errati?
- il sistema viola le regole stabilite?
Dovrebbe esistere un processo chiaro: Rilevamento → arresto → analisi → correzione → ripristino → monitoraggio
Questo è particolarmente importante nei sistemi che operano in modo autonomo.
Chi dovrebbe essere responsabile dell'AI in azienda?
Non esiste una risposta universale.
A seconda delle dimensioni dell'azienda possono essere coinvolti:
- il consiglio di amministrazione,
- CTO,
- CIO,
- CISO,
- ufficio legale,
- compliance,
- Data Protection Officer,
- proprietari dei processi,
- team IT,
- data scientist,
- ingegneri ML,
- product manager,
- utenti business.
È importante però che la responsabilità non sia sfumata.
"L'AI è di tutti" spesso significa, nella pratica: "Nessuno ne è responsabile."
Per questo ogni iniziativa AI rilevante dovrebbe avere un proprietario chiaramente definito.
RACI per i sistemi AI
Un buon strumento può essere il classico modello RACI.
Permette di definire:
Responsible - chi esegue il compito?
Accountable - chi ha la responsabilità finale?
Consulted - chi deve essere consultato?
Informed - chi deve essere informato?
Ad esempio, per un sistema AI che supporta l'assistenza clienti:
- IT è responsabile dell'infrastruttura,
- il data team dei dati,
- il proprietario del processo dell'uso dell'AI,
- compliance della valutazione dei requisiti normativi,
- il business dell'approvazione della soluzione.
Così, in caso di problema, è chiaro chi deve reagire.
AI Governance in una piccola azienda
L'AI Governance non deve significare creare un grande comitato.
Una piccola azienda può iniziare con pochi elementi semplici:
1. Elenco degli strumenti AI
Sapere cosa usiamo.
2. Regole sui dati
Sapere cosa non inviare a servizi esterni.
3. Classificazione del rischio
Stabilire quali applicazioni sono a basso, medio o alto rischio.
4. Proprietario AI
Designare una persona responsabile della coordinazione.
5. Regole Human-in-the-Loop
Definire quando una decisione richiede l'intervento umano.
6. Monitoring
Verificare che il sistema continui a funzionare come previsto.
Questo è già molto.
La cosa più importante è la consapevolezza.
AI Governance in una grande organizzazione
In una realtà più grande la situazione è più complessa.
Potrebbe essere necessario:
- un AI Governance Board,
- un registro dei modelli,
- una classificazione del rischio,
- un processo di approvazione per nuovi usi,
- politiche sui dati,
- monitoraggio dei modelli,
- audit,
- procedure per gli incidenti,
- controllo degli accessi,
- gestione dei fornitori AI,
- revisioni periodiche.
Nelle grandi organizzazioni la governance dovrebbe essere integrata anche con i processi esistenti:
- IT Governance,
- Security Governance,
- Data Governance,
- Risk Management,
- Compliance.
L'AI non opera nel vuoto.
Diventa un elemento dell'intero ecosistema di gestione dell'organizzazione.
Errori più comuni nell'AI Governance
Errore 1 - la governance arriva solo dopo il deploy
Prima deployiamo l'AI.
Poi ci chiediamo chi ne è responsabile.
È l'ordine sbagliato.
Errore 2 - la governance è solo un documento
La policy AI da sola non risolve nulla.
Se nessuno la applica, rimane solo un documento.
Errore 3 - la responsabilità è assegnata solo all'IT
L'AI impatta business, diritto, sicurezza e persone.
Non può essere solo un problema del reparto tecnologico.
Errore 4 - mancanza di monitoring
Il modello è stato distribuito.
Tutti si sono dimenticati di lui.
Dopo un anno si scopre che il sistema funziona in modo completamente diverso rispetto all'inizio.
Errore 5 - assenza di arresto rapido dell'AI
Se il sistema opera in autonomia ma nessuno può fermarlo rapidamente, l'organizzazione non controlla il sistema.
Checklist pratica di AI Governance
L'organizzazione dovrebbe avere:
\u2610 un registro dei sistemi AI usati,
\u2610 un proprietario definito per ogni sistema rilevante,
\u2610 classificazione del livello di rischio,
\u2610 regole sui dati,
\u2610 policy di utilizzo dell'AI,
\u2610 regole per lo Shadow AI,
\u2610 meccanismi di controllo degli accessi,
\u2610 logging delle attività del sistema,
\u2610 monitoring della qualità,
\u2610 procedura di risposta agli incidenti,
\u2610 possibilità di arrestare il sistema,
\u2610 regole Human-in-the-Loop,
\u2610 revisioni periodiche dei modelli,
\u2610 valutazione dei requisiti normativi,
\u2610 regole chiare di responsabilità.
Se la maggior parte delle risposte è "no", l'azienda probabilmente non ha ancora una AI Governance matura.
Glossario dei termini
AI Governance
Insieme di regole, processi, responsabilità e meccanismi di controllo relativi alla progettazione, implementazione e uso dell'intelligenza artificiale.
Shadow AI
Uso informale o non autorizzato da parte dei dipendenti di strumenti AI al di fuori del processo ufficiale di gestione dell'organizzazione.
AI Inventory
Registro dei sistemi, modelli e applicazioni AI utilizzati nell'organizzazione.
Model Drift
Peggioramento della qualità delle prestazioni del modello dovuto a cambiamenti nei dati o nell'ambiente in cui opera.
Explainable AI (XAI)
Approcci e metodi che permettono di comprendere meglio i fattori che influenzano i risultati dei modelli AI.
AI Audit
Valutazione di un sistema AI in termini di funzionamento, sicurezza, conformità, qualità dei dati, rischio e aderenza a requisiti specifici.
Guardrails
Limitazioni che definiscono quali azioni un sistema AI può o non può intraprendere.
Kill Switch
Meccanismo che consente di arrestare rapidamente il sistema o limitare il suo funzionamento in caso di emergenza.
AI Incident
Evento legato a un sistema AI che può portare a errori, violazioni di sicurezza, non conformità o altre conseguenze indesiderate.
La conclusione più importante
Human-in-the-Loop ci dice: "L'uomo dovrebbe rimanere parte del processo."
L'AI Governance va oltre.
Dice: "L'organizzazione deve sapere come controllare questo processo."
Questa è una differenza fondamentale.
Possiamo creare l'agente AI più avanzato. Possiamo dargli accesso ai sistemi. Possiamo permettergli di pianificare e compiere azioni.
Ma se non sappiamo:
- cosa fa,
- perché lo fa,
- chi ne è responsabile,
- su quali dati opera,
- quando comincia a sbagliare,
- come fermarlo,
non abbiamo creato un sistema intelligente. Abbiamo creato un sistema che non sappiamo controllare.
E in un mondo di agenti sempre più autonomi, il controllo potrebbe diventare una delle più importanti leve competitive per le organizzazioni.
Nell'ultima, quarta parte della serie passeremo dai principi all'architettura.
Mostreremo come potrebbe essere un sistema AI progettato con attenzione alla sicurezza, al controllo e alla responsabilità: dal modello e dall'agente, allo strato decisionale e alle regole di business, fino al workflow, al monitoring, all'override umano e ai meccanismi di emergenza.
Perché, in definitiva, la domanda più importante non è: "Siamo in grado di costruire un agente AI autonomo?"
Oggi sempre più spesso sì, siamo in grado.
La domanda è: "Siamo in grado di costruire un agente su cui manteniamo ancora il controllo?"
