Leader di pensiero

La prossima crisi dell’AI non sarà un fallimento del modello. Sarà un problema di sistema.

mm
Aggiungi Unite.AI alle tue fonti preferite su Google
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 nell’impresa negli ultimi anni e la quantità di investimenti e il ritmo del mercato sono un indicatore chiave delle crescenti aspettative sull’AI. All’inizio 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 l’impresa negli anni a venire.

Gli 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 globali ha segnalato almeno un progetto di AI che si è spostato dalla fase di prova 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 minacciosamente: può l’infrastruttura supportare la domanda e il tasso al quale questi progetti di AI stanno scalando?

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

I carichi di lavoro dell’AI introducono nuove sfide in tutta l’impresa 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 del traffico sui loro siti. Tuttavia, queste ondate di traffico 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 alla velocità della macchina 24 ore al giorno, 7 giorni a settimana. Con l’emergere di carichi di lavoro autonomi e guidati dalle macchine, le architetture stanno raggiungendo i limiti che non erano state progettate per gestire inizialmente. E, se i rivenditori e le società di scommesse sportive sono già sovraccarichi con l’attività umana, non sono assolutamente preparati a tenere il passo con gli agenti dell’AI che operano costantemente.

Attualmente, le organizzazioni sperimentano in media 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 senza problemi, la maggior parte rimane impreparata a effettuare i cambiamenti necessari 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 progressi nella distribuzione dell’AI, non si sta facendo nulla per prevenire il disastro. Mentre gli aggiornamenti del sistema e le ristrutturazioni potrebbero sembrare un investimento a lungo termine e costoso, il costo del downtime dell’AI è ancora più significativo.

Attualmente, oltre la metà (57%) delle organizzazioni stima che anche solo un’ora di downtime dell’AI costerebbe 100.000 dollari o più, e più grande è l’organizzazione, più grande è il costo. Anche se le operazioni sono in esecuzione il 99,9% del tempo, quei 0,1% si traducono in 9 ore di downtime all’anno in cui si possono 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 downtime dell’AI, ma le aziende affrontano anche la perdita della 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. Trasformare questo in realtà può essere ottenuto mantenendo le fondamenta pronte per l’AI, il costo, la scala e la resilienza in cima alla mente 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 offrono alle imprese la scalabilità elastica necessaria per evolversi insieme ai carichi di lavoro dell’AI, oltre a recuperare dai fallimenti senza intervento manuale.

Come per tutte le migrazioni, migrare da sistemi legacy a sistemi moderni richiede tempo. In media, passare alle 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 nel primo anno. Con un forte ROI in solo un anno, gli investimenti nelle fondamenta modernizzate consentiranno ai massicci investimenti in AI di ripagare nel lungo termine senza preoccuparsi della scala o dei rischi di downtime.

Rispondere alla 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 nell’impresa, dal potenziale ricavo 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.

Man mano che ci spostiamo nella prossima era dei carichi di lavoro dell’AI, i leader passeranno dall’interrogarsi su quanto rapidamente l’AI possa essere adottata a chiedersi se la loro infrastruttura sopravvivrà quando l’AI raggiungerà la piena scala. Risolvendo i problemi infrastrutturali sottostanti 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 vari 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.