Il Field CTO Globale Esorta i Leader a Concentrarsi sull’Infrastruttura Dati Prima dell’IA

Il ruolo di Field CTO è diverso dalla gestione di una singola organizzazione di ingegneria. Lavoro simultaneamente su decine di ambienti clienti, fornendo consulenza ad architetti e leader C-suite su infrastrutture dati, strategia di integrazione e adozione dell'AI. Questa ampiezza mi conferisce un vantaggio nel riconoscimento dei pattern difficile da ottenere stando all'interno di una sola azienda.

Il mio background copre l'intera storia dell'integrazione dati nelle aziende: ETL, ESB, iPaaS e API Management, poi nove anni focalizzati sul data streaming con Apache Kafka e Flink come backbone per architetture event-driven e, sempre più, orchestrazione dei processi e AI in tutto lo spettro, dal machine learning predittivo all'AI generativa e agentica. Aggiorno regolarmente gli analisti di Gartner e Forrester e pubblico le mie ricerche, che coprono panoramiche sui fornitori, pattern architetturali e casi reali di settore. Ho anche pubblicato un libro sul data streaming.

La conversazione sulla trasformazione AI che affronto con i leader tecnologici non riguarda principalmente i modelli. Riguarda l'infrastruttura che ci sta sotto. I sistemi AI agentici che compiono azioni autonome all'interno dei processi aziendali necessitano di tre cose per funzionare in modo affidabile:

• Dati in tempo reale per agire sulla realtà attuale
• Intelligenza di processo per definire cosa possono fare
• Fiducia incorporata nell'architettura, non solo nel modello

Il mio pensiero si concentra su questa convergenza.

Perché i layer architetturali devono convergere per il successo dell'AI

In tutti i settori, vedo costantemente aziende che investono molto in tre layer separati: una dorsale per l'integrazione dati, un layer di automazione dei processi e, sempre più, un'iniziativa AI. Il problema è che questi tre layer quasi mai sono progettati per funzionare insieme. L'integrazione dati sposta i dati ma non si collega alle decisioni aziendali. L'automazione dei processi impone workflow ma funziona su contesti obsoleti. Gli agenti AI generano raccomandazioni o prendono decisioni, ma manca un perimetro governato sulle loro capacità. Ogni layer lavora in modo isolato. Manca l'architettura convergente.

I modelli di implementazione che vedo variano molto. Alcune organizzazioni utilizzano infrastrutture cloud-native completamente gestite tramite AWS, Azure o GCP, e le grandi multinazionali includono spesso deployment nella Cina continentale su Alibaba Cloud, mantenuti separati per ragioni legali, normative e di privacy dei dati. Altre operano con architetture ibride con data center on-premise connessi al cloud, spinte da requisiti di sovranità dei dati o da sistemi legacy che non possono migrare rapidamente. I settori regolamentati come finanza e sanità hanno quasi sempre esigenze multi-regione o multi-cloud, non per scelta ma per obbligo normativo. I clienti nel manifatturiero hanno frequentemente deployment edge in cui i dati vengono elaborati vicino al piano produttivo prima di essere aggregati centralmente.

In tutti questi ambienti, l'architettura event-driven è ormai un'infrastruttura mission-critical. Apache Kafka è diventato lo standard de facto per il brokeraggio degli eventi, per un vero disaccoppiamento tra sistemi, elaborazione dati in tempo reale a qualsiasi scala e integrazione ibrida e multi-cloud. PayPal gestisce oltre un trilione di messaggi Kafka al giorno. New Relic acquisisce miliardi di dati al minuto. Non sono implementazioni sperimentali. Sono la spina dorsale operativa dell'azienda.

Molte aziende hanno già i tre elementi necessari per un'AI agentica affidabile. Manca loro l'impegno architetturale per farli convergere.

Perché la preparazione dei dati precede la preparazione all'AI

Pensieri di Kai

La prontezza AI è data dalla prontezza dei dati.

Ecco cosa ho scoperto: l'AI non è l'aspetto difficile. Lo è l'infrastruttura dati sottostante.

La maggior parte delle iniziative AI aziendali che ho visto avere successo o fallire negli ultimi nove anni dipendeva meno dal modello scelto e molto di più dal fatto che l'organizzazione disponesse di una base affidabile, governata e in tempo reale, in grado di alimentare il modello con dati aggiornati, precisi e attendibili.

Un modello ben allineato che riceve dati obsoleti o incoerenti produrrà risultati inaffidabili. Un sistema di intelligenza artificiale agentico senza uno strato di processo che definisca cosa può fare, prima o poi intraprenderà un'azione che nessuno riuscirà a spiegare o annullare. Questi non sono problemi del modello. Sono problemi di infrastruttura e architettura. Ed è possibile prevederli del tutto prima ancora di scrivere una singola riga di codice AI.

L'implicazione 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 regolamentati che definiscono cosa un sistema di intelligenza artificiale può e non può fare autonomamente?
3. Esiste un framework di fiducia integrato a livello architetturale, e non solo all'interno del modello, in grado di far rispettare tali limiti in produzione?

Se la risposta a una di queste tre domande è no, il percorso verso l'AI deve partire da lì, non dal modello.

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

Il cambiamento più significativo che ho promosso è stato il passaggio dal costruire l’AI come iniziativa separata all’integrarla nei processi aziendali esistenti. Questo aspetto è fortemente sottovalutato e ha un impatto profondo. Anzi, direi che la maggior parte dei CTO dovrebbe spostare il focus dalla progettazione di nuovi sistemi AI alla progettazione delle modalità con cui l’AI partecipa ai workflow esistenti, dei limiti che lo strato di processo impone, e di come costruire governance e auditabilità — prima ancora di implementare un singolo modello.

Prima di operare questa svolta, lo schema si ripeteva quasi sempre uguale. Un progetto AI partiva scollegato dai sistemi operativi. Il modello funzionava bene in laboratorio. In produzione, però, mancava l’accesso affidabile ai dati aggiornati, un perimetro preciso per le sue azioni e l’integrazione nei flussi di approvazione di cui l’azienda aveva bisogno. Demo impressionante. Implementazione fallita.

Il cambiamento che ora promuovo sistematicamente è duplice.

• In primo luogo, trattare l’architettura esistente, basata su eventi, come fondamento per l’adozione dell’AI, anziché come obiettivo da sostituire. I sistemi rimangono. I processi aziendali rimangono. L’AI partecipa ai workflow già in esecuzione, consuma eventi in tempo reale e agisce nei limiti definiti dallo strato di processo.
• In secondo luogo, spostare le barriere di sicurezza dell’AI dal modello stesso allo strato di orchestrazione dei processi. Un modello ben calibrato non basta. Un’AI affidabile in produzione significa che lo strato di workflow fa rispettare i gate di approvazione, i percorsi di escalation e i tracciamenti di audit per ogni azione autonoma dell’agente.

Alpian, la prima banca digitale privata svizzera con licenza completa, è un esempio eccellente di come fare tutto questo correttamente fin dal primo giorno. Alpian ha costruito l’intera piattaforma in modo event-driven, utilizzando Apache Kafka come "sistema nervoso centrale" che collega microservizi, prodotti dati di dominio e agenti AI. Quando hanno introdotto AI agentica e RAG nei workflow di interazione con il cliente, l’architettura era già pronta. Gli eventi Kafka fornivano agli agenti il contesto in tempo reale. Lo strato di processo faceva osservare i controlli di conformità. Loro hanno previsto fin dall’inizio la crittografia a livello di campo e la governance degli schemi.

Il risultato è stato un’istituzione finanziaria regolamentata che esegue agenti AI autonomi all’interno di workflow regolamentati e auditabili — esattamente il modello che oggi molte aziende tradizionali stanno cercando di replicare.

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

Le organizzazioni che riescono in questo trattano l’adozione dell’AI come una disciplina architetturale, non come una corsa a tappe… Il divario tra esiti positivi e negativi deriva quasi sempre dal fatto che l’infrastruttura dati fosse realmente pronta 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 preparazione dei dati determina il successo nell’implementazione dell’AI

Dopo nove anni in Confluent e centinaia di ambienti aziendali, ho visto risultati AI profondamente discontinui. Il divario tra esiti positivi e negativi deriva quasi sempre da una cosa: se l’infrastruttura dati era pronta o meno prima dell’introduzione dell’AI.

Dal lato positivo, i numeri derivanti da implementazioni ben architettate sono convincenti. BMW previene oltre 500 minuti di inattività produttiva non pianificata all'anno in un singolo stabilimento. Alpian gestisce una banca digitale completamente regolamentata con intelligenza artificiale agentica integrata in flussi di lavoro per i clienti governati e verificabili. Il modello qualitativo che attraversa le implementazioni di successo è coerente: tempi di immissione sul mercato più rapidi, riduzione dei costi operativi in flussi di lavoro ripetitivi ad alto volume e un'esperienza cliente significativamente migliore quando l'IA accede a contesti in tempo reale invece che a dati batch obsoleti.

Dal lato negativo, lo schema di fallimento è altrettanto coerente. I progetti di IA senza una base dati governata producono quasi sempre lo stesso risultato: demo impressionanti, implementazioni in produzione fallite. Il modello funziona in laboratorio. In produzione, riceve dati obsoleti o incoerenti, "allucina" sui casi limite, compie azioni senza traccia di audit e mina la fiducia nell'IA invece di rafforzarla. Una ricerca del MIT stima che circa il 95% dei progetti pilota di IA nelle aziende non fornisce un impatto aziendale misurabile. Questo dato corrisponde alle mie osservazioni sul campo.

La modalità di fallimento più recente che sto osservando è una governance aggiunta troppo tardi. Le organizzazioni implementano IA agentica e poi scoprono, di solito dopo un incidente, che nessun livello di processo ha definito cosa potesse fare l'agente, nessun percorso di escalation per output del modello incerti e nessuna traccia di audit per ricostruire gli eventi. Questo non è un problema dell’IA. È un problema di architettura. Ed è completamente prevenibile.

Perché l’IA informa le decisioni ma gli esseri umani garantiscono la responsabilità

Vedo costantemente un modello: l’IA informa e accelera. Prende decisioni autonome entro confini definiti. Ma sono le persone a essere responsabili delle decisioni che contano di più.

Dal lato in cui l’IA informa, la sintesi delle ricerche, la creazione di contenuti, la generazione di codice per problemi ben delimitati, i test automatizzati e la scansione della sicurezza apportano un valore chiaro. Nel mio lavoro, gli strumenti di IA comprimono giornate di sintesi tra report di analisti, conversazioni con i clienti e documentazione tecnica. L’output richiede comunque un giudizio esperto per essere validato, ma il punto di partenza è molto più avanzato.

Dal lato delle decisioni autonome, gli agenti IA dovrebbero decidere in modo indipendente quando il rischio è limitato e il processo ben governato. Il rilevamento delle frodi nei servizi finanziari è l’esempio più chiaro. Sotto una certa soglia di rischio, un agente IA blocca automaticamente una transazione senza l’intervento umano. Con l’aumentare dell’importo della transazione e del rischio regolamentare, il livello di orchestrazione del processo indirizza il caso a un analista umano prima di intraprendere qualsiasi azione. Il confine non è fisso. Lo definisce il business, lo codifica il flusso di lavoro e lo fa rispettare il livello di processo, non il modello stesso.

Dal lato esplicitamente umano, pongo la linea di demarcazione sulle decisioni con rilevanti conseguenze architetturali, rischio strategico per il business o significativa responsabilità normativa. Scegliere il modello di architettura fondamentale, selezionare il fornitore tecnologico strategico, progettare il modello di governance per un sistema di IA agentica: queste rimangono decisioni umane. Procedere più velocemente non compensa le conseguenze degli errori in queste scelte.

Perché l’IA non mantiene le promesse in tre aree principali

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

La prima è l’integrazione dei dati aziendali. Si pensava che l’IA avrebbe semplificato enormemente il collegamento tra sistemi eterogenei: mappatura degli schemi, applicazione della qualità dei dati, logica di trasformazione e governance su ambienti ibridi complessi. In pratica, l’IA assiste in questi compiti ma non li risolve. Un modello non può "ragionare" al di là della debolezza architetturale sottostante, dei sistemi legacy con modelli dati non documentati, della semantica incoerente tra le business unit, dei metadati mancanti e della frammentazione della proprietà dei dati. Gli ingegneri devono ancora svolgere il lavoro difficile.

La seconda riguarda l’IA agentica in flussi di lavoro aziendali complessi e multi-step. Le demo sono convincenti. In produzione, però, gli agenti falliscono in modo imprevedibile quando si imbattono in casi limite non coperti dai dati di addestramento, quando la finestra di contesto manca di sufficiente stato corrente o quando il livello di processo non intercetta e gestisce correttamente gli errori degli agenti. Il divario tra ciò che un agente può fare in un ambiente controllato e ciò che possiamo fidarci di lasciargli fare in autonomia in un flusso di lavoro regolamentato è ancora significativo.

La terza è il processo decisionale architetturale. Gli strumenti di IA hanno realmente accelerato la codifica di routine, la scrittura di test e la documentazione. Ma non migliorano in modo affidabile le decisioni relative all’architettura di base. I modelli riflettono schemi del passato. L’architettura aziendale richiede invece un giudizio sulle future limitazioni, traiettorie regolamentari e scelte tecnologiche che i modelli non possono compiere in modo adeguato. I team che fanno troppo affidamento sull’IA nelle decisioni architetturali tendono a produrre sistemi coerenti localmente ma fragili su scala generale.

Il filo conduttore nelle tre aree è questo: l’IA funziona quando il problema è ben delimitato, i dati sono puliti e attuali, e una persona competente nel settore è coinvolta. Non mantiene le promesse ovunque il problema richieda giudizio contestuale, cambiamento organizzativo, o pensiero architetturale che va oltre la semplice rilevazione di schemi nei dati storici.

Come l’IA fatica con sicurezza e scalabilità nel codice

La difficoltà più costante che vedo è al confine tra codice generato dall’IA e giudizio d’ingegneria di livello produttivo.

Gli strumenti di generazione di codice tramite IA sono davvero utili per compiti ben definiti e ripetitivi: boilerplate, casi di test, documentazione e trasformazioni dirette. I problemi emergono quando i team estendono questa fiducia a decisioni architetturali, codici sensibili alla sicurezza o componenti critici per la scalabilità senza una rigorosa revisione umana.

Dal lato della sicurezza, il codice generato dall’IA spesso introduce vulnerabilità sottili che superano la scansione automatica ma falliscono in condizioni avverse. L’iniezione di prompt è l’esempio più chiaro attualmente nei sistemi IA agentici. Un agente che genera o esegue codice sulla base degli input dell’utente senza una corretta validazione e sandboxing crea superfici d’attacco difficili da individuare e da rilevare ex post. Ho visto questo schema emergere nelle prime implementazioni di IA agentica, dove i team puntavano su capacità e velocità, trattando la revisione della sicurezza come un passaggio successivo.

Dal lato della scalabilità, gli strumenti di IA tendono a generare soluzioni che funzionano correttamente su piccola scala, ma presentano ipotesi nascoste su volume dei dati, concorrenza o latenza che emergono solo sotto carico produttivo. Un consumatore Kafka generato che funziona bene nei 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 del controllo della pressione. Il modello non conosce il tuo ambiente di produzione. Conosce i pattern dei dati di addestramento.

La risposta pratica non è smettere di usare l’IA per la generazione di codice. È trattare il codice creato dall’IA come quello di un bravo ma giovane sviluppatore che non conosce il tuo sistema di produzione. Devi revisionarlo. Devi testarlo in condizioni realistiche. E non lasciarlo mai nei percorsi critici per la sicurezza o la scalabilità senza l’approvazione di un ingegnere senior.

Cosa devono fare ora i leader tecnologici

Le riflessioni di Kai

Investi nella tua base dati prima di puntare all’IA…tratta la governance dell’IA come un problema architetturale, non di policy…pensa in entrambe le direzioni simultaneamente.

Ecco tre consigli, nell’ordine in cui contano:

Per prima cosa, investi nella tua base dati prima di puntare all’IA. Le organizzazioni che ottengono risultati concreti grazie all’IA non sono quelle che hanno adottato per prime un nuovo modello. Avevano già dati puliti, in tempo reale e governati che scorrevano nei loro sistemi prima che iniziasse la conversazione sull’IA. Se i tuoi dati sono isolati, obsoleti, o senza governance, aggiusta quello per prima cosa. Nessun modello può compensare dati scadenti su larga scala.

Secondo, tratta la governance dell’IA come un problema architetturale, non di policy. Scrivere linee guida per l’utilizzo responsabile dell’IA è necessario, ma non sufficiente. È il livello di processo che governa realmente 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 limiti a prescindere da ciò che raccomanda il modello. Costruisci questi elementi nell’architettura fin dall’inizio. Adattare la governance dopo il deployment è costoso, inaffidabile e di solito viene fatto solo dopo che c’è stato un problema.

Terzo, pensa in entrambe le direzioni simultaneamente. La pressione dal basso per mettere rapidamente in produzione casi d’uso IA è reale e legittima. Lo è anche l’esigenza di una visione architetturale dall’alto che eviti di creare soluzioni frammentate che impiegherai anni a districare. I CTO che vedo destreggiarsi meglio sanno reggere entrambe le pressioni: procedono rapidamente sui casi d’uso specifici mantenendo allo stesso tempo una chiara direzione architettonica che rende i casi d’uso componibili e governabili nel tempo.

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

Segui gli aggiornamenti

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

Presto nuove interviste con esperti su The CTO Club!