La maggior parte delle organizzazioni sta adottando l'intelligenza artificiale. Poche possono dimostrare che funzioni. Ecco cosa distingue gli esperimenti dall'impatto.
La maggior parte delle organizzazioni ha già percepito l'entusiasmo iniziale dello sviluppo assistito dall'IA. Gli sviluppatori scrivono codice più rapidamente. La produttività sembra aumentata. Ma poi succede qualcosa di strano: le metriche di delivery complessive non migliorano molto. Oppure, in alcuni casi, la stabilità peggiora.
Questa tensione è stata uno dei punti principali al centro di un recente webinar di Adaptavist e GitLab, in cui i nostri esperti hanno esplorato che cosa realmente serve per ottenere un valore significativo e misurabile dall’IA agentica lungo l’intero ciclo di consegna del software. E questo si collega a qualcosa su cui stiamo facendo ricerche più approfondite: il divario tra adozione dell'IA e impatto dell'IA non è solo un problema tecnico. È anche un problema umano.
I numeri non quadrano
I dati del webinar sono degni di attenzione: secondo il report di Atlassian “
State of Team 2026”, l'89% dei dirigenti afferma che l'intelligenza artificiale ha aumentato la velocità del lavoro. Eppure,
solo il 6% si sente sicuro di poter indicare un ritorno sull'investimento specifico e a livello organizzativo. L'implementazione non strategica dell'IA sta costando alle aziende Fortune 500 circa
161 miliardi di dollari all'anno in quella che il report definisce una “
tassa sulla frammentazione”. La nostra ricerca evidenzia una storia simile anche dal punto di vista dei knowledge workers.
ll costo umano della trasformazione guidata dall'IA
Abbiamo intervistato i knowledge workers per capire come l'IA stia effettivamente entrando nel mondo del lavoro: i risultati rivelano un divario tra adozione e coinvolgimento che la maggior parte delle organizzazioni non sta considerando.
Il 36% dei knowledge workers spesso non capisce perché ci si aspetti che usino l'IA nel loro ruolo. L'adozione sta avvenendo, ma non è la stessa cosa dell'impegno, e uno non garantisce l'altro. Per molti lavoratori, l'IA non ha ridotto tanto il carico di lavoro quanto lo ha redistribuito: meno tempo per eseguire, più tempo per verificare e controllare i risultati ottenuti con strumenti per i quali non sono stati adeguatamente formati.
Quando le organizzazioni considerano l'IA un problema di implementazione anziché una trasformazione, questa è la conseguenza a larga scala.
Il paradosso dell'IA è reale
Il problema non è la tecnologia, ma in che contesti le organizzazioni la applicano. Quando l'intelligenza artificiale viene usata semplicemente come un modo più rapido per scrivere codice, si comprime una fase del delivery mentre tutto ciò che viene dopo rimane invariato. Revisioni, controlli di sicurezza, test e coordinamento dell'implementazione diventano tutti i nuovi colli di bottiglia.
Questo è ciò che accade quando si vede l’AI come un semplice autocomplete evoluto, senza coglierne il potenziale nel resto del processo.
Matthias Ewald
Partner Solution Architect, GitLab
Una generazione del codice più rapida, senza un cambiamento più ampio del processo, non accelera il delivery. Sposta semplicemente il vincolo.
L’IA amplifica ciò che è già presente
La ricerca DORA citata nel webinar conferma questo punto: un aumento del 25% nell'adozione dell'IA è stato associato a una diminuzione dell'1,5% nella produttività nel delivery e a una diminuzione del 7,2% nella stabilità della consegna. L'IA tende ad aumentare la produttività nelle organizzazioni con buone performance, ma in quelle meno operative amplifica le disfunzioni esistenti. Se i tuoi processi, la governance e l'allineamento del team non sono solidi, l'IA evidenzierà e accelererà queste lacune anziché mascherarle.
Il cambiamento non è più soltanto uno shift-left
L’industria ha trascorso l’ultimo decennio concentrandosi sul concetto di “shift-left”: intercettare i problemi di sicurezza e di qualità nelle fasi iniziali della pipeline, quando correggerli costa meno. Questo principio resta valido.
Ma l’IA agentica introduce una nuova dimensione: Matthias Ewald l’ha definita “shift-up”: portare i team al di sopra del loop di delivery, in modo che definiscano le regole, impostino le policy e lascino agli agenti l’esecuzione lungo le diverse fasi.
Il ciclo di vita non scompare. Le fasi non scompaiono. Ciò che cambia è che l’attesa, i passaggi di consegna manuali e la traduzione tra una fase e l’altra possono essere sempre più automatizzati.
La governance di questo nuovo livello, al di sopra dell’SDLC, sta diventando rapidamente una delle sfide centrali della software delivery in ambito enterprise. Quali agenti possono agire? Con quali dati? In quali ambienti? Chi risponde quando qualcosa va storto? Non si tratta di domande di contorno. È da qui che dipende la reale capacità di scalare un investimento in IA.
Tre condizioni essenziali perché gli agenti possano operare su scala
Nel corso della sessione sono emersi alcuni elementi imprescindibili per le organizzazioni che vogliono andare oltre la sperimentazione:
Una solida base DevSecOps: l’IA agentica non elimina la necessità di controlli CI/CD, policy as code, gestione delle identità e degli accessi o audit trail immutabili. Al contrario, li rende ancora più importanti: gli agenti devono operare all’interno della pipeline, non al di fuori di essa.
Analisi del blast radius: prima di concedere a un agente qualsiasi azione autonoma nel proprio ambiente, è necessario capire su cosa può intervenire, cosa può compromettere e se potrebbe innescare loop fuori controllo che prosciugano il budget di token. Ridurre al minimo il perimetro d’azione non limita le capacità dell’IA: è una misura fondamentale di gestione del rischio.
Responsabilità umana in ogni passaggio: ogni azione compiuta da un agente deve poter essere ricondotta a una persona. Nei settori regolamentati non è facoltativo, ma resta una buona pratica in qualsiasi settore.
Come sai se sta funzionando davvero?
La questione del ROI dell’IA è emersa direttamente durante la sessione di Q&A, e la risposta è più pratica di quanto molte organizzazioni si aspettino. L’impatto dell’IA si misura nello stesso modo in cui si misurerebbe qualsiasi cambiamento nel processo di delivery: attraverso le metriche DORA. Frequenza di deployment, lead time delle modifiche, tasso di failure delle modifiche, tempo di ripristino. Se stai già lavorando su GitLab, gran parte di questi dati è probabilmente già disponibile.
Il value stream mapping aggiunge un’altra dimensione: le metriche DORA indicano quanto le cose siano migliorate, mentre il value stream mapping mostra dove gli agenti stanno facendo davvero la differenza. Usati insieme, offrono una base credibile e quantificabile per dimostrare al business il ritorno sull’investimento.
Cosa aspettarsi in termini di tempistiche
I benefici individuali possono arrivare in tempi rapidi, ma un miglioramento esteso all’intera organizzazione si misura in mesi o trimestri, non in giorni. L’adozione segue una curva: i first mover dimostrano il valore all’interno dell’azienda, l’enablement si diffonde progressivamente e gli adottanti più tardivi richiedono ulteriore supporto.
Il rollout tecnico rappresenta solo una parte dell’equazione. Change management, comunicazione chiara sul perché l’IA viene introdotta e supporto ai team nel gestire il cambiamento contano quanto le scelte di piattaforma.
Provare a forzare o saltare uno di questi passaggi produce spesso proprio quel tipo di implementazione dell’IA frammentata e scoordinata che finisce per alimentare il costo della frammentazione.
Guarda l'intera sessione
Il webinar approfondisce i requisiti della piattaforma per l'IA agentica, l'approccio di GitLab alla gestione del contesto e alla governance, e i quadri pratici per prioritizzare l’investimento in IA in base al massimo impatto.
Superare il paradosso dell’IA
Jan Rockemann e Matthias Ewald analizzano i requisiti delle piattaforme, i quadri di governance e gli approcci alla misurazione che distinguono i programmi di intelligenza artificiale di successo da costosi esperimenti.
