Leader tecnologico con oltre 30 anni di esperienza spiega come passare dai compartimenti stagni dell’IA a un modello operativo governato

Prem Kumar A S ha oltre 30 anni di esperienza nella gestione di progetti IT e di infrastrutture cloud. Attualmente ricopre il ruolo di VCTO presso The Preminent.

Ci siamo confrontati con Prem per capire come le organizzazioni possano passare da iniziative isolate di IA a un modello operativo governato. Ecco cosa ci ha raccontato.

Oltre 30 anni di esperienza

Ho oltre 30 anni di esperienza nella gestione di progetti IT e di infrastrutture cloud in tutto il mondo. Attualmente lavoro come VCTO, fornendo consulenza a consigli di amministrazione e CXO su tecnologia, rischio informatico, resilienza, fiducia e governance nell'era dell'IA. Il mio obiettivo è aiutare i team dirigenziali a prendere decisioni più chiare, solide e orientate al futuro.

Parallelamente, conduco PREMINENT KONCLAVE di Power of Knowing Forum — una serie di podcast settimanali di punta che abbraccia tecnologia, cybersecurity, crescita e strategia, con oltre 370 conversazioni con leader e un ecosistema di esperti in continua espansione.

Come passare da iniziative isolate di IA a un modello operativo governato

Siamo passati dalla sperimentazione di strumenti a un modello operativo governato, in particolare introducendo un livello di governance dell'IA e di revisione delle implementazioni prima che qualsiasi soluzione basata sull'IA potesse entrare in produzione.

Prima di allora, l'IA veniva esplorata in ambiti isolati: copiloti, progetti pilota di automazione, casi d'uso di analisi e alcune sperimentazioni nell'ambito della sicurezza. Il problema non era la volontà, ma la frammentazione. Team diversi potevano valutare o persino implementare funzionalità basate sull'IA senza un quadro comune per la classificazione dei dati e il rischio di esposizione, i limiti di utilizzo dei modelli, le approvazioni degli strumenti di IA di terze parti, la revisione e la responsabilità umana oppure la misurazione dei risultati aziendali.

In parole semplici, l'IA stava iniziando a entrare nell'ambiente più rapidamente di quanto la governance riuscisse a tenere il passo. Questo crea tre rischi per qualsiasi organizzazione seria:

1. Esposizione a rischi per la sicurezza e la privacy: dati aziendali o dei clienti sensibili che entrano in flussi di lavoro IA non gestiti
2. Incoerenza operativa: team che utilizzano strumenti, prompt e processi diversi, senza standard ripetibili
3. Rischio a livello di consiglio di amministrazione senza visibilità: l'utilizzo dell'IA cresce, ma la dirigenza non sa dove si concentrino realmente l'esposizione o il ritorno sull'investimento

Per questo abbiamo introdotto un modello pratico di controllo dell'IA, collegato al modo in cui la tecnologia viene sviluppata, implementata e governata: non come un documento teorico di policy, ma come una disciplina operativa. Questo ha comportato cinque cambiamenti concreti:

1. I casi d’uso dell’AI dovevano essere classificati prima dell’adozione. Ogni caso d’uso dell’AI proposto veniva classificato come produttività a basso rischio, supporto alle decisioni interne, rivolto ai clienti oppure sensibile/regolamentato/ad alto rischio. Questo ha cambiato immediatamente la conversazione da «Possiamo usare l’AI?» a «Quale livello di governance richiede questo caso d’uso dell’AI?»
2. La distribuzione dell’AI prevedeva un controllo obbligatorio. Prima che uno strumento, un’automazione o un flusso di lavoro basato sull’AI potesse passare alla produzione, doveva superare una revisione riguardante la sensibilità dei dati, i controlli relativi a identità e accessi, i rischi associati al fornitore/modello, la gestione delle istruzioni e dei risultati, i punti di approvazione umana, i meccanismi di riserva/ripristino e i requisiti di registrazione degli audit. Questo ha reso la distribuzione dell’AI parte della governance tecnologica, non una semplice messinscena dell’innovazione.
3. Abbiamo separato la sperimentazione dalla produzione. È stato creato un modello di ambiente isolato controllato per la sperimentazione con l’AI. I team potevano testare rapidamente le idee — ma l’uso in produzione richiedeva insiemi di dati approvati, strumenti/modelli approvati, responsabili definiti, risultati aziendali misurabili e l’approvazione dei rischi ove necessaria. Si è trattato di un importante cambiamento culturale, perché ha protetto l’innovazione senza permettere che la sperimentazione diventasse silenziosamente una dipendenza aziendale.
4. Abbiamo introdotto regole «con supervisione umana» per i flussi di lavoro sensibili. Abbiamo richiesto la convalida umana prima dell’azione finale per qualsiasi caso d’uso dell’AI che avesse un impatto sui clienti, sulla conformità, sulle decisioni finanziarie, sulle operazioni di sicurezza o sulle comunicazioni aziendali critiche. Questo ha evitato l’errore classico di considerare automaticamente affidabile un risultato generato dall’AI solo perché era rapido.
5. Abbiamo iniziato a misurare l’AI in base al valore operativo, non all’entusiasmo. Ogni iniziativa di AI doveva rispondere a queste domande: Quale sforzo manuale viene ridotto? Quali tempi di ciclo migliorano? Quali rischi vengono ridotti? In che modo migliora la qualità delle decisioni? Quale vantaggio in termini di costi, produttività o resilienza ci si aspetta? Questo ha spostato l’AI da una conversazione sulle tendenze tecnologiche a una conversazione sul modello operativo aziendale.

Questo ci ha dato un controllo migliore senza compromettere lo slancio. La governance ha smesso di essere vista come un ostacolo. Creando un percorso chiaro — sperimentare qui, applicare la governance qui, distribuire qui — i team hanno lavorato più velocemente, con meno confusione e meno rischi nascosti.

Ha inoltre ridotto il rischio di un’AI ombra. Abbiamo ottenuto una visibilità molto migliore sugli strumenti utilizzati, sui team che li usavano, sui dati che vi confluivano e sui casi d’uso con un reale valore aziendale. Questo è fondamentale perché l’adozione non gestita dell’AI sta rapidamente diventando la nuova IT ombra.

Come implementare l’AI senza creare caos

Ecco alcuni consigli per chi sta iniziando — se volete evitare il caos:

1. Iniziate dai flussi di lavoro ad alto volume e basso rischio. Non cominciate dalle decisioni relative all’architettura di base o da modifiche autonome critiche per la produzione. Iniziate dalla documentazione, dalla creazione di test, dalla classificazione del supporto interno, dalla sintesi dei registri, dalla stesura delle procedure operative o dalla generazione delle note di rilascio.
2. Definite i vincoli prima di procedere su larga scala. Ogni implementazione dell’ingegneria dell’AI dovrebbe definire gli strumenti approvati, la politica sull’uso delle istruzioni e dei dati, le regole per la revisione del codice, i requisiti di scansione della sicurezza, i limiti dell’approvazione umana e la registrazione/tracciabilità degli audit.
3. Misurate prima e dopo. Monitorate il tempo di ciclo, la frequenza delle distribuzioni, i difetti che arrivano in produzione, l’MTTR, il tasso di ripristino, il tempo dedicato alle attività ripetitive e i feedback sulla soddisfazione/produttività degli ingegneri.
4. Mantenete la responsabilità in capo alle persone. L’AI dovrebbe supportare gli ingegneri, non sostituire la responsabilità ingegneristica. Il modello può proporre. Il team deve comunque decidere, convalidare, mettere in sicurezza e assumersi la responsabilità del risultato.

I migliori casi d’uso tecnici dell’AI

Se implementata correttamente, l’AI nei flussi di lavoro tecnici può migliorare concretamente velocità, visibilità, produttività e qualità delle decisioni. Se implementata male, può amplificare i difetti, aumentare il rischio operativo e creare una falsa sicurezza su larga scala.

Ecco i casi d’uso e i vantaggi che sto osservando:

Maggiore capacità produttiva dell’ingegneria quando l’AI viene utilizzata per il lavoro giusto: I vantaggi più consistenti si manifestano in genere nelle attività a bassa o media complessità, come la generazione di codice standard, la creazione di casi di test, la stesura di documentazione e procedure operative, la sintesi dei registri e la classificazione degli incidenti, la creazione di modelli di infrastruttura come codice, la classificazione delle richieste e i suggerimenti per la risoluzione dei problemi di primo livello. Tra i risultati quantitativi che sto osservando figurano:

• Riduzione del 20–40% del tempo di ciclo per le attività ingegneristiche ripetibili
• Miglioramento del 15–30% della produttività degli sviluppatori per il lavoro ben definito
• Triage degli incidenti più rapido del 25–50% quando l'IA riassume i registri, gli avvisi e le probabili cause principali
• Riduzione del 30–60% dello sforzo di documentazione per le procedure operative standard, i manuali operativi e gli articoli della base di conoscenza

Migliore efficienza DevOps e delle piattaforme: l'IA è particolarmente efficace nelle operazioni DevOps/SRE/infrastrutturali quando viene utilizzata come copilota per l'analisi anziché come decisore autonomo. Ad esempio, la correlazione dei registri tra gli strumenti diventa più rapida, gli avvisi rumorosi vengono raggruppati e riassunti, le note di distribuzione e i passaggi per il ripristino vengono generati automaticamente, i modelli di capacità vengono rilevati in anticipo e i controlli operativi ripetitivi vengono automatizzati. I miglioramenti quantitativi spesso includono:

• Miglioramento dell'MTTR del 20–35% negli ambienti caratterizzati da numerosi incidenti
• Dal 10 al 25% in meno di escalation agli ingegneri senior per modelli di problemi noti
• Miglioramento del 15–20% del tasso di successo delle modifiche quando l'IA viene utilizzata per applicare liste di controllo di distribuzione, note di rilascio e convalida delle dipendenze
• Riduzione del lavoro ripetitivo per i team di supporto e operativi L1/L2, liberando gli ingegneri senior per attività di architettura e resilienza

Prem Kumar condivide

Se implementata correttamente, l’IA nei flussi di lavoro tecnici può migliorare concretamente velocità, visibilità, produttività e qualità delle decisioni. Se implementata in modo inadeguato, può amplificare i difetti, aumentare il rischio operativo e creare una falsa sensazione di sicurezza su larga scala.

Miglioramento dell'ingegneria dei test e della copertura della qualità: uno degli usi più pratici è il collaudo assistito dall'IA. Ciò include la generazione di casi di test a partire dai requisiti o dalle storie utente, l'identificazione di scenari limite, la creazione di modelli di dati di test e il supporto ai team per migliorare più rapidamente la copertura della regressione. I risultati positivi possono includere:

• Creazione dei casi di test più rapida del 20–35%
• Maggiore copertura dei test nella stessa finestra dello sprint
• Cicli di preparazione della regressione più brevi
• Migliore rilevamento dei difetti nelle fasi iniziali del ciclo di vita, se i prompt e la convalida sono solidi

Gestione della conoscenza e inserimento dei nuovi membri più efficaci: l'IA è sottovalutata in un'area fondamentale: la cattura della conoscenza tacita. In molti team di ingegneria, gran parte del sapere operativo risiede nella mente di poche persone. L'IA aiuta a trasformarlo in manuali operativi consultabili, procedure per la risoluzione dei problemi, riepiloghi dell'architettura, guide per l'inserimento dei nuovi membri e sintesi delle RCA. I vantaggi tipici includono:

• Inserimento più rapido dei nuovi ingegneri
• Minore dipendenza da poche persone “eroiche”
• Migliore trasferimento delle conoscenze tra i team
• Minore tempo dedicato a cercare tra vecchi ticket e conversazioni su Slack/Teams

Per le PMI in crescita e le organizzazioni di ingegneria di medie dimensioni, questo può essere uno dei casi d'uso con il ROI più elevato, perché migliora la scalabilità della conoscenza ingegneristica, non solo la produzione di codice.

Gli svantaggi dell'IA

Naturalmente, i risultati non sono tutti positivi:

• Il tasso di difetti può aumentare se l'IA viene portata in produzione troppo rapidamente. Il più grande errore che osserviamo è considerare il codice generato dall'IA come “produttività degli sviluppatori” senza rafforzare la revisione, i test e la convalida della sicurezza.
• Il rischio per la sicurezza e la conformità aumenta in assenza di adeguate protezioni. Questa è una preoccupazione importante negli ambienti regolamentati o sensibili.

• I team possono diventare più veloci, ma meno riflessivi. Uno svantaggio sottile è lo scarico cognitivo. L'IA dovrebbe ridurre lo sforzo meccanico, non ridurre il pensiero ingegneristico.
• Il tempo di ciclo migliora, ma la qualità della distribuzione no. Questa è una delle trappole dirigenziali più comuni: i team celebrano una produzione di codice più rapida, ma ignorano se il risultato aziendale è migliorato. Il successo dell'IA non può essere misurato solo in base a “quanto più velocemente gli sviluppatori scrivono codice”. Deve essere misurato considerando la frequenza delle distribuzioni, il tasso di fallimento delle modifiche, il tasso di difetti sfuggiti ai controlli, l'MTTR, i problemi di sicurezza rilevati, il costo per rilascio e le ore di ingegneria risparmiate rispetto al lavoro di rifacimento creato.

Cosa l'IA non dovrebbe mai toccare

Questi sono gli ambiti in cui l'IA dovrebbe supportare il ragionamento, ma non sostituire mai la persona responsabile delle decisioni.

• Accettazione del rischio. Nessuna IA dovrebbe decidere se accettare un rischio per la sicurezza, se rimandare un aggiornamento correttivo, se operare con una lacuna di controllo nota o se proseguire con un rilascio che presenta problemi irrisolti. Questa decisione spetta al responsabile, perché comporta conseguenze finanziarie, legali e reputazionali.
• Leadership nelle crisi. In caso di grave interruzione del servizio, incidente informatico, violazione dei dati o escalation normativa, l'IA può fornire assistenza con dati e opzioni. Tuttavia, gli esseri umani devono essere responsabili delle comunicazioni con i portatori di interesse, dei rapporti con le autorità di regolamentazione, delle decisioni relative alla fiducia dei clienti, della comunicazione della leadership e della direzione della sala operativa.
• Etica, privacy e compromessi aziendali. L'IA non può essere l'autorità finale per stabilire se l'uso dei dati è eticamente accettabile, se una decisione è equa nei confronti di clienti o dipendenti, se un controllo di sorveglianza o monitoraggio è proporzionato o se la convenienza aziendale debba prevalere sui principi di fiducia. Queste sono decisioni della leadership.

Perché l'architettura non riguarda più soltanto la scalabilità e le prestazioni

L'IA mi ha costretto a riconsiderare l'idea che l'architettura sia qualcosa che si progetta una volta e si ottimizza nel tempo. Questo modello funzionava quando i sistemi cambiavano gradualmente. Non è più valido quando gli agenti di IA, gli assistenti di programmazione, i livelli di automazione e i flussi di dati iniziano a influenzare dinamicamente il comportamento in produzione.

Prem Kumar condivide

L’architettura non riguarda più soltanto la scalabilità e le prestazioni. Ora riguarda l’adattabilità, la tracciabilità, la resilienza e la governance.

Oggi l'architettura deve essere considerata un sistema di controllo vivente, non un progetto fisso. Ciò significa:

• I sistemi devono essere progettati per un'adattabilità continua.
• L'osservabilità deve estendersi oltre l'infrastruttura, fino a comprendere il comportamento dell'IA e la qualità delle decisioni.
• La sicurezza deve passare dalla difesa perimetrale alla fiducia, al controllo e alla resilienza integrati.

In altre parole, l'architettura non riguarda più soltanto la scalabilità e le prestazioni. Ora riguarda l'adattabilità, la tracciabilità, la resilienza e la governance.

Consigli per i CTO

Il mio consiglio ai CTO è semplice: non trattate l'IA solo come una gara tecnologica — consideratela un momento di leadership aziendale. In questo momento, troppe organizzazioni stanno inseguendo progetti pilota, strumenti e casi d'uso dell'IA senza porsi prima le domande più importanti: quale problema aziendale stiamo risolvendo? Quale rischio stiamo introducendo? Quale capacità stiamo costruendo per il lungo periodo?

I CTO devono guidare il cambiamento legato all'IA su cinque fronti:

1. Parti dal valore aziendale, non dall'entusiasmo per l'AI. Se l'AI non è collegata alla crescita dei ricavi, alla produttività, all'esperienza del cliente, alla riduzione dei rischi o alla velocità di esecuzione, si trasforma in sperimentazione senza impatto.
2. Costruisci l'AI su solide fondamenta. L'AI non può compensare infrastrutture deboli, dati frammentati, una governance carente o responsabilità poco chiare. I CTO devono innanzitutto assicurarsi che l'organizzazione disponga della corretta disciplina dei dati, della preparazione necessaria per il cloud, di adeguate misure di sicurezza informatica e di un'architettura d'integrazione coerente. In caso contrario, l'AI farà crescere la confusione più rapidamente di quanto faccia crescere il valore.
3. Considera la sicurezza informatica, la privacy e la governance come principi di progettazione. Non è questo il momento di aggiungere la sicurezza in un secondo momento. L'AI introduce nuovi rischi — fuga di dati, uso improprio dei modelli, pregiudizi, allucinazioni, lacune nella conformità e utilizzo non autorizzato dell'AI all'interno dei team. I migliori CTO integreranno la governance dell'AI, i controlli degli accessi, la protezione dei dati, la responsabilità sui modelli e la supervisione umana nel modello operativo fin dal primo giorno.
4. Ridefinisci il ruolo del leader tecnologico. In questa era, il CTO non è più soltanto il custode dei sistemi. Il CTO deve diventare un interprete tra l'ambizione aziendale e la realtà tecnica, aiutando il consiglio di amministrazione e il team dirigenziale a comprendere ciò che l'AI può davvero fare, dove può fallire e come adottarla in modo responsabile. Si tratta tanto di formazione, definizione delle priorità e costruzione della fiducia quanto di architettura.
5. Concentrati sull'incremento delle capacità prima che sull'automazione. La strategia più efficace per l'AI non è: “Come sostituiamo le persone?”. È: “Come rendiamo le nostre persone più veloci, più preparate e più efficaci?”. Inizialmente, l'AI dovrebbe potenziare i team, migliorando il processo decisionale, riducendo il lavoro ripetitivo, accelerando l'analisi e liberando il talento per contributi di maggior valore. È così che si costruisce la fiducia, migliora l'adozione e la trasformazione diventa sostenibile.

Segui gli aggiornamenti

Puoi seguire il lavoro di Prem su LinkedIn. E dai un'occhiata al suo podcast, PREMINENT KONCLAVE.

Presto arriveranno altre interviste a esperti su The CTO Club!