Direktvertrag vs. Hyperscaler vs. Gateway vs. Eigenbetrieb

Worum es geht

Wo Daten liegen und wo gerechnet wird, sind zwei verschiedene Fragen. Ein Tarif kann EU-Speicherung zusagen und die Anfrage trotzdem in den USA verarbeiten. Die Route entscheidet, nicht der Anbieter. Wer EU-Verarbeitung zusagt, prüft sie pro Modell.

Für dieselbe Anfrage an dasselbe Modell gibt es vier Wege, und sie unterscheiden sich nicht im Ergebnis, sondern darin, wer Vertragspartner ist, wo die Rechenleistung steht und wie gut sich das belegen lässt:

Direktvertrag beim Modellanbieter: OpenAI, Anthropic, Google oder Mistral AI als unmittelbarer Auftragsverarbeiter.
Hyperscaler: dasselbe Modell über AWS Bedrock, Google Vertex oder Azure, gebucht in einer EU-Region.
Gateway: ein Vermittler wie OpenRouter, Requesty, Langdock oder ein selbst betriebener LiteLLM-Proxy sitzt zwischen Anwendung und Modell.
Eigenbetrieb offener Gewichte: DeepSeek, Qwen, GLM oder Mistral Open auf Scaleway, Nebius, Hetzner oder eigener Hardware.

Vergleich

Dimension	Direktvertrag	Hyperscaler	Gateway	Eigenbetrieb
Vertragspartner	Modellanbieter	Cloud-Anbieter	Vermittler, Modellanbieter dahinter	niemand oder Infrastrukturanbieter
Rechenort belegbar	über Vertrag und Tarif	über die gebuchte Region	nur über die Zusage des Vermittlers	vollständig, es ist die eigene Maschine
Aufpreis für EU	keiner bis moderat	rund 10 Prozent bei regionalen Endpunkten	Aufschlag des Vermittlers	Hardware und Betrieb statt Tokenpreis
Modellauswahl	ein Anbieter	was der Hyperscaler führt	breit, Wechsel ohne Codeänderung	offene Gewichte
Frontier-Modelle	ja	ja	ja	nein
Wechselaufwand	hoch, eigene API	mittel	gering, das ist der Zweck	hoch
Zusätzliche Kette	keine	eine Stufe	zwei Stufen	keine
Typischer Fall	ein Werkzeug, viele Nutzer	Konzernumfeld, bestehender Cloud-Vertrag	mehrere Modelle, wechselnde Anforderungen	Berufsgeheimnis, Offline-Betrieb

Die zusätzliche Stufe beim Gateway ist kein Nachteil an sich, aber sie verschiebt die Beweislast: Man vertraut einer Zusage über eine Zusage.

Stand der Anbieter, August 2026

Anbieter	EU-Speicherung	EU-Inferenz
Anthropic direkt	nein	nein
Claude über AWS Bedrock	ja	Irland, Stockholm, Frankfurt
Claude über Google Vertex	ja	Frankfurt, EU-Multiregion
Claude in Microsoft Foundry	nein	nein
OpenAI Enterprise und API	ja	ja, seit 16.01.2026
OpenAI Business und Team	ja	nein
Google Gemini	ja	strittig
Microsoft 365 Copilot	ja	EU Data Boundary, mit Vorbehalt
Mistral	ja	ja
OpenRouter	konfigurierbar	nur mit Enterprise-Vertrag
Requesty	Frankfurt zugesagt	pro Modell zu prüfen
Langdock	ja, EU-Deployment	folgt dem Modell dahinter
Offene Gewichte im Eigenbetrieb	ja	ja

Sieben Fußnoten zu dieser Tabelle, weil das Wesentliche selten in der Spalte steht:

Anthropic bietet direkt keine EU-Inferenz an; die API kennt nur inference_geo: "us". In der EU rechnet Claude ausschließlich über Bedrock oder Vertex, mit rund zehn Prozent Aufschlag auf regionale Endpunkte. Claude in Microsoft Foundry ist seit Juli 2026 verfügbar, eine EU-Data-Zone ist angekündigt, ein Datum dafür gibt es nicht.

OpenAI hat In-Region-Inferenz in Europa seit dem 16.01.2026 ohne Aufpreis, aber nur für Enterprise-Verträge und nur in neu angelegten Workspaces. Für Business- und Team-Pläne bleibt es bei EU-Speicherung.

Microsoft 365 Copilot liegt in der EU Data Boundary, mit zwei Einschränkungen: „Flex Routing” kann seit April 2026 bei Lastspitzen außerhalb der EU rechnen und gehört im Admin Center abgeschaltet; die in Copilot eingebundenen Claude-Modelle liegen außerhalb der Boundary und sind in EU, EFTA und UK standardmäßig aus.

OpenRouter bietet EU-Routing über eu.openrouter.ai nur Enterprise-Kunden. Alle anderen können Provider filtern und Zero Data Retention erzwingen – das beruht laut Anbieter selbst auf der Selbstauskunft der Modellanbieter, die Rechenzentrumsstandorte werden nicht verifiziert (Anbieterangabe, 22.06.2026).

Requesty betreibt ein Frankfurter Gateway, die Gesellschaft ist REQUESTY LTD mit Sitz im Vereinigten Königreich. Der Transfer dorthin stützt sich auf den EU-UK-Angemessenheitsbeschluss, im Januar 2026 erneuert und bis zum 27.12.2031 gültig – eine eigene Rechtsgrundlage, nicht der Normalfall „alles in der EU”.

Langdock ist eine Arbeitsplattform mit Oberfläche und Governance, kein Modellanbieter. Das EU-Deployment betrifft die Plattform; die Residenzfrage verschiebt sich auf das Modell dahinter, sie verschwindet nicht.

Offene Gewichte (DeepSeek V4, Qwen 3.5 und 3.6, GLM-5, Mistral Open) laufen auf Scaleway, Nebius, Hetzner oder eigener Hardware. Es ist die einzige Zeile, in der die Frage nach dem Rechenort keine Vertragsfrage ist.

Der strittige Punkt bei Google steht hier bewusst offen. Eine Sekundärquelle vom Juli 2026 führt EU-Datenresidenz nur bis Gemini 3.5 Flash, neuere Flash-Modelle nur global. Gleichzeitig bietet mindestens ein Gateway einen EU-Endpunkt für Gemini 3.7 Flash an und wir nutzen ihn selbst (siehe unten). Beides kann stimmen, wenn der Endpunkt über Vertex läuft und die Sekundärquelle nur das Direktangebot beschreibt. Aufgelöst ist das nicht. Wer darauf eine Zusage stützt, holt sie sich schriftlich vom Anbieter.

Was wir selbst machen

Die Wissenssuche auf go4ai.de lief bis zum 17.08.2026 über OpenRouter mit Gemini 2.5 Flash, also über einen US-Vermittler ohne EU-Inferenzzusage. Seit dem 17.08.2026 läuft sie über das EU-Gateway von Requesty an einen EU-Endpunkt von Google Vertex mit Gemini 3.7 Flash. Das ist der Gateway-Weg aus der Tabelle, mit allem, was daran hängt: Der Wechsel war eine Konfigurationszeile, die Modellwahl blieb frei, und die Zusage über den Rechenort ist eine Zusage des Vermittlers, keine eigene Messung.

Zwei Dinge, die dabei aufgefallen sind und die in keinem Anbietertext stehen. Erstens zieht ein solcher Wechsel Dokumentationspflichten nach sich: Empfänger und Drittlandbegründung in der Datenschutzerklärung waren nach dem Umstellen falsch, bis sie nachgezogen wurden. Zweitens ist der Vertragspartner nicht dort, wo die Rechenleistung steht. Requesty betreibt ein Frankfurter Gateway, die Gesellschaft sitzt im Vereinigten Königreich. Das ist zulässig, aber es ist ein Drittlandtransfer mit eigener Rechtsgrundlage, nicht der Normalfall „alles in der EU”.

Praktische Heuristik

Ein Werkzeug, viele Nutzer, keine besonderen Datenklassen → Direktvertrag. Die einfachste Kette ist die, die man am leichtesten belegt.
Bestehender Cloud-Vertrag mit AWS, Google oder Microsoft → Hyperscaler. Der Auftragsverarbeitungsvertrag existiert bereits, die Region ist buchbar, der Aufschlag ist kalkulierbar.
Mehrere Modelle, wechselnde Anforderungen, kleines Team → Gateway. Der Preis dafür ist eine zusätzliche Stufe in der Kette und eine Zusage, die man nicht selbst prüfen kann.
Berufsgeheimnis nach § 203 StGB, Art.-9-Daten, echte Offline-Anforderung → Eigenbetrieb. Nicht weil offene Gewichte besser wären, sondern weil nur hier die Frage nach dem Rechenort trivial ist.
Gemischte Lage → kombinieren. Ein Proxy wie LiteLLM vor mehreren Routen erlaubt, harmlose Anfragen billig und sensible Anfragen in der EU zu fahren, mit einer Schnittstelle für die Anwendung. So läuft der Privacy Gateway.

Entscheidungssatz

Nicht der Anbieter entscheidet, sondern die Route. Alle vier Wege können eine EU-Verarbeitung tragen, sie unterscheiden sich darin, wie weit der Beleg dafür trägt: vom eigenen Rechner über den gebuchten Regionsvertrag bis zur Zusage eines Vermittlers über eine Zusage. Wer EU-Verarbeitung zusagt, muss sagen können, welche Route gemeint ist und woran man sie erkennt. Die Antwort „unser Anbieter ist DSGVO-konform” beantwortet die Frage nicht.

Im Wiki

Fachliche Grundlage: Tool-Compliance-Matrix für KMU (Abschnitt Inferenz-Geografie), LLM-Anbieter und DSGVO – Risikomanagement statt Cloud-Act-Pauschalurteil, Modell-Landschaft 2026, LLM-Datenschutzrisiken, DSGVO-Pflichten für KMU. Anbieterprofile: OpenRouter, Requesty, Langdock, LiteLLM, Mistral AI.

Wo rechnet mein Modell, und wie belege ich das?

Verglichene Wege.

Kurz eingeordnet.