L’avviso di forza maggiore di Oracle mette in luce il collo di bottiglia energetico dell’AI

Oracle ha emesso un avviso di forza maggiore dopo che ritardi nella disponibilità di energia hanno minacciato Project Jupiter, il suo previsto campus di data center AI da 2,45 gigawatt in New Mexico. L’avviso di forza maggiore di Oracle non annulla il progetto né dimostra che la sua apertura subirà ritardi. Rivela però un conflitto sempre più ampio tra i contratti per le infrastrutture AI e i sistemi più lenti necessari a fornirne l’elettricità.

Si prevede che Project Jupiter supporti OpenAI attraverso il programma infrastrutturale Stargate. STACK Infrastructure, di proprietà di Blue Owl Capital, sta sviluppando il campus. Oracle rimane il principale locatario e afferma che la costruzione procede secondo il calendario previsto.

L’avviso è rilevante perché Oracle ha collegato impegni finanziari enormi a una capacità che non esiste ancora. OpenAI e altri clienti vogliono maggiore potenza di calcolo, mentre Oracle necessita di edifici completati, apparecchiature energetiche, autorizzazioni, combustibile e infrastrutture di trasmissione prima di poter riconoscere gran parte di questa domanda come ricavi.

Questo crea il rovesciamento centrale. Le aziende AI possono ordinare processori e firmare accordi cloud più rapidamente di quanto gli sviluppatori riescano a garantire una fornitura elettrica affidabile. Il componente più scarso nel piano di espansione di Oracle non è più necessariamente la GPU. È un sito operativo con elettricità sufficiente a far funzionare ininterrottamente migliaia di unità.

Cosa ha effettivamente cambiato l’avviso di forza maggiore di Oracle

Oracle ha riservato una tutela contrattuale contro i ritardi legati all’energia, ma non ha abbandonato Project Jupiter.

Secondo un rapporto sui ritardi energetici pubblicato da Reuters, Oracle ha inviato l’avviso a un’unità di Blue Owl che sviluppa il campus del New Mexico. Il rapporto afferma che l’azione è stata motivata da potenziali ritardi nell’assicurarsi l’energia.

La forza maggiore è una clausola contrattuale che copre circostanze straordinarie al di fuori del ragionevole controllo di una parte. Il suo effetto legale dipende dal contratto, dall’evento scatenante e dal fatto che la parte interessata abbia seguito le procedure richieste.

Un avviso è quindi diverso da un inadempimento accertato. Può preservare diritti contrattuali mentre le parti continuano a lavorare verso il completamento. Può anche avviare una controversia su chi abbia accettato un particolare rischio di sviluppo.

Blue Owl ha dichiarato che l’avviso non ha modificato gli impegni finanziari del progetto. L’azienda ha inoltre affermato che le parti restavano allineate sullo sviluppo pluriennale. Separatamente, Oracle ha sostenuto che Project Jupiter restava nei tempi previsti.

Queste dichiarazioni restringono le conclusioni possibili. Non esistono prove verificate che Oracle abbia cancellato il campus, terminato il proprio rapporto con STACK o ritirato il proprio impegno verso il New Mexico.

La controversia immediata riguarda invece la protezione dai costi qualora problemi energetici ritardino l’occupazione. Le condizioni di locazione riportate indicano che Oracle potrebbe chiedere di rinviare l’inizio del pagamento dell’affitto per tre anni se entrambe le parti riconoscessero un evento di forza maggiore qualificante.

Questo esito non è automatico. Lo sviluppatore dovrebbe accettare la richiesta, oppure le parti dovrebbero risolvere qualsiasi disaccordo attraverso il processo di risoluzione delle controversie previsto dal contratto.

Secondo quanto riferito, Oracle continuerebbe a coprire alcuni costi del progetto durante il differimento. Resterebbe inoltre responsabile dell’affitto per l’intera durata del contratto di locazione una volta avviati i pagamenti. Questi dettagli rendono l’avviso più difensivo che definitivo.

La distinzione è importante per gli investitori e i clienti cloud. Una struttura cancellata segnalerebbe un indebolimento della domanda o una rottura fondamentale del progetto. Un differimento dei pagamenti sposterebbe invece i tempi e l’allocazione del rischio di costruzione.

La scala prevista di Project Jupiter spiega perché tale tempistica sia importante. Secondo il resoconto di Bloomberg, il campus è stato progettato per 2,45 gigawatt di capacità. Un sito di queste dimensioni necessita di un sistema energetico paragonabile a un’infrastruttura al servizio di una grande area metropolitana.

Non può affidarsi a una normale connessione commerciale. Il progetto necessita di generazione dedicata, fornitura di combustibile, apparecchiature elettriche, autorizzazioni locali e sistemi in grado di operare con requisiti rigorosi di disponibilità.

Ciò rende l’energia una dipendenza della costruzione, anziché un acquisto mensile di servizi. Se un componente critico arriva in ritardo, le sale dati completate potrebbero restare incapaci di ospitare apparecchiature di calcolo che generano ricavi.

L’avviso trasforma questa dipendenza fisica in una questione finanziaria. Chi paga mentre un campus AI in gran parte costruito attende energia utilizzabile?

La domanda AI si è mossa più rapidamente dell’infrastruttura energetica

Project Jupiter mostra che la domanda AI contrattualizzata e la capacità di calcolo effettivamente erogabile si muovono ormai secondo tempistiche diverse.

L’arretrato cloud di Oracle suggerisce che l’interesse dei clienti rimanga forte. Il suo documento trimestrale di agosto 2026 riportava 664 miliardi di dollari in obbligazioni di prestazione residue.

Le obbligazioni di prestazione residue rappresentano ricavi contrattualizzati che non sono ancora stati riconosciuti. Non equivalgono a vendite immediatamente incassabili, profitti garantiti o liquidità sul conto bancario di Oracle.

Oracle prevedeva di riconoscere circa il 13% di tale arretrato nei successivi 12 mesi. Un altro 37% era previsto nei mesi dal 13° al 36°, mentre il 34% era programmato nei mesi dal 37° al 60°.

Questa tempistica rende l’esecuzione infrastrutturale centrale nella storia finanziaria dell’azienda. Oracle non può convertire nei tempi previsti un grande contratto cloud in ricavi se non installa le apparecchiature e non rende disponibile la capacità promessa.

Lo stesso documento ha rivelato ulteriori impegni di locazione per 288 miliardi di dollari. La maggior parte riguardava accordi per data center che dovrebbero iniziare tra l’esercizio fiscale 2027 e l’esercizio fiscale 2029, con durate da 15 a 19 anni.

Tali contratti di locazione non erano ancora riflessi nel bilancio di Oracle perché non erano ancora iniziati. La loro scala mostra comunque quanta capacità futura Oracle abbia contrattualizzato prima che i siti sottostanti diventino operativi.

Oracle ha inoltre segnalato 34,2 miliardi di dollari in acquisti incondizionati e altri obblighi di durata superiore a un anno. Questi impegni riguardavano principalmente componenti dell’infrastruttura cloud e accordi energetici per data center.

L’opportunità commerciale dell’azienda è quindi accompagnata da una lunga catena di obblighi fisici. Processori, apparecchiature di rete, edifici, sistemi di raffreddamento, elettricità, finanziamenti e clienti devono diventare disponibili nella sequenza corretta.

L’energia è particolarmente difficile da accelerare. I produttori di chip possono espandere la produzione, anche se questo richiede tempo. Anche i progetti elettrici affrontano pianificazione delle utility, accesso ai terreni, valutazioni ambientali, code per le apparecchiature e partecipazione pubblica.

I dati nazionali mostrano perché queste code stanno diventando affollate. Una stima federale ha collocato il consumo dei data center negli Stati Uniti a 176 terawattora nel 2023.

Il Dipartimento dell’Energia ha previsto un consumo compreso tra 325 e 580 terawattora entro il 2028. Nello scenario superiore, la domanda crescerebbe di oltre tre volte nell’arco di cinque anni.

Questa crescita non si distribuisce uniformemente nel Paese. Un singolo campus hyperscale può creare una domanda concentrata in un’area in cui il sistema esistente non è mai stato progettato per sostenerla.

Le utility devono determinare se nuova generazione e trasmissione possano servire il carico senza indebolire l’affidabilità. Le autorità di regolazione devono decidere chi finanzierà tali potenziamenti e chi sopporterà il rischio se la domanda prevista scomparirà.

Anche le comunità locali vogliono prove che i progetti non aumenteranno le bollette domestiche, consumeranno acqua scarsa o creeranno inquinamento senza offrire i benefici promessi. Tali preoccupazioni possono influenzare i calendari delle autorizzazioni anche quando i responsabili politici nazionali sostengono la costruzione per l’AI.

Questo crea pressione su ogni partecipante. Gli sviluppatori necessitano delle autorizzazioni prima che i finanziatori eroghino capitale. Le utility hanno bisogno di previsioni di carico credibili prima di costruire infrastrutture. Le aziende tecnologiche necessitano di date di completamento certe prima di promettere capacità ai clienti.

Oracle si trova al centro di queste dipendenze. I suoi accordi con i clienti creano urgenza, ma i suoi partner infrastrutturali non possono eliminare le tempistiche normative attraverso un contratto cloud.

Il piano energetico di Project Jupiter continua a cambiare

La ricerca del progetto di elettricità affidabile ha già imposto una significativa riprogettazione tecnica.

Project Jupiter aveva originariamente proposto turbine a gas naturale e generatori diesel di riserva. Oracle ha poi sostituito quel progetto con una microrete a celle a combustibile che utilizza tecnologia di Bloom Energy.

Una microrete è un sistema elettrico locale in grado di alimentare un sito definito. In questo caso, le celle a combustibile convertirebbero il gas naturale in elettricità attraverso un processo elettrochimico anziché mediante combustione convenzionale.

Il piano energetico aggiornato di Oracle affermava che il nuovo progetto avrebbe ridotto le emissioni e l’uso di acqua rispetto alla proposta precedente. Questa è la valutazione di Oracle, non una conclusione indipendente sul campus completato.

La modifica ha affrontato alcune obiezioni legate al precedente piano delle turbine. Non ha eliminato la dipendenza del progetto dall’infrastruttura di combustibile, dall’approvazione normativa o dalla consegna tempestiva delle apparecchiature.

Le celle a combustibile possono fornire generazione in loco senza attendere una connessione alla rete convenzionale dimensionata per l’intero campus. Ciò le rende interessanti per gli sviluppatori AI che affrontano lunghe code presso le utility.

Tuttavia, le celle a combustibile necessitano ancora di una fornitura affidabile di gas naturale. La loro installazione richiede inoltre integrazione elettrica, valutazione della qualità dell’aria, controlli di sicurezza e apparecchiature sufficienti a supportare un carico insolitamente elevato.

Il gasdotto proposto per servire Project Jupiter ha incontrato problemi propri. Il commissario per le terre statali del New Mexico ha respinto autorizzazioni che interessavano un percorso pianificato, aggiungendo incertezza al calendario di consegna del combustibile.

Successivamente, lo sviluppatore del gasdotto ha subito un rinvio della data prevista di entrata in servizio. Questo contrattempo è importante perché il campus non può risolvere un vincolo di rete con generazione in loco se il combustibile non riesce a raggiungere i generatori.

La sequenza illustra un problema infrastrutturale ricorrente. Sostituire un collo di bottiglia spesso crea una dipendenza diversa anziché eliminare il rischio originario.

Una connessione alla rete dipende da utility, capacità di trasmissione e allocazione normativa dei costi. Un sistema di generazione dedicata dipende dalla consegna del combustibile, dalla produzione delle apparecchiature, dai permessi per la qualità dell’aria e dalle approvazioni del sito.

L’approccio a celle a combustibile offre ancora potenziali vantaggi. Unità modulari possono essere installate in fasi, il che potrebbe consentire a Oracle di energizzare sezioni del campus man mano che gli edifici diventano pronti.

L’installazione graduale si allinea inoltre meglio con un’implementazione progressiva dei server. Oracle non avrebbe necessariamente bisogno di tutti i 2,45 gigawatt il primo giorno operativo.

Tuttavia, la costruzione a fasi introduce complessità di pianificazione. Ogni sala dati utilizzabile necessita di generazione adeguata, raffreddamento, rete, sistemi di backup e autorizzazioni di sicurezza prima che i clienti possano distribuire carichi di lavoro di produzione.

Un’apertura parziale sarebbe quindi utile solo se l’energia disponibile corrispondesse alla capacità di calcolo promessa nei contratti di Oracle con i clienti. Le divulgazioni pubbliche non forniscono questo livello di dettaglio.

L’insistenza di Oracle sul fatto che il progetto rimanga nei tempi previsti può riflettere fiducia in percorsi alternativi o fasi costruttive riviste. L’avviso di forza maggiore suggerisce che l’azienda si stia preparando anche a un esito meno favorevole.

Quelle posizioni non sono necessariamente contraddittorie. Un’impresa può aspettarsi un completamento puntuale preservando al tempo stesso i propri diritti contrattuali nel caso in cui una dipendenza esterna venga meno.

Il problema è informativo. Gli investitori non possono verificare in modo indipendente il calendario di costruzione, il percorso critico del gasdotto o le condizioni necessarie perché inizino gli obblighi di pagamento del canone da parte di Oracle.

Questa incertezza rende Project Jupiter una prova di esecuzione, non di domanda. Oracle ha clienti in cerca di capacità. La questione aperta è se il suo piano energetico riuscirà a trasformare edifici e processori in infrastruttura cloud utilizzabile nei tempi previsti.

Il conflitto è tra i contratti AI e la realtà fisica

Il modello di espansione di Oracle presuppone che impegni finanziari a lungo termine possano essere sincronizzati con infrastrutture esposte a ritardi locali.

Il mercato del cloud per l’AI premia le aziende che assicurano capacità in anticipo. Attendere che un sito riceva ogni autorizzazione prima di firmare contratti con i clienti potrebbe lasciare Oracle indietro rispetto a concorrenti più grandi.

Amazon, Microsoft e Google possono distribuire i carichi di lavoro tra vaste regioni cloud e relazioni energetiche già esistenti. Oracle dispone di un’impronta infrastrutturale più ridotta, pur perseguendo alcuni dei maggiori accordi AI del settore.

La strategia di Oracle dipende quindi in larga misura da campus futuri. Questo produce una rapida crescita del backlog dichiarato, ma concentra anche il rischio di esecuzione in progetti che richiedono anni di costruzione.

Project Jupiter rende visibile questa tensione. La domanda dei clienti di Oracle è a valle di OpenAI e di altri sviluppatori di modelli. I suoi obblighi di locazione sono a monte, verso sviluppatori, finanziatori, utility e fornitori di apparecchiature.

Se il campus apre nei tempi previsti, la struttura può funzionare bene. Oracle incassa ricavi dal computing, mentre i partner infrastrutturali raccolgono pagamenti contrattualizzati lungo periodi di locazione estesi.

Se l’energia arriva tardi, ricavi e costi di occupazione possono disallinearsi. Oracle potrebbe dover effettuare pagamenti prima di disporre di capacità utilizzabile, mentre sviluppatori e finanziatori continuano ad aspettarsi rendimenti sul capitale impegnato.

La comunicazione di force majeure di Oracle sembra concepita per limitare questo disallineamento. Offre all’azienda una base per sostenere che ritardi eccezionali nell’energia dovrebbero posticipare alcuni pagamenti.

Gli sviluppatori vedono il rischio in modo diverso. Finanziano la costruzione anche perché un grande locatario tecnologico ha accettato un impegno di lunga durata. Se quel locatario può ritardare i pagamenti, i fornitori di capitale sopportano un rischio maggiore legato al calendario.

Ecco perché Blue Owl ha sottolineato che gli impegni finanziari del progetto non erano cambiati. La dichiarazione rassicura finanziatori e investitori senza risolvere il modo in cui opererebbe la clausola di force majeure.

La questione è più ampia di un singolo contratto di locazione. Il finanziamento delle infrastrutture AI utilizza sempre più spesso progetti a finalità specifica sostenuti da contratti a lungo termine con aziende tecnologiche.

Questi contratti aiutano gli sviluppatori a raccogliere capitali senza caricare ogni costo di costruzione sul bilancio di un provider cloud. Creano anche dipendenze tra clienti, locatari, sviluppatori, fondi di credito privato, utility e fornitori di energia.

Un ritardo può propagarsi lungo questa catena. Il locatario rinvia l’occupazione, lo sviluppatore attende il canone e i finanziatori rivalutano il valore del debito del progetto.

La reazione del mercato ha riflesso questa preoccupazione. Le azioni di Oracle e Blue Owl sono entrambe scese dopo le notizie sulla comunicazione, anche se una singola seduta di negoziazione non può stabilire l’economia di lungo periodo del progetto.

La lettura scettica è che Oracle stia trattando una sfida energetica prevedibile come un evento straordinario. I grandi data center hanno ovviamente bisogno di energia, e le autorizzazioni del New Mexico hanno sempre fatto parte del processo di sviluppo.

Da questa prospettiva, la disponibilità di energia rientra nel normale rischio di costruzione. Definirla force majeure indebolirebbe la certezza che rende possibile il finanziamento di progetti a lungo termine.

La tesi opposta è che specifici dinieghi di autorizzazioni o azioni governative possano qualificarsi anche se la categoria generale di rischio era nota. L’esito legale dipende da un linguaggio contrattuale che non è pubblico.

Nessuna delle due interpretazioni è stata stabilita in modo conclusivo. La comunicazione non dimostra che la pretesa di Oracle avrà successo, e la dichiarazione dell’azienda sul calendario non dimostra che ogni dipendenza sia stata risolta.

La conclusione più prudente è più circoscritta. Oracle ha individuato un’incertezza sufficiente a preservare un rimedio contrattuale, mentre tutte le parti continuano a presentare Project Jupiter come un progetto attivo.

La scarsità di energia sta diventando una competizione nel cloud

I provider cloud competono sempre più per megawatt effettivamente disponibili, non solo per clienti, processori o funzionalità software.

I modelli AI richiedono cluster densi di acceleratori collegati tramite reti ad alta velocità. I lavori di addestramento e i grandi servizi di inferenza possono mantenere tali apparecchiature operative ad alta utilizzazione per periodi prolungati.

Questo modello operativo genera un grande carico elettrico costante. Sistemi di raffreddamento, storage, apparecchiature di rete e infrastrutture di backup si aggiungono al consumo diretto dei server.

Le nuove strutture desiderano inoltre elettricità prima di quanto i progetti convenzionali di generazione e trasmissione riescano a fornirla. La costruzione della rete richiede spesso più tempo dell’allestimento di una sala dati.

Il risultato è un mercato emergente per siti con energia garantita. Un provider cloud con processori disponibili ma senza un edificio alimentato non può vendere la capacità di calcolo di cui i clienti hanno bisogno.

Questo cambia il significato della scala. In passato, l’espansione cloud spesso consisteva nell’aggiungere server in una regione esistente. Gli attuali progetti AI possono richiedere sistemi energetici interamente nuovi, misurati in gigawatt.

Amazon, Microsoft, Google, Meta e Oracle hanno perseguito contratti nucleari, progetti rinnovabili, accordi con la rete e generazione in loco. Ogni approccio bilancia velocità, affidabilità, costi, emissioni ed esposizione normativa.

L’energia dalla rete può offrire una generazione efficiente a livello di sistema, ma le code per la connessione possono essere lunghe. La generazione a gas può arrivare più vicino al carico, ma affronta vincoli legati a gasdotti e ambiente.

Le centrali nucleari forniscono elettricità affidabile a basse emissioni di carbonio, ma richiedono tempi di sviluppo lunghi. La generazione rinnovabile può essere costruita relativamente in fretta, sebbene i grandi cluster AI necessitino anche di stoccaggio o capacità di backup stabile.

Le celle a combustibile occupano un’altra posizione in questo mix. Il loro design modulare supporta l’installazione in loco, ma le grandi installazioni dipendono comunque dal gas naturale e da un’ampia infrastruttura di supporto.

Project Jupiter rappresenta quindi un esperimento più ampio per il settore. Oracle sta cercando di assemblare capacità di calcolo ed energia su una scala che i sistemi locali non sono stati progettati per fornire rapidamente.

I concorrenti dell’azienda affrontano pressioni simili, ma le loro posizioni di partenza differiscono. Gli operatori cloud più grandi dispongono di più regioni, maggiore generazione di cassa e portafogli infrastrutturali più ampi.

Il grande backlog di Oracle le offre un forte incentivo a espandersi rapidamente. I suoi impegni di locazione riducono inoltre il margine per ritardi prolungati su più progetti.

Ecco perché l’avvertimento va oltre gli azionisti Oracle. OpenAI dipende dai partner per fornire l’infrastruttura alla base dei suoi servizi, mentre le imprese dipendono da tali servizi per i carichi di lavoro AI in produzione.

Un campus in ritardo non interrompe immediatamente un’applicazione esistente. Può influire sul momento in cui diventano disponibili ulteriore addestramento dei modelli, capacità di inferenza e risorse cloud aziendali.

I vincoli di capacità possono influenzare decisioni di allocazione e distribuzione prima che i clienti riscontrino un’interruzione. I provider potrebbero dare priorità ai grandi contratti, ritardare nuove regioni o spostare i carichi di lavoro verso sedi più costose.

Gli acquirenti aziendali dovrebbero quindi valutare più dei conteggi di GPU annunciati. La domanda rilevante è se un provider possa fornire capacità continua e alimentata nelle regioni e negli intervalli temporali richiesti da un’implementazione.

Per gli sviluppatori, il problema appare indirettamente attraverso quote, liste d’attesa, prenotazioni di capacità e disponibilità regionale. Questi segnali operativi rivelano più di un rendering di un campus lontano.

I knowledge worker non seguiranno le autorizzazioni dei gasdotti durante il normale utilizzo dell’AI. Potrebbero comunque incontrarne le conseguenze attraverso un’espansione dei prodotti più lenta, funzionalità limitate o costi organizzativi più elevati.

La comunicazione di force majeure di Oracle rende visibile questa catena. La pianificazione energetica è diventata parte dell’affidabilità del prodotto cloud, anche quando l’utente finale non vede mai la fonte di energia.

Tre segnali mostreranno se l’avvertimento di Oracle si diffonde

Le prossime evidenze dovrebbero provenire dal calendario del progetto, dalle informative finanziarie di Oracle e dalle condizioni di finanziamento utilizzate nei nuovi campus AI.

Il primo segnale è il programma del combustibile e dell’energia di Project Jupiter. Oracle necessita di progressi chiari sul gasdotto, sull’installazione delle celle a combustibile e sulle autorizzazioni richieste per un’operatività graduale.

Una data certa di entrata in servizio del gasdotto rafforzerebbe l’affermazione di Oracle secondo cui il campus resta nei tempi previsti. Ulteriori ostacoli nelle autorizzazioni renderebbero il suo avvertimento contrattuale più rilevante.

Il secondo segnale è la tempistica dei contratti di locazione di Oracle e dei rimanenti obblighi di prestazione. Le sue comunicazioni dovrebbero mostrare se gli impegni per i data center iniziano come previsto e se il backlog si trasforma in ricavi.

Gli investitori dovrebbero monitorare i cambiamenti nei contratti di locazione non ancora avviati, negli obblighi di acquisto di energia, nelle spese in conto capitale e nel riconoscimento previsto dei ricavi. Nessuna di queste misure, da sola, confermerà lo stato di Project Jupiter.

Insieme, possono mostrare se l’infrastruttura sta recuperando rispetto alla domanda contrattualizzata. Un backlog in crescita accompagnato da ripetuti ritardi di capacità amplierebbe il divario tra promesse commerciali e consegna fisica.

Il terzo segnale è il modo in cui sviluppatori e finanziatori prezzano il rischio di calendario nei progetti successivi. Nuovi contratti potrebbero assegnare più esplicitamente la responsabilità dell’energia o richiedere garanzie maggiori ai locatari tecnologici.

Questa risposta indicherebbe che Project Jupiter ha cambiato le pratiche di finanziamento anche se il campus alla fine aprisse nei tempi previsti. Aumenterebbe inoltre il costo di spostare l’infrastruttura fuori dal bilancio di un provider cloud.

Al contrario, condizioni di finanziamento immutate e una domanda continua da parte dei finanziatori suggerirebbero che il mercato considera la comunicazione una precauzione specifica del progetto.

I lettori dovrebbero resistere alla tentazione di trattare ogni comunicazione di force majeure come prova di un crollo dell’AI. Ritardi nei progetti possono verificarsi durante un ciclo di espansione duraturo, soprattutto quando la costruzione raggiunge una scala poco familiare.

Dovrebbero anche evitare di liquidare la comunicazione come semplice formalità legale. Oracle ha centinaia di miliardi in backlog e impegni futuri di locazione legati a infrastrutture che devono ricevere energia affidabile.

Il test essenziale è la conversione. Oracle deve trasformare i contratti in capacità alimentata, quindi trasformare quella capacità in ricavi cloud riconosciuti.

Project Jupiter resta in fase di sviluppo e Oracle afferma che il suo calendario è invariato. Blue Owl afferma che gli impegni finanziari restano in vigore.

Resta irrisolto se il sistema energetico arriverà quando i contratti di computing lo richiederanno. La comunicazione di force majeure di Oracle è il segnale più chiaro che questa tempistica non può più essere data per scontata.

Nei prossimi mesi, osservate il calendario del gasdotto, le autorizzazioni per le celle a combustibile e le informative sulle locazioni di Oracle. Questi segnali mostreranno se Project Jupiter sta superando un ritardo locale o sta esponendo una debolezza ripetibile nella costruzione AI. Per gli acquirenti aziendali, la risposta pratica è mettere in discussione le date di consegna, la capacità regionale e i piani di emergenza prima di dipendere da un’infrastruttura promessa. Per gli investitori, il backlog dovrebbe essere valutato accanto all’accesso all’energia e all’avvio delle locazioni, non isolatamente. L’espansione dell’AI ha ancora clienti, capitale e processori. Il suo prossimo vincolo è se i progetti energetici e le autorizzazioni pubbliche riescano a eguagliare la velocità di tali impegni.