L’AI non può diventare un alibi

Lavoro e Pubblica Amministrazione: dalla responsabilità umana alla controllabilità effettiva

La governance dell’intelligenza artificiale nel lavoro non si risolve con una firma umana in fondo al processo. L’AI promette velocità e qualità, ma ridisegna la catena delle decisioni: per governarla servono poteri reali di intervento, tracciabilità, formazione, gestione degli incidenti, audit e contratti che non lascino il rischio tecnico sul lavoratore o sul cittadino.

Andrea Viliotti · Consulente strategico AI · 28 luglio 2026

Analisi manageriale e organizzativa. Non costituisce parere legale.

Governance dell'AI nel lavoro 

QUATTRO IDEE GUIDA

01 · Governare gli effetti — Il perimetro comprende anche workflow, dashboard, scoring e software deterministici quando incidono sul lavoro.	02 · Dare potere alla supervisione — Competenza, tempo, log, override, escalation e stop condition rendono reale l’intervento umano.
03 · Trattare dati e log come indizi — KPI, alert e output sono elementi istruttori: senza contesto e prova autonoma non sono verdetti.	04 · Far seguire la responsabilità al controllo — Formazione, audit, incidenti e procurement devono impedire lo scarico del rischio verso il basso.

Un sistema non è governato perché un essere umano firma alla fine. È governato quando quella persona può capire, intervenire e fermare.

1. Dalla governabilità all’architettura

Nel contributo che ho firmato con Marco Carlomagno su AI4Business, «AI nel lavoro, come garantire la governabilità», abbiamo usato l’immagine di due cantieri opposti: da una parte la tecnologia che concentra potere e opacità, dall’altra la tecnologia inserita in una comunità capace di comprenderla, discuterla e correggerla. Qui voglio compiere un passo ulteriore: portare quel ragionamento dalla metafora all’architettura organizzativa.

La governabilità non si misura dalla presenza nominale di una persona alla fine del processo. Si misura dalla qualità della catena che porta dall’input alla decisione, dalla possibilità di ricostruirla e dal potere effettivo di intervenire quando qualcosa non funziona. La domanda manageriale, allora, non è se l’AI debba entrare nel lavoro — è già nei processi di selezione, assistenza, controllo qualità, pianificazione, customer care, redazione di documenti, analisi del rischio e gestione delle pratiche — ma questa: chi vede che cosa, chi può intervenire, chi risponde dell’errore e come l’organizzazione impara dall’incidente.

La governabilità non è un comitato che autorizza un prodotto, né un allegato etico alla fine di un progetto. È un sistema di decision rights, informazioni, prove, competenze e contratti che accompagna l’intero ciclo di vita: scelta del caso d’uso, configurazione, utilizzo, aggiornamento, audit, contestazione, sospensione e dismissione.

2. L’AI redistribuisce potere, non soltanto produttività

Il dibattito sull’AI nel lavoro viene spesso ridotto a due domande: quanti posti sostituirà e quanta produttività genererà. Sono legittime, ma non bastano. Un sistema può suggerire una priorità, assegnare una pratica, classificare un rischio, produrre una bozza, generare un punteggio, segnalare un’anomalia o orientare una valutazione. In ciascuno di questi casi cambia la geografia della responsabilità: chi formula la prima ipotesi, chi la controlla, chi può correggerla, chi conserva le prove, chi risponde dell’errore e quanto il lavoratore conosca davvero il processo che gli viene chiesto di convalidare.

La tecnologia, in altre parole, non distribuisce soltanto efficienza. Distribuisce visibilità, capacità di intervento e rischio. Un dirigente può mantenere formalmente la responsabilità finale mentre il sapere tecnico resta presso il fornitore. Un dipendente può essere giudicato da un indicatore che non rappresenta la complessità delle pratiche. Un cittadino può ricevere un esito prodotto da una catena che l’operatore allo sportello non è in grado di spiegare o correggere.

È qui che nasce il rischio più serio. Non è l’automazione in sé: è la separazione tra responsabilità formale e potere reale. Quando l’organizzazione attribuisce a una persona l’obbligo di rispondere di un risultato, ma non le consente di conoscere la versione del sistema, accedere alle informazioni pertinenti, contestare l’output o attivare un’escalation, non sta preservando la centralità umana. Sta costruendo un punto di scarico del rischio.

Anche il calcolo della produttività deve diventare più maturo. Al tempo risparmiato vanno sottratti i costi di verifica, correzione, incidenti, formazione, contenzioso, resistenza organizzativa e perdita di fiducia. Una soluzione che accelera il flusso ordinario ma moltiplica gli errori nelle eccezioni può apparire efficiente in dashboard e risultare costosa nella realtà. La prestazione va quindi misurata sull’intero processo, non sul solo output generato.

La catena, non il singolo modello, è la nuova unità di governance. Per governare l’AI occorre ricostruire la catena completa: dati, modello o regola, versione, configurazione, workflow, interfaccia, supervisore, decisione e destinatario. Ogni passaggio deve avere un proprietario, un limite dichiarato e un canale di escalation. Se manca uno di questi elementi, l’organizzazione non possiede il sistema: ne dipende.

3. Governare gli effetti, non le etichette

Il perimetro corretto non coincide con la sola AI generativa. Sul lavoro incidono modelli statistici, algoritmi di ranking, software deterministici, workflow, piattaforme, dashboard, sistemi di ticketing, KPI, alert e semafori operativi. Una regola che protegga il lavoratore solo quando il fornitore definisce il prodotto “intelligenza artificiale” sarebbe facilmente aggirabile e organizzativamente miope. Un cruscotto che alza automaticamente la priorità di una pratica, o un workflow che blocca una fase, possono condizionare tempi, valutazioni e responsabilità quanto un modello predittivo — a volte più di un chatbot.

Per questo la governance dovrebbe seguire gli effetti del sistema. La domanda non è soltanto quale tecnologia sia stata acquistata, ma se essa incida sull’assegnazione dei compiti, sull’intensità del lavoro, sulla valutazione, sul controllo, sulla sicurezza, sulla responsabilità professionale o sul rapporto con il cittadino.

Anche il quadro giuridico va letto con precisione. La legge 23 settembre 2025, n. 132 stabilisce, per l’AI nel lavoro, principi di sicurezza, affidabilità, trasparenza, dignità e tutela dei dati; per la Pubblica Amministrazione qualifica l’AI come strumento di supporto, lascia alla persona autonomia e potere decisionale e richiede misure tecniche, organizzative e formative. L’articolo 1-bis del decreto legislativo n. 152 del 1997 disciplina obblighi informativi in presenza di sistemi decisionali o di monitoraggio integralmente automatizzati. Il Regolamento europeo sull’AI (Reg. UE 2024/1689), applicabile per fasi, prevede obblighi specifici per i sistemi che rientrano nel suo perimetro, in particolare quelli ad alto rischio. Il GDPR interviene, tra l’altro, sulle decisioni basate unicamente sul trattamento automatizzato nei casi previsti dall’articolo 22.

Questi sono vincoli e presìdi reali, ma non autorizzano generalizzazioni. Non esiste un unico diritto alla spiegazione valido per ogni software, né ogni workflow rientra automaticamente nelle norme sui sistemi integralmente automatizzati o ad alto rischio. L’estensione delle garanzie agli effetti di piattaforme, software deterministici e processi parzialmente automatizzati è quindi anche una proposta di buona governance, di organizzazione e, quando pertinente, di contrattazione collettiva. Distinguere il diritto vigente dalle scelte ulteriori non indebolisce la tutela: la rende più credibile.

4. La responsabilità umana non basta se l’umano non ha potere

Il quadro normativo italiano ed europeo ha fissato un principio necessario: l’AI deve restare strumentale e l’intervento umano deve essere reale. Ma tra principio e organizzazione esiste ancora un vuoto operativo.

Un essere umano che approva in pochi secondi un output che non può comprendere, verificare o modificare non esercita supervisione: presta una firma. Lo stesso vale per il dirigente che riceve un report già filtrato, per il funzionario che vede soltanto il semaforo finale o per il manager cui è attribuito un rischio senza accesso ai log e senza potere sul fornitore. È il paradosso dello human-in-the-loop che diventa human-on-the-hook: una persona agganciata alla responsabilità, ma non al controllo.

La responsabilità deve seguire il potere reale di conoscere, controllare, correggere e motivare. Principio di controllabilità effettiva

La supervisione è effettiva soltanto quando sono definiti almeno sei elementi: identità del supervisore; competenza sul processo e sul sistema; tempo sufficiente; accesso alle informazioni e ai log pertinenti; potere di override o escalation; possibilità di sospendere l’uso dell’output in presenza di anomalie. Il soggetto deve poter contestare, correggere o sospendere l’output, attivare un’escalation, motivare una scelta diversa e non essere costretto — per obiettivi, tempi o cultura organizzativa — a convalidare automaticamente ciò che la macchina propone.

Questo criterio protegge anche il dirigente. Chiedere una responsabilità piena senza consegnare poteri corrispondenti espone l’organizzazione a una falsa sicurezza. L’override deve essere tecnicamente possibile, procedimentalmente legittimo e culturalmente accettato. La segnalazione di un’anomalia non può diventare un costo reputazionale per chi la compie. Un’organizzazione che documenta ruoli, limiti e poteri riduce l’ambiguità nelle crisi, accelera le istruttorie e difende meglio le decisioni.

Il principio non chiede immunità né manleve generali. Chiede una corretta allocazione della prova e del rischio: prima di imputare a una persona un errore connesso a un sistema digitale, occorre verificare il dovere concreto, le istruzioni ricevute, la formazione, la versione del sistema, i log accessibili, il potere di correzione, il canale di escalation e il nesso causale. Le responsabilità previste dalla legge restano; ciò che va impedito è la loro attribuzione automatica sulla base di un output opaco.

5. Dati, log e KPI: elementi istruttori, non verdetti

La digitalizzazione produce una tentazione: scambiare ciò che è misurabile per ciò che è vero. Un log registra un evento, non spiega da solo perché sia avvenuto. Un KPI sintetizza una dimensione, non esaurisce la qualità del lavoro. Un ranking ordina casi secondo criteri definiti, non dimostra la responsabilità di chi li gestisce. Eppure, nelle organizzazioni digitalizzate, questi oggetti tendono ad acquisire un’autorità superiore alla loro capacità probatoria.

Questo vale soprattutto quando i numeri entrano nella valutazione del personale. Se una dashboard segnala tempi medi più lunghi, la domanda non può essere soltanto “chi è più lento?”. Occorre sapere quali pratiche sono state assegnate, quanto erano complesse, quali interruzioni si sono verificate, quale versione del software era in uso e quali attività non standardizzabili restano fuori dal conteggio. Un ritardo medio può nascondere casi più complessi; un semaforo verde può essere stato prodotto da dati incompleti; un log può non registrare un errore di configurazione o un passaggio svolto fuori piattaforma. Senza contesto, il numero diventa una scorciatoia disciplinare.

Il contraddittorio non è un ostacolo alla misurazione. È il meccanismo che evita di trasformare una traccia tecnica in prova automatica di scarso rendimento, errore professionale, inadempimento o correttezza della decisione amministrativa. L’organizzazione deve poter mostrare non soltanto “che cosa dice il sistema”, ma perché quel dato è affidabile nel caso concreto e quali verifiche indipendenti lo sostengono.

L’AI generativa va trattata come bozza, non come fonte autonoma di verità. Nei processi documentali l’output generativo può accelerare sintesi, classificazione e redazione: proprio per questo va qualificato correttamente come bozza o supporto istruttorio. Quando entra in un atto, in una valutazione o in una contestazione, devono essere verificati fonti, dati e passaggi decisivi. Inoltre, i sistemi non autorizzati non devono ricevere dati personali, informazioni riservate, segreti d’ufficio o contenuti che l’organizzazione non può legittimamente trasmettere. La tracciabilità non richiede di conservare ogni conversazione: richiede una politica proporzionata che, nei casi ad alto impatto, permetta di ricostruire prompt o istruzioni rilevanti, versione, output, revisione umana e motivazione dell’uso.

6. L’incidente digitale è un fatto organizzativo

Bug, indisponibilità delle piattaforme, aggiornamenti non governati, dati incompleti, configurazioni errate, allucinazioni dei sistemi generativi e cambiamenti di versione non sono eccezioni teoriche. Sono eventi operativi. Se non vengono registrati e gestiti, riemergono come ritardi, errori o conflitti attribuiti alla persona che si trovava al termine della catena.

Ogni organizzazione dovrebbe avere un registro degli incidenti collegato a ticket tracciabili, un responsabile della presa in carico, tempi di risposta, procedure di fallback e regole chiare sugli effetti dell’incidente. Se una piattaforma è indisponibile, deve essere esplicitato che cosa accade ai termini, agli obiettivi e alle valutazioni. Se un aggiornamento modifica il comportamento del sistema, occorre conservare il changelog e verificare se istruzioni e formazione siano ancora adeguate. Se un modello generativo produce una citazione inesistente, l’errore va ricostruito insieme alle condizioni d’uso, alle fonti disponibili e ai controlli richiesti.

La regola organizzativa dovrebbe essere semplice: nessun ritardo o errore prodotto dal sistema può essere imputato automaticamente al dipendente. Prima serve un’istruttoria tecnica che distingua il malfunzionamento, la scelta del fornitore, la configurazione interna, l’assenza di fallback e il comportamento dell’operatore. Questa memoria degli incidenti è anche uno strumento di miglioramento: permette di correggere il processo invece di punire il suo punto più visibile.

7. Audit e formazione per sistemi che cambiano

L’audit iniziale non basta, perché il sistema sottoposto a verifica non resta immobile. Cambiano i dati, le soglie, le integrazioni, i modelli, l’interfaccia e l’uso reale che ne fanno gli uffici. Un sistema acquistato per supportare una priorità può diventare, nel tempo, un filtro sostanziale; una dashboard informativa può trasformarsi in strumento di valutazione; un aggiornamento può alterare gli errori senza che l’organizzazione se ne accorga.

Gli audit devono quindi essere periodici e proporzionati al rischio. Devono controllare accuratezza, bias, falsi positivi e falsi negativi, impatti sulle categorie vulnerabili, drift, modifiche di versione, qualità dei dati, differenza tra uso dichiarato e uso effettivo, conseguenze sull’organizzazione e qualità del servizio. Non tutto richiede accesso indiscriminato al codice sorgente o ai dataset del fornitore: servono livelli di verifica — documentazione leggibile, accesso tecnico sotto riservatezza, audit indipendente e, nei casi previsti, intervento delle autorità competenti.

La formazione deve seguire la stessa logica. Una lezione generale sull’AI non abilita all’uso responsabile di uno specifico sistema. La formazione deve essere collegata al ruolo, riferita al prodotto e alla versione utilizzata, svolta durante il tempo di lavoro, aggiornata dopo modifiche sostanziali e verificabile. Deve comprendere limiti, errori tipici, controllo delle fonti, privacy, sicurezza, uso dei dati, escalation, override e procedure alternative. Non è corretto pretendere un uso qualificato senza poter dimostrare di avere fornito una formazione qualificata.

8. Perché la Pubblica Amministrazione è il banco di prova più esigente

La Pubblica Amministrazione non è semplicemente un’impresa con più vincoli. Esercita poteri, gestisce diritti, distribuisce risorse e deve garantire imparzialità, motivazione e continuità del servizio. La legge n. 132 del 2025 afferma che la persona resta responsabile dei provvedimenti e dei procedimenti nei quali l’AI è utilizzata. È una scelta condivisibile, ma ha una conseguenza organizzativa precisa: se si mantiene la responsabilità umana, occorre rendere umano anche il potere di controllo. Non basta collocare una firma in fondo a una catena costruita altrove.

Per questo la governabilità dell’AI nella PA ha almeno cinque caratteristiche specifiche.

1. L’output digitale entra in procedimenti che incidono su persone e imprese. Una classificazione, un punteggio o una bozza possono orientare controlli, autorizzazioni, prestazioni, graduatorie e rapporti di lavoro. Anche quando la decisione finale resta umana, il sistema può definire l’agenda, selezionare le anomalie e rendere alcune opzioni più visibili di altre.

2. Il lavoratore pubblico diventa spesso l’interfaccia tra sistema e cittadino. Quando l’output è errato o incomprensibile, il cittadino non incontra il modello: incontra l’operatore. Se quest’ultimo non dispone di informazioni, tempo, potere di correzione e canali di escalation, assorbe un conflitto generato altrove.

3. La catena di responsabilità è più lunga e frammentata. Dirigente, responsabile del procedimento, process owner, struttura IT, data owner, DPO, ufficio acquisti, fornitore e operatore possono partecipare allo stesso processo senza condividere la stessa visibilità. Dire che “il dirigente resta responsabile” non risolve questa complessità: servono una matrice dei ruoli, un dossier tecnico-organizzativo e regole che rendano evidente chi controlla dati, configurazioni, versioni, log e fallback.

4. Gli incidenti digitali possono diventare ritardi, danni o valutazioni ingiuste. Un downtime, un update non comunicato o un dato incompleto può far saltare un termine, alterare una coda o produrre un output errato. Nei casi più gravi, la valutazione negativa o la contestazione individuale dovrebbe attendere l’istruttoria tecnica: prima si accerta che cosa è accaduto al sistema, poi si valuta il comportamento della persona.

5. Il procurement è parte della responsabilità pubblica. Se la responsabilità resta dentro l’amministrazione mentre documentazione e capacità tecnica restano fuori, il contratto ha creato un’asimmetria pericolosa.

A tutto questo si aggiunge un vincolo che è insieme giuridico e di legittimità: l’obbligo di motivazione previsto dall’articolo 3 della legge n. 241 del 1990 non può essere soddisfatto da un rinvio opaco a un punteggio o a una classificazione. Il responsabile del procedimento, il dirigente e il funzionario devono poter comprendere il ruolo del sistema, conoscere i dati e i criteri pertinenti, verificare la versione utilizzata, distinguere un suggerimento da una regola vincolante e motivare una decisione diversa. La motivazione deve restare comprensibile al cittadino e imputabile all’amministrazione, anche quando l’istruttoria è assistita da strumenti complessi. Serve inoltre un canale umano nei passaggi che incidono in modo rilevante su diritti, prestazioni o opportunità: il cittadino deve poter segnalare un’anomalia, produrre elementi non considerati e ottenere una risposta umana quando l’automazione non rappresenta adeguatamente il caso.

QUATTRO STRESS TEST PER UN ENTE PUBBLICO

•           Una dashboard segnala scarso rendimento, ma non considera la complessità delle pratiche e i downtime.

•           Un semaforo classifica una pratica come “verde”, mentre il funzionario non vede i dati che avrebbero consentito di correggerlo.

•           Un sistema generativo propone una motivazione con una fonte inesistente e la bozza entra nell’atto senza verifica.

•           La piattaforma è indisponibile, i termini slittano e il ritardo viene attribuito all’operatore anziché all’incidente.

9. La governance comincia dal capitolato

Molti problemi attribuiti all’uso dell’AI nascono prima che il sistema entri in esercizio. Nascono quando l’acquisto privilegia la prestazione promessa e lascia sullo sfondo la capacità dell’organizzazione di verificare, sospendere o sostituire la soluzione. Il procurement è quindi la prima decisione di governance, non una fase amministrativa separata.

Capitolati, contratti, livelli di servizio e condizioni di fornitura devono disciplinare la documentazione, le versioni e i changelog, la conservazione dei log, l’assistenza agli audit, la segnalazione degli incidenti, i tempi di presa in carico, la qualità dei dati e degli aggiornamenti, le procedure di sospensione, la portabilità, la continuità operativa e l’uscita dal rapporto. Devono chiarire che cosa resta in capo al fornitore e che cosa all’organizzazione. Una clausola generica di conformità non sostituisce una catena di responsabilità.

Per le amministrazioni pubbliche il tema è ancora più delicato. Se l’amministrazione non può ottenere informazioni utili, conservare le tracce necessarie o gestire un aggiornamento, non perde soltanto autonomia tecnologica: perde la capacità di motivare e difendere le proprie decisioni. La governabilità si compra — o si perde — nel momento in cui si scrivono i requisiti.

10. I sette cantieri della governabilità

Per passare dai principi all’esecuzione, sette cantieri. Non sono una nuova burocrazia: sono il minimo sistema di qualità necessario quando un digitale incide su persone, decisioni e responsabilità. La profondità dei controlli deve essere proporzionata al rischio, ma nessun cantiere può essere sostituito da una formula generica.

#	Cantiere	Che cosa deve esistere	Domanda di controllo
1	Perimetro e dossier del sistema	Registro dei sistemi che incidono sul lavoro; finalità, processo, dati, parametri, versione, owner, fornitore, log, limiti noti, metriche, formazione, fallback e incidenti.	Sappiamo quale versione e quale configurazione hanno inciso sulla decisione?
2	Supervisione umana effettiva	Supervisore nominato, competente, con tempo, accesso alle informazioni, potere di override, escalation e stop condition. La mera conferma formale non è supervisione.	La persona può davvero cambiare o sospendere l’output?
3	Output, log e KPI contestabili	Uso come elementi istruttori, non come prova autosufficiente. Contesto organizzativo, prova autonoma, versione, anomalie e contraddittorio devono accompagnare il dato.	Chi subisce l’effetto può contestarlo con informazioni equivalenti?
4	Audit e gestione degli incidenti	Audit periodici su accuratezza, bias, falsi positivi e negativi, drift e aggiornamenti; registro incidenti graduato con impatto su termini, servizio, valutazioni e responsabilità.	Che cosa succede quando il sistema sbaglia o non è disponibile?
5	Responsabilità e controllabilità	Verifica di dovere, istruzioni, formazione, versione, log accessibili, potere di correzione, escalation, nesso causale e nesso soggettivo. Garanzie procedimentali, non immunità.	Il rischio è assegnato a chi possiede il potere reale di controllo?
6	Formazione, reskilling e salute digitale	Formazione per ruolo, processo e versione; uso dei dati, limiti, override, sicurezza e casi di errore. Reskilling, carico cognitivo, tecnostress, notifiche e disconnessione.	Le persone sono addestrate anche a dubitare, fermare ed escalare?
7	Procurement e governance partecipata	SLA, changelog, log retention, incident reporting, audit support, fallback, continuità ed exit; confronto con lavoratori e rappresentanze prima delle modifiche ad alto impatto.	L’organizzazione resta in grado di governare dopo la firma del contratto?

Principio di proporzionalità: più il sistema incide su diritti, valutazione, disciplina o responsabilità, più il dossier, l’audit e la tracciabilità devono essere robusti.

11. Che cosa cambia per imprenditori e manager

Le specificità della PA non devono essere lette dalle imprese come una lontana eccezione burocratica. Anticipano problemi che il settore privato incontra già: valutazioni automatizzate, shadow AI, dipendenza dai fornitori, responsabilità frammentate, rischio privacy, contenzioso e perdita di fiducia. L’impresa può muoversi con maggiore velocità, ma non sfugge alla stessa domanda: chi può spiegare e correggere la decisione?

La prima conseguenza è che la governance dell’AI non può restare confinata all’IT. Deve coinvolgere business owner, HR, legale, privacy, sicurezza, acquisti, controllo interno e rappresentanze dei lavoratori quando il sistema incide sull’organizzazione. Non serve convocare tutti per ogni sperimentazione; serve una classificazione del rischio che determini quali casi d’uso richiedono dossier, audit e autorizzazioni più robuste.

La seconda conseguenza riguarda il ritorno sull’investimento. Il business case deve includere i costi di revisione, formazione, monitoraggio, incident response, fallback e change management. Se questi costi non sono nel modello, non scompaiono: emergono dopo, spesso nel momento peggiore. Una produttività non governabile è temporanea; il primo incidente rilevante può trasformarla in blocco, contenzioso o rifiuto organizzativo.

La terza conseguenza è culturale. Le persone adottano meglio una tecnologia quando conoscono lo scopo, i limiti e i canali di correzione. La trasparenza non elimina la resistenza, ma la rende discutibile e quindi gestibile. Un sistema che ascolta gli utenti intercetta errori e drift prima che diventino danni: il confronto con i lavoratori non è dunque soltanto tutela, è una rete di sensori organizzativi.

Infine, la governance va progettata come un sistema di qualità, non come una sequenza di permessi. L’obiettivo non è rallentare ogni uso dell’AI, ma rendere rapidi i casi a basso rischio e rigorosi quelli ad alto impatto.

12. Una checklist per il lunedì mattina

Un vertice aziendale o pubblico può verificare in poco tempo se sta governando davvero l’AI. Le dieci domande seguenti non sostituiscono un audit, ma rivelano immediatamente le aree in cui la responsabilità è più avanti del controllo.

1.         Abbiamo un inventario aggiornato dei sistemi digitali che incidono su assegnazione, tempi, monitoraggio, valutazione, disciplina o relazione con cittadini e clienti?

2.         Per ogni sistema conosciamo finalità, owner, fornitore, versione, dati, limiti, metriche e processo interessato?

3.         È nominata una persona che possa comprendere, correggere, sovrascrivere o sospendere l’output?

4.         I log e i KPI possono essere letti nel loro contesto — carico, complessità, downtime, priorità e qualità dei dati — oppure vengono usati come verità autosufficiente?

5.         Esiste un registro degli incidenti e sappiamo come un incidente modifica termini, performance, valutazioni e responsabilità?

6.         Gli audit verificano accuratezza, bias, falsi positivi e negativi anche dopo aggiornamenti e cambi di configurazione?

7.         La formazione è riferita al ruolo e alla versione effettiva, e comprende privacy, sicurezza, limiti, override ed escalation?

8.         Gli output generativi sono trattati come bozze verificate e l’uso di dati riservati è governato da strumenti e policy autorizzati?

9.         I contratti con i fornitori prevedono changelog, log retention, supporto agli audit, SLA, fallback, continuità ed exit?

10.     Lavoratori, cittadini o clienti dispongono di un canale comprensibile per chiedere intervento umano, correzione e riesame?

Se un’organizzazione non sa rispondere a queste domande, non sta ancora governando l’AI: la sta semplicemente usando.

13. Dall’umano nel ciclo all’umano con potere

L’AI può migliorare il lavoro, ridurre attività ripetitive, sostenere decisioni più tempestive e rendere i servizi più accessibili. Proprio per questo va liberata da una promessa troppo facile: che basti introdurre il sistema e aggiungere una generica supervisione umana. L’innovazione sostenibile richiede organizzazioni capaci di vedere i propri strumenti, registrarne gli incidenti, correggerne gli errori e discutere apertamente i poteri che redistribuiscono.

La sfida dei prossimi anni non sarà decidere se adottare l’AI, ma definire quali istituzioni del lavoro devono accompagnarla. Serviranno nuove competenze, certo. Ma serviranno anche nuove regole di prova, nuove clausole di acquisto, nuove procedure di incidente e una più precisa relazione tra potere e responsabilità. Per la Pubblica Amministrazione questo significa proteggere insieme legalità, qualità del servizio e professionalità del lavoro pubblico. Per le imprese significa costruire fiducia, ridurre il rischio e rendere sostenibile la produttività.

La posizione, allora, è netta. L’AI è governabile soltanto quando responsabilità e potere effettivo di controllo restano allineati. Dove questo allineamento manca, la responsabilità umana è una formula. Dove esiste, diventa una pratica: informata, tracciabile, contestabile e capace di correggere la macchina prima che il suo errore venga scaricato sulle persone. Non basta mettere un essere umano alla fine della catena: bisogna restituirgli conoscenza, tempo e potere lungo tutta la catena.

È questa la differenza tra un’AI semplicemente adottata e un’AI davvero governata.

Riferimenti essenziali

1.         Marco Carlomagno e Andrea Viliotti, AI nel lavoro, come garantire la governabilità, AI4Business, 27 luglio 2026 (contributo di partenza).

2.         Legge 23 settembre 2025, n. 132 — in particolare articoli 11 e 14.

3.         D.lgs. 26 maggio 1997, n. 152, articolo 1-bis — sistemi decisionali o di monitoraggio integralmente automatizzati.

4.         Regolamento (UE) 2024/1689 — AI Act — regole armonizzate sull’intelligenza artificiale.

5.         Regolamento (UE) 2016/679 — GDPR — in particolare articolo 22.

6.         Legge 7 agosto 1990, n. 241, articolo 3 — motivazione del provvedimento amministrativo.

Nota: il presente testo offre un’analisi organizzativa e manageriale generale. Per applicazioni contrattuali, disciplinari, amministrative, privacy o di procurement è necessaria la validazione dei professionisti competenti.