Connect with us

Leader di pensiero

La prossima crisi dell’AI non sarà un fallimento del modello. Sarà una crisi dei sistemi.

mm
A wide, clean photograph inside a modern data center aisle with rows of server racks under cool blue lighting. On the right, blue neon energy light trails emanate from a server, representing flowing data and scalable AI infrastructure.

L’AI e l’AI agente sono stati termini chiave nel settore aziendale negli ultimi anni, e la quantità di investimenti e il ritmo del mercato sono un indicatore chiave delle crescenti aspettative sull’AI. Solo nel primo semestre del 2026, sono stati investiti miliardi di dollari in aziende di AI, tra cui OpenAI e CoreWeave, segnalando come l’AI continuerà ad essere una priorità in tutto il settore aziendale negli anni a venire.

Questi investimenti in aumento sembrano essere mirati a scalare l’AI dalla fase sperimentale alla fase di produzione. In effetti, il recente rapporto di Cockroach Labs – The State of AI Infrastructure 2026 ha mostrato che il 98% degli esecutivi tecnologici a livello globale ha segnalato almeno un progetto di AI passato dalla fase di pilotaggio alla produzione nell’ultimo anno, nella speranza di generare un reale ROI. Tuttavia, mentre le organizzazioni continuano a spostarsi nella fase di produzione, una domanda si profila in modo inquietante: l’infrastruttura può supportare la domanda e il ritmo al quale questi progetti di AI stanno scalando?

Perché l’infrastruttura attuale non si adatta alle richieste dell’AI

I carichi di lavoro dell’AI introducono nuove sfide in tutto il settore che non sono mai state affrontate in precedenza. In particolare: i rivenditori si aspettano un aumento del traffico sui loro siti durante gli eventi di Black Friday e Cyber Monday, proprio come le società di scommesse sportive sanno che la domenica del Super Bowl porterà un aumento di traffico sui loro siti. Tuttavia, questi aumenti derivano tutte da attività umana che consente pause nell’utilizzo e non sono in esecuzione costante.

I sistemi legacy che molte aziende stanno utilizzando per costruire i loro progetti di AI sono stati costruiti per il traffico umano con clic, pause e orari di punta. Gli agenti dell’AI non operano in questo modo; funzionano a velocità di macchina 24 ore al giorno, 7 giorni alla settimana. Con l’emergere di carichi di lavoro autonomi e guidati da macchine, le architetture stanno raggiungendo i limiti che non erano state progettate per gestire inizialmente. E, se i rivenditori e i siti di scommesse sono già sovraccarichi con l’attività umana, non sono assolutamente preparati a tenere il passo con gli agenti dell’AI in esecuzione continua.

Attualmente, le organizzazioni sperimentano già una media di 86 interruzioni di servizio all’anno. Inoltre, l’83% ritiene che la propria infrastruttura di dati fallirà a causa del peso dell’AI nel prossimo anno, con il 34% che non si aspetta che duri più di 11 mesi. E la domanda di AI sta accelerando. La modernizzazione non è più un’opzione gradita, è una necessità.

Le poste in gioco per lasciare l’infrastruttura così com’è

Mentre la maggior parte delle organizzazioni è consapevole delle richieste di infrastruttura che l’AI richiede per funzionare correttamente, la maggior parte rimane impreparata a effettuare i necessari cambiamenti per prevenire i fallimenti del sistema. Quasi due terzi (63%) dei leader tecnologici affermano che i loro team sottovalutano quanto rapidamente le richieste di AI supereranno l’infrastruttura di dati esistente, dimostrando che mentre si sta facendo progresso nella distribuzione dell’AI, non si sta facendo nulla per prevenire il disastro. Mentre gli aggiornamenti del sistema e le ristrutturazioni possono sembrare un investimento a lungo termine e costoso, il costo del tempo di inattività dell’AI è ancora più significativo.

Attualmente, più della metà (57%) delle organizzazioni stima che anche solo un’ora di tempo di inattività dell’AI costerebbe 100.000 dollari o più, e più grande è l’organizzazione, più alto è il costo. Anche se le operazioni sono in esecuzione il 99,9% del tempo, quei 0,1% si traducono in 9 ore di tempo di inattività all’anno in cui si può perdere 100.000 dollari o più all’ora; entrate perse che la maggior parte non ha budgetizzato. Per i carichi di lavoro stagionali e i picchi estremi (pensiamo a Black Friday e Super Bowl Sunday), le organizzazioni rischiano perdite che definiscono l’attività. Non solo la perdita finanziaria si profila con il tempo di inattività dell’AI, ma le aziende rischiano di perdere la fiducia dei consumatori. La fiducia è già fragile quando si tratta di interruzioni, con il 50% degli acquirenti online che probabilmente passerà a un’altra marca se si verifica un’interruzione o un errore di checkout. Le poste in gioco per il mantenimento delle operazioni online sono alle stelle.

Conseguire la resilienza operativa con architetture distribuite

Quando si tratta di ridisegnare l’infrastruttura per supportare le intense richieste dei carichi di lavoro dell’AI, la resilienza operativa deve essere al centro della strategia. Con la scalabilità dell’infrastruttura dell’AI (55%), l’esplorazione di nuovi casi d’uso (51%) e il rafforzamento della resilienza (51%) emergenti come strategie principali per contrastare il peso della scala dell’AI, partire dalle fondamenta per offrire la resilienza operativa è fondamentale. Rendersi conto di ciò può essere realizzato tenendo presenti le fondamenta pronte per l’AI, i costi, la scala e la resilienza e questo è dove le architetture dei database distribuiti entrano in gioco.

I leader tecnologici citano l’incorporazione di un’ingestione ad alto throughput (50%), una migliore osservabilità per il controllo dei costi (48%) e una scala elastica per adattarsi ai carichi di lavoro dell’AI imprevedibili (47%) come principali esigenze per il successo. Con la loro capacità di scalare in modo fluido, i database SQL distribuiti danno alle aziende la scalabilità elastica necessaria per evolversi insieme ai carichi di lavoro dell’AI, oltre a recuperare da fallimenti senza intervento manuale.

Come per tutte le migrazioni, migrare da sistemi legacy a sistemi moderni richiede tempo. In media, passare ad architetture distribuite richiede circa 10 mesi e costa circa 200.000 dollari. Le aziende che effettuano il passaggio trovano risparmi fino a 700.000 dollari solo nel primo anno. Con un forte ROI già nel primo anno, gli investimenti in fondamenta modernizzate permetteranno ai massicci investimenti in AI di pagare nel lungo termine senza preoccuparsi dei rischi di scala o di tempo di inattività.

Incontrare la domanda dell’AI prima che sia troppo tardi

La resilienza è stata la sfida più difficile e pressante nelle applicazioni di infrastruttura e ora è il momento di affrontare i problemi prima che i sistemi collassino, portando con sé il ROI dei progetti di AI. L’AI agente sta accelerando tutto nel settore, dalle potenziali entrate alle aspettative dei clienti e ai carichi di lavoro. Nell’accelerazione, l’AI sta anche esponendo la fragilità architettonica e la bassa fiducia dei leader tecnologici nell’infrastruttura necessaria per supportare i carichi di lavoro in aumento.

Mentre ci spostiamo nel prossimo era dei carichi di lavoro dell’AI, i leader passeranno dal chiedersi quanto rapidamente l’AI possa essere adottata a chiedersi se la propria infrastruttura sopravvivrà quando l’AI raggiungerà la piena scala. Rendendo conto dei problemi infrastrutturali di base e adottando database che supportano la scala, la flessibilità e la coerenza necessarie per mantenere i sistemi dell’AI a galla, i leader saranno pronti ad affrontare l’AI nel 2026 e oltre.

Rob Reid è un Technical Evangelist presso Cockroach Labs, dove aiuta gli sviluppatori e le organizzazioni a costruire applicazioni resilienti e scalabili utilizzando SQL distribuito. Un ingegnere software esperto con sede a Londra, Rob ha lavorato in diversi settori, tra cui finanza, retail, telecomunicazioni e scommesse sportive, sviluppando sistemi backend, frontend e di messaggistica. È l'autore di Practical CockroachDB e CockroachDB: The Definitive Guide, e è un frequentatore, scrittore e educatore su argomenti come sistemi distribuiti, architettura multi-regione e resilienza delle applicazioni.