Router

Ein Endpunkt, vier Schutzstufen. Sie wählen, wie weit die Anfrage reisen darf.

Die Schutzstufe wird beim Onboarding festgelegt und gilt als harte Vorab-Regel, bevor eine Anfrage überhaupt das Haus verlässt — nicht als nachträgliche Prüfung. Fail-closed: ist kein Anbieter Ihrer Stufe verfügbar, schlägt die Anfrage fehl. Sie wird nie auf eine niedrigere Stufe heruntergestuft.

Warum ein Gateway allein das nicht beantwortet

„Wir nutzen einen Gateway-Verbund” ist kein Subprozessorenverzeichnis.

Ein reiner Gateway wählt den Subprozessor pro Anfrage zur Laufzeit — aus über hundert Anbietern. Wer tatsächlich geantwortet hat, steht nicht standardmäßig in der Antwort. Ein Subprozessorenverzeichnis, das Sie nicht führen können, ist keins.

Von den erreichbaren AnbieternAnzahl
Erreichbare Anbieter insgesamt103
Davon in den USA ansässig54
Jurisdiktion an der maßgeblichen Quelle unbekannt29
China / Singapur12
Ohne veröffentlichte Datenschutzerklärung12
EWR-ansässig4
Mit tatsächlich geklärten Aufbewahrungsfristen2

Deshalb bekommt jede Anfrage vorab eine harte Zuordnung zu Ihrer gewählten Schutzstufe, statt sich im Nachhinein zu zeigen, wer geantwortet hat.

Die drei Stufen im Router

Stufe 1 gibt es nur auf eigener Hardware — hier die drei, die ein Gateway tatsächlich liefern kann.

Jede Stufe kompiliert in eine harte Vorab-Regel UND in den Anhangstext Ihres AVV — Vertrag und Laufzeitverhalten können nicht auseinanderlaufen. Jede Stufe zeigt auch, was sie nicht leistet.

Stufe 2Aktuell kein Anbieter

EWR-Region

Unternehmen mit bestehendem Azure-/AWS-AVV

egress:
Rechenzentrum auf ein EWR-Land gepinnt — Deutschland selbst steht hier nicht zur Wahl.
modelle:
Irland oder Schweden

Nie unterhalb dieser Region — kein Fallback in ein anderes Land.

  • — Aktuell kein zulässiger Anbieter: die einzigen zwei Länder-Endpunkte im Katalog (Amazon Bedrock/Irland, Azure/Schweden) haben eine ungeklärte Aufbewahrungsfrist — ungeklärt gilt als nicht-konform, die Stufe liefert deshalb derzeit null zulässige Anbieter.
  • — Eine EWR-Region hebt die Transfer-Frage nicht auf: eine US-kontrollierte Entität kann trotz EWR-Serverstandort dem CLOUD Act unterliegen.
  • — Löst Art. 28/32 DSGVO, nicht automatisch Kapitel V — bei Drittlandbezug zusätzlich SCC/TIA prüfen.
  • — Die Verifikation ist schwächer als bei Stufe 1 oder 3: manche Anbieter melden nur den Basisnamen zurück, nicht die tatsächlich bedienende Region — solche Anfragen werden als „Region unverifiziert" aufgezeichnet, nicht stillschweigend als konform gezählt.
Stufe 3

EU-Anbieter

Reguläre Geschäftsnutzung ohne Berufsgeheimnis-Bindung

egress:
Ausschließlich EWR-ansässige Entitäten.
modelle:
4 Anbieter (Mistral FR, Nebius NL, NextBit ES, Inceptron SE)

Nie außerhalb dieser vier Anbieter — kein Fallback in ein Land ohne EWR-Sitz.

  • — Nur 4 von 103 im Katalog erreichbaren Anbietern sind EWR-ansässig — schmaler, als der Name vermuten lässt.
  • — Eine EWR-Entität kann eigene Subprozessoren außerhalb der EWR beauftragen — das schränkt nur ein, mit wem wir vertraglich stehen, nicht deren eigene Lieferkette.
  • — Training auf übermittelten Inhalten ist auf dieser Stufe standardmäßig nicht ausgeschlossen — eine EWR-Entität allein ist keine Zusage dazu. Wer das braucht, muss Nicht-Training gesondert verlangen; die Trainingsbedingungen der vier Anbieter sind noch nicht abschließend geklärt.
Stufe 4

Global, protokolliert

Forschung, Evaluation, nicht-personenbezogene Daten

egress:
Uneingeschränkt — aufgezeichnet, nicht blockiert.
modelle:
Alle verfügbaren Anbieter

Jede Anfrage protokolliert und dem tatsächlich antwortenden Anbieter zugeordnet — auch wenn dieser nicht eingeschränkt wird.

  • — Das ist ein Nachweis, kein Schutz: nichts wird blockiert, das Register hält nur fest, wohin die Daten gingen — nachdem sie schon dort waren.
  • — Ohne dokumentierte Übermittlungsgrundlage nur für nicht-personenbezogene Daten geeignet — protokolliert zu sein macht eine Verarbeitung allein nicht zulässig.
  • — Startet im Beobachtungsmodus: Verstöße werden aufgezeichnet, die Anfrage aber trotzdem bedient, bis eine Allowlist definiert und auf „warn" oder „enforce" umgestellt wird.
  • — Training ist auf dieser Stufe nicht kontrollierbar — kein Feld in der Anfrage drückt das aus; die einzige Kontrolle wäre, Anbieter komplett auszuschließen, was diese Stufe bewusst nicht tut.

Kein Vendor-Lock-in

Ihre Werkzeuge zeigen auf eine base_url — nicht auf einen bestimmten Anbieter. Wird ein Modell für Sie gesperrt, ändert ein Anbieter seine Bedingungen, oder passt ein Anbieter nicht mehr in Ihre Schutzstufe, wechseln wir die Zuordnung hinter dem Endpunkt. Claude Code, Cursor oder Ihre eigene Integration merken davon nichts — es ändert sich nichts an Ihrer base_url, nur wer dahinter antwortet.

Für Entwickler

Der Wechsel ist eine Zeile Code.

Verfügbar
curl https://ai-sidecar-api.datafortress.cloud/v1/chat/completions \
  -H "Authorization: Bearer ihr_schluessel" \
  -H "Content-Type: application/json" \
  -d '{"model":"qwen3.8-27b","messages":[{"role":"user","content":"..."}]}'

Direkter HTTPS-Aufruf, ohne SDK.

Dieselbe base_url funktioniert für jede Stufe — nur das Onboarding legt fest, welche Stufe für Ihren Schlüssel gilt.

Was jede Anfrage hinterlässt

Unabhängig von der Stufe schreibt jede Anfrage denselben geprüften Nachweis-Rekord: Modell, tatsächlicher Subprozessor, Hash, Zeitstempel, verkettet mit der vorherigen Anfrage. Exportierbar als Art. 30 VVT-Eintrag, signiertes PDF oder CSV — unabhängig mit einem eigenständigen, dependency-freien Skript nachprüfbar, statt eine Zusicherung glauben zu müssen.

Preis

Tokens werden zum Einkaufspreis durchgereicht — der Umsatz kommt aus der Compliance-Schicht, nie aus einer Marge auf Inferenz. Die genaue Aufschlagshöhe hängt von der gewählten Stufe und dem Volumen ab und wird im Onboarding festgelegt.

Vier Fragen, dann wissen Sie, welche Stufe passt.

Der Fragebogen empfiehlt Produkt und Stufe direkt auf der Seite, ohne Anmeldung.