--- title: "La governance dell'AI tra persone e sistemi" url: https://zerofive.ai/blog/ai-governance/governance-ai-persone-sistemi canonical: https://zerofive.ai/blog/ai-governance/governance-ai-persone-sistemi language: it published: 2026-10-29 updated: 2026-10-28 author: "ZeroFive.AI" tags: governance AI, adozione AI, organizzazione, competenze, AI Rating abstract: "Spesa, produttività, formazione e ROI dell'AI hanno spesso responsabili diversi. Perché serve un mandato unico su persone e sistemi, e da dove partire." --- # La governance dell'AI tra persone e sistemi **In sintesi.** Nella maggior parte delle aziende la spesa per l'AI, la produttività, la formazione e il ritorno dell'investimento hanno responsabili diversi, e il valore che le persone ottengono dagli strumenti si perde nel passaggio all'organizzazione. Atlassian ha scelto di affidare persone e sistemi interni a un'unica guida. Al di là del nome del ruolo, la scelta indica che serve un mandato unico su strumenti, lavoro che cambia, competenze e rischio, e questo vale anche per una PMI. Ad aprile 2026 Atlassian ha allargato il mandato della sua responsabile delle persone, che oggi guida anche l'IT interno, la data science, il supporto tecnico ai clienti e la customer engineering. Il gruppo che dirige è passato da circa settecento persone a più di tremila, come ha ricostruito [Information Age](https://ia.acs.org.au/article/2026/atlassian-s-ceo-on-why-his-it-team-now-reports-to-hr.html) a inizio ottobre. Il nuovo titolo ha fatto parlare, e si capisce: un'azienda di software che porta l'IT sotto la funzione che si occupa di persone è una notizia. A noi interessa poco come si chiama il ruolo, perché in un'altra azienda potrebbe avere qualunque nome, e interessa molto di più il ragionamento che ha portato a quella scelta, perché descrive con precisione un problema che vediamo ogni settimana nelle aziende italiane che stanno adottando l'intelligenza artificiale. ## Le ragioni della riorganizzazione Mike Cannon-Brookes, CEO di Atlassian, lo ha spiegato al [podcast Decoder di The Verge](https://www.theverge.com/podcast/1000914/atlassian-ceo-mike-cannon-brookes-saaspocalypse-ai-enterprise-software-trello-jira). Quando ha messo in fila tutto quello che l'azienda doveva cambiare per lavorare davvero con l'AI, si è ritrovato con due gruppi di progetti, uno sulle persone (come farle crescere, come portarle a usare questi strumenti, come cambiare il loro modo di ragionare) e uno sui sistemi, cioè i server MCP da predisporre, l'operatività delle applicazioni interne, il controllo della spesa in token. Nella stessa intervista Cannon-Brookes racconta di essersi trovato più volte a fare da arbitro in discussioni interne su un singolo tema, per stabilire se fosse un problema di talento o un problema di sistema. La decisione di mettere tutto sotto un'unica guida nasce da lì, dalla constatazione che quella distinzione, sui progetti AI, smette di essere utile. Chi lavora sui progetti AI in azienda conosce bene quella discussione. Un assistente per il customer care va in produzione, i tempi di risposta scendono, e dopo tre mesi qualcuno chiede perché il team è ancora dimensionato come prima. L'IT risponde che il suo lavoro era rilasciare lo strumento, le risorse umane che nessuno le aveva coinvolte, il business che aspettava i numeri. Ognuno ha ragione sul proprio pezzo, e intanto il valore promesso non arriva. ## La frammentazione delle responsabilità Avani Prabhakar, la manager che oggi guida il nuovo gruppo, ha descritto la situazione tipica in un'[intervista al podcast Future of Work di Workday](https://www.workday.com/en-us/perspectives/hr/2026/09/how-hr-can-lead-ai-transformation.html), a settembre 2026. Nella maggior parte delle organizzazioni la spesa per i modelli la governa l'IT, la produttività la segue il CTO, la formazione la gestiscono le risorse umane e il ritorno dell'investimento lo misura un'altra funzione ancora. Quattro responsabili per lo stesso investimento. Quando i risultati tardano, ciascuno ha una parte della spiegazione e nessuno ha il quadro intero, che è esattamente la condizione in cui un progetto AI resta in pilota per anni. L'Osservatorio Artificial Intelligence del Politecnico di Milano, a febbraio 2026, ha contato progetti AI attivi nel 71% delle grandi aziende italiane e una [governance strutturata soltanto nel 9%](/blog/approfondimenti/71-percento-progetti-ai-9-percento-governance). In quella distanza c'è poco di tecnologico: ci sono decisioni che nessuno ha l'autorità di prendere da solo, perché toccano insieme i sistemi, i ruoli e il budget. L'AI non è un progetto dell'IT, è un progetto di governo dell'organizzazione. Lo diciamo da tempo ai consigli di amministrazione che incontriamo, e la scelta di Atlassian ha il merito di trasformare questa frase in un organigramma. ## L'impatto dell'automazione sul lavoro Quando si automatizza un processo, la parte facile è il rilascio. La parte difficile arriva dopo e riguarda il lavoro che resta: il tempo liberato va reinvestito in qualcosa, le persone hanno bisogno di competenze che prima non servivano, le responsabilità vanno ridisegnate perché chi prima eseguiva ora controlla, corregge, decide sulle eccezioni. Se queste decisioni vengono prese da funzioni diverse in momenti diversi, il tempo liberato si disperde. Atlassian lo ha misurato in una ricerca con clienti della Fortune 500: l'uso individuale dell'AI produce un guadagno di produttività personale intorno al 33%, mentre il ritorno a livello di azienda resta fermo su valori a una cifra bassa. La produttività individuale c'è, e si perde nel passaggio dalla persona all'organizzazione, che è precisamente lo spazio di cui nessuno, nell'organigramma tradizionale, risponde per intero. ## Le metriche di adozione Chi sta impostando un cruscotto sull'adozione dell'AI dovrebbe conoscere un dettaglio del caso Atlassian. La prima metrica che l'azienda si era data contava quanti dipendenti usassero almeno una funzione AI. In tre mesi era arrivata al 90%, e all'azienda non diceva quasi nulla di utile. L'hanno sostituita con una scala di maturità che distingue chi non usa l'AI, chi la usa per compiti semplici, chi la usa in modo strategico e chi ci ragiona insieme, costruendo ipotesi e mettendole alla prova. Su quest'ultimo gruppo hanno visto una produzione circa doppia rispetto agli utenti semplici, e soprattutto un effetto sui colleghi, perché sono loro a costruire il contesto (dati collegati, istruzioni, flussi) che rende l'AI utile anche agli altri. È un ragionamento vicino a quello dei [livelli di delega](/blog/strategia/ai-assisted-ai-first-ai-native-livelli-delega) che usiamo nei nostri assessment, dove si misura quanto lavoro viene affidato al sistema invece di quante persone hanno una licenza. Una metrica di diffusione la può gestire l'IT da sola, guardando i log delle licenze. Una metrica di profondità richiede di sapere come lavorano le persone, che competenze hanno, dove stanno cambiando i ruoli, ed è il motivo per cui nel nostro [AI Rating](/servizi/ai-rating) l'adozione reale e la fiducia degli utenti hanno una dimensione propria, Confidence, valutata separatamente dalla Delivery tecnica. ## L'ordine delle decisioni su compiti e ruoli L'altra scelta che ci sembra trasferibile riguarda l'ordine delle decisioni. Atlassian ha lavorato prima sui singoli compiti, poi sulle competenze che quei compiti richiedevano, e solo alla fine sui ruoli. Ha riscritto le job description dopo aver osservato come stavano cambiando, partendo dal design, dove alcuni designer avevano cominciato a scrivere e rilasciare codice e meritavano una famiglia professionale nuova. Prabhakar lo riassume così: invece di chiedersi se un ruolo servirà ancora, se ne servirà di più o di meno, hanno guardato come quel ruolo stava cambiando davvero. Sembra una sfumatura, e invece cambia la natura della conversazione con le persone, perché parte da quello che fanno ogni giorno e da lì arriva, eventualmente, alle previsioni sul loro futuro. Questa sequenza funziona solo se chi decide vede contemporaneamente i sistemi e le persone. Chi guarda solo i sistemi tende a saltare direttamente ai ruoli, con stime di riduzione dell'organico costruite su presentazioni dei fornitori. Chi guarda solo le persone tende a fermarsi alla formazione generica, senza collegarla ai compiti che cambiano, un limite di cui abbiamo scritto nel pezzo sul [change management per l'AI](/blog/approfondimenti/change-management-ai). ## I tagli al personale Accanto alla riorganizzazione c'è un dato che completa il quadro. Nello stesso anno Atlassian ha ridotto il personale di circa 1.600 persone, intorno al 10% della forza lavoro globale, per finanziare con risorse proprie gli investimenti in AI e nelle vendite enterprise. Cannon-Brookes ha parlato di scelte molto difficili legate al cambio del mix di competenze. Mettere persone e tecnologia sotto la stessa guida significa anche che la stessa funzione decide sulla formazione e sulle uscite. È coerente, perché sono davvero decisioni collegate, e proprio per questo richiede criteri espliciti, scritti prima, e un consiglio di amministrazione che li approvi sapendo cosa sta approvando. Cannon-Brookes distingue tra la trasparenza su ogni dettaglio, che dice di non dovere ai dipendenti, e la chiarezza sulle ragioni di ogni decisione, che invece ritiene dovuta. Su questo secondo punto, nelle aziende italiane, siamo spesso molto indietro. ## Le implicazioni per le aziende italiane Una PMI strutturata non ha tremila persone da riorganizzare e non ha bisogno di un nuovo titolo in organigramma. Ha bisogno di qualcuno, con un mandato chiaro del vertice, che risponda del programma AI nel suo insieme: gli strumenti, il lavoro che cambia, le competenze, il rischio. In molte aziende sarà il direttore generale, in altre il CFO o chi guida le operations, conta meno chi sia e conta molto che il mandato sia unico, con lo stesso principio che chiediamo per ogni agente in produzione, che deve avere un [owner con nome e cognome](/blog/ai-governance/agenti-ai-owner-nominativo-produzione). Conta anche come si comincia. Atlassian ha avviato il lavoro circa tre anni fa con un tavolo tra CISO, CTO, CIO e responsabile delle persone, affrontando prima le regole di sicurezza e poi i flussi di lavoro. Le persone sono entrate nel tavolo dal primo giorno, quando le decisioni si stavano ancora prendendo, invece di essere coinvolte a progetto finito per gestirne le conseguenze. Il resto discende da qui: un budget AI letto in un solo posto, metriche che misurano la profondità d'uso e il valore prodotto, decisioni sul lavoro che resta prese insieme a quelle sull'automazione. È anche il motivo per cui il nostro lavoro parte quasi sempre da una misura della maturità su quattro dimensioni (Readiness, Delivery, Risk e Confidence) con soglie che non si compensano tra loro: un'ottima infrastruttura tecnica non copre un'organizzazione che non sa ancora cosa fare del tempo che l'AI le restituisce. La domanda da portare in consiglio, a questo punto, riguarda chi risponde del lavoro che resta una volta che l'automazione è in produzione, e quante delle aziende che conosciamo saprebbero indicare un nome. Su come impostare quella conversazione con il board c'è l'articolo su [come presentare lo stato dell'AI al consiglio di amministrazione](/blog/ai-governance/come-presentare-ai-al-cda). Per capire da dove parte la vostra organizzazione potete [avviare un AI Rating](/avvia-ai-rating) o [fissare un incontro di valutazione](https://calendly.com/fabiolalli/zerofive).