5 schemi comuni che causano 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, comunicazione efficace e decisioni più consapevoli.
Adam Horner
Fondatore di The CTO Playbook
Sfide per il CTO: I CTO affrontano sfide comuni nell'integrazione dell'IA, richiedendo una leadership capace di guidare profonde trasformazioni organizzative.
Impatto dell'IA: L'IA cambia il perimetro del lavoro di ingegneria, migliorando il processo decisionale oltre la semplice risoluzione tecnica dei problemi.
Ciclo di triage dell'IA: L'IA velocizza i cicli di triage e risoluzione, riducendo i tempi di attesa dell'assistenza clienti e rafforzando il focus dei team.
Rischi d'uso: Un utilizzo incontrollato degli strumenti IA può aumentare i rischi legati ai dati; le organizzazioni devono gestire policy e supervisione dell'IA.
Piccoli team: L'IA trasforma la dinamica dei team, permettendo a gruppi più piccoli di lavorare in modo efficiente con lo sviluppo assistito dall'IA.
Adam Horner ha costruito team di ingegneria sia nel fintech che nel software aziendale. Ora è il fondatore di The CTO Playbook, dove svolge un'attività educativa e lavora come CTO frazionale.
Ci siamo seduti con lui per capire quali schemi sta osservando dietro ai successi e ai fallimenti nell'integrazione dell’IA. Ecco cosa ci ha raccontato.
Una qualche versione della stessa sfida
Sono Adam Horner, coach per CTO e CTO frazionale presso The CTO Playbook. Ho trascorso la prima parte della mia carriera come ingegnere e CTO cofondatore, costruendo e guidando team di ingegneria nel fintech e nel software aziendale, compresi diversi anni in Palantir come uno dei 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 mio passaggio al coaching deriva da una semplice osservazione: diventare un dirigente tecnologico efficace è davvero impegnativo, e la maggior parte delle persone affronta questo percorso senza una mappa o qualcuno al proprio fianco che ci sia già passato. Questo è ciò che faccio ora: aiuto i CTO ad attraversare quello che chiamo il "CTO chasm".
L’aspetto IA, per me, non è un tema separato. Si intreccia praticamente con ogni conversazione di coaching che affronto, perché ogni CTO con cui lavoro sta affrontando una qualche versione della stessa sfida: come guidare un'organizzazione attraverso una trasformazione di tale portata, nella propria fase specifica, con il proprio team, e uscirne come una realtà più solida?
Il caotico mezzo della curva di crescita
La mia organizzazione è piccola e volutamente snella, un team fondatore di quattro persone che costruisce tutto secondo una logica full-AI, e sfruttiamo questa esperienza per restare vicini alle realtà dello sviluppo prodotto in fase iniziale. Lavoro inoltre come CTO frazionale con una startup fintech pre-accreditamento, affrontando le particolari pressioni di lanciare sul mercato un prodotto regolamentato insieme a un team di sviluppo esterno.
Ma il quadro più ampio, e dove risiede la vera profondità dell'esposizione organizzativa, sono i CTO che seguo come coach. Si va da team fondatori e startup autofinanziate nelle fasi iniziali, a scaleup in forte crescita sostenuti da VC e PE, passando per aziende di medie dimensioni che gestiscono complessità strutturali reali, fino a grandi aziende multi-dipartimentali che operano su larga scala.
Il caotico mezzo della curva di crescita è dove trascorro la maggior parte del mio tempo, ed è lì che le sfide di leadership tendono a essere più intense.
Come l’IA permette agli ingegneri di vedere il quadro generale
Per me, il cambiamento più significativo non è stato uno strumento o un processo, ma un’aspettativa. Come leader, quando dai al team il permesso — e, più importante, l’obbligo — di rivalutare l’intero ciclo di consegna a partire dalle basi, la portata di quella rivalutazione conta. Non solo come viene scritto o distribuito il codice, ma tutto ciò che tocca il processo di delivery: supporto clienti, valore per l’utente, e l’intento di business che sta dietro ogni singolo lavoro.
Quando il costo di scrivere e mantenere codice era alto, tenere gli ingegneri concentrati strettamente sul problema tecnico aveva senso. Ma questo costo è crollato. Il fattore limitante non è più la velocità di sviluppo, ma quanto chiaramente tutti i coinvolti comprendono cosa valga davvero la pena costruire e perché.
Ingegneri che comprendono il prodotto, il cliente e gli obiettivi di business dietro una modifica possono prendere decisioni e agire in modi prima impensabili. A migliorare non è stato un indicatore numerico, ma la qualità delle domande che il team ha iniziato a porsi prima ancora di scrivere una riga di codice.
Come i cicli di triage e correzione possono essere compressi con l’IA
Un esempio riguarda la rivisitazione dell’interazione tra supporto clienti e ingegneria relativa ai bug confermati. Prima, i cicli di triage e correzione si misuravano in giorni o settimane, con i team di supporto a gestire i clienti frustrati e gli ingegneri a sostenere il costo di distrazione degli incidenti in tempo reale oltre agli altri compiti. Quando il ciclo di consegna è stato rivalutato con in mente lo sviluppo assistito dall’IA, i cicli di correzione si sono drasticamente ridotti e gran parte del processo è stata automatizzata.
Questo ha comportato un maggiore lavoro iniziale per il supporto, che ha dovuto raccogliere e classificare chiaramente i problemi, ma il risultato è stata una risoluzione in poche ore invece che in giorni. Gli ingegneri sono rimasti focalizzati. I clienti hanno ottenuto risposte più rapide. L’interfaccia tra due funzioni che storicamente era accettata come lenta, si è rivelata completamente ridefinibile.
Perché le organizzazioni non dovrebbero applicare l’IA a tutto
Per decidere cosa dovrebbe essere compito umano e cosa invece è adatto all’IA, ogni organizzazione deve valutare la propria situazione. Il giusto punto di partenza non è una lista di attività, ma una chiara comprensione di dove risiede il valore e dove si concentra il rischio.
Le parti del processo che sono fondamentali per il business — la logica, la differenziazione, le aree in cui un fallimento sarebbe visibile o costoso — meritano generazione e supervisione umana. Tutto il resto si colloca su uno spettro.
Un’azienda di sicurezza informatica dedicherà molta attenzione umana alle proprietà di sicurezza del proprio codice, perché quello è il cuore del business. Un’azienda specializzata in automazione dei flussi di lavoro potrebbe concentrare la stessa attenzione sulla logica decisionale di un workflow critico, lasciando invece che la strumentazione di sicurezza venga gestita dall’IA, se adeguata allo scopo.
Applicare una politica unica in ogni direzione è errato. La domanda non dovrebbe essere "L’IA può farlo?" ma "Qual è il costo se qualcosa va storto?"
Ecco un’altra cosa: molta della complessità che si vuole automatizzare è in realtà debito di processo non risolto. Occorre affrontare prima quello. Così adottare l’IA sarà più semplice ed economico.
Perché i CTO devono iniziare automatizzando la delivery, non il codice
È davvero difficile confrontare i risultati dell’IA tra diverse organizzazioni, perché la maggior parte dei leader, sia nel settore tecnologico che nel business in generale, fatica ancora a misurare chiaramente l’impatto e il ROI dei loro investimenti in IA. Senza queste misurazioni, è difficile capire cosa significhi davvero un buon risultato, e ancor più difficile sostenere la necessità di investire ulteriormente.
Complessivamente, la gamma dei risultati che si ottengono con l’IA è molto ampia. Da una parte, ho lavorato con organizzazioni che sono state in grado di eliminare di fatto l’arretrato e ora lavorano direttamente mirando al valore per il cliente e agli obiettivi aziendali, rappresentando una trasformazione fondamentale nel modo in cui l’ingegneria si relaziona con il resto dell’azienda.
Ho notato uno schema ricorrente nelle organizzazioni che ci sono riuscite: nessuna di queste ha iniziato dalla parte sinistra del ciclo di vita dello sviluppo software. Non hanno iniziato dalla generazione del codice. Hanno iniziato dalla parte destra: pipeline CI/CD, fiducia nei processi di deployment, revisione automatizzata del codice. Rendere la fase di delivery affidabile e solida fin dall’inizio 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 più che sulla velocità.
I team che hanno fatto più progressi sono quelli che operavano in maggiore autonomia, non perché avessero eliminato il giudizio umano, ma perché ne avevano codificato abbastanza nei loro processi da poter prendersi carico di volumi di lavoro significativamente maggiori con fiducia. L’arretrato non è scomparso perché scrivevano codice più in fretta. È scomparso perché il rapporto tra intenzione e consegna è diventato privo di ambiguità.
Dall’altro lato, ho visto un vero turnover del personale causato dal crescente divario tra chi si muove rapidamente con l’IA e chi invece resta indietro. Quando inizia l’adozione dell’IA, quasi sempre un piccolo gruppo si muove velocemente, mentre la maggioranza rimane più lenta; l’istinto naturale è lasciare correre i primi. Questo però, in modo silenzioso e rapido, genera attrito, diffidenza e sospetto tra i team, erodendo i vantaggi più in fretta di quanto i progressi iniziali possano essere accumulati. Il consiglio che ora do all’inizio di ogni percorso è lo stesso: non lasciate indietro nessuno. Il ritmo d’adozione dev’essere determinato dalla rapidità con cui riuscite a portare tutta l’organizzazione con voi, non da quanto velocemente i vostri ingegneri più motivati si muovono individualmente.
Un’organizzazione a due velocità dà l’impressione di progresso da chi sta avanti. Da chi sta dietro, sembra di essere abbandonato — e quella sensazione ha delle conseguenze.
Quando l’adozione dell’IA inizia, c’è quasi sempre un piccolo gruppo che si muove velocemente e un gruppo più numeroso che non lo fa, e l’istinto naturale è lasciare che siano i primi ad andare avanti. Quello che si crea, in modo silenzioso e rapido, è attrito, diffidenza e sospetto tra i team che erodono i progressi più velocemente di quanto i primi risultati possano accumularli.
Perché la base di conoscenza di un'organizzazione deve essere ripensata per l'IA
La lacuna più evidente che ho riscontrato nelle capacità dell'IA sta nel processo decisionale in condizioni di incertezza.
L'IA è fondamentalmente un motore di previsione, e la previsione non è lo stesso che il giudizio. Non ha nulla in gioco, non percepisce le conseguenze, non si assume la responsabilità dell'esito. Pretendere che prenda decisioni per conto nostro sarà valido solo quanto la sua capacità predittiva, che in situazioni realmente incerte o nuove è limitata. Le organizzazioni che hanno subito le maggiori delusioni dall'IA sono solitamente quelle che vi hanno fatto affidamento proprio in quei momenti.
L'altro ambito dove l'impatto viene meno, in modo più silenzioso ma altrettanto significativo, è quando le implicazioni delle finestre di contesto sono comprese superficialmente. Se si fornisce a un'IA un contesto incompleto o poveramente strutturato, essa darà comunque una risposta sicura di sé. Distinguere tra un risultato ben fondato e uno solo plausibile richiede un giudizio umano che ancora pochi team hanno sviluppato.
Per questo motivo, la base di conoscenza di un'organizzazione è fondamentale. Con questo intendo tutto il contesto che attualmente risiede nelle teste delle persone: il modo in cui si è sempre fatto qualcosa, gli approcci di default, le regole non scritte di come l'organizzazione realmente funziona. L'IA non può lavorare con conoscenze istituzionali mai esternalizzate, e la maggior parte delle organizzazioni ne detiene una quantità enorme.
La buona notizia è che estrarre queste informazioni non richiede una strutturazione perfetta. Grazie all'IA multimodale, una video-presentazione, uno schema approssimativo e un documento non revisionato costituiscono tutti input rilevanti. La priorità è esternare prima, strutturare dopo.
Quello che riscontro costantemente è che il semplice atto di tirar fuori il contesto dalle teste delle persone e trasferirlo in qualsiasi forma di documentazione è utile di per sé, ancor prima che venga trattato dall'IA. Questo fa emergere discrepanze, mette in luce presupposti errati e rivela processi difettosi che nessuno aveva notato perché vi era troppo immerso.
Questa base poi moltiplica tutto ciò che l'IA potrà realizzare successivamente. È una delle attività con il maggior effetto leva su cui un CTO può investire tempo in questo momento, e una delle più trascurate, nonostante il fatto che i venditori di Business Process Automation ce lo ripetano da anni!
Come evitare che sviluppatori scettici rallentino un'organizzazione
Un problema frequente che vedo non riguarda propriamente un fallimento dell'IA, ma un fallimento nell'adozione, che tende a seguire uno schema riconoscibile.
Uno sviluppatore scettico — e ce ne sono sorprendentemente tanti — fa un tentativo poco convinto con il minimo contesto, ottiene un risultato insoddisfacente e lo porta a prova che l'IA non può svolgere quel lavoro. La conclusione viene espressa con sicurezza. Il metodo viene raramente approfondito. Ciò che rende questa situazione più di una semplice frustrazione individuale è l'effetto a catena.
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 la propria produttività.
La lezione che traggo non riguarda le limitazioni dell'IA. Piuttosto, l'adozione è una sfida di leadership tanto quanto tecnica. La qualità di ciò che l'IA produce è inseparabile dalla qualità del contesto e dell'intento che ci si mette, e costruire questa comprensione a livello di team richiede lo stesso impegno deliberato di qualunque altro cambiamento significativo nel modo di lavorare. Solo così si può passare dalla percezione della "magia fallace" alla "tecnologia avanzata" effettivamente utilizzabile.
Perché i piccoli team sono un vantaggio con l'IA
L'assunto che un team di ingegneria funzionante e produttivo avesse bisogno di un certo numero di persone per mantenere abbastanza contesto e muoversi a un ritmo significativo non ha resistito al confronto con come funziona effettivamente lo sviluppo assistito dall'IA.
Il fattore limitante in qualsiasi team è sempre stato di natura cognitiva: quanta parte del contesto ogni persona riesce a trattenere, quanto chiaramente riesce a comunicarlo alle persone intorno a sé, e quanta energia richiede questa comunicazione. Ciò che è cambiato è che l'unità che svolge il lavoro non è più solo una persona. Ogni membro del team gestisce diversi agenti, e questi agenti portano e applicano il contesto in modi che cambiano completamente l'aritmetica. La regola delle due pizze di Amazon era un'euristica ragionevole per un mondo pre-IA.
Ecco un esempio.
Un'organizzazione con cui collaboro ha sempre desiderato un'interfaccia amministrativa interna per la propria piattaforma, ma non riusciva mai a giustificarne l'investimento. In passato aveva stimato il costo come uno sforzo di mesi per l'intero team. Invece, hanno assegnato due persone: entrambe con una profonda conoscenza del business e della piattaforma esistente, alta autonomia e un insieme chiaro di vincoli entro cui lavorare. Sei settimane dopo, avevano una prima versione funzionante.
La familiarità di queste due persone con il business si è rivelata importante quanto gli strumenti di IA. Meno domande, meno overhead, decisioni più rapide. Ma il risultato più prezioso non è stato lo strumento in sé. È stato ciò che l'organizzazione ha imparato su come lavorare in questo modo.
I team che vedo operare più efficacemente ora sono composti da due o tre persone, ognuna delle quali gestisce più agenti, e questo non è un limite. Per il tipo giusto di lavoro, è un vantaggio.
Perché la comunicazione frequente è fondamentale con i flussi di lavoro alimentati 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 i team piccoli funzionano meglio al momento.
Sembra semplicemente troppo faticoso mantenere stato e coerenza con un team numeroso e molteplici processi di codifica agentica paralleli per persona. Alcuni dei team con cui lavoro sono passati a due standup al giorno per mantenere la coerenza.
Perché i CTO devono tenere d'occhio l'IA ombra
L'IA ombra è il problema già osservato dell'IT ombra, con un nuovo budget e un nuovo nome.
L'uso incontrollato e senza vincoli di strumenti di IA in tutta l'azienda può aumentare facilmente i rischi di perdita di dati e proprietà intellettuale — "esfiltrazione" come la definisce il CISO — spesso del tutto involontariamente da parte degli utenti.
La maggior parte delle organizzazioni sta rapidamente uscendo dalla fase 1 del CMM (la fase di sperimentazione "far west") per mettere in atto politiche e vincoli tecnici per ridurre i rischi.
Perché i CTO devono concentrarsi sul proprio sviluppo
In questo momento c'è molta ansia nel settore su cosa significhi l'IA per i team di ingegneria, per il numero di persone, per il ruolo stesso.
Che quell'ansia sia giustificata o meno è quasi irrilevante. Quello che conta è che siamo in un periodo di cambiamento significativo e rapido, e per orientarsi bene servono leader che sviluppino attivamente le proprie capacità, non solo che gestiscano i cambiamenti intorno a loro.
Ciò che ancora mi sorprende, considerato tutto quello che sta succedendo, è quanti CTO e leader tecnologici senior operano senza alcun investimento dedicato nella propria crescita. Nessun coach, nessuno sviluppo strutturato, nessun partner di riflessione. L'ho fatto anch'io una volta, e gli errori che ho commesso e il tempo perso non erano inevitabili.
I leader che usciranno più forti da questo periodo non sono necessariamente quelli con i migliori strumenti o i team più grandi. Sono quelli che stanno sviluppando il giudizio, l'influenza e la chiarezza di pensiero per guidare bene quando nessuno ha una guida certa.
Segui gli aggiornamenti
Puoi seguire il lavoro di Adam Horner su LinkedIn. Per coaching individuale 1:1, corsi di gruppo e il podcast, vai su The CTO Playbook. E per un corso email gratuito di 5 giorni dedicato ai CTO alle prime armi, vai su Early CTO Map.
Altre interviste ad esperti in arrivo su The CTO Club!
