Un framework di governance dell’AI è l’insieme di ruoli, policy, controlli e verifiche che stabiliscono come la vostra azienda sceglie, sviluppa, utilizza e monitora l’AI. Per un’azienda SaaS da 20 a 200 persone si riduce a cinque elementi: un responsabile designato, un registro di tutti gli usi dell’AI, un livello di rischio per ciascun uso, una policy breve che le persone possano seguire e controlli integrati nei sistemi stessi. Questa guida mostra come costruire ciascun elemento, da quali framework esterni attingere e dove l’AI non dovrebbe essere usata affatto.
In sintesi
- Un framework è una governance che funziona, non un PDF: un unico responsabile, un inventario degli usi dell’AI, livelli di rischio, una policy d’uso breve e il monitoraggio.
- Non dovete inventarlo da zero. L’AI RMF del NIST e ISO/IEC 42001 offrono una struttura, mentre l’EU AI Act e il GDPR aggiungono obblighi di legge.
- Classificate l’AI in base alle conseguenze di un errore, non in base a quanto sia avanzato lo strumento.
- I controlli integrati nei sistemi di CRM, finanza e accessi reggono meglio delle regole che le persone devono ricordare.
- Alcune decisioni devono restare alle persone. Indicatele per iscritto.
Indice
- Che cos’è un framework di governance dell’AI
- Le componenti di cui ogni framework ha bisogno
- Chi dovrebbe essere responsabile della governance dell’AI
- Passo 1: costruire l’inventario
- Passo 2: classificare ogni uso in base alle conseguenze
- Dove l’AI non ha posto
- Che cosa dovrebbe coprire la vostra policy d’uso dell’AI
- Europa: che cosa aggiunge la legge
- Passo 3: integrare i controlli nei vostri sistemi
- Passo 4: monitorare e riesaminare
- La nostra prospettiva
- Come può aiutarvi NordOps Consulting
- FAQ
- Fonti
Che cos’è un framework di governance dell’AI
Se si toglie il linguaggio dei fornitori, la definizione è semplice. L’AI Risk Management Framework del NIST descrive la governance come l’insieme di policy, processi, documentazione, ruoli e competenze che gestiscono il rischio dell’AI lungo l’intero ciclo di vita, allineati ai valori dell’organizzazione e comprensivi di sistemi e dati di terze parti. In parole semplici: chi decide, su quale base, con quali evidenze e chi risponde quando qualcosa va storto.
Se volete approfondire le ragioni di business della governance come disciplina, i fondamenti della corporate governance mostrano la stessa logica di responsabilità e supervisione applicata a un’intera azienda.
Perché un’azienda SaaS in crescita ne ha bisogno
La maggior parte dei team SaaS usa già l’AI. Le vendite scrivono bozze di messaggi con un assistente, il supporto incolla i ticket in un chatbot, la finanza prova un modello sulle riconciliazioni, gli ingegneri usano assistenti per il codice. Nessuno ha deciso tutto questo a livello aziendale e nessuno ne è responsabile. È il vuoto che un framework colma.
Il vantaggio pratico è la velocità, non la burocrazia. Un framework ben gestito vi dà ciò che BetterCloud definisce un sistema operativo di base fatto di ruoli e controlli che rende l’adozione dell’AI più rapida, più sicura e verificabile nei modelli di responsabilità condivisa tipici del SaaS. Anche i vostri clienti enterprise lo chiederanno nei questionari di sicurezza, di solito prima ancora di chiedervi del vostro modello.
Le componenti di cui ogni framework ha bisogno
Lo Human Technology Institute della UTS elenca gli elementi essenziali: strutture di responsabilità, principi e policy sull’AI che includano limiti invalicabili, gestione del rischio e controlli pratici per il monitoraggio e la rendicontazione lungo tutto il ciclo di vita. Lo stesso documento sottolinea un punto da ricordare: i principi da soli non bastano. Devono tradursi in limiti invalicabili specifici per l’acquisto, la progettazione e la messa in produzione dell’AI.
Ecco come tutto questo si traduce per un’azienda da 20 a 200 persone.
| Componente | Come si presenta in un’azienda SaaS |
|---|---|
| Responsabilità | Un unico dirigente responsabile designato, più un responsabile designato per ogni uso dell’AI |
| Principi e limiti invalicabili | Un elenco di mezza pagina di ciò che qui l’AI non deve mai fare |
| Inventario | Un registro aggiornato di ogni strumento e uso dell’AI |
| Livelli di rischio | Basso, medio, alto, ciascuno con i controlli richiesti |
| Pratiche e controlli | Checklist, passaggi di approvazione, permessi, registrazione dei log |
| Monitoraggio | Revisioni programmate, gestione degli incidenti, tracciamento delle modifiche dei fornitori |
Le quattro attività del NIST
Il NIST organizza il lavoro in quattro funzioni collegate. GOVERN definisce responsabilità e policy, MAP stabilisce il contesto e i potenziali impatti, MEASURE testa e monitora, e MANAGE assegna le priorità e tratta il rischio. GOVERN attraversa tutto il resto, mentre le altre tre si applicano a specifici sistemi di AI e a specifiche fasi del ciclo di vita. Per una piccola azienda, va letto come un ciclo: decidere chi è responsabile, comprendere ogni utilizzo, verificare come si comporta, correggere ciò che non va, ripetere.

ISO/IEC 42001 come sistema di gestione
ISO/IEC 42001:2023 definisce un sistema di gestione dell'AI come elementi organizzativi correlati tra loro che stabiliscono policy, obiettivi e i processi per raggiungerli, e richiede un miglioramento continuo. È pensata per organizzazioni di qualsiasi dimensione che sviluppano, forniscono o utilizzano l'AI. Non serve la certificazione per fare propria la sua logica. Se in seguito un cliente di grandi dimensioni vi chiederà informazioni al riguardo, il vostro framework avrà già una forma riconoscibile.
Chi dovrebbe essere responsabile della governance dell’AI
Il fallimento più comune è la responsabilità condivisa, che significa nessuna responsabilità. Il documento dell'HTI raccomanda una gerarchia di responsabilità che definisca chi risponde delle decisioni su acquisto, gestione e supervisione continua dell'AI. Ecco una suddivisione praticabile per una società SaaS in fase di crescita:
- Un responsabile esecutivo. Una persona con autorità su Finance, Sales, Customer Success e Product. A questa dimensione di solito è il CEO o il COO, oppure un dirigente fractional.
- Un responsabile di processo per ogni utilizzo dell'AI. Il responsabile del reparto che ne dipende, non l'IT per impostazione predefinita.
- Un revisore per dati e sicurezza. Chi oggi si occupa delle questioni di GDPR e sicurezza.
- Un ritmo di revisione breve. Mensile all'inizio, trimestrale quando la situazione si stabilizza.
Non costituite un comitato numeroso. In un'azienda di 60 persone, un comitato di otto è una riunione a cui nessuno partecipa.
Passo 1: costruire l’inventario
Non si può governare ciò che non si vede. La nota pratica in stile Chartered Banker della CBA suggerisce di avviare la ricognizione tra acquisti e contratti, registri delle app approvate, note di rilascio dei fornitori, note spese, sondaggi tra i team e interviste ai responsabili di processo. Le note spese sono un buon indizio: cercate piccoli abbonamenti mensili a strumenti di AI che non sono mai passati dall'ufficio acquisti.
Create poi un registro vivo. Per ogni utilizzo, annotate:
- Scopo e processo che supporta
- La decisione che informa o prende
- Chi ne è interessato
- Il responsabile
- Il fornitore, oppure se lo avete sviluppato voi
- I dati che tratta
- Come vengono verificati gli output
- Stato: proposto, approvato, sospeso, dismesso
Per iniziare va bene un foglio di calcolo. Ricordate che i fornitori aggiungono funzioni di AI a strumenti che già possedete, quindi ricontrollate dopo gli aggiornamenti importanti dei prodotti.
Passo 2: classificare ogni uso in base alle conseguenze
La stessa nota pratica raccomanda di classificare l'AI in base a le conseguenze di un errore, non la sofisticazione della tecnologia. I fattori includono il possibile danno alle persone, le decisioni che riguardano le persone, scala e velocità, rilevabilità e reversibilità, e l'uso di dati personali o riservati.
Applicato al SaaS:
- Basso: redigere appunti interni, riassumere documenti pubblici, fare brainstorming. Una risposta sbagliata viene individuata e costa pochi minuti.
- Medio: riassumere le chiamate con i clienti, redigere risposte ai clienti che una persona rivede, prevedere la pipeline. Gli errori sono plausibili e, se non controllati, si diffondono.
- Alto: qualsiasi cosa che modifichi record dei clienti, denaro, accessi o decisioni sul personale senza un controllo umano.
Per gli utilizzi ad alto impatto, la nota richiede controlli più rigorosi, tra cui una valutazione d'impatto e un intervento umano di blocco che funzioni davvero. Annotate perché ogni utilizzo è stato collocato nel suo livello, in modo che il ragionamento resti valido anche quando il personale cambia.
Dove l’AI non ha posto
Un framework che dice solo sì non è governance. Terremmo l'AI fuori da queste aree, o rigorosamente circoscritta al loro interno:
- Decisioni finali sulle persone. Assunzioni, licenziamenti, valutazioni delle prestazioni e retribuzioni. Un modello può riassumere; un manager decide e sa spiegare perché.
- Modifiche non riviste ai registri finanziari. Fatture, riconoscimento dei ricavi, rimborsi e pagamenti richiedono un passaggio di approvazione umana e una traccia.
- Concedere accessi senza approvazione. L'assegnazione di accessi all'ambiente di produzione o ai dati dei clienti non dovrebbe mai basarsi solo sul giudizio di un modello.
- Incollare dati riservati in strumenti non approvati. Contratti dei clienti, dati personali e codice sorgente vanno solo negli strumenti elencati nel vostro registro.
- Qualsiasi caso in cui non si possa spiegare o annullare l'esito. Se un errore non è rilevabile ed è permanente, una persona resta nel processo.
- Processi difettosi. L'AI applicata a dati CRM o finanziari disordinati produce risposte sbagliate ma sicure di sé, più rapidamente. Correggete prima i dati.
Questi sono i vostri limiti invalicabili. Riportateli in una sola pagina.
Che cosa dovrebbe coprire la vostra policy d’uso dell’AI
Una policy d'uso è la parte del framework che il vostro personale legge davvero. HTI descrive pratiche e controlli come strumenti funzionali, come checklist o requisiti di progettazione, che trasformano le policy di alto livello in istruzioni operative. Mantenete la vostra entro due pagine e includete:
- Strumenti approvati e come richiederne uno nuovo.
- Regole sui dati: cosa si può e cosa non si può inserire, per classe di dati.
- Limiti invalicabili: l'elenco sopra, adattato alla vostra realtà.
- Revisione umana: quali output richiedono l'approvazione di una persona prima di uscire dall'azienda o di modificare un record.
- Informativa: quando i clienti devono essere informati che è coinvolta l'AI.
- Segnalazione degli incidenti: dove segnalare un output errato o una fuga di dati, e cosa succede dopo.
- Responsabilità: a chi rivolgersi e chi aggiorna la policy.
Una policy è il livello delle istruzioni. Il framework è la policy più l'inventario, i livelli, i responsabili, i controlli e le revisioni che la circondano.
Europa: che cosa aggiunge la legge
Un framework volontario e un obbligo di legge sono cose diverse. Framework come NIST e ISO/IEC 42001 sono strutture volontarie. GDPR, EU AI Act e NIS2 sono leggi con un proprio ambito di applicazione. Quanto segue è un'informazione generale, non una consulenza legale, e seguire un framework non garantisce la conformità a nessuna di esse. Chiedete a un legale qualificato come si applicano ai vostri prodotti.
GDPR
Quando l'AI elabora dati personali, il GDPR si applica come a qualsiasi trattamento. Il Comitato europeo per la protezione dei dati afferma che le valutazioni d'impatto sulla protezione dei dati sono un elemento importante della responsabilizzazione quando il trattamento tramite modelli di AI può presentare un rischio elevato per i diritti e le libertà delle persone. Osserva inoltre che i titolari del trattamento possono documentare le misure adottate per limitare la raccolta di dati personali, ridurre l'identificabilità e proteggere dall'estrazione. Il vostro registro e i vostri livelli sono la sede naturale di tale documentazione.
L'EU AI Act
Il Regolamento (UE) 2024/1689 stabilisce norme basate sul rischio che riguardano pratiche vietate, AI ad alto rischio, obblighi di trasparenza, modelli di AI per finalità generali, governance e applicazione, con alcune esenzioni. Tra l'altro, i fornitori di sistemi ad alto rischio devono gestire i rischi lungo l'intero ciclo di vita e mantenere la documentazione tecnica, e il Regolamento prevede anche obblighi per i deployer e obblighi di trasparenza per alcuni sistemi. Se siete fornitori, deployer o entrambi dipende da ciò che sviluppate e utilizzate. Gli obblighi entrano in applicazione gradualmente, quindi consultate le pagine ufficiali della Commissione per le date di applicazione aggiornate.
Il punto pratico è che un inventario con responsabili, livelli ed evidenze è la materia prima per ciascuno di questi obblighi. Le evidenze tracciabili sono anche ciò che gli acquirenti chiedono sempre più spesso, come sostiene questo articolo sulle evidenze tracciabili per l'EU AI Act rivolto alle startup che vendono in trattative regolamentate. La community AI Alliance della Commissione europea aggiunge che impostare ora la governance può aiutare le aziende a prepararsi all'AI Act ed evitare in seguito oneri di conformità.
NIS2
NIS2 è la direttiva dell'UE sulla cybersicurezza. A seconda del settore e delle dimensioni, voi o i vostri clienti potreste rientrarvi, con effetti sul modo in cui gestite rischio di sicurezza, incidenti e fornitori. Considerate gli strumenti di AI parte di quella catena di fornitura e chiedete al vostro legale se vi riguarda.
Passo 3: integrare i controlli nei vostri sistemi
Una policy che dipende dalla memoria si disallinea. BetterCloud osserva che per le aziende SaaS l'automazione mantiene la governance operativa, perché il tracciamento manuale delle policy porta a derive man mano che fornitori e modelli si aggiornano. Anche le indicazioni di Microsoft puntano a integrare i controlli nello stack SaaSOps, come la prevenzione della perdita di dati e la gestione degli accessi, oltre a monitoraggio continuo, audit e revisioni delle prestazioni.
In pratica significa:
- I permessi seguono i ruoli. Un assistente AI può leggere solo ciò che la persona che lo interroga è autorizzata a leggere.
- Passaggi di approvazione per le azioni. Leggere i dati è a basso rischio. Aggiornare un record, avviare un processo o assegnare accessi richiede l'approvazione al livello adeguato.
- Una traccia di audit. Ogni domanda, modifica e approvazione viene registrata, così potete rispondere a chi ha fatto cosa e perché.
- Una sola versione concordata dei dati. Se CRM e finanza non concordano, l'AI ne sceglierà una a caso. Stabilite prima la fonte di verità.
Passo 4: monitorare e riesaminare
NIST è chiaro nel dire che la governance è trasversale e orienta ogni altra funzione, non un progetto una tantum. Fissate un calendario: un controllo mensile su nuovi strumenti e incidenti, una revisione trimestrale degli usi di livello alto e una nuova classificazione ogni volta che un uso cambia dati, ambito o fornitore. Dismettete ciò che nessuno usa.
La nostra prospettiva
Vediamo lo stesso schema nelle aziende SaaS da 20 a 200 persone: l'AI è già in uso e nessuno ne è responsabile. La governance scritta come documento a sé resta quindi accanto al lavoro invece che al suo interno.
Costruiamo seguendo un ordine preciso. Prima le fondamenta dei dati: dati CRM e finanziari come fonte di verità, con una sola versione concordata dei numeri. Poi il livello AI, che collega quei dati all'assistente che il vostro team già utilizza. Poi gli agenti di reparto per Finanza, Vendite e Customer Success, che operano entro i permessi, con approvazione dove serve e una traccia di audit. La governance non è un livello aggiunto alla fine. GDPR, NIS2 e EU AI Act sono requisiti di progettazione fin dal primo giorno, e le nostre attività di sviluppo, pilota e test girano su infrastruttura europea self-hosted in Germania.

Riteniamo inoltre che l'AI vada adottata un processo alla volta, partendo da quello più costoso. Cercare di governare quindici sperimentazioni insieme è il modo in cui i framework diventano carta morta. Scegliete un processo, classificatelo, assegnategli un responsabile, misuratelo, poi passate al successivo.
Nulla di quanto qui riportato sostituisce il vostro avvocato. Un framework aiuta a prepararsi e a dimostrare il lavoro svolto; non garantisce la conformità.
, Claus Nielsen
Come può aiutarvi NordOps Consulting
Se il vostro team usa l'AI e nessuno ne è responsabile, il nostro servizio di Fractional Chief AI Officer vi mette a disposizione una persona di riferimento, con 25 anni di leadership operativa, che decide dove l'AI rende, definisce la governance e costruisce gli agenti.
Ci sono diversi modi per iniziare. L'AI Snapshot è un intervento una tantum, con prezzo di €2,500-€3,500. L'AI Readiness Assessment parte da €4,500. Il Fractional Chief AI Officer parte da €3,000 al mese a livello Advisor, da €6,500 al mese a livello Operating e da €11,000 al mese a livello Embedded. Le realizzazioni sono prezzate al 30% del risparmio del primo anno una volta misurato e dimostrato, oppure a prezzo fisso concordato prima dell'inizio dei lavori. Ciò che viene realizzato è vostro, compresi codice sorgente, documentazione e infrastruttura alla consegna. Iniziate con una call conoscitiva gratuita di 30 minuti sul sito di NordOps Consulting.
FAQ
Qual è la differenza tra un framework di governance dell'AI e una policy d'uso dell'AI?
La policy è il breve regolamento che il personale segue: strumenti approvati, regole sui dati, limiti invalicabili e fasi di revisione. Il framework è l'intero sistema che la circonda, compresi responsabilità, inventario, livelli di rischio, controlli e monitoraggio. Servono entrambi, e di solito la policy è la prima cosa da scrivere.
Ci serve la certificazione ISO/IEC 42001?
Non come punto di partenza. Lo standard è progettato per organizzazioni di qualsiasi dimensione che sviluppano, forniscono o utilizzano l'AI, e se ne può adottare la struttura senza certificarsi. Valutate la certificazione se clienti o gare iniziano a richiederla.
Da quale framework dovrebbe partire una piccola azienda SaaS?
NIST AI RMF è un punto di partenza pratico perché le sue quattro funzioni, GOVERN, MAP, MEASURE e MANAGE, si adattano facilmente a inventario, livelli e revisioni. BetterCloud osserva che la governance SaaS può utilizzare NIST AI RMF e COBIT in linea con la strategia IT e di business esistente. Aggiungete i requisiti di legge del GDPR e dell'EU AI Act dove si applicano a voi.
Chi dovrebbe essere responsabile della governance dell'AI in un'azienda di 50 persone?
Un unico dirigente, in genere il CEO, il COO o un responsabile AI fractional, con un referente nominato in ogni reparto per i rispettivi usi dell'AI. Evitate il comitato. Una chiara responsabilità su acquisti, gestione e supervisione conta più del titolo.
Quanto tempo serve per metterla in piedi?
Una prima versione dell'inventario, dei livelli di rischio e di una policy di due pagine è realistica nell'arco di poche settimane, perché si tratta soprattutto di scoperta e di decisioni. La parte continuativa è il ritmo delle revisioni, che per progettazione non finisce mai.
Fonti
- NIST: Artificial Intelligence Risk Management Framework (AI RMF 1.0)
- UTS Human Technology Institute: Essential Components of AI Governance
- ISO/IEC 42001:2023: AI management systems
- CBA Practice Note: Establishing an AI system inventory
- EDPB Opinion 28/2024 on data protection aspects of AI models
- EUR-Lex: Rules for trustworthy artificial intelligence in the EU
- Future of Life Institute: EU AI Act overview
- European AI Alliance: Implementing AI Governance, from Framework to Practice
- BetterCloud: AI governance for SaaS
- Microsoft: AI Governance Frameworks for software development companies