5 Schemi Comuni Che Causano i Fallimenti dell’IA
Scopri le cause più comuni dei fallimenti nell'adozione dell'IA e come i leader tecnologici possono migliorare i risultati attraverso un contesto migliore, una comunicazione più efficace e decisioni informate.
Adam Horner
Fondatore di The CTO Playbook
Sfide del CTO: I CTO affrontano sfide comuni nell'integrazione dell’IA, richiedendo capacità di leadership per guidare importanti trasformazioni organizzative.
Impatto dell’IA: L’IA modifica l’ambito del lavoro di ingegneria, migliorando il processo decisionale oltre la semplice risoluzione tecnica dei problemi.
Ciclo di Triage dell’IA: L’IA ottimizza i cicli di triage e risoluzione, riducendo i ritardi nell’assistenza clienti e aumentando la concentrazione dei team.
Rischi nell’Uso: Un uso incontrollato degli strumenti di IA può aumentare i rischi legati ai dati; le organizzazioni devono gestire policy e supervisione sull’IA.
Team Ridotti: L’IA cambia la dinamica dei team, consentendo a gruppi più piccoli di lavorare in modo efficiente grazie allo sviluppo assistito dall’IA.
Adam Horner ha costruito team di ingegneria nei settori fintech e software aziendale. Ora è il fondatore di The CTO Playbook, dove educa e lavora come CTO frazionario.
Ci siamo seduti con lui per capire quali schemi sta osservando dietro i successi e i fallimenti nell'integrazione dell'AI. Ecco cosa ci ha raccontato.
Una versione della stessa sfida
Sono Adam Horner, coach CTO e CTO frazionario presso The CTO Playbook. Ho passato la prima parte della mia carriera come ingegnere e CTO cofondatore, costruendo e guidando team di ingegneria nel fintech e nel software aziendale, incluso diversi anni in Palantir come uno dei loro primi assunti nel Regno Unito.
Vuoi di più da The CTO Club?
Crea un account gratuito per completare questo articolo e unirti a una comunità di CTO e leader ingegneristici che condividono framework, strumenti e approfondimenti reali per progettare, implementare e scalare tecnologie guidate dall'IA.
Have an account? Log In
Il passaggio al coaching è nato da una semplice osservazione: diventare un dirigente tecnologico efficace è davvero difficile, e la maggior parte delle persone ci si addentra senza una mappa o nessuno al loro fianco che ci sia già passato. Questo è il lavoro che faccio ora, aiutando i CTO ad attraversare ciò che chiamo il "CTO chasm".
Il discorso sull'AI, per me, non è un filone separato. Corre attraverso quasi ogni conversazione di coaching che ho, perché ogni CTO con cui lavoro sta affrontando una versione della stessa sfida: come guidare un'organizzazione attraverso una trasformazione di questa portata, nella tua fase specifica, con il tuo team specifico e uscirne con un'azienda più forte?
Il caotico centro della curva di crescita
La mia organizzazione è piccola e volutamente snella, un team di fondatori di quattro persone che costruiscono tutto con un approccio "AI-first", sfruttando questa esperienza per restare vicini alle realtà dello sviluppo prodotto nelle fasi iniziali. Lavoro anche come CTO frazionario in una startup fintech pre-accreditamento, affrontando le pressioni particolari di portare sul mercato un prodotto regolamentato con un team di sviluppo esterno.
Ma il quadro più ampio, e da dove deriva la vera profondità di esposizione organizzativa, sono i CTO che seguo come coach. Si va dai team di fondazione e startup autofinanziate nelle prime fasi, passando per scaleup ad alta crescita sostenute da VC e PE, fino ad aziende di medie dimensioni che gestiscono una reale complessità organizzativa e aziende multidipartimentali che operano su larga scala.
Il "caotico centro" della curva di crescita è dove passo la maggior parte del mio tempo, ed è dove le sfide di leadership tendono ad essere più acute.
Come l’AI permette agli ingegneri di guardare all’insieme
Per me, il cambiamento più significativo non è stato uno strumento o un processo; è stata un'aspettativa. Come leader, quando dai al team il permesso — e soprattutto l'obbligo — di rivalutare l'intero ciclo di consegna dal basso verso l'alto, la portata di quella rivalutazione conta. Non solo come viene scritto o distribuito il codice, ma tutto ciò che riguarda il processo di consegna: supporto al cliente, valore per l'utente e l'intento aziendale che si cela dietro ogni attività.
Quando il costo di scrivere e mantenere il codice era elevato, aveva senso tenere gli ingegneri concentrati sul problema tecnologico. Ma quel costo è crollato. Il fattore limitante non è più la velocità di sviluppo, ma quanto chiaramente tutti i coinvolti comprendano cosa valga davvero la pena costruire e perché.
Gli ingegneri che comprendono il prodotto, il cliente e gli obiettivi aziendali dietro un cambiamento possono prendere decisioni e muoversi in modi che prima semplicemente non erano possibili. Ciò che è migliorato non è stato un indicatore. È stata la qualità delle domande che il team ha iniziato a porsi prima ancora di scrivere una sola riga.
Come i cicli di triage e risoluzione possono essere ridotti con l’AI
Un esempio riguarda la rielaborazione di come il supporto clienti e l'ingegneria interagivano sui bug confermati. In passato, i cicli di triage e risoluzione si misuravano in giorni o settimane, con i team di supporto che gestivano clienti frustrati e gli ingegneri che subivano il costo della distrazione dei problemi in produzione insieme al resto del loro lavoro. Quando il ciclo di consegna è stato rivalutato considerando lo sviluppo assistito dall’AI, i cicli di risoluzione si sono drasticamente ridotti e molta parte del processo è stata automatizzata.
Ciò ha comportato maggiore lavoro per il supporto all’inizio, che ha dovuto raccogliere e categorizzare le segnalazioni in modo puntuale, ma il vantaggio è stato una risoluzione in poche ore invece che giorni. Gli ingegneri sono rimasti concentrati. I clienti hanno ricevuto risposte più rapide. L’interfaccia tra due funzioni che fino a quel momento era sempre stata accettata come lenta si è rivelata completamente rinegoziabile.
Perché le organizzazioni non dovrebbero applicare l'IA a tutto
Per quanto riguarda cosa dovrebbe essere affidato agli esseri umani e cosa all'IA, la risposta varia per ogni organizzazione. Il punto di partenza corretto non è una lista di attività, ma una chiara comprensione di dove risiede il proprio valore e dove si concentra il rischio.
Le parti del processo che sono fondamentali per ciò che fa l'azienda — la logica, la differenziazione, le aree dove il fallimento è visibile o costoso — richiedono generazione e supervisione umana. Tutto il resto si colloca su uno spettro.
Un'azienda di sicurezza informatica impiegherà particolare attenzione umana alle proprietà di sicurezza del proprio codice, perché quella è la sua attività principale. Un'azienda di automazione dei processi può invece focalizzare la stessa attenzione sulla logica decisionale interna a un flusso di lavoro critico, mentre considera gli strumenti di sicurezza come qualcosa che l'IA può gestire adeguatamente.
Ciò che è sbagliato è applicare una politica generalizzata in una direzione o nell'altra. La domanda da porsi non è "L'IA può farlo?" ma "Qual è il costo se qualcosa va storto?"
Ecco un'altra cosa: una quantità sorprendente della complessità che le persone vogliono automatizzare è in realtà debito di processo irrisolto. Affrontate prima quello. In seguito, adottare l'IA sarà più semplice ed economico.
Perché i CTO dovrebbero iniziare automatizzando la delivery, non il codice
È davvero difficile confrontare i risultati dell'IA tra organizzazioni, perché la maggior parte dei leader, sia nel settore tecnologico che nel business più ampio, sta ancora lottando per misurare chiaramente l'impatto e il ROI dei propri investimenti in IA. Senza questo, è difficile sapere quale sia un buon risultato, e ancor più difficile sostenere la necessità di farne di più.
Tuttavia, in generale, la varietà dei risultati ottenuti con l'IA è ampia. Da un lato, ho lavorato con organizzazioni che sono riuscite di fatto ad eliminare l'arretrato e ora lavorano direttamente in funzione del valore per il cliente e dell'intento aziendale, rappresentando un cambiamento fondamentale nel modo in cui l'ingegneria si relaziona con il resto dell'azienda.
Ho notato un modello comune nelle organizzazioni che ci sono riuscite: nessuna ha iniziato dalla fase iniziale del ciclo di vita dello sviluppo software. Non sono partite dalla generazione di codice. Sono partite dalla parte finale: pipeline CI/CD, fiducia nella distribuzione, revisione automatica del codice. Rendere solida e affidabile la fase di delivery è ciò che ha creato le condizioni per tutto il resto. Da lì, l'attenzione si è spostata su test, vincoli e controlli prima della generazione, e sulla struttura rispetto alla velocità.
I team che hanno compiuto i maggiori progressi erano quelli che operavano in modo più autonomo, non perché avessero eliminato il giudizio umano, ma perché avevano integrato abbastanza di quel giudizio nel loro processo da poter affrontare con fiducia compiti significativamente più grandi. L'arretrato non è sparito perché scrivevano codice più velocemente. È sparito perché l'intera relazione tra intento e delivery è diventata inequivocabile.
Dall'altro lato, ho visto un vero calo di personale causato dal crescente divario tra chi si muove rapidamente con l'IA e chi no. Quando si inizia ad adottare l'IA, c'è quasi sempre un piccolo gruppo che va veloce e un gruppo più grande che non lo fa, e l'istinto naturale è lasciar correre i più veloci. Ciò che si crea, in modo silenzioso e veloce, è attrito, sfiducia e sospetto tra i team, che erodono i progressi più rapidamente di quanto si riesca ad accumularli. Il consiglio che ora do a ogni inizio di collaborazione è lo stesso: non lasciate indietro nessuno. Il ritmo di adozione dovrebbe essere determinato dalla velocità con cui riuscite a portare con voi tutta l'organizzazione, non da quanto possano correre individualmente i vostri ingegneri più entusiasti.
Un'organizzazione a due velocità dà la sensazione di progresso a chi è davanti. A chi sta dietro, sembra di essere lasciato indietro, e questa percezione ha delle conseguenze.
Quando inizia l’adozione dell’IA, c’è quasi sempre un piccolo gruppo che si muove velocemente e uno più grande che non lo fa; l’istinto naturale è lasciare che siano i più rapidi ad andare avanti. Quello che si crea, silenziosamente e rapidamente, è attrito, sfiducia e sospetto tra i team che erodono i progressi più in fretta di quanto i successi iniziali possano accumularli.
Perché la base di conoscenza di un'organizzazione deve essere riprogettata per l'IA
La lacuna più evidente che ho riscontrato nelle abilità dell'IA riguarda la presa di decisioni in condizioni di incertezza.
L'IA è fondamentalmente un motore di predizione e la predizione non è la stessa cosa del giudizio. Non ha nulla da perdere, nessun senso delle conseguenze, nessuna proprietà dell'esito. Aspettarsi che prenda decisioni al posto tuo sarà sempre limitato alla sua capacità di prevedere, che nelle situazioni veramente nuove o incerte è limitata. Le organizzazioni che sono rimaste più deluse dall'IA di solito sono quelle che ci hanno fatto affidamento proprio in quei momenti.
L'altro ambito in cui l'impatto dell'IA è inferiore alle attese, in modo più silenzioso ma altrettanto significativo, è dove le implicazioni delle finestre di contesto sono poco comprese. Se si fornisce all'IA un contesto incompleto o mal strutturato, essa darà comunque una risposta sicura di sé. Distinguere tra una risposta realmente ben informata e una che suona soltanto plausibile richiede il giudizio umano che non abbastanza team hanno ancora sviluppato.
Per questo, la base di conoscenza di un'organizzazione è fondamentale. Con ciò intendo tutto il contesto che vive oggi nella testa delle persone: il modo in cui le cose sono sempre state fatte, gli approcci di default, le regole non scritte su come funziona davvero l'organizzazione. L'IA non può lavorare con la conoscenza istituzionale che non è mai stata esternalizzata, e la maggior parte delle organizzazioni ne è piena.
La buona notizia è che per esternare questa conoscenza non serve che sia perfettamente strutturata. L'IA multimodale implica che un video esplicativo, uno schema grezzo e un documento non revisionato sono comunque input utili. La priorità è esternalizzare prima, strutturare poi.
Quello che riscontro costantemente è che l'atto stesso di estrarre questo contesto dalle menti delle persone e portarlo su qualsiasi tipo di documentazione ha valore in sé, prima ancora che l'IA lo tocchi. Fa emergere discrepanze, smaschera assunzioni sbagliate e rivela processi difettosi che nessuno aveva notato perché troppo coinvolto nel quotidiano.
Questa base, poi, moltiplica tutto ciò che l’IA potrà fare in seguito. È una delle attività a maggior impatto su cui un CTO può investire tempo in questo momento, ed è tra le più costantemente trascurate, nonostante i venditori di Business Process Automation lo dicano da anni!
Come evitare che gli sviluppatori scettici rallentino un'organizzazione
Un problema comune che vedo non è realmente un fallimento dell'IA. È un fallimento dell’adozione, e segue spesso uno schema riconoscibile.
Uno sviluppatore scettico — e sono sorprendentemente numerosi — fa una prova svogliata con contesto minimo, ottiene un risultato deludente e lo presenta come prova che l'IA non può svolgere il lavoro. La conclusione viene esposta con sicurezza. Raramente viene analizzato il metodo. Ciò che rende questa dinamica più di una semplice frustrazione individuale è l'effetto a cascata che ne consegue.
L'integrazione dell'IA in un team o in un ciclo di sviluppo è uno sport di squadra, e pochi ingegneri motivati a dimostrare che non funziona possono rallentare l'intera organizzazione, non solo le loro attività.
La lezione che traggo da questo non riguarda i limiti dell'IA. È che l'adozione è una sfida di leadership tanto quanto tecnica. La qualità di ciò che produce l'IA è inseparabile dalla qualità del contesto e dall’intenzione con cui la si impiega, e sviluppare questa consapevolezza nel team richiede lo stesso impegno deliberato necessario a qualsiasi altro cambiamento significativo nel modo di lavorare. Solo così possiamo passare dalla percezione di una "magia" difettosa a quella di una "tecnologia avanzata" davvero utilizzabile.
Perché i piccoli team sono un vantaggio con l’IA
L’assunto secondo cui un team di ingegneria funzionante e produttivo avesse bisogno di un certo numero di persone per gestire abbastanza contesto e lavorare a un ritmo significativo non ha retto il confronto con il modo in cui funziona davvero lo sviluppo assistito dall’IA.
Il fattore limitante in qualsiasi team è sempre stato di tipo cognitivo: quante informazioni di contesto ciascuno può gestire, quanto chiaramente riesce a comunicarle alle persone intorno a lui e quanta energia consuma quello scambio comunicativo. Quello che è cambiato è che l’unità operativa non è più solo una persona. Ognuno nel team gestisce più agenti, e quegli agenti portano e applicano il contesto in modi che cambiano totalmente la dinamica. La regola delle due pizze di Amazon era un’euristica ragionevole per il mondo prima dell’IA.
Ecco un esempio.
Un’organizzazione con cui lavoro ha sempre desiderato un’interfaccia amministrativa interna per la propria piattaforma, ma non è mai riuscita a giustificare l’investimento. Avevano già calcolato che sarebbe stato un progetto di mesi e avrebbe richiesto il team completo. Invece, hanno assegnato il compito a due persone: entrambe con profonda conoscenza del business e della piattaforma esistente, alta autonomia e un set chiaro di vincoli operativi. Sei settimane dopo avevano una prima versione funzionante.
La familiarità con l’azienda di queste due persone si è rivelata importante quanto gli strumenti di IA. Meno domande, meno overhead, decisioni più rapide. Ma il risultato davvero prezioso non era lo strumento in sé. Era ciò che l’organizzazione ha imparato su come lavorare in questo modo.
I team che sto vedendo operare in modo più efficace ora sono composti da due o tre persone, ognuna delle quali gestisce più agenti, e questo non rappresenta un limite. Per il tipo giusto di lavoro, è un vero vantaggio.
Perché la comunicazione frequente è fondamentale con i flussi di lavoro potenziati dall’IA
La collaborazione può diventare difficile con l’IA.
È necessaria una comunicazione molto più frequente perché tutto si muove più velocemente. È uno dei motivi per cui al momento i team più piccoli funzionano meglio.
Sembra semplicemente troppo estenuante mantenere lo stato e la coerenza con un team numeroso e diversi processi di codifica agentici paralleli per persona. Alcuni team con cui lavoro hanno adottato due standup al giorno per mantenere la coerenza.
Perché i CTO devono prestare attenzione alla Shadow AI
La Shadow AI è il vecchio problema della shadow IT ma con un nuovo budget e un nuovo nome.
L’utilizzo incontrollato e senza vincoli degli strumenti di IA nell’organizzazione può facilmente aumentare i rischi di perdita di dati e proprietà intellettuale — "esfiltrazione" come la definisce il CISO — spesso in modo del tutto involontario da parte degli utenti.
La maggior parte delle organizzazioni sta rapidamente abbandonando la fase 1 del CMM (la fase di sperimentazione "far west") per introdurre politiche e vincoli tecnici che riducano i rischi.
Perché i CTO devono concentrarsi sul proprio sviluppo
Al momento c’è molta ansia nel settore su ciò che l’IA significhi per i team di ingegneria, per il numero di persone e per il ruolo stesso.
Se questa ansia sia giustificata o meno è quasi irrilevante. Ciò che conta è che stiamo vivendo un periodo di cambiamenti significativi e rapidi, e navigarlo bene richiede leader che investano attivamente nello sviluppo delle proprie competenze, non solo nell’adattare i cambiamenti intorno a loro.
Quello che ancora mi sorprende, visto tutto ciò che sta accadendo, è quanti CTO e leader tecnologici senior stiano operando senza alcun investimento dedicato nella propria crescita. Nessun coach, nessuno sviluppo strutturato, nessun partner di pensiero. Ho commesso quell’errore una volta, e gli errori che ho fatto e il tempo che ho perso non erano inevitabili.
I leader che usciranno più forti da questo periodo non saranno necessariamente quelli con gli strumenti migliori o i team più grandi. Saranno quelli che stanno costruendo capacità di giudizio, influenza e chiarezza di pensiero per guidare bene quando nessuno ha una mappa chiara.
Seguimi
Puoi seguire il lavoro di Adam Horner su LinkedIn. Per coaching individuali, corsi di gruppo e il podcast, vai su The CTO Playbook. E per un corso gratuito via email di 5 giorni dedicato ai CTO alle prime armi, visita Early CTO Map.
Altre interviste con esperti in arrivo su The CTO Club!
