Oracle sichert sich gegen Verzögerungen ab
Oracle hat dem Entwickler von Project Jupiter in New Mexico eine Force-Majeure-Mitteilung übermittelt. Empfänger ist eine Einheit von Blue Owl Capital. Eine solche Mitteilung beruft sich auf höhere Gewalt, also Ereignisse außerhalb der vertraglichen Kontrolle einer Partei.
Nach aktuellem Stand plant Oracle keinen Ausstieg als Hauptmieter. Die Mitteilung soll dem Unternehmen vielmehr ermöglichen, Zahlungen aufzuschieben, falls der Rechenzentrumscampus nicht wie vorgesehen 2028 in Betrieb geht. Ob Oracle dieses Recht tatsächlich nutzen wird, ist offen.
„Project Jupiter bleibt in unserem geplanten Zeitplan. Wir bekennen uns voll und ganz zu New Mexico und sind zuversichtlich, was den weiteren Weg angeht“, erklärte Oracle, sinngemäß aus dem Englischen übersetzt.
Blue Owl Capital betont ebenfalls, dass sich die finanziellen Verpflichtungen für das mehrjährige Projekt durch die Mitteilung nicht ändern. Zwischen der offiziellen Zeitplanung und den bereits bekannten Problemen bei der Energieversorgung besteht dennoch eine erkennbare Spannung.
Gaspipeline verzögert sich um fast sechs Monate
Project Jupiter soll eine Gesamtleistung von 2,45 Gigawatt erreichen. Die Energieversorgung basiert auf gasbetriebenen Brennstoffzellen von Bloom Energy. Damit wird eine verlässliche Gasversorgung zu einer zentralen Voraussetzung für den Betrieb.
Die dafür vorgesehene Pipeline von Energy Transfer hat sich um fast sechs Monate verzögert. Nachdem Behörden Genehmigungen mehrfach verweigert hatten, musste die geplante Trasse geändert werden. Als neues Fertigstellungsdatum gilt der 1. Februar 2027.
| Kennzahl | Stand |
|---|---|
| Geplante Gesamtleistung | 2,45 Gigawatt |
| Ziel für die Inbetriebnahme | 2028 |
| Neuer Termin für die Gaspipeline | 1. Februar 2027 |
| Frist für die Luftqualitätsgenehmigung | 23. November |
Zusätzlich steht eine Genehmigung zur Luftreinhaltung für das Brennstoffzellensystem aus. Das Umweltministerium des Bundesstaates muss darüber bis zum 23. November entscheiden. Ob die Genehmigung erteilt oder verweigert wird, ist bislang nicht bestätigt.
Stargate trifft auf physische Grenzen
Project Jupiter gehört zu den Flaggschiff-Standorten von Stargate, der KI-Infrastrukturinitiative von Oracle, OpenAI und SoftBank. Das Vorhaben stößt vor Ort auf Widerstand von Anwohnern und Umweltgruppen. Inzwischen ist der Campus auch zu einem politischen Streitpunkt geworden.
Der Fall zeigt, dass KI-Infrastruktur nicht allein von verfügbaren Chips und Investitionskapital abhängt. Leitungen, Kraftwerke, Umweltauflagen und lokale Akzeptanz können Zeitpläne ebenso stark beeinflussen. Ähnliche Konflikte führen bereits andernorts zu strengeren Regeln für Rechenzentren.
Auch neue Ansätze zur flexibleren Nutzung vorhandener Energie ändern nichts am grundsätzlichen Engpass. Projekte wie die geplante Erschließung zusätzlicher Netzkapazität für Rechenzentren unterstreichen, wie zentral die Energiefrage für den weiteren KI-Ausbau geworden ist.
Was das für Unternehmen im DACH-Raum bedeutet
Ein direkter Bezug zum DACH-Markt besteht nicht. Verzögerungen bei großen US-Standorten können jedoch mittelbar die globale Verfügbarkeit von Cloud-Kapazitäten beeinflussen. Bei knappen Ressourcen sind auch Auswirkungen auf Preise und Bereitstellungszeiten denkbar, konkrete Folgen für OpenAI-Dienste innerhalb von Stargate sind derzeit aber nicht belegt.
Für IT-Verantwortliche liegt das strategische Risiko in der starken Abhängigkeit von wenigen Großanbietern und deren zentralen Ausbauprojekten. Wer sämtliche KI-Workloads an eine einzelne Cloud bindet, übernimmt neben Preis- und Vertragsrisiken auch die infrastrukturellen Risiken des Anbieters.
Kleinere, energieeffiziente Open-Source-Modelle auf eigener oder lokaler Infrastruktur können diese Abhängigkeit reduzieren. Sie ersetzen große Cloud-Modelle nicht in jedem Anwendungsfall, schaffen aber eine belastbare Alternative für klar abgegrenzte Aufgaben. Entscheidend sind dabei nicht nur Modellqualität und Betriebskosten, sondern auch Datenschutz, Wartungsaufwand und die verfügbare Rechenleistung.