Il CTO afferma che l’IA ha bisogno di un nuovo modello di governance

Tyrone Grandison ha ricoperto numerosi ruoli a livello dirigenziale nei suoi 35 anni di carriera nel settore tecnologico e attualmente è il CTO di Cornerstone Assurance Corporation. È anche l'autore di La rivoluzione dell'IA e una cultura che dura nel tempo.

Abbiamo parlato con Tyrone per capire come l'IA stia cambiando la governance nelle organizzazioni tecnologiche. Ecco cosa ci ha raccontato.

35 anni nel settore tecnologico

Guido un'organizzazione tecnologica snella che supporta un'azienda in crescita nei settori assicurativo e dei servizi finanziari, chiamata Cornerstone Assurance Corporation. Ciò che rende il ruolo particolarmente interessante è che stiamo costruendo un moderno insieme di tecnologie mentre operiamo in un settore caratterizzato da significativi requisiti normativi, dati finanziari sensibili, integrazioni complesse con i vettori assicurativi e una tolleranza molto bassa per gli errori.

Ho iniziato la mia carriera come informatico, molto prima che l'IA diventasse l'argomento di ogni conversazione nei consigli di amministrazione e di ogni intervento ai convegni. Nel corso degli anni, il mio lavoro mi ha portato dalla costruzione della tecnologia alla guida di organizzazioni attraverso i cambiamenti che la tecnologia stava imponendo loro. Ho ricoperto i ruoli di Direttore dell'intelligenza artificiale, Direttore della tecnologia, Direttore dei sistemi informativi e Vice direttore dei dati. Ho lavorato nel settore pubblico, nel mondo accademico, in startup, nella consulenza, in organizzazioni non profit e in grandi aziende.

Dopo 35 anni nel settore tecnologico, ho avuto il privilegio di assistere all'introduzione di diverse tecnologie presentate come “la tecnologia che cambierà tutto”. E alcune lo hanno fatto davvero.

Ogni grande cambiamento costringe i leader a prendere decisioni prima di disporre di informazioni perfette. Mette alla prova i modelli di business, i modelli operativi, la cultura, i talenti, la governance e talvolta la nostra comprensione di ciò che dovrebbero essere i nostri stessi lavori. L'IA sta facendo tutto questo contemporaneamente.

Ma ciò che rende questo momento particolarmente affascinante per me è che siamo andati oltre un'IA che si limita ad aiutarci ad analizzare le informazioni. Oggi disponiamo di sistemi in grado di generare, ragionare, pianificare, creare, scrivere codice, utilizzare strumenti e, sempre più spesso, agire. Questo cambia radicalmente la conversazione sulla leadership.

La domanda un tempo era: “Cosa può fare l'IA?”

Credo che questa stia rapidamente diventando la domanda meno interessante. Persino la domanda sbagliata.

Le domande molto più importanti sono: cosa dovremmo consentirle di fare? Dove resta essenziale il giudizio umano? Come riprogettiamo le organizzazioni quando anche le intuizioni diventano abbondanti? E come possiamo sfruttare l'enorme potenziale di questa tecnologia senza creare rischi che non comprendiamo o sistemi che non siamo in grado di governare?

È questo il punto in cui si concentra oggi il mio lavoro. Collaboro con dirigenti e organizzazioni per aiutarli a distinguere il segnale dalla considerevole quantità di rumore che circonda l'IA, a comprendere ciò che sta realmente cambiando e a trasformare questa comprensione in strategia, governance, prodotti e risultati aziendali misurabili.

Come l'IA trasforma i cicli di vita dello sviluppo del software

Uno dei cambiamenti più importanti che ho apportato in Cornerstone Assurance Corporation è stato riprogettare il nostro ciclo di vita dello sviluppo del software partendo dal presupposto che l'IA scriverà una percentuale significativa del nostro codice.

Prima di questo cambiamento, seguivamo un flusso di lavoro ingegneristico piuttosto tradizionale. Uno sviluppatore prendeva in carico un requisito, progettava la soluzione, scriveva il codice, creava i test, inviava una richiesta di integrazione e un altro ingegnere la esaminava. Utilizzavamo naturalmente l'automazione, ma gli esseri umani svolgevano ancora la maggior parte del lavoro cognitivo, dal requisito alla distribuzione.

L'IA ha cambiato completamente l'economia di questo modello.

Abbiamo quindi introdotto una pipeline di sviluppo assistita dall'IA, utilizzando GitHub Copilot per la generazione e la ristrutturazione del codice, ChatGPT e Claude per l'esplorazione architetturale guidata dall'IA, la scomposizione dei requisiti, la ricerca e correzione degli errori e la generazione dei casi di test, mentre i nostri normali strumenti di CI/CD e di sicurezza fornivano i controlli deterministici sul lavoro generato dall'IA.

Perché il codice generato dall'IA richiede un nuovo modello di governance

Ma il cambiamento importante non è stato: “Ehi, ora avete tutti Copilot”. Abbiamo cambiato il modello di governance.

Fasi di approvazione

Ora trattiamo il codice generato dall'IA quasi come il codice inviato da un ingegnere junior molto veloce, che non dorme mai, ha letto una quantità assurda di documentazione e occasionalmente dice qualcosa di completamente sbagliato con enorme sicurezza.

Ciò significa che l'AI può generare codice, test unitari, contratti API, documentazione, query di database, definizioni dell'infrastruttura e correzioni proposte, ma non può approvare il proprio lavoro né avere un percorso incontrollato verso la produzione.

Abbiamo introdotto punti espliciti di approvazione umana per le modifiche sensibili alla sicurezza, l'autenticazione e l'autorizzazione, la gestione dei dati dei clienti e finanziari, le integrazioni esterne e l'infrastruttura di produzione.

Test automatizzati

Abbiamo inoltre ampliato i test automatizzati e la revisione del codice perché il collo di bottiglia si è spostato. Quando l'AI aumenta drasticamente la velocità con cui si può produrre codice, il problema non è più la generazione del codice. Il problema diventa dimostrare che il codice merita di essere eseguito.

Un semplice esempio è la creazione dei test. In precedenza, un ingegnere poteva implementare una funzionalità e poi scrivere gli ovvi test unitari. Ora possiamo chiedere all'AI di generare casi di test avversariali oltre a questi. Cosa succede con un input non valido? Cosa succede quando un'API restituisce una risposta imprevista? Cosa succede al confine delle autorizzazioni? Cosa succede quando un record cliente contiene dati incompleti?

Questo assegna all'ingegnere umano un compito diverso. Invece di dedicare tutto il proprio tempo alla produzione di artefatti, dedica più tempo a mettere in discussione le ipotesi e a convalidare il comportamento del codice.

Governance dell'AI

Abbiamo anche cambiato il modo in cui governiamo l'AI stessa. Registriamo le attività assistite dall'AI quando appropriato, manteniamo le informazioni sensibili dei clienti fuori dagli strumenti di AI per uso personale, controlliamo quali modelli e servizi possono accedere ai dati aziendali e separiamo la sperimentazione dall'accesso alla produzione. Nel settore assicurativo e nei servizi finanziari, «il modello pensava che fosse una buona idea» non costituirà mai una strategia di governance.

Come l'AI sposta il collo di bottiglia dell'ingegneria

Il risultato più importante che ho visto integrando l'AI nei nostri flussi di lavoro di ingegneria è la velocità, ma aggiungo sempre un asterisco a questa risposta perché la velocità nella direzione sbagliata non è produttività.

L'AI ha compresso drasticamente il nostro ciclo di sviluppo. Stiamo osservando attività che in precedenza richiedevano diversi giorni a uno sviluppatore passare dai requisiti a un'implementazione verificabile in poche ore. Per la prototipazione in particolare, stimerei che abbiamo ridotto i tempi del ciclo di circa il 50-70 percento.

E la documentazione ha probabilmente prodotto il guadagno di efficienza meno appariscente, ma più immediato. La documentazione delle API, le note di rilascio, la documentazione dei test, le spiegazioni del codice e le prime bozze delle specifiche tecniche non devono più iniziare con un cursore lampeggiante. L'AI produce il primo 70 o 80 percento e il mio team dedica il proprio tempo a correggere e migliorare invece di creare tutto da zero.

Ma c'è un aspetto negativo, e penso che i responsabili tecnologici debbano parlarne di più: l'AI rende incredibilmente economico produrre rapidamente codice scadente.

Abbiamo scoperto che il fattore limitante si sposta a valle. Se posso generare una quantità di codice cinque volte maggiore, ma gli esseri umani devono comunque comprenderlo, esaminarlo, testarlo, proteggerlo, distribuirlo, monitorarlo e mantenerlo, non ho necessariamente aumentato la capacità di elaborazione del sistema. Potrei aver semplicemente creato un ingorgo nella revisione del codice.

Questa è probabilmente stata la lezione più preziosa per me. Non ottimizzo più la mia organizzazione di ingegneria principalmente in base alla velocità con cui possiamo scrivere software. L'AI sta rapidamente trasformando questa parte in un prodotto standardizzato. Ottimizzo in base alla velocità con cui possiamo dimostrare che il software merita di essere eseguito in produzione. È un'organizzazione di ingegneria molto diversa.

Dove l'AI ha voce e dove ha voto

Ho adottato un approccio piuttosto consapevole nel separare due aspetti: quando l’IA ha voce in capitolo e quando ha potere decisionale. Nella nostra organizzazione, ormai l’IA ha voce in capitolo in quasi ogni fase del ciclo di vita della tecnologia. Non ha potere decisionale su ogni scelta.

Alcuni esempi:

• Architettura: utilizziamo ChatGPT e Claude come interlocutori per confrontarci sull’architettura. Se stiamo progettando un nuovo servizio, posso fornire al modello i nostri requisiti, i vincoli, le interfacce esistenti, i confini di sicurezza, il volume previsto delle transazioni e gli scenari di errore. Gli chiederò di proporre più architetture, individuare i compromessi, mettere in discussione le nostre supposizioni e persino argomentare contro la propria raccomandazione. Quello che non farò è chiedere: «Quale architettura dovremmo utilizzare?» per poi realizzare qualunque cosa venga proposta. La decisione finale sull’architettura rimane umana, perché l’architettura implica un contesto che va ben oltre l’ottimizzazione tecnica. Devo considerare la nostra strategia aziendale, gli obblighi normativi, la maturità operativa, la tolleranza al rischio, i costi, il debito tecnico e ciò che il mio team è effettivamente in grado di supportare alle 2:00 del mattino.
• Codice: in questo ambito concediamo all’IA una libertà decisamente maggiore. Utilizziamo GitHub Copilot per la generazione del codice, il refactoring, la documentazione e la creazione di test unitari. Utilizziamo inoltre ChatGPT e Claude per risolvere i difetti, esplorare approcci di implementazione e generare casi di test avversariali. L’IA può scrivere una prima implementazione a una velocità incredibile. Un ingegnere umano rimane comunque responsabile della richiesta di integrazione e approva ciò che viene infine integrato.
• Test: probabilmente questo è l’ambito che si è spostato maggiormente verso l’IA. Mi piace usare l’IA per chiedere: «Come riusciresti a mandare tutto in errore?». Possiamo individuare casi che uno sviluppatore, dopo aver trascorso due giorni a realizzare la funzionalità, potrebbe trascurare inconsapevolmente. L’IA diventa un avversario molto economico e incredibilmente perseverante.
• Sicurezza: è qui che inverto deliberatamente l’equazione. L’IA ci aiuta a identificare le vulnerabilità, analizzare i modelli di codice, modellare le minacce e generare scenari di attacco, ma, come ho detto, gli esseri umani mantengono l’autorità sull’accettazione della sicurezza, sulle decisioni relative a identità e accessi, sulla gestione dei dati sensibili e sulle eccezioni. L’iniezione di prompt e la divulgazione di informazioni sensibili rimangono rischi riconosciuti nelle applicazioni basate su LLM, quindi collegare l’IA ai sistemi aziendali richiede più controlli, non meno.
• Risposta agli incidenti: questo ambito si colloca da qualche parte nel mezzo. L’IA può acquisire i log, correlare gli eventi, riepilogare migliaia di righe di dati di telemetria, proporre le probabili cause principali e raccomandare misure correttive. Ciò può ridurre drasticamente i primi 30 minuti di un incidente. Tuttavia, se qualcuno vuole disabilitare un servizio di produzione, eseguire il rollback di una distribuzione critica, modificare una politica di sicurezza o intraprendere un’azione che ha effetti sui clienti, la decisione spetta a una persona.
• Definizione delle priorità dell’elenco delle attività arretrate: anche qui applico la stessa regola. L’IA può analizzare i problemi segnalati al supporto, l’impegno ingegneristico, le dipendenze, l’utilizzo del prodotto e gli obiettivi aziendali, e dire: «Ecco come darei la priorità a queste 40 attività e il motivo». È incredibilmente utile. Ma l’IA non comprende la nostra strategia meglio di noi. Sono i responsabili del prodotto e della tecnologia a prendere la decisione finale sulle priorità.

La mia regola, quindi, è piuttosto semplice: l’IA ottiene maggiore autonomia quando l’azione è reversibile, osservabile, verificabile e ha conseguenze limitate. L’autorità umana aumenta quando un’azione diventa più difficile da annullare o comporta un impatto maggiore sui clienti, a livello finanziario, di sicurezza, normativo o reputazionale.

Un flusso di lavoro ingegneristico del mondo reale

Ecco un esempio di flusso di lavoro «dal requisito alla produzione con l’IA nel ciclo». Supponiamo di dover aggiungere una nuova funzionalità a un flusso di lavoro basato su agenti che recupera informazioni sui clienti e sulle politiche, applica una serie di regole aziendali e consiglia l’azione successiva appropriata:

1. Tutto inizia dal requisito. Invece di ricevere un ticket scritto in modo approssimativo e iniziare immediatamente a programmare, utilizziamo ChatGPT o Claude per analizzare il requisito. Forniamo la storia dell'utente, i criteri di accettazione, le regole aziendali pertinenti, i contratti API e i vincoli tecnici. Poi chiediamo di identificare ambiguità, casi limite mancanti, dipendenze, problemi di sicurezza e domande a cui dovremmo rispondere prima che qualcuno scriva del codice. Sembra semplice, ma permette di individuare in anticipo una quantità sorprendente di incomprensioni costose.
2. Segue l'architettura e la scomposizione delle attività. Utilizziamo Claude e ChatGPT per esplorare le opzioni di implementazione e suddividere i requisiti in componenti. Il modello può individuare una modifica all'API, una modifica al modello dati, una dipendenza di integrazione, requisiti di autorizzazione, telemetria e i casi di test necessari. Gli chiediamo anche di contestare l'architettura proposta. La decisione architetturale spetta a un ingegnere umano. L'IA fornisce le opzioni. Noi ci assumiamo le conseguenze.
3. Poi passiamo all'implementazione. Utilizziamo GitHub Copilot all'interno dell'ambiente di sviluppo per generare codice standard, implementare funzioni ben definite, effettuare il refactoring del codice, creare client API, spiegare sezioni poco familiari della base di codice e generare documentazione. L'ingegnere passa dal digitare ogni riga al dirigere, revisionare e perfezionare l'implementazione. Questa distinzione è importante. Non voglio che gli sviluppatori diventino operatori di completamento automatico molto costosi. Voglio che riflettano sul sistema.
4. Poi forniamo a ChatGPT o Claude il requisito e l'implementazione e diciamo, in sostanza: “Ottimo. Ora distruggili.” L'IA aiuta a generare scenari avversari, mentre Copilot contribuisce a trasformarli in test unitari e di integrazione automatizzati.
5. Poi subentra il meccanismo deterministico. La richiesta di integrazione entra nella nostra pipeline CI/CD. Eseguiamo test automatizzati, analisi statica, scansioni delle dipendenze e delle vulnerabilità e i nostri normali controlli di qualità. Un ingegnere umano revisiona la richiesta di integrazione.
6. Poi distribuiamo in modo incrementale. La modifica passa dagli ambienti di sviluppo e staging prima di arrivare in produzione. Quando è opportuno, utilizziamo flag delle funzionalità o modalità di distribuzione controllata per limitare l'esposizione, osservare il comportamento e ripristinare rapidamente la versione precedente.
7. E il lavoro dell'IA non è ancora finito. Una volta che la funzionalità è operativa, l'IA diventa un'assistente per l'osservabilità. La utilizziamo per riepilogare i log, correlare i modelli di errore, analizzare comportamenti imprevisti e aiutare gli ingegneri a passare da “qualcosa non funziona” a una probabile causa principale molto più velocemente.

Come cambiare il comportamento degli ingegneri con l'IA

Avrei voluto capire prima che fornire strumenti di IA agli ingegneri è semplice. Cambiare il comportamento degli ingegneri è la parte difficile.

Quando abbiamo iniziato a utilizzare strumenti come GitHub Copilot, ChatGPT e Claude, ho affrontato l'introduzione nel modo in cui lo fanno molti responsabili tecnologici. Fornire a ingegneri talentuosi strumenti potenti, stabilire alcune solide linee guida e aspettare che la produttività aumenti.

È aumentata, ma non in modo uniforme e non sempre nei modi che mi aspettavo.

La prima cosa che ho imparato è stata che l'accesso non equivale all'adozione e l'adozione non equivale alla competenza.

Due ingegneri possono avere esattamente lo stesso strumento di IA e ottenere risultati completamente diversi. Uno tratta l'IA come il completamento automatico e risparmia qualche pressione di tasto. L'altro impara a fornire contesto, scomporre i problemi, mettere in discussione i risultati, generare test, esplorare alternative e utilizzare il modello come interlocutore tecnico. La differenza di produttività tra queste due persone può diventare enorme.

Avrei investito molto prima nella cultura dell'IA e nei metodi di lavoro. Non “ecco un corso di due ore sull'ingegneria dei prompt”, ma esempi pratici costruiti attorno al nostro effettivo lavoro ingegneristico.

Commenti di Tyrone

Avrei investito molto prima nella cultura dell’IA e nei metodi di lavoro. Non “ecco un corso di due ore sull’ingegneria dei prompt”, ma esempi pratici costruiti attorno al nostro effettivo lavoro ingegneristico.

Come l'IA sta trasformando la leadership tecnologica

Passiamo molto tempo a chiederci che cosa farà l'IA agli sviluppatori, agli architetti, agli analisti e ad altri ruoli tecnici. Penso che i CTO debbano ribaltare questa domanda e rivolgerla a noi stessi.

Per gran parte della mia carriera, la leadership tecnologica premiava il fatto di sapere cose che gli altri non sapevano. L'esperienza ti dava la capacità di riconoscere gli schemi. La competenza tecnica ti dava autorevolezza. Potevi entrare in una stanza e fornire una risposta che qualcun altro avrebbe potuto impiegare giorni a trovare.

Ora posso mettere un sistema di IA incredibilmente capace nelle mani di tutti. Questo cambia la leadership.

Non penso più che il mio valore come CTO derivi dall'avere le risposte. Deriva dal porre domande migliori, fornire contesto, fare compromessi, esercitare il giudizio e creare un ambiente in cui esseri umani e macchine si migliorino a vicenda.

Questo richiede umiltà. A volte l'IA individuerà un approccio che non avevo preso in considerazione. Un ingegnere junior con ottime competenze nell'IA potrebbe mettere in discussione un'ipotesi che qualcuno con 25 anni di esperienza considera ovvia. Penso che i grandi leader tecnologici debbano accogliere questa possibilità.

Il CTO dell'era dell'IA non può semplicemente essere la persona tecnicamente più preparata nella stanza. Dobbiamo diventare le persone che progettano la stanza. Chi ha voce in capitolo? Che cosa può decidere l'IA? Dove il giudizio umano rimane essenziale? Come facciamo a sapere quando sbagliamo?

Questa è la trasformazione della leadership.

Perché i CTO dovrebbero essere cauti riguardo ai guadagni di efficienza

Il mio principale consiglio ai CTO in questo momento è: non confondete il procedere rapidamente con il fare progressi.

C'è un'enorme pressione sui leader tecnologici affinché “facciano qualcosa con l'IA”. I consigli di amministrazione fanno domande al riguardo. I CEO fanno domande al riguardo. I dipendenti la stanno già utilizzando, che abbiate o meno una policy. Ogni fornitore ha improvvisamente scoperto che il proprio prodotto è sempre stato “alimentato dall'IA”.

È molto facile diventare reattivi. Ma penso che il compito del CTO in questo momento sia creare chiarezza in mezzo a tutto questo rumore.

• Primo, usate personalmente la tecnologia. E intendo dire: usatela davvero. Non costruite la vostra strategia sull'IA interamente basandovi sui rapporti degli analisti e sulle dimostrazioni dei fornitori. Io uso strumenti come ChatGPT, Claude e GitHub Copilot perché ho bisogno di un'esperienza diretta dei contesti in cui sono straordinari, dei casi in cui falliscono e della rapidità con cui questi confini si spostano. Non si può guidare efficacemente una transizione tecnologica che si sperimenta solo attraverso PowerPoint.
• Secondo, partite dai vincoli aziendali, non dalle capacità dell'IA. Mi interessa molto meno chiedere: “Dove possiamo usare l'IA generativa?” che chiedere: “Dove siamo lenti, costosi, incoerenti, limitati dalla capacità o lasciamo i clienti frustrati?” Poi posso determinare se l'IA appartenga davvero alla soluzione.
• Terzo, sistemate le vostre fondamenta. L'IA non salverà dati scadenti, API deboli, una scarsa osservabilità, documentazione inesistente o pratiche ingegneristiche disfunzionali. Spesso li amplificherà. L'IA agisce come un amplificatore dell'organizzazione e del sistema tecnico sottostanti.
• Quarto, progettate la governance in base alle conseguenze, non alla paura. Non voglio una policy sull'IA di 47 pagine che in pratica dica: “Per favore, non fate nulla di interessante”. Voglio controlli proporzionati al rischio. Lasciate che le persone sperimentino in modo deciso quando le azioni sono reversibili e hanno conseguenze limitate. Aumentate la supervisione umana quando le decisioni iniziano a riguardare i dati dei clienti, il denaro, la sicurezza, gli obblighi normativi o i sistemi di produzione.
• Quinto, e questo potrebbe essere il punto più importante, riprogettate il lavoro invece di aggiungere semplicemente l'IA al lavoro. Se il mio processo di sviluppo prevede dodici fasi e l'IA rende la quarta fase più veloce del 70 percento, non ho trasformato l'ingegneria. Ho accelerato la quarta fase.
• E infine, proteggete il giudizio umano eliminando con decisione le incombenze ripetitive.

Penso che i CTO abbiano un'opportunità rara in questo momento. Non chiedetevi semplicemente in che modo l'IA renda più efficiente la vostra organizzazione attuale. Chiedetevi quale organizzazione costruireste se partiste oggi. Questa è la domanda più scomoda. È anche quella che distinguerà le aziende che semplicemente usano l'IA da quelle che si trasformano davvero grazie ad essa.

Segui

Puoi seguire il lavoro di Tyrone Grandison su LinkedIn e sul suo sito web personale. Puoi anche dare un'occhiata ai suoi libri, La rivoluzione dell'IA e Una cultura che dura nel tempo.

Presto arriveranno altre interviste a esperti su The CTO Club!