Il CTO Globale invita i leader a concentrarsi sull’infrastruttura dati prima dell’IA

Il ruolo di Field CTO si differenzia dalla gestione di una singola organizzazione di ingegneria. Opero in dozzine di ambienti clienti contemporaneamente, consigliando architetti e dirigenti C-suite su infrastrutture dati, strategie di integrazione e adozione dell’IA. Questa ampiezza mi offre un vantaggio nel riconoscere i pattern che è difficile ottenere stando all’interno di una sola azienda.

La mia esperienza copre l’intera storia dell’integrazione dati aziendale: ETL, ESB, iPaaS e gestione delle API, a cui si aggiungono nove anni di focalizzazione sullo streaming dei dati con Apache Kafka e Flink come backbone per architetture event-driven, e sempre più, orchestrazione dei processi e IA lungo tutto il ventaglio che va dal machine learning predittivo all’IA generativa e agentica. Informo regolarmente analisti di Gartner e Forrester e pubblico le mie ricerche, che trattano scenari di fornitori, pattern architetturali e casi di studio reali del settore. Ho inoltre pubblicato un libro sul data streaming.

Quando parlo di trasformazione IA con i leader tecnologici, il tema non riguarda principalmente i modelli. Si tratta invece dell’infrastruttura sottostante. I sistemi di IA agentica che compiono azioni autonome nei flussi di lavoro aziendali hanno bisogno di tre cose per funzionare in modo affidabile:

• Dati in tempo reale per poter agire sulla realtà attuale
• Intelligenza di processo per definire ciò che possono fare
• Fiducia incorporata nell’architettura, non solo nel modello

Il mio pensiero è focalizzato su questa convergenza.

Perché i livelli dell’architettura devono convergere per il successo dell’IA

Attraverso i vari settori, vedo costantemente imprese che investono molto su tre livelli separati: una dorsale per l’integrazione dati, uno strato di automazione dei processi e, sempre più spesso, un’iniziativa per l’IA. Il problema è che questi tre elementi quasi mai sono progettati per funzionare insieme. L’integrazione dati muove i dati ma non si connette alle decisioni di business. L’automazione dei processi applica i flussi di lavoro ma si basa su contesti obsoleti. Gli agenti IA generano raccomandazioni o compiono azioni, ma senza un perimetro governato rispetto a ciò che possono fare. Ogni strato lavora in isolamento. Manca l’architettura convergente.

I modelli di deployment che vedo variano molto. Alcune organizzazioni utilizzano infrastrutture cloud-native completamente gestite su AWS, Azure o GCP, e grandi aziende globali includono spesso deployment nella Cina continentale su Alibaba Cloud, volutamente separati per ragioni legali, regolamentari e di tutela dei dati. Altre operano con architetture ibride, con data center on-premise collegati al cloud, spinte da esigenze di sovranità dei dati o sistemi legacy che non possono essere spostati rapidamente. Settori regolamentati come finanza e sanità quasi sempre hanno requisiti multi-regione o multi-cloud, non per scelta ma per obbligo normativo. I clienti nel manifatturiero spesso prevedono deployment edge, processando i dati vicino alla linea di produzione prima di aggregarli centralmente.

In tutti questi ambienti, l’architettura event-driven è diventata infrastruttura fondamentale per le operazioni. Apache Kafka si è imposto come standard de facto per l’event brokering vero tra sistemi, l’elaborazione in tempo reale a qualsiasi scala e l’integrazione ibrida o multi-cloud. PayPal elabora oltre un trilione di messaggi Kafka ogni giorno. New Relic raccoglie miliardi di dati al minuto. Non si tratta di deployment sperimentali. Sono la spina dorsale operativa del business.

Molte aziende hanno già i tre componenti necessari per una IA agentica affidabile. Mancano però dell’impegno architetturale per farli convergere.

Perché la preparazione dei dati precede la preparazione dell’IA

Il pensiero di Kai

La preparazione per l’IA coincide con la preparazione dei dati.

Ecco cosa ho riscontrato: l’IA non è la parte difficile. Lo è l’infrastruttura dati che vi sta sotto.

Nella maggior parte delle iniziative IA aziendali che ho visto negli ultimi nove anni, il successo o il fallimento dipendono meno dal modello scelto e più dal fatto che l’organizzazione disponga o meno di una base affidabile, governata e in tempo reale capace di alimentare quel modello con dati attuali, accurati e attendibili.

Un modello ben allineato che riceve dati obsoleti o incoerenti produrrà risultati inaffidabili. Un sistema AI agentico senza uno strato di processo che definisca cosa può fare finirà per compiere un'azione che nessuno può spiegare o annullare. Questi non sono problemi di modello. Sono problemi di infrastruttura e di architettura. E sono del tutto prevedibili prima ancora di scrivere una sola riga di codice AI.

La conseguenza pratica è che la "prontezza" all'AI coincide con la prontezza dei dati. Prima di selezionare un modello, prima di scegliere un fornitore di AI, prima di lanciare un progetto pilota, un CTO dovrebbe essere in grado di rispondere onestamente a tre domande.

1. L’organizzazione ha accesso affidabile ai dati in tempo reale dai propri sistemi operativi?
2. Esistono processi governati che definiscono ciò che un sistema AI può e non può fare in autonomia?
3. È presente un framework di fiducia a livello architetturale, non solo all’interno del modello, che possa applicare tali limiti in produzione?

Se la risposta a una di queste tre domande è no, il viaggio verso l’AI dovrebbe partire da lì, non dal modello.

Perché l'AI deve essere integrata nei processi aziendali esistenti

Il cambiamento più significativo che ho promosso è stato passare dalla costruzione di progetti AI separati all’integrazione dell’AI nei processi aziendali esistenti. Questo aspetto è fortemente sottovalutato e di grande importanza. Anzi, direi che la maggior parte dei CTO dovrebbe spostare l’attenzione dalla progettazione di nuovi sistemi AI alla progettazione della partecipazione dell’AI nei flussi di lavoro già esistenti, quali limiti siano imposti dallo strato di processo e come siano inclusi governance e auditabilità — prima di distribuire qualsiasi modello.

Prima di questa svolta, il modello era quasi sempre lo stesso. Un progetto AI partiva disconnesso dai sistemi operativi. Il modello funzionava bene in laboratorio. In produzione, mancava l’accesso affidabile ai dati aggiornati, non aveva limiti definiti per le sue azioni e non era integrato nei flussi di approvazione di cui l’azienda aveva bisogno. Demo impressionante. Distribuzione fallita.

Il cambiamento che ora promuovo con costanza si articola in due punti.

• Innanzitutto, considerare l’architettura esistente basata sugli eventi come fondamento per l’adozione dell’AI invece che come obiettivo da sostituire. I sistemi restano. I processi aziendali restano. L’AI partecipa ai flussi di lavoro già attivi, consumando eventi in tempo reale e agendo entro i limiti definiti dallo strato di processo.
• In secondo luogo, spostare i guardrail dell’AI fuori dal modello e dentro lo strato di orchestrazione dei processi. Un modello ben allineato non basta. Un’AI affidabile in produzione richiede che il livello dei workflow imponga i gate di approvazione, i percorsi di escalation e la tracciabilità completa di ogni azione autonoma compiuta dall’agente.

Alpian, la prima banca digitale privata svizzera ad avere una licenza completa, è un esempio eccellente di corretta implementazione sin dal primo giorno. Alpian ha costruito tutta la propria piattaforma su architettura event-driven, con Apache Kafka come sistema nervoso centrale che collega microservizi, prodotti dati di dominio e agenti AI. Quando hanno introdotto AI agentica e RAG nei flussi di interazione con i clienti, l’architettura era già pronta. Gli eventi Kafka fornivano agli agenti contesto in tempo reale. Lo strato di processo applicava i controlli di conformità. L’encryption a livello di campo e la governance degli schemi sono stati previsti dall’inizio.

Il risultato è stato un’istituzione finanziaria regolamentata che esegue agenti AI autonomi all’interno di flussi di lavoro governati e tracciabili, ovvero esattamente il modello che la maggior parte delle aziende tradizionali sta ora cercando di adottare retroattivamente.

Le organizzazioni che riescono in questo trattano l'adozione dell’AI come una disciplina architetturale, non come una corsa di progetto.

Le organizzazioni che riescono in questo trattano l’adozione dell’AI come una disciplina architetturale, non come una corsa di progetto… Il divario tra esiti positivi e negativi deriva quasi sempre dal fatto che l’infrastruttura dati fosse pronta o meno prima dell’introduzione dell’AI.

Share This Quote on:

• Share on Twitter
• Share on LinkedIn
• Share on Facebook

Kai WaehnerOpens new window

Global Field CTO, Confluent

Perché la prontezza dei dati determina il successo della distribuzione AI

Dopo nove anni in Confluent su centinaia di ambienti aziendali, i risultati che ho visto con l’AI sono profondamente disomogenei. La differenza tra successi e insuccessi deriva quasi sempre da un solo aspetto: se l’infrastruttura dati era pronta prima dell’introduzione dell’AI.

Dal lato positivo, i numeri provenienti da implementazioni ben architettate sono convincenti. BMW previene oltre 500 minuti di fermo produzione non pianificato all'anno in un unico stabilimento. Alpian gestisce una banca digitale completamente regolamentata con agentic AI integrata in workflow dei clienti governati e tracciabili. Il modello qualitativo tra le implementazioni di successo è costante: tempo di immissione sul mercato più rapido, riduzione dei costi operativi in processi ripetitivi ad alto volume e un'esperienza cliente significativamente migliore quando l'AI accede a contesti in tempo reale invece che a dati batch obsoleti.

Dal lato negativo, il modello di fallimento è altrettanto coerente. I progetti di AI senza una solida base dati governata producono quasi sempre lo stesso risultato: demo impressionanti, distribuzioni in produzione fallite. Il modello funziona in laboratorio. In produzione, riceve dati obsoleti o incoerenti, genera "allucinazioni" su casi limite, compie azioni senza tracciabilità e mina la fiducia del business nell'AI anziché rafforzarla. Una ricerca MIT stima che circa il 95% dei progetti pilota di AI aziendale non generano impatti di business misurabili. Questo numero corrisponde alle mie osservazioni sul campo.

La modalità di fallimento più recente che sto osservando è l'introduzione della governance troppo tardi. Le organizzazioni implementano agentic AI e poi scoprono, solitamente dopo un incidente, che nessun livello di processo ha definito cosa poteva fare l'agente, nessun percorso di escalation per output incerti del modello, e nessuna traccia di audit per ricostruire gli eventi. Non è un problema di AI. È un problema architetturale. Ed è totalmente evitabile.

Perché l'AI informa le decisioni ma gli esseri umani garantiscono la responsabilità

Riscontro costantemente uno schema: l'AI informa e accelera. Prende decisioni autonome entro confini definiti. Ma la responsabilità per le decisioni più importanti rimane agli esseri umani.

Nell'ambito informato dall'AI, la sintesi della ricerca, la creazione di contenuti, la generazione di codice per problemi ben definiti, il testing automatizzato e lo scanning di sicurezza apportano valore chiaro. Nel mio lavoro, gli strumenti di AI comprimono giorni di sintesi tra report di analisti, conversazioni con clienti e documentazione tecnica. Il risultato richiede ancora valutazione esperta, ma il punto di partenza è molto più avanzato.

Dal lato delle decisioni autonome, gli agenti AI dovrebbero decidere autonomamente quando il rischio è contenuto e il processo ben governato. La rilevazione delle frodi nei servizi finanziari è l'esempio più chiaro. Al di sotto di una certa soglia di rischio, un agente AI blocca automaticamente una transazione senza intervento umano. Se cresce l'importo della transazione e l'esposizione normativa, il livello di orchestrazione del processo indirizza il caso a un analista umano prima di prendere qualsiasi decisione. Il confine non è fisso. Viene definito dall'azienda, codificato nel workflow e applicato dal livello di processo, non dal modello stesso.

Sul lato esplicitamente umano, pongo il limite alle decisioni con importanti conseguenze architetturali, rischio strategico per il business o significative responsabilità normative. Scegliere uno schema architetturale fondamentale, selezionare un fornitore tecnologico strategico, progettare il modello di governance per un sistema di agentic AI: queste restano decisioni umane. Accelerare non compensa le conseguenze di errori in questi ambiti.

Perché l'AI non mantiene le promesse in tre aree principali

L'AI non ha prodotto l'impatto tecnico o ingegneristico che i clienti si aspettavano inizialmente in tre aree.

La prima è l'integrazione dei dati aziendali. L'AI aveva promesso di semplificare in modo drastico la connessione tra sistemi eterogenei: mapping degli schemi, enforcement della qualità dei dati, logiche di trasformazione e governance in ambienti ibridi complessi. In pratica, l'AI assiste in questi compiti ma non li risolve. Un modello non può ragionare oltre il debito architetturale sottostante, sistemi legacy con modelli dati non documentati, semantiche incoerenti tra unità di business, metadati mancanti e proprietà frammentate. Gli ingegneri devono ancora affrontare il lavoro più difficile.

La seconda è l'AI agentica in workflow aziendali complessi e a più passaggi. Le demo sono convincenti. In produzione, gli agenti falliscono in modo imprevedibile quando si trovano ad affrontare casi limite non coperti dai dati di training, quando la finestra di contesto non dispone di uno stato sufficientemente aggiornato o quando il livello di processo non intercetta e gestisce adeguatamente gli errori degli agenti. Il divario tra ciò che un agente può fare in ambiente controllato e ciò che possiamo fidarci che faccia in autonomia in workflow produttivi regolamentati è ancora significativo.

La terza è la presa di decisioni architetturali. Gli strumenti di AI hanno accelerato significativamente la codifica di routine, la scrittura di test e la documentazione. Ma non migliorano in modo affidabile le decisioni riguardo i fondamenti architetturali. I modelli riflettono i pattern del passato. L'architettura aziendale richiede giudizio sui vincoli futuri, sull'evoluzione normativa e sulle scommesse tecnologiche che i modelli non sono in grado di valutare efficacemente. I team che fanno troppo affidamento sull'AI per le decisioni architetturali tendono a produrre sistemi coerenti localmente ma fragili a livello globale.

L'elemento comune tra tutte e tre le aree è questo: l'AI dà risultati quando il problema è ben definito, i dati sono puliti e aggiornati e c'è un esperto del dominio coinvolto. Non raggiunge le aspettative quando il problema richiede giudizio contestuale, cambiamento organizzativo o pensiero architetturale che vada oltre la semplice identificazione di pattern sui dati storici.

Come l'IA lotta con sicurezza e scalabilità nel codice

La difficoltà più costante che vedo si trova al confine tra il codice generato dall'IA e il giudizio ingegneristico di livello produttivo.

Gli strumenti di generazione di codice tramite IA sono davvero utili per attività ben definite e ripetitive: boilerplate, casi di test, documentazione e trasformazioni semplici. I problemi emergono quando i team estendono quella fiducia alle decisioni architetturali, al codice sensibile alla sicurezza o ai componenti critici per la scalabilità senza un rigoroso controllo umano.

Dal punto di vista della sicurezza, il codice generato dall'IA introduce frequentemente vulnerabilità sottili che superano le scansioni automatiche ma falliscono in condizioni avverse. L'iniezione di prompt è l'esempio più evidente oggi nei sistemi agentici di IA. Un agente che genera o esegue codice in base all'input dell'utente senza una convalida appropriata dell'input e senza sandoboxing crea superfici di attacco che sono facili da trascurare e difficili da rilevare dopo che il danno è fatto. Ho visto questo schema presentarsi nelle prime implementazioni di IA agentica in cui i team si concentravano su capacità e velocità, considerano la revisione della sicurezza solo come un passo posteriore.

Dal punto di vista della scalabilità, gli strumenti IA tendono a generare soluzioni che funzionano correttamente su piccola scala ma che comportano ipotesi nascoste su volume di dati, concorrenza o latenza che emergono solo sotto carico produttivo. Un consumer Kafka generato che funziona bene in fase di test può fallire in modo imprevedibile a diecimila eventi al secondo se il codice generato non tiene conto del ribilanciamento delle partizioni, della gestione degli offset o della gestione del backpressure. Il modello non conosce il tuo ambiente di produzione. Conosce i pattern nei dati con cui è stato addestrato.

La risposta pratica non è smettere di usare l'IA per la generazione di codice. Bisogna trattare il codice generato dall'IA come se provenisse da uno sviluppatore capace ma junior che non ha mai visto il tuo sistema di produzione. Rivedilo. Testalo in condizioni realistiche. E non lasciarlo mai avvicinare a percorsi critici per la sicurezza o la scalabilità a meno che non ci sia l'approvazione di un ingegnere senior.

Cosa devono fare i leader tecnologici ora

Il pensiero di Kai

Investe nella tua base dati prima della tua ambizione sull’IA… considera la governance dell’IA come un problema architetturale, non di policy… pensa in entrambe le direzioni contemporaneamente.

Ecco tre consigli, nell'ordine in cui contano:

Per prima cosa, investi nella tua base dati prima della tua ambizione sull'IA. Le organizzazioni che ottengono risultati misurabili con l'IA non sono quelle che sono passate più velocemente a un nuovo modello. Avevano dati puliti, in tempo reale e governati che scorrevano nei loro sistemi prima che iniziasse la discussione sull'IA. Se i tuoi dati sono isolati, obsoleti o privi di governance, risolvi prima quello. Nessun modello compensa dati scadenti su larga scala.

Secondo, considera la governance dell'IA come un problema architetturale, non di policy. Scrivere linee guida sull'uso responsabile dell'IA è necessario ma non sufficiente. È lo strato di processo che realmente governa il comportamento degli agenti in produzione: i gate dei workflow, le soglie di approvazione, i percorsi di escalation e le tracce di audit che impongono dei limiti indipendentemente da ciò che raccomanda il modello. Costruisci questi elementi nell'architettura fin dall'inizio. Aggiungere la governance dopo la messa in produzione è costoso, inaffidabile e di solito avviene solo dopo che qualcosa è già andato storto.

Terzo, pensa in entrambe le direzioni contemporaneamente. La pressione bottom-up per implementare rapidamente casi d'uso IA è reale e legittima. Così come lo è la necessità top-down di una strategia architetturale che eviti la creazione di soluzioni puntuali frammentate che impiegherai anni a dover sistemare. I CTO che vedo gestire bene questa situazione riescono a mantenere entrambe le cose: avanzare rapidamente sui casi d'uso specifici mantenendo una chiara "stella polare" architetturale che rende questi casi d'uso componibili e governabili nel tempo.

Le organizzazioni che guarderanno a questo periodo come un vantaggio competitivo non sono quelle che hanno adottato l'IA per prime. Sono quelle che hanno costruito l'infrastruttura per rendere l'IA affidabile, e poi si sono mosse velocemente su quella base solida.

Segui gli aggiornamenti

Puoi seguire il lavoro di Kai Waehner sul suo sito, sul blog e su LinkedIn.

Altre interviste con esperti in arrivo su The CTO Club!