Il responsabile globale dell’architettura delle soluzioni di AWS condivide il suo modello di modernizzazione guidato dall’IA
Saurabh Shrivastava spiega come i CTO possano trasformare gli esperimenti con l'IA in sistemi pronti per la produzione, riprogettando l'ingegneria attorno alla governance, alla validazione umana e al valore aziendale.
Saurabh Shrivastava
Responsabile globale dell'architettura delle soluzioni
Industrializzazione: L'adozione efficace dell'IA richiede modelli operativi, governance, architettura, competenze e disciplina di prodotto, non esperimenti isolati.
Implementazione sul campo: L'ingegneria implementata sul campo porta la modernizzazione dell'IA agentica negli ambienti reali, affrontando tempestivamente i vincoli relativi a dati, codice e sicurezza.
Modello di fiducia: Utilizza l'analisi deterministica, l'implementazione assistita dall'IA e la validazione umana per modernizzare più rapidamente senza sacrificare accuratezza, sicurezza o responsabilità.
Controllo dei costi: L'economia dell'inferenza è importante: l'instradamento dei modelli, la memorizzazione nella cache, l'elaborazione in batch, la quantizzazione e la distribuzione ottimizzata possono ridurre i costi e migliorare l'affidabilità.
Ciclo di sviluppo guidato dall'IA: Il ciclo di sviluppo guidato dall'IA riprogetta la distribuzione attorno a ideazione, costruzione e gestione, integrando agenti, controlli di sicurezza, valutazione, osservabilità e miglioramento continuo.
Saurabh Shrivastava è il responsabile globale dell'architettura delle soluzioni e dell'ingegneria dislocata in prima linea presso Amazon Web Services, dove si concentra sull'IA agentica e sulla modernizzazione aziendale.
Abbiamo parlato con Saurabh per conoscere i nuovi modelli ingegneristici che sta utilizzando nel suo lavoro presso AWS. Ecco cosa ci ha raccontato.
Industrializzare l'IA in modo responsabile
Sono un responsabile della trasformazione tecnologica e dell'IA con oltre 20 anni di esperienza nell'aiutare le aziende a trasformare cambiamenti tecnologici complessi in risultati aziendali scalabili. Il mio percorso mi ha portato a occuparmi di ingegneria, architettura aziendale, ingegneria sul campo orientata ai prodotti, trasformazione cloud e, ora, IA agentica e modelli di fabbrica del software presso AWS.
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
All'inizio della mia carriera ho costruito e guidato piattaforme aziendali su larga scala nei settori delle telecomunicazioni, della vendita al dettaglio, della catena di approvvigionamento, della tecnologia finanziaria e della ricerca e sviluppo. Questo mi ha permesso di apprezzare profondamente il pensiero sistemico, l'affidabilità, la complessità dell'integrazione e la realtà della gestione della tecnologia su scala aziendale.
In AWS, il mio ruolo si è ampliato: dall'aiutare i clienti a modernizzare infrastrutture e applicazioni alla guida di iniziative globali di architettura delle soluzioni e ingegneria dislocata in prima linea incentrate sull'IA, sulla modernizzazione e sulle piattaforme agentiche. Ho collaborato con dirigenti aziendali, partner, team di prodotto e team di ingegneria per passare dalla strategia e dalla sperimentazione a piattaforme governate e pronte per la produzione.
L'IA non è più soltanto un'altra ondata tecnologica. Sta cambiando il modo in cui le organizzazioni sviluppano il software, il modo in cui lavorano i dipendenti, il modo in cui interagiscono i clienti e il modo in cui devono operare le organizzazioni tecnologiche. La vera sfida per la leadership non consiste solo nella scelta dei modelli o degli strumenti. Consiste nel creare il modello operativo, l'architettura, la governance, le competenze e la disciplina di prodotto necessari per industrializzare l'IA in modo responsabile.
Guidare l'architettura delle soluzioni AWS
In qualità di responsabile globale dell'architettura delle soluzioni e dell'FDE, guido l'organizzazione globale di AWS per l'architettura delle soluzioni e l'ingegneria dislocata in prima linea, con un focus sulle piattaforme di IA agentica, sulla modernizzazione aziendale e sulla trasformazione cloud su scala produttiva.
L'organizzazione opera su scala aziendale, collaborando con grandi clienti globali, partner strategici, team di prodotto, team di ingegneria specializzati e organizzazioni operative regionali. L'ambito architetturale è ampio: piattaforme di IA/ML, flussi di lavoro agentici, basi dati e analisi, modernizzazione delle applicazioni, infrastrutture cloud-native, sicurezza, governance e soluzioni integrate con i partner.
Guido, abilito e influenzo a livello globale più di 200 specialisti, ingegneri dei partner e responsabili della tecnologia sul campo. Il lavoro è estremamente complesso perché non costruiamo dimostrazioni isolate. Aiutiamo le aziende a passare dalle prime idee sull'IA e dai casi aziendali di modernizzazione a piattaforme ripetibili, sicure e pronte per la produzione, in grado di scalare tra unità aziendali, mercati e ambienti dei clienti.
Il nostro modello di distribuzione combina l'ingegneria dislocata in prima linea, meccanismi globali di piattaforma, distribuzione guidata dai partner e cicli di feedback tra prodotto e team sul campo. Il mio team crea progetti riutilizzabili, architetture di riferimento, dimostrazioni per i dirigenti, manuali tecnici, modelli di governance e modelli di soluzioni componibili che accelerano l'adozione mantenendo al contempo qualità, sicurezza e disciplina operativa.
Perché un modello di ingegneria dislocata in prima linea è essenziale con l'IA
L'anno scorso ho introdotto un modello di ingegneria dislocata in prima linea per la modernizzazione guidata dall'IA.
Nell'era del cloud disponevamo di architetture di riferimento riutilizzabili, progetti di soluzioni, modelli di distribuzione e checkpoint di governance. Erano necessari, ma non sufficienti con l'IA. I clienti continuavano ad avere difficoltà nel passare dal POC alla produzione perché il lavoro più complesso si svolgeva all'interno del loro ambiente reale: dati, patrimonio applicativo, complessità del codice, vincoli di sicurezza e modello operativo.
Per questo ho introdotto un meccanismo FDE che integra gli ingegneri molto più vicino ai carichi di lavoro reali dei clienti. Invece di fornire consulenza dall'esterno, il team FDE lavora con i dati, il codice, l'architettura e i team di distribuzione del cliente per individuare i candidati alla modernizzazione, creare risorse utilizzabili e portare il primo carico di lavoro in produzione.
Ho inoltre introdotto un semplice modello 3-3-3: 3 giorni per la scoperta, 3 settimane per la valutazione e 3 mesi per portare il primo carico di lavoro in produzione. Questo ha offerto ai dirigenti un percorso chiaro dall'ambizione legata all'IA al valore misurabile.
L'impatto è stato significativo. I clienti hanno potuto accelerare il percorso di modernizzazione da 2x a 4x, ridurre i costi fino alla metà e andare oltre le dimostrazioni, ottenendo un ROI concreto. Ancora più importante, ha cambiato il dialogo con i dirigenti. L'IA non era più un esperimento secondario; è diventata un meccanismo pratico per modernizzare carichi di lavoro reali, migliorare la produttività ingegneristica e creare valore aziendale misurabile.
Come modernizzare più velocemente senza perdere la fiducia
L’IA diventa più potente nel lavoro dello stato futuro: genera opzioni di modernizzazione, propone nuove architetture, definisce i confini dei servizi, sviluppa modelli di migrazione, scrive codice, genera test e accelera l’implementazione. Questa parte può essere più probabilistica perché l’IA può esplorare le opzioni e migliorare la velocità di sviluppo. Ma anche in questo caso, la decisione finale rimane umana.
Uso intensamente l'IA per accelerare la comprensione tecnica, il riconoscimento dei modelli e la produttività ingegneristica, ma non delego la responsabilità all'IA.
Nelle aziende complesse, il business si basa spesso su decenni di codice, debito tecnico, dipendenze non documentate e regole aziendali incorporate. In questo contesto, abbiamo bisogno sia di approcci deterministici sia di approcci probabilistici. Non si può fare affidamento esclusivamente sulla scoperta probabilistica dell'IA quando si cerca di comprendere sistemi mission-critical.
Per la scoperta del codice, l'estrazione delle regole aziendali, l'analisi delle dipendenze, la mappatura delle funzionalità e la valutazione dello stato attuale, preferisco un approccio più deterministico. Abbiamo bisogno di tracciabilità, ripetibilità, prove e fiducia in ciò che il sistema fa. L'IA può essere d'aiuto riassumendo, raggruppando e accelerando l'analisi, ma le fondamenta devono essere costituite da fatti verificabili ricavati dal codice, dai log, dai flussi di dati, dal comportamento in fase di esecuzione e dalle evidenze architetturali.
L'IA diventa più potente nel lavoro sullo stato futuro: genera opzioni di modernizzazione, propone nuove architetture, definisce i confini dei servizi, sviluppa modelli di migrazione, scrive codice, genera test e accelera l'implementazione. Questa parte può essere più probabilistica perché l'IA può esplorare le opzioni e migliorare la velocità di sviluppo.
Ma anche in questo caso, la decisione finale rimane umana. Ingegneri e leader responsabili devono convalidare le scelte architetturali, il livello di sicurezza, la prontezza per la produzione, i rischi di conformità, l'impatto sui clienti e i compromessi relativi agli investimenti.
Il mio modello è quindi: scoperta deterministica, progettazione e implementazione accelerate dall'IA e convalida governata dall'uomo. Questa combinazione ci permette di modernizzare più rapidamente senza perdere fiducia, controllo o responsabilità aziendale.
Gli svantaggi dell'IA nei flussi di lavoro ingegneristici
Il risultato positivo più importante è stato che l'IA ha accorciato significativamente il percorso dalla scoperta alla produzione quando è stata integrata in un flusso di lavoro ingegneristico disciplinato.
L'IA ha inoltre accelerato la comprensione del codice, l'estrazione delle regole aziendali, l'analisi delle dipendenze, la generazione dei test, la documentazione e la pianificazione della modernizzazione. Ha ridotto il tempo dedicato all'analisi manuale, aiutando i team di ingegneria a concentrarsi maggiormente sulle decisioni architetturali, sulla convalida e sulla prontezza per la produzione.
Tuttavia, l'IA può diventare molto costosa molto rapidamente se i team non progettano tenendo conto dell'economia dell'inferenza. Nelle grandi aziende con milioni di utenti, i costi dei token dei modelli più avanzati possono arrivare a milioni di dollari se ogni interazione dipende da modelli di base esterni di terze parti senza ottimizzazione.
Una lezione è che l'architettura dell'IA deve includere anche un'architettura dei costi. Per alcuni carichi di lavoro, le aziende dovrebbero valutare l'inferenza autogestita o ospitata nel cloud utilizzando GPU o acceleratori, incluse opzioni come vLLM su infrastrutture cloud. Ciò offre un maggiore controllo sui costi, sulla latenza, sui confini dei dati e sulla strategia di fornitura dei modelli. Tecniche come la memorizzazione nella cache KV, il batching continuo, la quantizzazione e l'ottimizzazione dei kernel possono migliorare sostanzialmente l'utilizzo delle GPU e ridurre i costi di inferenza.
Il costo non è l'unico svantaggio. L'IA può anche creare una falsa fiducia se i team la usano senza governance. I rischi includono una comprensione incompleta del codice, dipendenze allucinate, una copertura dei test insufficiente, lacune nella sicurezza e team che passano troppo rapidamente dal prototipo alla produzione.
Perché l'IA incontra difficoltà nella modernizzazione dall'inizio alla fine dei sistemi preesistenti
L'IA ha incontrato le maggiori difficoltà quando i team le hanno chiesto di formulare valutazioni tecniche senza un contesto sufficiente sul sistema.
Un esempio comune è la modernizzazione dei sistemi legacy. L'IA può riepilogare il codice, generare idee per la migrazione e persino produrre rapidamente nuovo codice. Tuttavia, nelle grandi aziende, la complessità reale va oltre il codice. Comprende decenni di regole aziendali, integrazioni non documentate, processi batch, dipendenze dai dati, eccezioni operative, vincoli di sicurezza e responsabilità organizzative. Se si chiede all'IA di modernizzare quell'ambiente disponendo solo di una visione parziale, può produrre risposte sicure di sé ma incomplete.
La preparazione alla produzione è un altro ambito in cui incontra difficoltà. L'IA può creare prototipi molto rapidamente, ma molti prototipi non si trasformano automaticamente in sistemi di produzione sicuri, osservabili, resilienti ed efficienti in termini di costi. A volte i team sottovalutano il lavoro necessario per i test, la governance, la risposta agli incidenti, il monitoraggio, la valutazione dei modelli, la qualità dei dati e la gestione del ciclo di vita.
Come gli ingegneri possono migliorare i prodotti controllando i costi e l'affidabilità dell'inferenza
Ecco un esempio tratto da una grande piattaforma di creazione di contenuti multimediali e di marketing, in cui l'IA aiuta gli utenti a passare dall'intento agli asset digitali finiti su scala aziendale.
Il flusso di lavoro inizia quando un utente descrive ciò che vuole creare: una campagna per il lancio di un prodotto, un contenuto creativo per i social media, una presentazione commerciale, un breve video o un asset di marketing localizzato. L'IA interpreta l'intento dell'utente, includendo il pubblico, il formato, il tono, le linee guida del marchio, gli asset richiesti, i vincoli del canale e i requisiti di conformità.
Da quel momento, la piattaforma utilizza un flusso di lavoro basato su agenti. Un agente recupera modelli, loghi, caratteri, colori e asset di campagna approvati dal marchio. Un altro genera testi e varianti creative. Un altro propone i layout. Un altro verifica la conformità al marchio, l'accessibilità, le policy e la sicurezza dei contenuti. Un livello finale di orchestrazione assembla l'output in asset modificabili e lo indirizza ai flussi di approvazione o pubblicazione.
A questa scala, l'ingegneria ha dovuto affrontare sfide legate non solo alla qualità dei modelli, ma anche all'economia dell'inferenza, alla latenza, all'affidabilità e alla governance. Il team ha ottimizzato un ambiente di inferenza su larghissima scala, che supportava circa 10.000 nodi di calcolo e circa 80.000 GPU. L'architettura combinava capacità GPU provenienti da più fornitori cloud e terze parti approvate, collegando questi ambienti attraverso un livello di rete ibrida. Questo ha dato alla piattaforma la flessibilità di collocare i carichi di lavoro in base a costi, latenza, disponibilità e localizzazione dei dati.
Gli esseri umani sono rimasti al controllo nei momenti decisionali chiave. L’IA generava opzioni, consigliava layout, scriveva testi e accelerava la produzione, ma era l’utente o il responsabile del marchio ad approvare l’asset finale.
Il team ha inoltre implementato una strategia più disciplinata per la distribuzione dei modelli. Invece di inviare ogni richiesta al modello di frontiera più costoso, la piattaforma indirizzava le richieste verso modelli adatti allo scopo, inclusi modelli aperti come Kimi e Qwen, distribuiti tramite runtime ottimizzati come vLLM e modelli basati su schemi in stile Ollama. Il team ha inoltre applicato tecniche di ottimizzazione dell'inferenza, tra cui caching KV, batching continuo, quantizzazione, ottimizzazione della memoria e ottimizzazione a livello di kernel, per migliorare l'utilizzo delle GPU e ridurre i costi.
Gli esseri umani sono rimasti al controllo nei momenti decisionali chiave. L'IA generava opzioni, consigliava layout, scriveva testi e accelerava la produzione, ma era l'utente o il responsabile del marchio ad approvare l'asset finale. I team di ingegneria erano responsabili delle misure di protezione: sicurezza, accesso ai dati, selezione dei modelli, osservabilità, latenza, controllo dei costi, verifiche di sicurezza e cicli di feedback.
Il risultato è stato un flusso di lavoro basato sull'IA che è entrato a far parte dell'esperienza del prodotto, non soltanto uno strumento interno per la produttività. Ha ridotto il tempo necessario per passare dall'idea all'asset, migliorato la personalizzazione, aumentato il riutilizzo dei componenti del marchio approvati e creato un ciclo di feedback in cui le modifiche degli utenti e i dati sul coinvolgimento miglioravano le raccomandazioni future. Allo stesso tempo, l'architettura ha dato all'azienda un controllo molto più solido sui costi di inferenza, sull'affidabilità e sulla governance.
Perché l'implementazione dell'IA richiede una mentalità orientata al prodotto
Implementare strumenti di IA riguarda meno l'adozione degli strumenti e più il cambiamento del modello operativo dell'ingegneria.
Inizialmente, molte organizzazioni pensano che la sfida consista nel dare agli ingegneri accesso a copiloti, assistenti di programmazione, API dei modelli o piattaforme interne di IA. Questo aiuta, ma non è sufficiente. In assenza di schemi chiari, i team utilizzano l'IA in modo incoerente. Alcuni la usano solo per generare codice. Altri la usano per la documentazione. Alcuni si fidano troppo. Altri la evitano perché non sono sicuri dei rischi legati alla sicurezza, alla proprietà intellettuale o alla qualità.
Se dovessi ricominciare, definirei ancora prima il flusso di lavoro dell'ingegneria dell'IA: dove l'IA dovrebbe e non dovrebbe essere utilizzata, quali prove sono necessarie, cosa devono verificare gli esseri umani e come l'output viene testato, protetto e promosso alla produzione.
Questo avrebbe evitato alcuni problemi. Primo, avremmo potuto ridurre l'utilizzo incoerente tra i team. Secondo, avremmo potuto evitare un'eccessiva fiducia nel codice o nelle analisi generati dall'AI, che sembravano corretti ma non disponevano di un contesto sufficiente. Terzo, avremmo potuto controllare prima i costi implementando fin dall'inizio l'instradamento dei modelli, la definizione del budget dei token, la memorizzazione nella cache e la governance dell'inferenza. Quarto, avremmo potuto creare modelli riutilizzabili migliori invece di lasciare che ogni team inventasse il proprio approccio.
La lezione più importante è che l'adozione dell'AI richiede una mentalità orientata al prodotto e alla piattaforma. Servono abilitazione, misure di protezione, osservabilità, controlli dei costi, revisione della sicurezza, prompt e agenti riutilizzabili, modelli di valutazione e una chiara responsabilità umana. Altrimenti, l'AI aumenta l'attività senza aumentare sempre la qualità ingegneristica o il valore aziendale.
Perché l'SDLC deve diventare l'AI-DLC
I CTO dovrebbero riprogettare attivamente il ciclo di vita della distribuzione del software. Penso a questo processo come al passaggio dall'SDLC tradizionale all'AI-DLC, un ciclo di vita della distribuzione potenziato dall'AI per l'era dell'AI agentica.
Nell'SDLC tradizionale, spesso seguiamo fasi lineari: requisiti, progettazione, sviluppo, distribuzione e assistenza. Questo approccio funzionava abbastanza bene quando l'obiettivo principale era costruire software deterministico attraverso passaggi di consegne strutturati. Con l'AI, soprattutto con l'AI agentica, il ciclo di vita diventa però più iterativo e compatto.
Semplifico l'AI-DLC in tre fasi principali: avvio, costruzione e operatività.
- Nella fase di avvio, l'AI aiuta con l'analisi esplorativa, la comprensione del codice, l'estrazione delle regole aziendali, l'analisi delle dipendenze, il chiarimento dei requisiti, l'identificazione dei rischi e la pianificazione dello stato obiettivo.
- Nella fase di costruzione, l'AI assiste nella valutazione delle opzioni architetturali, nella scomposizione dei servizi, nella generazione di codice e test, nella documentazione, nelle revisioni della sicurezza, nei modelli infrastrutturali e nell'esecuzione della modernizzazione.
- Nella fase operativa, l'AI supporta l'osservabilità, la classificazione iniziale degli incidenti, i cicli di feedback, la valutazione dei modelli, l'ottimizzazione dei costi, la governance e il miglioramento continuo.
Il punto importante è che l'AI-DLC non è semplicemente un SDLC a cui è stato aggiunto un assistente alla programmazione. È un modello operativo ingegneristico riprogettato. Integra agenti AI, analisi deterministica, convalida umana, controlli di sicurezza, preparazione alla produzione e governance dei costi in un unico flusso di lavoro.
Come stanno cambiando i team di ingegneria a causa dell'AI
L'AI ha spostato i team di ingegneria da un'esecuzione sequenziale e basata sui ruoli verso squadre più integrate e orientate ai risultati.
In passato, ci organizzavamo intorno a ruoli distinti: architetti, ingegneri applicativi, ingegneri dei dati, DevOps, sicurezza, QA e operazioni. Questi ruoli sono ancora importanti, ma l'AI comprime il ciclo di vita e riduce il valore dei lunghi passaggi di consegne. I team più efficienti sono più interfunzionali e più vicini al problema aziendale.
Per la modernizzazione guidata dall'AI e l'ingegneria dei prodotti, ora cerco team che combinino diverse competenze: solide basi di ingegneria del software, ingegneria cloud e delle piattaforme, competenza in ambito AI, consapevolezza della sicurezza, mentalità orientata al prodotto e capacità di giudizio operativo. Apprezzo anche gli ingegneri che lavorano in contesti ambigui, ragionano dai principi fondamentali e convalidano i risultati dell'AI invece di accettarli ciecamente.
Il modello di ingegneria distribuita è un buon esempio. Invece di mantenere architettura, ingegneria AI, DevOps e sicurezza su percorsi sequenziali separati, avviciniamo queste competenze al cliente o all'ambiente aziendale. Il team lavora con codice, dati, vincoli e metriche di successo reali.
Anche le assunzioni sono cambiate. Continuo ad attribuire grande importanza alla profondità tecnica, ma cerco anche pensatori sistemici: persone che comprendono l'architettura, utilizzano l'AI in modo responsabile, comunicano con le parti interessate aziendali e si assumono la responsabilità dei risultati in produzione. Nell'era dell'AI, i migliori ingegneri non sono semplicemente produttori di codice. Sono persone che definiscono i problemi, validatori e costruttori di sistemi ripetibili.
Come misurare l'efficacia dell'AI
I CTO non dovrebbero misurare l’IA solo in base al numero di progetti pilota o copiloti implementati, né all’accuratezza del modello considerata isolatamente. Sono indicatori utili, ma non dimostrano una trasformazione…I CTO devono trasformare l’attività legata all’IA in una capacità ripetibile.
Una domanda che vorrei fosse posta più spesso è: come dovrebbero misurare i CTO se l'IA sta creando un valore aziendale duraturo?
I CTO non dovrebbero misurare l'IA solo in base al numero di progetti pilota o copiloti implementati, né all'accuratezza del modello considerata isolatamente. Sono indicatori utili, ma non dimostrano una trasformazione.
I CTO dovrebbero misurare l'IA in quattro dimensioni:
- Produttività ingegneristica: l'IA sta riducendo i tempi di ciclo, migliorando la qualità del codice, aumentando la copertura dei test, accelerando la modernizzazione e riducendo il debito tecnico?
- Impatto aziendale: l'IA sta migliorando l'esperienza del cliente, la produttività dei dipendenti, la conversione dei ricavi, l'efficienza dei costi o la velocità di immissione sul mercato?
- Maturità in produzione: i sistemi di IA sono sicuri, osservabili, affidabili, governati e soggetti a controllo dei costi? Dispongono di una chiara responsabilità umana e di criteri definiti per l'idoneità alla produzione?
- Riutilizzabilità e scalabilità: i team stanno sviluppando servizi di IA, agenti, prompt, modelli, prodotti di dati e funzionalità di piattaforma riutilizzabili, oppure stanno creando demo isolate?
Questo è importante perché l'IA può generare una grande quantità di attività visibile senza creare valore duraturo. I CTO devono trasformare l'attività legata all'IA in una capacità ripetibile. Ciò significa collegare strategia, architettura, modello operativo, governance ed economia.
Perché i CTO devono separare la sperimentazione dall'industrializzazione
Ecco i miei consigli.
Innanzitutto, non trattate l'IA come un esperimento secondario. Consideratela un nuovo livello operativo per l'azienda. L'IA influenzerà il modo in cui viene sviluppato il software, il modo in cui lavorano i dipendenti, il modo in cui interagiscono i clienti e il modo in cui vengono prese le decisioni. Il compito del CTO è portare l'organizzazione da progetti pilota frammentati a una strategia di piattaforma IA governata e scalabile.
In secondo luogo, separate la sperimentazione dall'industrializzazione. Sperimentare rapidamente va bene, ma l'IA in produzione richiede architettura, sicurezza, governance dei dati, valutazione, osservabilità, controlli dei costi e una chiara responsabilità umana. Molte aziende sono bloccate perché hanno numerose demo, ma nessun percorso ripetibile verso la produzione. I CTO devono creare questo percorso.
In terzo luogo, concentratevi sul valore aziendale, non sulla novità del modello. Le organizzazioni vincenti non saranno quelle che si limitano a utilizzare il modello più recente. Saranno quelle che integrano l'IA nei flussi di lavoro reali, modernizzano le proprie fondamenta tecnologiche, migliorano la produttività ingegneristica e misurano risultati quali tempo di ciclo, efficienza dei costi, esperienza del cliente, impatto sui ricavi e riduzione dei rischi.
In quarto luogo, il mio consiglio pratico è creare insieme una piattaforma IA e un modello di ingegneria distribuita sul campo. La piattaforma offre riutilizzo, governance e scalabilità. Il modello FDE porta l'IA nei carichi di lavoro reali dei clienti e delle aziende, utilizzando dati reali, codice reale e vincoli reali. È così che i CTO possono passare dall'ambizione legata all'IA a un ROI effettivamente realizzato.
Segui gli aggiornamenti
Segui il lavoro di Saurabh Shrivastava su LinkedIn e sulla sua pagina autore di Amazon.
Presto arriveranno altre interviste a esperti su The CTO Club!
