Der Großteil des KI‑ROIs geht in der Infrastruktur verloren, nicht im Modell

Die Vorteile von KI schlagen sich selten in der Gewinn- und Verlustrechnung nieder – doch Grund hierfür ist meistens die Architektur, nicht das Modell. Teams überführen ein erfolgreiches Pilotprojekt in die Produktion und müssen dann zusehen, wie der ROI verloren geht – durch Latenz, unkontrollierbare Rechenleistung und Sicherheitsvorfälle, die niemand im Budget eingeplant hat. Das Modell liefert zwar die gewünschte Leistung, doch die zugrunde liegende Infrastruktur wurde nie darauf ausgelegt, die entsprechende Workload in der Produktion auszuführen.

Akamai hat zwei Studien in Auftrag gegeben, um zu prüfen, wo genau die Probleme liegen. Im Rahmen der Studie Der aktuelle Stand der KI‑Inferenz 2026 wurden 200 Experten befragt, die Inferenz in der Produktion ausführen – drei Viertel von ihnen sind Techniker und Architekten und die meisten sind Entscheidungsträger im Bereich der Bereitstellung. Und für die API‑Sicherheitsstudie 2026 wurden 1.840 Sicherheitsexperten aus sechs Branchen und 10 Ländern befragt. 

Die beiden Berichte kommen zu einem gemeinsamen Schluss: Die meisten Teams skalieren mit einer Infrastruktur, die nur für das Training entwickelt wurde und nun durch die zusätzliche Inferenz überlastet wird – und diese fehlenden Ressourcen schlagen sich in Kosten, Latenz und Sicherheitsrisiken nieder.

Doch dieses Problem lässt sich lösen, indem drei Aspekte kombiniert werden: 

1. Eine Architektur, die sich an Live-Bedingungen anpasst 

2. Sicherheit, die fest in diese Architektur integriert ist, anstatt nachträglich hinzugefügt zu werden 

3. Inferenz, die nah genug an Nutzern erfolgt, um Echtzeitziele zu erreichen 

Keines dieser Elemente ist für sich genommen neu. Das Problem besteht darin, dass sie als separate Projekte behandelt werden, die von unterschiedlichen Teams betreut werden.

Beginnen wir mit der grundlegenden Anatomie: Die Inferenz ist der Live-Schritt, bei dem ein trainiertes Modell eine neue Eingabe erhält und eine Ausgabe zurückgibt. Jeder Inferenzaufruf erfolgt als API‑Aufruf, weshalb Modell und API nicht getrennt betrachtet werden dürfen. Sie teilen sich denselben Anfragepfad, dieselben Probleme und dieselbe Angriffsfläche. Das ist der rote Faden, der beide Umfragen verbindet.

Zentrale Inferenz ist nicht generell zum Scheitern verurteilt: Für Training, Batch-Jobs und latenztolerante Workloads ist es oft die beste Option, die Rechenleistung auf wenige, große Regionen zu konzentrieren – und Akamai führt zahlreiche Workloads auf diese Weise aus. Die Geschichte, die unsere Studiendaten erzählen, ist spezifischer: Zentralisierung versagt bei einer bestimmten, wachsenden Klasse von Workloads – und viele Teams haben ihre Architektur noch nicht entsprechend angepasst.

Der Bericht „Der aktuelle Stand der KI-Inferenz“ ergab, dass 75 % der Unternehmen generative KI (GenAI) in die Produktion überführt haben, doch dass ihre Infrastruktur dabei nicht Schritt gehalten hat. Ein wachsender Anteil dieser GenAI-Workloads erfordert heute strikte Echtzeitlatenz, die sich mit einem Paketumlauf zu einer weit entfernten Region einfach nicht erreichen lässt. Entsprechend bewerten 60 % der befragten Experten die Nähe zu Nutzern und Daten als „wichtig“ oder „kritisch“. 

Dennoch führen 46 % die Inferenz nach wie vor über eine einzige zentrale Region aus. Das ist das Ungleichgewicht: Es geht nicht darum, dass Zentralisierung überall versagt, sondern dass ein steigender Anteil der Produktionsinferenz näher am Nutzer ausgeführt werden muss, als es eine zentrale Infrastruktur erlaubt.

Dabei lässt sich leicht vorhersagen, welche Workloads als Erstes versagen: Betrugsbewertung bei Live-Transaktionen, Sprachagenten, Echtzeit-Personalisierung und jede agentische Pipeline, die mehrere Modellaufrufe verkettet, bevor sie eine Antwort zurückgibt. Jeder Schritt übernimmt die Latenz des vorherigen. Wenn man diesen Ablauf auf eine einzige Region konzentriert, summieren sich die Warteschlangenverzögerungen mit steigender Nutzung. Und so entstehen letztlich zusätzliche Latenzen von hunderten Millisekunden – und zwar genau dann, wenn es sich die Workload am wenigsten leisten kann.

Es geht also nicht um die generelle Glaubensfrage „Zentralisiert oder verteilt?“, sondern darum, welche Workloads Nähe erfordern und welche nicht. Erfolgreiche Teams beantworten diese Frage individuell für jede Workload, anstatt standardmäßig alles in einer Region auszuführen und die Latenz hinzunehmen.

Ein schwacher ROI ist in der Regel ein Anzeichen dafür, dass ein Team operativ gegensteuert statt über die Architektur. Der entscheidende Indikator sind die Unit Economics, also die Kosten einer einzelnen Inferenzanfrage, gemessen pro Token oder pro Abfrage. Wenn Sie diese Zahl nicht einsehen können, können Sie sie auch nicht optimieren oder den Moment erkennen, in dem sie außer Kontrolle gerät.

Den meisten Teams fehlt dieser Einblick: 77 % der Unternehmen verfügen nicht über einheitliche Unit-Economics-Daten für die Inferenz – und das bedeutet, dass die Mehrheit nicht ermitteln kann, ob eine bestimmte Workload mit zunehmender Skalierung günstiger oder teurer wird. Diese Transparenzlücke ist gleichzeitig auch eine Sicherheitslücke: Denn ein unerklärlicher Anstieg des Token-Verbrauchs ist oft das erste Anzeichen für einen DoW‑Angriff (Denial of Wallet), bei dem Angreifer das Inferenzvolumen gezielt in die Höhe treiben, um die Kosten zu steigern.

Wenn sich ein schlechter ROI in hoher Latenz und geringen Konversionsraten äußert, ist die geografische Lage in der Regel die Hauptursache. Echtzeitinferenz verursacht sprunghaften Traffic, ist latenzempfindlich und lässt sich über die Kombination aus öffentlichem Internet und weit entfernten Rechenzentren nicht zuverlässig erreichen.

Die Rechnung ist unerbittlich: Wenn Ihr End-to-End-Latenzbudget 250 Millisekunden beträgt, aber die Berechnung 100 ms und der API‑Handshake 50 ms dauern, bleiben Ihnen nur noch 100 Millisekunden für die Datenübertragung. Wenn Sie jetzt noch einen Kontinent überqueren müssen, ist dieses Budget ist aufgebraucht, bevor das Modell überhaupt an die Arbeit geht. 

Indem Sie die Inferenz an verteilten Points of Presence ausführen, wird der Großteil der Arbeit in derselben Region ausgeführt, in der sich auch Nutzer befinden. Hierdurch können Sie Engpässe im öffentlichen Internet umgehen und die Geschwindigkeitsbegrenzung beseitigen, die ein zentraler Ansatz mit sich bringt. Die Antwort fühlt sich direkt an, weil sie lokal generiert wird.

Wenn Sie die Inferenz nicht schützen, können Sie sie auch nicht skalieren. Und wenn Sie Sicherheit als parallelen Bereich behandeln, zahlen Sie dafür letztlich mit Leistungseinbußen. Beide Studien zeigen, dass das eigentliche Problem nicht in der Topologie liegt, sondern in ungesicherten, ungetesteten und unsichtbaren APIs.

Die Daten sind erschreckend: 87 % der Unternehmen erlebten im vergangenen Jahr einen API‑Sicherheitsvorfall – 2022 waren es noch 76 %. Unter den Teams, bei denen Vorfälle auftraten, waren Angriffe auf KI‑verknüpfte APIs laut der Studie die am häufigsten genannte Art API‑bezogener Sicherheitsvorfälle: 42 % berichteten von Angriffen auf APIs, die mit KI‑Technologien verbunden sind. 

Ein durchschnittlicher Vorfall kostet jetzt 700.000 US‑Dollar pro Jahr, wobei das oberste Quartil der Vorfälle sogar mehr als 1,8 Millionen US‑Dollar kostet. Risiken, die durch KI‑verknüpfte APIs entstehen, sind kein Problem der Zukunft – sie sind längst Realität.

Die Transparenz entwickelt sich derweil in die falsche Richtung: Nur 23 % der Unternehmen wissen, welche ihrer APIs sensible Daten zurückgeben – 2022 waren es noch 40 %. Doch eine Infrastruktur, die Sie nicht einsehen können, können Sie auch nicht schützen. Und KI erweitert diese Infrastruktur schneller, als manuelle Bestandsaufnahmen mithalten können. Copiloten richten Endpoints ein, die niemals einer Sicherheitsprüfung unterzogen werden. Dialogorientierte Nutzeroberflächen machen die Datenextraktion durch Prompt Injection zum Kinderspiel, wenn Angreifer den richtigen ungeschützten Weg finden.

Wichtig ist hierbei, dass der Einstiegspunkt nicht die ganze Geschichte ist: Ein Angreifer, der eine einzige offengelegte API knackt, wird versuchen, sich durch laterale Netzwerkbewegung zu den Komponenten vorzuarbeiten, die den eigentlichen Wert darstellen: zu den Feature Stores, die KI‑Daten kuratieren, und zu den Repositorys, die Modellgewichtung und -logik enthalten. 

Mikrosegmentierung – die Sicherheits-Best-Practice, die einzelne Workloads isoliert – kann diesen Auswirkungsradius eindämmen. Doch leider haben die meisten Unternehmen sie noch nicht implementiert. Aber diejenigen, die es getan haben, können Angriffe deutlich schneller eindämmen. Die herkömmliche, netzwerkbasierte Segmentierung gilt allgemein als komplex, aufwendig und ineffektiv. Moderne, KI‑gestützte Mikrosegmentierung löst dieses Problem: Wenn Sie diese Segmentierung in dasselbe Netzwerk integrieren, das die Inferenz bereitstellt, vermeiden Sie den Kompromiss zwischen Schutz und Performance.

Die Implementierung muss hierbei identitätsbasiert erfolgen. Unternehmen sollten wie folgt vorgehen:

• Definieren Sie den Zugriff nach Workload-Identität statt nach IP‑Adresse, damit ein bestimmter Inferenzdienst nur einen bestimmten Feature Store erreichen kann – und nichts anderes. 

• Führen Sie kontinuierliche API‑Erkennung aus, um verwaiste Test-Endpoints zu finden, die weiterhin mit Produktionsdaten verbunden sind. 

So wird Sicherheit zu einem festen Bestandteil der Infrastruktur – statt einer punktuellen Prüfung, die Entwickler umgehen können.

Das tiefer liegende Problem, das beide Studien aufdecken, ist organisatorischer und nicht technischer Natur: Teams entwickeln Traffic und Sicherheit separat und die Probleme entstehen genau an der Schnittstelle zwischen den beiden Bereichen.

Hierbei besteht eine wichtige Kluft hinsichtlich des Vertrauens: 40 % der C‑Level-Führungskräfte geben an, dass ihre API‑Tests sehr ausgereift sind, doch nur 28 % der DevSecOps-Teams, die sich um die eigentliche Arbeit kümmern, stimmen dieser Einschätzung zu. Führungskräfte glauben, das Problem sei gelöst, wodurch die Grundlagen weiterhin unterfinanziert bleiben, während die Ausgaben in verwandte Tools fließen. Die Kluft zwischen dem, was die Führung für geschützt hält, und dem, was tatsächlich geschützt ist, wird immer größer.

Um diese Kluft zu schließen, müssen die Teams, die den Traffic verwalten, und die Teams, die ihn schützen, auf derselben – oder zumindest auf einer konvergierten – Kontrollebene arbeiten. Wenn Erkennung und Eindämmung diese Ebene gemeinsam nutzen, kann ein anomales Anfragemuster – wie es für Prompt Injection oder DoW typisch ist – die automatische Isolierung des betroffenen Endpunkts auslösen, ohne dass ein Mensch eingreifen muss. Doch diese Synchronisierung ist nur möglich, wenn Verteilung und Sicherheit keine separaten Systeme sind.

Zwei Fähigkeiten unterscheiden Teams, die skalieren, von denen, die ins Stocken geraten:

1. Portabilität: Ausgereifte Unternehmen sind deutlich weniger an bestimmte Lösungen gebunden, da sie Workloads je nach Kosten- und Kapazitätsentwicklung zwischen verwalteten GPUs, gehosteten APIs und serverlosen Laufzeiten verschieben können. 

2. Laufzeit-Governance: Die Kontrolle sowohl eingehender schädlicher Prompts als auch ausgehender Antworten, die Daten preisgeben, wird auf der Netzwerkebene durchgesetzt und nicht erst nachträglich in die Anwendung integriert.

Bringt man diese Funktionen auf einer einzigen Plattform zusammen, auf der sich Verteilung, Sicherheit und Traffic-Steuerung eine gemeinsame Kontrollebene teilen, fällt der Kompromiss zwischen Schutz und Performance weg. So erhalten Sie einen einheitlichen Überblick darüber, was ausgeführt wird, wo es ausgeführt wird und ob es angegriffen wird.

Dies ist das Problem, das Akamai bereits für die Inhaltsbereitstellung und -sicherheit gelöst hat und nun auch für die Produktionsinferenz löst. Dasselbe globale Netzwerk, das die Inferenz nahe an Nutzer heranbringt, sorgt auch für die API‑Sicherheit, Mikrosegmentierung und den DDoS‑Schutz (Distributed Denial-of-Service) für diese Inferenz. Dank dieser Reichweite kann ein einziges Netzwerk beide Aufgaben gleichzeitig erfüllen.

Die Ursache liegt in einer Infrastruktur, die anpassungsfähige Architektur, Sicherheit und Verteilung noch nicht auf einer gemeinsamen Grundlage vereint hat. Die Lücke zwischen Performance und Schutz wird immer größer, doch sie ist weder struktureller Natur noch unlösbar. Diese Lücke schließt sich, wenn die Teams, die den Traffic verwalten, ihn auch schützen – und zwar auf einer Infrastruktur, die von Grund auf auf Inferenz ausgelegt ist, anstatt nachträglich angepasst zu werden, um sie irgendwie zu bewältigen.

Ausführlichere Informationen hierzu finden Sie im Bericht Der aktuelle Stand der KI-Inferenz 2026 und in der API‑Sicherheitsstudie.