DECISION TOOLKIT · MODELLO OPERATIVO DI GOVERNANCE
Allineare l’intensità dei controlli alla conseguenza
Il rischio non è una proprietà del nome del modello. Dipende dalla conseguenza del workflow, dall’autorità concessa al sistema e dalla capacità di rilevare e invertire un errore.
drafting, ricerca, lavoro interno a basso impatto
strumento approvato · responsabilità utente · log leggerigiudizio professionale o contenuto esterno
evaluation set · reviewer · output tracciabilescrive nei sistemi o incide sui clienti
least privilege · chiamate validate · confermadiritti, sicurezza, finanza o decisioni regolamentate
approvazione formale · assurance indipendente · esercitazione incidenteCreare un fast track per gli usi a basso rischio; riservare la governance più forte ai workflow con potenziale di danno materiale.
La governance dell’AI non funziona se consiste soltanto in principi, una policy e un comitato di approvazione. Deve rispondere operativamente a quattro domande: quali sistemi esistono, quale rischio comportano, chi può decidere cosa e quali evidenze dimostrano che i controlli funzionano?
Per le imprese svizzere, il punto di partenza è la Legge federale sulla protezione dei dati e gli obblighi specifici dell’organizzazione. Secondo mercato, clienti e utilizzo, può essere rilevante anche l’EU AI Act. La governance deve quindi abilitare l’analisi giuridica senza confondersi con essa.
1. Mantenere un inventario AI vivo
L’inventario non deve contenere solo le piattaforme acquistate ufficialmente. Include workspace enterprise, API, funzioni AI incorporate nel SaaS, coding agent, modelli locali, esperimenti e account personali critici.
Per ogni sistema servono almeno:
- processo aziendale e gruppi di utenti interessati;
- classi di dati e percorsi informativi;
- modelli, fornitori e pattern di deployment e integrazione;
- azioni possibili e approvazioni umane;
- business, technical e risk owner;
- stato del ciclo di vita e prossima review.
Un foglio annuale non basta. L’inventario deve collegarsi a procurement, architettura, sicurezza e delivery.
2. Classificare per impatto e autorità
La classe di rischio non può dipendere solo dal nome del modello. Conta il sistema: finalità, utenti, dati e capacità di agire.
| Dimensione | Domanda guida |
|---|---|
| Impatto | Influenza persone, denaro, diritti o processi critici? |
| Dati | Tratta informazioni confidenziali, personali o regolamentate? |
| Autorità | Può scrivere, eseguire, comunicare o avviare transazioni? |
| Esposizione | È interno, rivolto ai clienti o pubblico? |
| Dipendenza | Le persone possono realisticamente verificare e correggere il risultato? |
Un assistente interno per bozze può seguire un percorso leggero. Un agente con diritti di scrittura nei sistemi core richiede architettura, evaluation, approvazioni e incident readiness più forti.
3. Tradurre le policy in controlli
Una regola come «nessun dato confidenziale nei sistemi non approvati» è operativa solo se il sistema approvato è facile da usare, le identità sono gestite, le classi di dati sono comprese e i confini tecnici sostengono il percorso sicuro.
Un sistema completo copre quattro livelli:
- Organizzazione — ownership, acceptable use, formazione, procurement ed escalation.
- Architettura — identità, confini dei dati, rete, isolamento, segreti e integrazioni.
- Modello e applicazione — evaluation, grounding, prompt injection, controlli degli output e gate umani.
- Operations — logging, monitoring, cambiamenti, incidenti, review e shutdown.
Ogni controllo necessita di owner, frequenza, evidenza e collegamento motivato con il rischio.
4. Definire l’evaluation prima dell’approvazione
«Il modello sembra buono» non è un criterio di accettazione. Un evaluation set deve includere task rappresentativi, caratteristiche qualitative attese e failure mode rilevanti: affermazioni false, uso non sicuro dei tool, perdita di dati, superamento dei permessi, prompt injection e incertezza non dichiarata.
La soglia è basata sul rischio. L’ideazione creativa richiede uno standard diverso dall’analisi contrattuale, dalla comunicazione cliente o dalle modifiche al codice.
5. Rendere visibile l’accettazione del rischio
Non ogni rischio residuo può essere eliminato tecnicamente. Una persona nominata deve allora accettarlo con contesto, durata e condizioni. Un decision record solido indica:
- utilizzo e rischio interessati;
- evidenze esaminate;
- controlli applicati e lacune residue;
- chi accetta, fino a quando e a quali condizioni;
- evento che attiva una nuova revisione.
6. Operare la governance come servizio
La governance scala quando il percorso sicuro è più chiaro e veloce di quello informale. Servono template, piattaforme approvate, architetture standard, evaluation harness e fast track definiti per usi a basso rischio.
Un forum mensile non deve prendere ogni decisione tecnica. Governa il portafoglio, valuta eccezioni, osserva incidenti e definisce nuovi confini di rischio. I delivery team restano responsabili dei controlli nei propri sistemi.
La domanda decisiva non è se l’impresa «ha una policy AI». È se può dimostrare in qualsiasi momento quale AI opera con quale autorità, quali controlli sono attivi e chi reagisce alle nuove evidenze.