Governance dell’AI in azienda: le sei aree da progettare

Cosa trovi in questo articolo

Cosa significa governance dell’AI per una PMI
Le sei aree: inventario, processi, dati e accessi, controlli, responsabilità umana, registrazioni
Come distinguere un esperimento da un sistema che lavora davvero
Quanta approvazione umana serve per ogni tipo di azione
Un esempio completo sulle email dei fornitori
Le domande da portare alla prossima riunione

Un’impiegata usa un assistente di scrittura per rispondere ai fornitori. Un commerciale ha collegato un programma di intelligenza artificiale al proprio calendario. Il responsabile amministrativo sperimenta un sistema che legge le fatture e prepara le registrazioni. Intanto il gestionale ha introdotto una funzione di classificazione automatica delle richieste. Tutte queste iniziative possono essere utili, ma la direzione potrebbe non sapere quali dati trattano, quali decisioni influenzano e chi controlla gli errori. È da questa situazione ordinaria che conviene partire quando si parla di governance dell’intelligenza artificiale.

Il termine governance indica l’insieme delle decisioni, delle responsabilità e delle verifiche che consentono a un’organizzazione di mantenere il controllo su una tecnologia. Per una piccola o media impresa significa sapere che cosa viene utilizzato, da chi, per quale risultato, con quali dati e con quali limiti. Non serve creare subito un nuovo reparto o scrivere un manuale di cento pagine. Serve però individuare le persone che possono autorizzare un utilizzo, verificare un risultato, gestire un incidente e decidere di sospendere un sistema.

La questione riguarda anche le aziende che non hanno approvato formalmente nessun progetto di AI. È possibile che i dipendenti utilizzino già applicazioni personali o funzioni integrate nei programmi abituali. Quando l’adozione avviene senza una visione comune, ogni scelta rimane isolata.

Il rischio aumenta man mano che gli strumenti smettono di produrre semplici bozze e iniziano a leggere archivi, modificare dati o inviare comunicazioni. Vediamo come affrontare il problema attraverso sei aree di lavoro, con esempi che un imprenditore e un responsabile possono adattare alla propria organizzazione.

1. Fare l’inventario di quello che si usa davvero

Il primo passo consiste nel capire dove l’intelligenza artificiale sia già presente. Chiedere genericamente «usate ChatGPT?» non basta. Un dipendente potrebbe non considerare AI la funzione del programma che riassume le riunioni, il sistema che propone risposte nella posta elettronica o l’applicazione che traduce i documenti. Altri potrebbero usare diversi account, uno personale e uno aziendale, senza riconoscere le differenze di trattamento dei dati. L’inventario deve quindi partire dalle attività, prima ancora dei nomi dei fornitori.

Le sei aree di lavoro della governance dell’AI: Inventario; Processi; Informazioni e accessi; Controllo dopo l’avvio; Responsabilità umana; Registrazioni. — Le sei aree di lavoro dell’articolo, nell’ordine in cui conviene affrontarle.

Un questionario di poche domande può essere sufficiente per la prima ricognizione. Quale attività svolgi con uno strumento AI? Che programma usi? Con quale account accedi? Inserisci informazioni sui clienti, sui colleghi o sui prodotti? Il risultato viene letto da una persona prima di essere utilizzato?

Lo strumento invia messaggi o modifica informazioni autonomamente? Conviene spiegare che la ricognizione serve a mettere ordine e a mettere tutti in condizione di lavorare in sicurezza. Se le persone temono una punizione per avere sperimentato, tenderanno a omettere proprio gli usi più interessanti da analizzare.

Il risultato può essere una tabella molto semplice, consultabile da chi si occupa del progetto. Ogni riga contiene nome dello strumento, reparto, attività, referente interno, tipo di dati, modalità di accesso, eventuali sistemi collegati e livello di controllo umano. Una funzione AI inclusa nel gestionale merita una riga tanto quanto un assistente esterno. L’inventario va aggiornato ogni volta che entra una nuova applicazione o un fornitore attiva una funzione significativa. Senza questo elenco l’azienda non ha una base affidabile da cui prendere decisioni successive.

Distinguere gli esperimenti dai sistemi che lavorano davvero

Durante la ricognizione si scopre spesso che le attività hanno livelli di rischio molto diversi. Una persona che chiede a un chatbot di spiegare una formula di Excel usando dati inventati sta facendo una prova limitata. Un programma che consulta la corrispondenza commerciale per preparare offerte accede invece a informazioni riservate. Un agente che inserisce ordini nel gestionale può modificare lo stato di un processo aziendale. La distinzione non dipende soltanto dalla qualità della tecnologia: dipende da ciò che il programma può vedere e fare.

Per ogni utilizzo vale la pena annotare se il sistema propone un testo, supporta un operatore, compila una bozza da approvare o completa un’azione senza conferma. Questa classificazione aiuta a stabilire quali verifiche siano necessarie. Una bozza di comunicazione interna richiederà una revisione ordinaria.

Una proposta di pagamento, una decisione sui lavoratori o una modifica alle condizioni di un cliente richiederanno precauzioni diverse. Non esiste una soglia uguale per tutte le imprese: un dato che in un contesto è pubblico, in un altro può rappresentare un segreto industriale.

La scheda di inventario dovrebbe inoltre riportare chi ha autorizzato l’uso dello strumento e a quale scopo. Se una prova diventa attività quotidiana, è opportuno registrare il cambiamento. Molti incidenti nascono infatti quando un esperimento informale viene considerato affidabile semplicemente perché ha funzionato per alcune settimane. Il passaggio dalla prova alla produzione richiede una valutazione esplicita, anche quando il programma sembra facile da utilizzare e non è stato necessario installare nulla.

2. Scegliere i processi partendo dal lavoro reale

Una volta ricostruiti gli strumenti in uso, bisogna individuare le attività in cui l’intelligenza artificiale può creare un miglioramento concreto. Le aziende sono spesso tentate di partire dal prodotto più pubblicizzato: un assistente per tutti, un agente capace di fare qualsiasi cosa, una piattaforma unica da collegare a ogni reparto. Una dimostrazione convincente può far sembrare urgente acquistare, ma non chiarisce quali problemi quotidiani saranno risolti e quali costi organizzativi comporterà l’introduzione del sistema.

Un metodo più utile consiste nell’osservare il lavoro insieme alle persone che lo svolgono. In un ufficio ordini, per esempio, una richiesta arriva via email, viene letta, i codici prodotto sono cercati nel gestionale, si verifica la disponibilità a magazzino e infine si prepara una risposta.

A seconda del cliente, l’operatore può dover controllare listini, condizioni commerciali, accordi speciali e tempi di consegna. Dire che l’ufficio «gestisce gli ordini» non permette di capire quali passaggi siano ripetitivi, quali richiedano giudizio e quali dipendano da informazioni non sempre aggiornate.

Per ricostruire un processo occorre seguire una pratica completa, comprese le eccezioni. Si annotano i documenti utilizzati, i programmi aperti, i dati copiati a mano, le approvazioni e le situazioni che fanno interrompere il lavoro. Soltanto dopo si valuta se serva l’AI. Talvolta basta correggere un’impostazione del gestionale o far comunicare due programmi già presenti. Automatizzare un passaggio inutile significa conservare l’inefficienza e farla eseguire più velocemente. Il progetto dovrebbe descrivere il processo desiderato prima di scegliere lo strumento che lo realizzerà.

Come decidere quale processo affrontare per primo

Un processo interessante non è necessariamente quello che occupa più persone. Vale la pena considerare quanto spesso l’attività si ripete, quali errori può produrre, quanto sono stabili le regole, se i dati sono disponibili e quanto lavoro richiede il controllo dei risultati. Un’attività poco frequente ma estremamente delicata potrebbe non essere il punto di partenza migliore. Al contrario, classificare ogni giorno richieste molto simili può essere un esperimento più semplice, dal quale ricavare indicazioni utili per progetti successivi.

Le sei aree della governance dell’AI, inventario, scelta dei processi, sicurezza, controllo nel tempo, responsabilità umana e compliance, collocate nella fase in cui si disegna il processo; a destra, segnata come tardi, la fase in cui… — Le sei aree si affrontano mentre si disegna il processo. Quando l’AI è già dentro i processi, diventa più complicato.

Immaginiamo una PMI che riceve le richieste di assistenza su un unico indirizzo email. Oggi una persona legge tutto e inoltra i messaggi ai colleghi competenti. Un sistema potrebbe proporre una categoria, indicare il prodotto citato e assegnare una priorità da verificare. Il progetto avrebbe confini chiari: leggere le richieste, organizzarle, lasciare all’operatore la possibilità di correggere la classificazione. Prima di pensare a risposte automatiche o rimborsi, si può controllare se la prima funzione è davvero utile e quali errori compie.

La misura del beneficio deve includere il tempo necessario a controllare il risultato, la gestione delle eccezioni e la manutenzione della soluzione. Il solo tempo di esecuzione del programma racconta poco. Se una classificazione automatica richiede tre minuti di verifica a fronte di quattro minuti di lavoro manuale, il vantaggio operativo è limitato.

Se invece il sistema prepara correttamente la maggior parte delle informazioni e segnala le situazioni dubbie, gli operatori possono concentrarsi sui casi che richiedono attenzione. Le misure vanno raccolte sul proprio processo, senza prendere come garanzia numeri pubblicati da fornitori o concorrenti.

3. Proteggere informazioni, accessi e collegamenti

Quando si utilizza un assistente sul sito pubblico dell’azienda, il suo accesso potrebbe limitarsi ai contenuti già pubblicati. Quando lo stesso assistente viene collegato al sistema di gestione dei clienti, alla posta elettronica o a un archivio contratti, il problema cambia. Il sistema può vedere dati personali, prezzi riservati e informazioni che non devono essere disponibili a tutti i dipendenti. La prima regola di sicurezza consiste nel concedere soltanto le autorizzazioni necessarie per l’attività prevista.

Per rendere concreta questa regola, pensiamo a un agente incaricato di preparare il riepilogo degli ordini di un cliente. Deve leggere gli ordini pertinenti e forse alcune informazioni sulle spedizioni. Non ha motivo di consultare le buste paga, modificare l’anagrafica dei fornitori o inviare disposizioni di pagamento. Se il software impone l’accesso all’intero gestionale, l’azienda deve trattare questa limitazione come un problema progettuale, valutando se sia accettabile, se possa essere mitigata o se convenga scegliere un’altra strada.

La sicurezza non si esaurisce con una password. Servono account aziendali gestiti centralmente, autenticazione adeguata, permessi distinti, procedure per revocare gli accessi e una verifica degli strumenti esterni collegati. I dati devono essere trattati in base alla loro natura e agli obblighi applicabili.

Le informazioni personali dei clienti hanno implicazioni diverse da una ricetta produttiva o da un listino riservato; entrambe, tuttavia, possono essere preziose. Il responsabile del progetto dovrebbe coinvolgere chi segue protezione dei dati, sicurezza informatica e contratti, senza presumere che una soluzione sia sicura soltanto perché funziona su un server europeo.

Dove vanno le informazioni quando il sistema lavora

Per valutare un programma è utile disegnare il percorso di una richiesta. Da quale applicazione parte il testo? Quali documenti vengono recuperati? C’è un componente che elimina informazioni superflue? Il contenuto viene inviato a un modello esterno? Dove vengono conservati i messaggi e le registrazioni? Chi può leggere le risposte? Non occorre essere programmatori per formulare queste domande; occorre pretendere dal fornitore risposte comprensibili e verificabili.

Una tecnica possibile è il mascheramento di alcuni dati identificativi. Prima di inviare una richiesta a un servizio esterno, un componente sostituisce nomi, recapiti e riferimenti con segnaposto. Il modello elabora il testo e, quando necessario, il sistema rimette i dati al loro posto in un ambiente controllato.

È una misura utile, ma non bisogna attribuirle capacità assolute. In alcuni documenti i dettagli rimasti permettono comunque di riconoscere una persona o un’azienda; in altri, togliere gli importi rende impossibile svolgere correttamente il compito. Ogni tecnica va provata sul proprio caso e associata ad altri controlli.

È altrettanto importante distinguere l’uso dei dati per produrre una risposta dal loro eventuale impiego per addestrare i modelli del fornitore. Sono due questioni differenti e dipendono dal contratto, dal piano e dalle impostazioni. Un servizio che non utilizza i contenuti per l’addestramento deve comunque elaborarli per offrire la funzione richiesta e può conservarne alcune tracce secondo condizioni specifiche. La valutazione deve riguardare l’intero trattamento, non soltanto una casella delle preferenze.

4. Controllare il sistema anche dopo la messa in funzione

Un’applicazione tradizionale può smettere di funzionare quando cambia un collegamento o compare un errore nel codice. Con l’AI si aggiungono altri rischi: un modello aggiornato può interpretare diversamente le istruzioni, una nuova serie di documenti può modificare la qualità delle risposte e una procedura interna può diventare obsoleta. Un sistema che ha prodotto buoni risultati durante una settimana di prova non è per questo affidabile per sempre.

Il controllo deve cominciare con la definizione di ciò che si considera corretto. Se l’AI classifica le richieste di assistenza, si possono raccogliere esempi rappresentativi e confrontare le categorie proposte con quelle approvate dagli operatori. È utile includere messaggi incompleti, allegati non leggibili, richieste urgenti e casi che appartengono a più categorie. Se il sistema prepara bozze di risposta, si controllano precisione delle informazioni, rispetto delle condizioni commerciali e adeguatezza del tono. Non basta verificare che il testo sia scritto bene.

Dopo l’avvio, la verifica può essere periodica e basata sul rischio. I risultati dei casi più delicati possono essere sempre rivisti da una persona; quelli più semplici possono essere controllati a campione se le condizioni lo consentono. Le anomalie vanno registrate per capire se dipendono da dati sbagliati, istruzioni confuse, aggiornamenti o caratteristiche del modello. Senza una persona incaricata di osservare questi segnali, l’azienda rischia di accorgersi del peggioramento soltanto quando arriva un reclamo.

Stabilire che cosa succede quando qualcosa va storto

Un buon piano di controllo deve prevedere almeno tre situazioni. Nella prima il sistema non riesce a completare un’attività: deve dichiararlo e lasciare il lavoro a un operatore, evitando di inventare un risultato. Nella seconda produce una proposta incerta: deve permettere la revisione prima che il dato diventi operativo. Nella terza compie o tenta un’azione non autorizzata: occorre poter sospendere l’accesso e ricostruire quanto è accaduto.

Prendiamo un agente che legge fatture ed è autorizzato a predisporne la registrazione, lasciando l’approvazione finale all’amministrazione. Se riceve un documento danneggiato, non dovrebbe ricostruire a intuito la partita IVA mancante. Se trova due fornitori con nomi simili, dovrebbe indicare l’ambiguità. Se il gestionale non risponde, deve interrompere la procedura senza continuare a premere pulsanti su schermate di cui non conosce lo stato. Questi comportamenti sono requisiti da provare prima del rilascio, non dettagli da sistemare dopo il primo incidente.

Conviene inoltre assegnare un responsabile operativo. È la persona che sa chi contattare, quali accessi sospendere, come recuperare i dati e come riprendere il lavoro manualmente quando il sistema è indisponibile. L’esistenza di un pulsante di arresto non basta: quel pulsante deve funzionare, qualcuno deve avere il diritto di usarlo e la procedura deve essere conosciuta. Lo stesso vale per le copie di sicurezza e per la capacità di ricostruire modifiche errate al gestionale.

5. Conservare la responsabilità umana nelle decisioni

Quando un programma prepara una risposta, un operatore può accettarla troppo velocemente perché ha un aspetto professionale. Quando la stessa risposta compare ogni giorno ed è quasi sempre corretta, il controllo può diventare una formalità. È un comportamento comprensibile, ma pericoloso. La presenza di una persona nel processo conta soltanto se quella persona dispone delle informazioni e del tempo necessari per esercitare un giudizio autonomo.

Per ogni attività bisogna quindi chiarire chi decide e quale potere possiede. Un sistema può proporre un ordine d’acquisto, ma chi è autorizzato ad approvarlo? Può suggerire che una pratica non sia completa, ma chi verifica se manchi davvero un documento? Può segnalare una discrepanza nella valutazione di un candidato, ma chi esamina i criteri utilizzati? Affidare formalmente la responsabilità a un dipendente senza dargli strumenti per contestare l’AI significa costruire un controllo soltanto apparente.

La supervisione richiede formazione sul processo e sui limiti dello strumento. Un amministrativo deve saper riconoscere importi incoerenti, riferimenti mancanti e condizioni particolari. Un professionista deve poter ricostruire il ragionamento dietro una bozza e verificare le fonti. Se l’automazione elimina tutte le occasioni per imparare, nel tempo l’azienda rischia di perdere proprio le competenze necessarie a verificarla. Un progetto ben progettato protegge anche la capacità delle persone di svolgere e comprendere i compiti essenziali.

L’approvazione umana deve essere proporzionata

Non tutte le azioni richiedono lo stesso controllo. Far proporre a un sistema l’etichetta «richiesta di assistenza» può avere conseguenze limitate, specialmente se un operatore può correggerla facilmente. Autorizzare automaticamente uno sconto, cancellare una registrazione o inviare una comunicazione che vincola l’azienda può avere effetti ben diversi. Per questo conviene distinguere attività preparatorie, attività reversibili e azioni che producono conseguenze difficili da correggere.

Una matrice di autorizzazione può essere scritta in termini accessibili: il programma può leggere questo insieme di documenti; può compilare una bozza; può inserire una proposta in attesa di controllo; non può inviare un pagamento; non può cancellare dati; non può comunicare informazioni riservate a un destinatario non verificato. Le eccezioni devono essere gestite da una persona individuata, attraverso un percorso noto. Questa descrizione è più utile di una formula generica come «è previsto il controllo umano».

Non tutte le azioni richiedono lo stesso controllo: Attività preparatorie; Attività reversibili; Azioni difficili da correggere. — Tre tipi di azione, con un controllo proporzionato alle conseguenze.

Nelle PMI una stessa persona può avere più responsabilità, purché i ruoli siano espliciti. Il titolare può approvare le attività critiche, il responsabile amministrativo può esaminare le anomalie e il fornitore tecnico può occuparsi della manutenzione. Se l’azienda cresce, la distribuzione cambierà. Ciò che conta è evitare zone grigie nelle quali nessuno si sente incaricato di verificare il sistema perché tutti presumono che lo faccia qualcun altro.

6. Registrare le attività e prepararsi a ricostruire le decisioni

Un sistema affidabile deve lasciare tracce sufficienti per capire che cosa è accaduto. Nel linguaggio informatico queste registrazioni si chiamano log: possono indicare che un’operazione è partita a una certa ora, quali sistemi sono stati consultati, quali azioni sono state tentate e se una persona le ha approvate. Nei processi importanti servono per individuare errori, correggerli e dimostrare come l’azienda ha governato la tecnologia.

I log non devono trasformarsi in una raccolta incontrollata di dati. Registrare integralmente ogni conversazione, ogni documento e ogni informazione personale può creare un rischio aggiuntivo. Bisogna decidere quali informazioni siano davvero utili, chi possa accedervi, quanto conservarle e come proteggerle da modifiche improprie. La scelta dipende dall’attività e dal quadro normativo applicabile. La tracciabilità si progetta insieme alla protezione dei dati, senza sacrificare l’una all’altra.

Immaginiamo un ordine registrato con un codice articolo sbagliato. L’azienda deve poter capire se il dato fosse presente nell’email originale, se il sistema lo abbia letto male, se sia stato modificato durante il passaggio al gestionale e chi abbia approvato la registrazione. Senza tracce sufficienti si può soltanto cercare di ricostruire la vicenda attraverso ricordi e messaggi. La stessa necessità esiste quando un cliente contesta uno sconto proposto da un assistente o quando un documento viene aggiornato senza che nessuno sappia spiegare perché.

La conformità normativa non è un documento da acquistare

Accanto alle registrazioni devono essere esaminati gli obblighi pertinenti: protezione dei dati personali, sicurezza, rapporti con lavoratori e clienti, contratti con i fornitori e regole specifiche per determinati sistemi di AI. Non ogni applicazione rientra nella stessa categoria di rischio, e gli adempimenti cambiano in base all’uso concreto. Un chatbot che spiega gli orari di apertura di un negozio va valutato diversamente da un sistema impiegato per assumere o valutare persone.

In Europa il riferimento principale è il regolamento sull’intelligenza artificiale, noto come AI Act. Il suo articolo 4 riguarda le misure per sostenere l’alfabetizzazione del personale e di chi utilizza i sistemi per conto dell’organizzazione; il testo è stato modificato dal Regolamento (UE) 2026/1744.

In concreto significa che le persone devono ricevere conoscenze adeguate al ruolo, agli strumenti e ai contesti d’uso. Non è sensato offrire la stessa breve presentazione a chi corregge email e a chi supervisiona un agente che aggiorna dati contrattuali. Il contenuto della formazione deve seguire il lavoro effettivo.

Un’azienda può iniziare documentando gli utilizzi, il percorso dei dati, il livello di supervisione, le prove effettuate e le persone responsabili. Per le attività più delicate sarà necessario coinvolgere competenze legali e tecniche qualificate. Nessuna checklist generica sostituisce tale valutazione. La governance ha valore quando le regole sono applicate e mantenute: un documento impeccabile, conservato in una cartella che nessuno consulta, offre una protezione operativa molto limitata.

Costruire un primo piano di lavoro senza bloccare l’azienda

Per mettere ordine non serve sospendere tutte le sperimentazioni. Una PMI può cominciare individuando un referente per il progetto e chiedendo ai responsabili di reparto un elenco degli utilizzi. Si scelgono quindi uno o due processi su cui fare un’analisi completa, osservando come lavorano le persone e documentando i dati coinvolti. Per ciascuno si definiscono limiti, autorizzazioni, controlli e criteri con cui capire se la soluzione funziona.

La prima riunione dovrebbe produrre decisioni concrete. Per esempio: da oggi non si incollano contratti di clienti in strumenti personali non approvati; il reparto amministrativo prova uno strumento autorizzato solo con documenti di test; ogni proposta di modifica al gestionale richiede conferma; il responsabile commerciale raccoglie gli errori delle risposte suggerite; prima di acquistare nuove licenze si verifica se una funzione esiste già negli strumenti aziendali. Queste scelte, una volta comunicate, fanno più differenza di un elenco di principi astratti.

È utile fissare un momento periodico per rivedere gli utilizzi e gli incidenti. Le domande sono semplici: sono comparsi nuovi strumenti? Un fornitore ha cambiato le condizioni? Ci sono funzioni che non vengono usate? Qualcuno ha trovato un errore ricorrente? Si sono aperti processi che meritano un progetto più strutturato? La governance non finisce il giorno in cui si firma un contratto. Accompagna il modo in cui l’azienda cambia i propri strumenti e il proprio lavoro.

Un esempio completo: le email dei fornitori

Consideriamo una piccola impresa manifatturiera che riceve quotidianamente messaggi dai fornitori. Alcuni comunicano ritardi, altri inviano conferme d’ordine, altri chiedono chiarimenti sulle fatture. L’azienda vorrebbe utilizzare l’AI per organizzare la posta e preparare un riepilogo delle questioni urgenti. Il caso è illustrativo, ma consente di applicare tutte le sei aree a un compito riconoscibile.

L’inventario rivela che due impiegati stanno già usando un assistente personale per riassumere messaggi. L’analisi del processo mostra che il vero problema è distinguere le comunicazioni che richiedono una decisione immediata dalle informazioni da archiviare. Il progetto viene quindi circoscritto: classificazione delle email e proposta di riepilogo, senza invio automatico e senza modifica degli ordini. Si sceglie uno strumento autorizzato, si limita l’accesso alla casella necessaria e si verifica quali informazioni arrivino al fornitore tecnologico.

Durante la prova vengono raccolti messaggi rappresentativi, comprese comunicazioni ambigue e allegati difficili da leggere. Gli impiegati confrontano i risultati e registrano gli errori. Un responsabile approva il passaggio all’uso quotidiano e definisce che cosa accada quando il programma non riconosce una richiesta.

I log permettono di capire quando un’email è stata classificata e se l’operatore ha corretto la categoria. Dopo alcune settimane si valuta il beneficio effettivo, considerando il tempo di controllo. L’AI è diventata parte di un processo governato perché qualcuno ha progettato questi passaggi, non perché il modello sia particolarmente sofisticato.

Le domande da portare alla prossima riunione

Se dovessi scegliere un solo esercizio da fare con la direzione, chiederei di prendere un processo in cui si usa già l’AI e di descriverlo dall’inizio alla fine. Che cosa entra nel sistema? Da dove viene? Chi può leggerlo? Che cosa produce il programma? Chi riceve il risultato? Una persona può modificarlo? Che cosa succede in caso di errore? Le risposte dovrebbero essere comprensibili anche a chi non ha partecipato al progetto.

La riunione dovrebbe inoltre chiarire chi può sospendere uno strumento e come si prosegue senza di esso. Molte aziende investono tempo per decidere come avviare un programma, ma non prevedono che un collegamento possa interrompersi, un abbonamento possa cambiare oppure una funzione possa produrre risultati scadenti. Un’alternativa temporanea, anche manuale, limita le conseguenze di questi problemi. Quando le persone conoscono il piano, l’AI diventa meno misteriosa e l’adozione è più serena.

Il valore di una buona governance si vede nel lavoro di ogni giorno. Le persone sanno quali strumenti usare, i responsabili conoscono i limiti delle automazioni e i clienti ricevono risposte di cui l’azienda può assumersi la responsabilità. Quando si decide di introdurre un nuovo sistema, esistono già domande, documenti e criteri con cui valutarlo. In una PMI questa capacità di scegliere e controllare conta più della quantità di applicazioni acquistate.

Governance dell’AI in azienda: le sei aree da progettare prima di affidarle un processo