Warum KI an den Stammdaten scheitert
Eva Mickler
4 Min. Lesezeit KI-Budgets fließen ins Modell, der Return bleibt aus. Der Grund liegt in der Datenbasis: ...
Zum Beitrag
5 Min. Lesezeit
Hyperscaler bauen weiter. Analysten und Earnings-Calls beschreiben aber ein flacheres Wachstumstempo der Investitionsausgaben. Für mehrjährige AI-Cloud-Verträge zählt das Szenario im Commitment: was passiert, wenn Kapazität, Preis oder Exit nicht mehr zur Leitungsentscheidung passen.
Das Wichtigste in Kürze
- Lage: Absolute Capex-Niveaus der Hyperscaler bleiben hoch. Das Wachstumstempo flacht in mehreren Szenarien ab – Verträge mit 3 bis 5 Jahren Laufzeit spüren das früher als Quartalsfolien.
- Hebel: Commitment-Staffelung, Exit-Fenster und Reserved Capacity gehören in denselben Vertrag wie der Rabatt – mit On-Prem-Inference als Szenario-Schalter.
- Erster Schritt: Drei Szenarien (Hochlauf, Plateau, Abflachung) mit denselben KPIs durchrechnen – bevor der nächste Rahmenvertrag unterschrieben wird.
VerwandtHardware schlägt Software-Deals – Capex neu sortieren / Token-OPEX: Inference steuert, nicht das Seat-Budget
AI-Cloud-Vertrag meint hier die mehrjährige Vereinbarung über Rechenkapazität, Modelle oder Inference-Leistung: Volumen, Preis, Reserved Capacity und Ausstieg. Sie bindet Budget an ein Nutzungsszenario und braucht deshalb Staffelungen, Re-Opener, Portabilität und Exit-Kosten über mehrere Betriebsjahre.
Die öffentliche Debatte hängt am Aktienkurs und an einzelnen Earnings-Wochen. Im Einkauf zählt etwas anderes: mehrjährige Commitments für Cloud- und AI-Kapazität. Wer 2027 und 2028 absichert, kauft in eine Welt, in der die Investitionsausgaben der Hyperscaler absolut weiter hoch liegen können – während das Wachstumstempo der Capex-Kurve in mehreren Markt-Szenarien abflacht.
Das ist kein Widerspruch. Es ist der Unterschied zwischen Niveau und Steigung. Ein Vertrag, der nur den heutigen Rabatt maximiert, ignoriert die Steigung. Ein Vertrag, der nur die Steigung fürchtet, verschenkt Kapazität. Brauchbar ist eine Szenario-Matrix, die beide Dimensionen in Klauseln übersetzt.
Niveau bleibt. Die Steigung ändert die Verhandlung.
Absolute Capex-Niveaus der großen Cloud- und AI-Infrastrukturanbieter liegen weiter in einer Größenordnung, die Region-Kapazität, GPU-Verfügbarkeit und Enterprise-Discount-Spielraum prägt. Gleichzeitig beschreiben Analysten-Pfade und Earnings-Guidance häufiger eine Abflachung des Wachstumstempos – nicht den Stopp des Ausbaus.
Für den DACH-Einkauf folgt daraus keine Panik und kein Blankoscheck. Es folgt eine Planungsfrage: Welches Tempo steckt im internen AI-TCO-Modell? Wer linearen Hochlauf einpreist und ein Plateau bekommt, sitzt auf Commitments ohne Nutzung. Wer ein Plateau einpreist und ein Hochlauf-Szenario bekommt, steht ohne Kapazität da – und zahlt Spot-Preise.
Entscheidungseinheit
Die Einheit heißt Commitment pro Szenario. Plus Exit pro Jahr und die Grenze, ab der Inference intern günstiger und steuerbarer wird als die API-Default-Route.
Token- und Runtime-Kosten (siehe verwandter Beitrag zu Token-OPEX) bleiben die variable Schicht. Capex-Tempo der Anbieter steuert die Schicht darunter: wie teuer und wie knapp die physische und vertragliche Kapazität wird, auf der Inference läuft. Beide Schichten gehören in dieselbe Entscheidungsvorlage – getrennt gemessen, gemeinsam verhandelt.
Drei Szenarien, eine Vertragslogik
Statt einer Prognose reichen drei belastbare Szenarien. Jedes braucht dieselben KPIs: genutzte GPU-/TPU-Stunden, Cost-per-Outcome der Kern-Workflows, Anteil Reserved vs. On-Demand, Exit-Kosten und Time-to-Replatform in Monaten.
| Szenario | Was im Markt passiert | Was der Vertrag können muss |
|---|---|---|
| Hochlauf | Capex und Region-Kapazität wachsen weiter stark; Reserved Capacity wird knapper. | Frühe Optionsfenster für zusätzliche Kontingente; Preis-Caps bei Overrun; Multi-Region-Fallback. |
| Plateau | Niveau bleibt hoch, Tempo flacht ab; Rabatte und Verfügbarkeit stabilisieren sich ungleichmäßig. | Staffelung statt Einmal-Commitment; jährliche Re-Openers; klare Definition von „unused commit“. |
| Abflachung | Wachstum bremst spürbar; Anbieter priorisieren Marge und Auslastung bestehender Parks. | Exit ohne Strafautomatik; Portabilität der Workloads; On-Prem-/Private-Inference als verhandelter Pfad. |
Die Szenarien sind Planungsrahmen. Eine Kursprognose sind sie nicht. Zahlen aus Earnings und Research nur als Eingangsannahmen, nie als Wahrheit des Vertrags.
Wer alle drei Szenarien mit denselben KPIs füllt, sieht sofort, wo der geplante Rahmenvertrag nur im Hochlauf trägt. Das ist der Punkt, an dem Einkauf und Architektur dieselbe Sprache brauchen: weniger „mehr Rabatt“ – und mehr „welche Klausel überlebt das Plateau“.
Vier Klauseln, die den Unterschied machen
Rabatte sind sichtbar. Die teuren Fehler sitzen woanders. Vier Klausel-Typen trennen einen verhandelbaren AI-Cloud-Rahmen von einem Hoffnungspapier.
1. Commitment-Staffelung statt Front-Loading. Statt 100 Prozent des Drei-Jahres-Volumens im Jahr eins bindet die Staffelung Tranchen an Nutzungsmilestones. Jede Tranche hat ein Opt-out mit Frist. Das kostet oft etwas Discount. Es spart den teureren Fehler: Commit ohne Workload.
2. Exit und Portabilität mit Messpunkt. Exit ohne Daten- und Modell-Portabilität ist Theater. Der Vertrag nennt Formate, Exportfristen und einen Testlauf pro Jahr. Wer den Testlauf scheut, weiß, dass der Exit nicht existiert.
3. Reserved Capacity mit Verfallsdatum und Umbuchung. Reservierungen ohne Umbuchung auf verwandte Skus und ohne Verfallslogik erzeugen tote Kontingente. Die Umbuchungsregel gehört in den Hauptteil, nicht in ein FAQ des Anbieters.
4. Preis- und Kapazitäts-Trigger. Wenn Region-Kapazität unter eine vereinbarte Schwelle fällt oder der Referenzpreis einer definierten SKU um mehr als X Prozent steigt, öffnet sich ein Re-Opener. X wird intern gesetzt, nicht vom Vendor-Default.
Der günstigste Cloud-Rabatt ist teuer, wenn er ein Szenario voraussetzt, das der eigene AI-Rollout nicht trägt.
Wo On-Prem-Inference den API-Default schlägt
On-Prem oder private Inference ist kein Gegenentwurf zur Cloud. Es ist der Schalter im Abflachungs- und im Hochlauf-Szenario mit knapper Kapazität. Die Entscheidung hängt an drei messbaren Größen: stabiler Workload mit hoher Token-Dichte, vorhersehbare Latenz-Anforderungen und die Fähigkeit, Eval-Suiten und Routing intern zu betreiben.
Wer diese drei Größen nicht messen kann, kauft weiter API-Default – und sollte das ehrlich so nennen. Wer sie messen kann, verhandelt die Cloud-Tranche kleiner und hält einen internen Pfad offen. Make-or-Buy bei Modellen ist dabei die zweite Achse: ein deutsches oder europäisches Modell rechnet sich oft erst, wenn Inference-Kosten und Datenresidenz in dieselbe Rechnung gehören.
Hardware-Capex im eigenen Haus (Server, Kühlung, Stromverträge) verschiebt das Risiko, löscht es nicht. Der verwandte Beitrag zur Hardware-vs-Software-Capex-Sortierung bleibt die Schwester-Diskussion. Hier zählt nur die Schnittstelle: Welche Workloads haben eine belastbare Break-even-Rechnung gegen den Hyperscaler-Pfad – und stehen die im Vertrag als Option, nicht als PowerPoint?
90 Tage bis zur nächsten Unterschrift
Der Test ist simpel: Würde dieselbe Unterschrift auch dann stehen, wenn das Capex-Wachstum der Anbieter 2027 deutlich flacher ausfällt als 2025/26? Wenn die Antwort von einem einzelnen Rabatt abhängt, ist der Vertrag zu dünn.
Häufig gestellte Fragen
Reicht ein Multi-Cloud-Vertrag als Absicherung gegen Capex-Tempo?
Nur wenn Workloads wirklich portabel sind und der zweite Anbieter kapazitativ erreichbar ist. Multi-Cloud ohne Exit-Test und ohne Datenpfad ist Doppel-Commitment. Eine Absicherung ist das nicht.
Sollten Quartalszahlen der Hyperscaler den Vertrag steuern?
Als Eingangsannahme ja, als Steuergröße nein. Der Vertrag steuert über Nutzung, Staffelung und Trigger – nicht über die nächste Earnings-Folie.
Wann lohnt private Inference gegen den API-Default?
Bei stabiler Last, klarer Eval-Suite und messbarem Cost-per-Outcome. Ohne diese drei Größen bleibt der API-Default ehrlicher – und billiger in der Governance.
Was ist der häufigste Fehler in AI-Cloud-Rahmenverträgen?
Front-loaded Commitments ohne Staffelung und ohne jährlichen Portabilitäts-Test. Der Rabatt sieht gut aus. Die ungenutzte Tranche nicht.
Wie hängt das mit Token-OPEX zusammen?
Token-OPEX steuert die variable Nutzungsschicht. Capex-Tempo der Anbieter steuert Verfügbarkeit und Preisdisziplin der darunterliegenden Kapazität. Beide gehören in dieselbe Entscheidungsvorlage.
Weiterlesen auf Digital Chiefs
Digital ChiefsStarre RZ-Verträge treffen fließendes EnEfGDigital ChiefsWann die Cloud der falsche Ort istDigital Chiefs3PL-Schnittstellen fressen die IT-AgendaMehr aus dem MBF Media Netzwerk
cloudmagazinWenn GPUs den SaaS-Etat auffressen mybusinessfutureMake-or-Buy bei KI: selbst bauen oder einkaufen? securitytodayNIS2-Patchwork: Vier Staaten vor dem EuGHBildquelle: KI-generiert (Mai 2026)