Nelle aziende italiane, soprattutto nelle PMI e nelle organizzazioni che hanno iniziato ad adottare strumenti generativi in modo rapido, la policy sull’intelligenza artificiale viene ancora troppo spesso concepita come un documento di igiene digitale, cioè come un insieme di divieti elementari, di richiami generici alla privacy e di raccomandazioni di buon senso sull’uso dei chatbot, quando invece ciò che oggi occorre è una vera architettura di governo, capace di distinguere tra uso consumer e uso enterprise, tra protezione del dato e protezione del know-how, tra adozione di strumenti esterni e costruzione di sistemi interni, e soprattutto tra automazione utile e delega implicita del giudizio.
La mia ipotesi è chiara: una buona policy AI aziendale, oggi, non può più limitarsi a gestire il rischio privacy, ma deve disciplinare almeno quattro dimensioni contemporaneamente, cioè conformità normativa, sovranità tecnologica, protezione del capitale cognitivo e governance delle decisioni, perché è proprio nell’intersezione tra questi quattro livelli che si produce il rischio più sottovalutato dell’adozione disordinata dell’AI, vale a dire quel fenomeno che possiamo definire Mind Breach organizzativo: la progressiva cessione, verso l’esterno o all’interno di sistemi non adeguatamente governati, della capacità dell’organizzazione di custodire il proprio sapere e di pensare in modo autonomo.
Indice degli argomenti
Policy AI aziendale e rischio privacy
Un primo errore è credere che una policy AI sia solo una policy privacy, che consista nell’impedire al personale di caricare dati personali in ChatGPT o in altri servizi simili, come se il problema fondamentale fosse soltanto la possibile violazione del GDPR, mentre in realtà un’organizzazione espone rischi molto più ampi quando trasferisce, anche in modo frammentato e involontario, procedure, logiche di erogazione, criteri di classificazione, strutture di priorità, casi d’uso ricorrenti, formule decisionali, eccezioni operative e segmenti del proprio linguaggio interno, tutti elementi che magari non sono dati personali in senso stretto, ma che costituiscono parte essenziale del suo patrimonio competitivo e identitario.
Per questo, una policy AI seria deve partire da una premessa culturale che in Italia non è ancora abbastanza diffusa, e cioè che l’intelligenza artificiale non tratta soltanto informazioni, ma assorbe anche contesto, metodo, ricorrenze, strutture implicite e relazioni tra elementi, ragione per cui la protezione dell’impresa non può esaurirsi nella protezione del dato personale, ma deve estendersi al capitale cognitivo, che comprende il modo in cui l’azienda lavora, decide, classifica, seleziona e giustifica le proprie scelte.
Rischio di know-how e capitale cognitivo
Un secondo errore sta nel non distinguere tra rischio di dato e rischio di know-how
È precisamente qui che una policy matura deve introdurre una classificazione diversa da quella che molte imprese usano oggi, perché non basta distinguere tra dato pubblico, dato interno e dato personale, mentre diventa decisivo distinguere anche in base al valore strategico e cognitivo del contenuto, separando ciò che è innocuo da ciò che, pur non essendo sensibile in senso tradizionale, rivela processi, regole, logiche di business o criteri decisionali che non dovrebbero essere esternalizzati. Nel documento che ho costruito come base di lavoro, questa esigenza prende la forma del “Rischio di Esfiltrazione Cognitiva”, che serve proprio a nominare il trasferimento non intenzionale e non governato di conoscenza organizzativa verso provider terzi.
Questa impostazione, a mio giudizio, è molto più utile di tante policy che si limitano a ripetere formule astratte, perché costringe l’impresa a porsi una domanda concreta: quali contenuti, anche se non coperti da privacy, rivelano il nostro modo di funzionare e quindi non dovrebbero mai finire in sistemi esterni non pienamente governati? Se una policy non costringe il management a rispondere a questa domanda, non sta governando l’AI, ma sta solo distribuendo istruzioni d’uso.
Piano enterprise, opt-out e limiti della protezione esterna
Un terzo errore da non commettere: credere che basti passare al piano enterprise o attivare l’opt-out
Molte organizzazioni, quando iniziano a maturare, fanno un passo avanti ma si fermano comunque troppo presto, perché abbandonano i tool gratuiti o consumer e passano a piani enterprise, oppure confidano nel fatto che l’opt-out dal training sia sufficiente a neutralizzare il rischio, mentre una policy robusta deve essere molto più esigente, e cioè deve verificare basi contrattuali, DPA, residenza dei dati, garanzie su accessi extra-UE, limiti d’uso, condizioni di retention, possibilità di audit e soprattutto margini di uscita dal fornitore.
Questo punto è tutt’altro che teorico, perché il quadro europeo si sta chiarendo rapidamente: l’AI Act disciplina l’AI con un approccio risk-based, introduce obblighi specifici per i modelli general-purpose e insiste su trasparenza, supervisione umana, logging, documentazione e robustezza, mentre il Data Act interviene anche sul tema del cloud switching e della graduale eliminazione dei costi di switching, segnalando con chiarezza che l’adozione di infrastrutture digitali non può essere governata senza considerare il tema del lock-in, che nel caso dell’AI non è mai soltanto tecnico, ma tende facilmente a diventare anche operativo e cognitivo.
AI interna e digital twin aziendale
Infine, quarto errore: pensare che il problema scompaia quando l’AI diventa interna
Una volta compreso che i sistemi esterni vanno governati con rigore, molte organizzazioni fanno il ragionamento apparentemente più razionale, cioè decidono di investire in AI locali, on-premise o comunque interne, e questo passaggio, se fatto bene, ha assolutamente senso, perché riduce la dipendenza da provider terzi, consente maggiore controllo sui dati, protegge meglio il know-how e permette di costruire un’infrastruttura più coerente con la propria sovranità tecnologica. Il problema, però, è che questo passaggio, pur risolvendo una parte del rischio, ne apre un’altra, che viene quasi sempre sottovalutata.
Quando infatti l’AI interna smette di essere un semplice modello locale e comincia a incorporare documentazione, processi, casi storici, workflow, regole, metriche e pattern organizzativi, essa tende naturalmente a evolvere verso una forma di digital twin aziendale, vale a dire verso una rappresentazione operativa della struttura, del linguaggio e dei meccanismi dell’organizzazione, e proprio per questo acquisisce un valore enorme, ma anche una capacità crescente di influenzare il modo in cui i problemi vengono inquadrati, le opzioni vengono ordinate e le scelte vengono giustificate.
È qui che entra in gioco il Mind Breach, che non va inteso in senso retorico, ma come categoria di governance: il rischio, cioè, che l’organizzazione, mentre costruisce il proprio digital twin per guadagnare efficienza, memoria e coerenza, finisca per attribuire al sistema un’autorità cognitiva crescente, fino al punto in cui l’output dell’AI non viene più trattato come un supporto contestabile, ma come il quadro implicito del plausibile, entro cui il management continua formalmente a decidere, ma di fatto smette progressivamente di produrre alternative realmente indipendenti.
Le due architetture di una policy AI seria
Una policy AI seria deve allora avere due gambe, non una sola. A mio giudizio, chi oggi vuole costruire una policy AI davvero utile per un’azienda italiana deve accettare che il documento debba reggersi almeno su due architetture distinte ma integrate. La prima è quella della protezione verso l’esterno, che riguarda strumenti cloud, classificazione dei contenuti, divieto di account consumer, presidi contrattuali, gestione del REC, residenza dei dati e protezione del know-how. La seconda è quella della governance interna, che riguarda invece il modo in cui sistemi locali, knowledge system, agenti e digital twin vengono inseriti nei processi dell’impresa, soprattutto quando toccano prioritizzazione, istruttorie, scenari, simulazioni o decisioni rilevanti.
Questa seconda gamba è quella che manca quasi sempre, perché molte policy si fermano appena la tecnologia rientra in casa, come se l’on-premise fosse di per sé una soluzione sufficiente, mentre in realtà un sistema interno può diventare ancora più persuasivo di uno esterno, proprio perché parla il linguaggio dell’organizzazione, riflette il suo passato, ordina il suo archivio, restituisce pattern coerenti con la sua storia e tende, per questo, a essere percepito come “più vero”, “più aderente” o “più nostro”, quando invece dovrebbe restare uno strumento da interrogare criticamente.
Che cosa deve contenere una policy AI aziendale
Ma allora, che cosa deve contenere, in concreto, una buona policy AI aziendale?
Se dovessi sintetizzare, direi che una policy efficace, soprattutto nel contesto italiano, deve fare almeno sette cose, ma non in forma di slogan, bensì traducendole in regole operative verificabili.
Deve anzitutto definire il perimetro, chiarendo che cosa rientra nella policy, distinguendo tra servizi esterni, sistemi enterprise, AI interne, agenti, knowledge system e digital twin, perché una policy che non delimita il proprio oggetto resta inevitabilmente ambigua nel momento in cui deve essere applicata.
Deve poi classificare i contenuti non solo per riservatezza formale, ma per valore cognitivo e strategico, in modo da impedire che processi, logiche operative e criteri di business vengano trattati come se fossero testo innocuo solo perché non contengono dati personali.
Deve inoltre distinguere tra ciò che può uscire e ciò che deve restare interno, e questo significa disciplinare i provider, i DPA, le condizioni contrattuali, la residenza dei dati, la reversibilità e il rischio di lock-in, coerentemente con il nuovo quadro europeo, in cui AI Act e Data Act iniziano finalmente a convergere nel segnalare che innovazione e controllo non possono più essere trattati come piani separati.
Deve anche disciplinare il ruolo dell’AI interna, chiarendo che l’obiettivo dell’AI locale non è semplicemente sostituire il cloud, ma consentire la costruzione governata di un digital twin aziendale, cioè di un’infrastruttura capace di incorporare e simulare il funzionamento dell’organizzazione, senza trasformarsi, per questo, in un sostituto del giudizio.
Deve poi introdurre presidi specifici per i processi sensibili, come review sostanziale, contro-ipotesi, challenge indipendente, registro dei casi d’uso, tracciabilità del ruolo svolto dall’AI e riesame periodico del framing, perché è proprio nei processi sensibili che la formula “human in the loop” smette di essere sufficiente e deve diventare una pratica verificabile.
Deve ancora assegnare responsabilità nominative, perché un documento senza owner, process owner, responsabilità IT, raccordo con DPO, funzione di controllo e regime di incident reporting è un documento che descrive intenzioni ma non crea governo.
Infine, deve prevedere formazione e AI literacy, perché il legislatore europeo è ormai esplicito nel richiedere che chi usa l’AI nelle organizzazioni abbia una comprensione adeguata del sistema e dei suoi rischi, e questo significa che l’alfabetizzazione non può essere confinata alla capacità di usare l’interfaccia, ma deve includere consapevolezza su limiti, bias, qualità dell’output, impatti organizzativi e condizioni di supervisione umana.
La vera funzione della policy AI aziendale
Bisogna avere chiaro che la vera funzione della policy non è frenare l’AI, ma impedire che diventi una delega non dichiarata
Qui, secondo me, sta la differenza tra una policy cosmetica e una policy seria. La prima serve a dire che l’azienda “ha una policy AI”, cioè a segnalare conformità e prudenza; la seconda serve invece a stabilire a quali condizioni l’AI può entrare nell’organizzazione senza trasformarsi in una scorciatoia decisionale, in un canale di drenaggio del know-how o in una gabbia di normalizzazione del passato.
Per questa ragione, chi costruisce oggi una policy AI per il contesto italiano non dovrebbe porsi soltanto la domanda classica — “come evitiamo usi impropri?” — ma una domanda molto più esigente, e cioè: come facciamo a introdurre capacità generativa, automazione e simulazione senza cedere sovranità cognitiva, senza indebolire il dissenso organizzativo e senza scambiare la comodità dell’output per qualità del giudizio? Se la policy non prova a rispondere a questo, non governa l’AI: governa soltanto il suo lessico esteriore.
In definitiva, quindi, costruire oggi una policy AI per un’azienda italiana significa accettare che l’intelligenza artificiale non sia più soltanto un tema di strumenti o di efficienza, ma una questione di architettura organizzativa, di protezione del capitale cognitivo e di disciplina del potere decisionale. Significa riconoscere che il vero salto non è passare dal tool gratuito al contratto enterprise, né semplicemente dal cloud all’on-premise, ma passare da una logica di uso opportunistico a una logica di governo, nella quale l’impresa stabilisce che cosa può uscire, che cosa deve restare, che cosa può essere internalizzato, che cosa può evolvere verso un digital twin e, soprattutto, quali confini non devono essere superati perché il supporto dell’AI non si trasformi, quasi senza che ce ne accorgiamo, in una delega implicita del pensiero.
Se c’è una formula che può aiutare a capire questo passaggio, è proprio quella di Mind Breach: non come slogan, ma come promemoria del fatto che, nell’era dell’AI, la vulnerabilità più seria di un’organizzazione non riguarda solo i dati che perde, ma anche la capacità di continuare a immaginare, scegliere e dissentire con autonomia. Ed è esattamente per questo che una policy AI ben costruita, oggi, non è più un allegato burocratico, ma una parte essenziale della strategia d’impresa.
