KI-Gateways: Der Kontrollpunkt für Datenschutz und Regulatorik

Über KI-Gateways wird derzeit vor allem als Kostenwerkzeug gesprochen: Sie machen die Monatsrechnung transparent, drosseln Ausreißer und verrechnen Token sauber pro Team. Das stimmt – und es verfehlt die Frage, die für jede Organisation unter DSGVO, EU AI Act, NIS2 oder DORA die eigentlich teure ist: An welcher technischen Stelle setzen Sie Ihre regulatorischen Pflichten im KI-Betrieb tatsächlich durch? Nicht in der Richtlinie, nicht im Verzeichnis von Verarbeitungstätigkeiten, sondern im einzelnen Request.

Die ehrliche Antwort lautet in den meisten Häusern: an keiner. Teams nutzen im Best-of-Breed-Ansatz Modelle verschiedener Anbieter, jeder Call läuft an der zentralen IT vorbei, und niemand kann rekonstruieren, welche Daten wann an welchen Provider in welchem Land geflossen sind. Das ist kein Kostenproblem. Das ist ein Kontrollproblem – und Kontrolle ist die Grundvoraussetzung jeder Compliance.

Der Zeitdruck lässt sich datieren. DORA ist seit dem 17. Januar 2025 anwendbar. Das deutsche NIS2-Umsetzungsgesetz ist seit dem 6. Dezember 2025 in Kraft, ohne Übergangsfrist. Es bringt persönliche Haftung der Geschäftsleitung und Bußgelder bis zu 10 Mio. Euro oder 2 Prozent des Weltumsatzes. Und die Transparenzpflichten des EU AI Act nach Artikel 50 werden am 2. August 2026 anwendbar, also in wenigen Wochen. Wer den „Digital Omnibus" als Aufschub gelesen hat, hat ihn falsch gelesen: Verschoben wurden die Hochrisiko-Pflichten auf 2027/2028 – die Kennzeichnungs- und Offenlegungspflichten für Chatbots und KI-generierte Inhalte ausdrücklich nicht.

Schatten-KI ist ein Datenschutzvorfall in Wartestellung

Der dezentrale KI-Einsatz erzeugt drei regulatorische Probleme gleichzeitig, und alle drei bleiben unsichtbar, bis sie eskalieren.

Erstens: Jeder unkontrollierte Prompt an einen US-Anbieter ist ein potenzieller Drittlandtransfer personenbezogener Daten nach Kapitel V DSGVO. Meist fehlt dafür die dokumentierte Rechtsgrundlage, oft die Transfer-Folgenabschätzung – und häufig weiß die Fachabteilung nicht einmal, dass sie überhaupt Personendaten verarbeitet. „Fasse mir diese Kundenmail zusammen" ist technisch trivial und datenschutzrechtlich ein grenzüberschreitender Vorgang.

Zweitens: Ohne zentralen Punkt gibt es keine Protokollierung – und damit keine Rechenschaftsfähigkeit. DSGVO (Art. 5 Abs. 2), NIS2 und DORA verlangen alle, dass Verarbeitungen nachvollziehbar sind. Nachvollziehbarkeit über fünf isolierte Anbieter-Dashboards hinweg ist keine.

Drittens: KI-Systeme, die niemand kennt, lassen sich nicht klassifizieren. Der EU AI Act zwingt Betreiber, ihre KI-Anwendungen zu inventarisieren und einzustufen. Ein Chatbot, den das Marketing eigenmächtig über eine Provider-API gebaut hat, taucht in keinem Inventar auf – und fällt trotzdem ab dem 2. August unter die Kennzeichnungspflicht des Art. 50.

Das verbindende Muster: Regulatorik setzt einen Engpass voraus, an dem man messen, protokollieren und eingreifen kann. Fehlt dieser Engpass, ist Compliance keine Tatsache, sondern eine Schätzung.

Was die Regulatorik vom KI-Betrieb konkret verlangt

Bevor man über Werkzeuge spricht, lohnt der Blick auf die Pflichten, die sich technisch überhaupt an einem Gateway abbilden lassen. Nicht jede Anforderung tut das – aber die operativ relevanten schon.

Der entscheidende Punkt in dieser Tabelle steht in der letzten Spalte: Drei der vier Rahmenwerke sind bereits scharf. Der EU AI Act wird es in Teilen in wenigen Wochen. Die Zeit der Vorbereitungsprojekte ist vorbei; gefragt ist jetzt technische Durchsetzung.

Der Gateway als Übersetzungsschicht

Ein KI-Gateway sitzt als zentraler Proxy zwischen den Applikationen und den Modell-Providern. Genau diese Position macht es zur einzigen Architekturkomponente, an der sich regulatorische Anforderungen in erzwingbare Regeln übersetzen lassen. Die native Funktionsliste marktüblicher Gateways – Helicone, Kong, LiteLLM, Portkey – liest sich wie ein FinOps-Prospekt. Übersetzt man sie in die Sprache der Regulatorik, ergibt sich ein anderes Bild: Während die erste Tabelle zeigt, welche Pflicht wo steht, zeigt die folgende, welche Gateway-Funktion sie tatsächlich abdeckt – und wo die Abdeckung endet.

Vier dieser Übersetzungen sind stark genug, um Governance-Konzepte zu tragen, die bisher rein organisatorisch blieben.

Die PII-Erkennung (PII: Personally Identifiable Information, also personenbezogene Daten) operationalisiert die Datenminimierung: Der Proxy erkennt und maskiert personenbezogene Daten, bevor der Prompt den Provider erreicht. Aus einem Grundsatz („so wenig Personendaten wie möglich") wird eine technische Regel.

Die Audit-Logs mit compliance-konformer Aufbewahrungsfrist sind das technische Rückgrat der Rechenschaftspflicht – und zugleich der Nachweis für DORA- und NIS2-Prüfer, dass Protokollierung stattfindet. Entscheidend ist hier nicht, dass geloggt wird, sondern wie lange und wie zugriffsgesichert.

Die Routing-Steuerung ist der unterschätzte Datenschutz-Hebel. Ein Gateway kann Anfragen mit sensiblem Kontext gezielt an EU-gehostete oder on-premises betriebene Modelle leiten und Provider ohne belastbare Transfergrundlage schlicht sperren. Damit wird die Drittlandtransfer-Frage aus Kapitel V von einer nachträglichen Rechtfertigung zu einer Design-Entscheidung.

Und das Kennzeichnungs-Enforcement adressiert die drängendste Frist: Das Gateway kann Metadaten oder Hinweise injizieren, die eine KI-Interaktion offenlegen – die technische Seite von Art. 50. Die Klassifizierung, ob ein Use Case überhaupt darunter fällt, bleibt allerdings Governance-Arbeit; sie lässt sich nicht an einen Proxy delegieren.

Der kritische Gegencheck: Das Gateway ist selbst eine Verarbeitung

Hier endet die Werbebroschüre und beginnt die Praxis. Ein KI-Gateway löst das Datenschutzproblem nicht – es verlagert und konzentriert es. Wer das übersieht, tauscht ein diffuses Risiko gegen ein zentrales, vollständiges ein.

Der Log ist die neue Angriffsfläche. Ein Gateway, das jeden Prompt und jede Antwort protokolliert, erzeugt eine lückenlose Sammlung genau der Daten, die vorher verstreut und flüchtig waren – inklusive potenziell besonderer Kategorien nach Art. 9. Dieser Log ist eine eigenständige Verarbeitungstätigkeit: mit eigener Rechtsgrundlage, eigenem Löschkonzept, eigener Zugriffskontrolle und eigenem Eintrag im Verzeichnis. Ein schlecht geführter Gateway-Log ist datenschutzrechtlich gefährlicher als die dezentralen Calls, die er ersetzt – gerade weil er vollständig ist.

PII-Erkennung ist probabilistisch. Sie arbeitet mit Klassifikatoren, nicht mit Garantien. False Negatives verlassen unbemerkt das Haus, False Positives brechen Funktionalität. Gegenüber einer Aufsichtsbehörde ist „der Klassifikator hat es übersehen" keine Verteidigung. PII-Redaction ist eine sinnvolle Schutzmaßnahme – aber sie ersetzt weder die Rechtsgrundlage noch die Datenminimierung an der Quelle.

Semantic Caching ist datenschutzrechtlich heikel. Zwischengespeicherte Antworten können Personendaten enthalten. Trifft ein Cache-Hit über Nutzergrenzen hinweg, kann die Antwort auf die Anfrage von Person A Daten von Person B offenbaren – eine Vertraulichkeitsverletzung nach Art. 32. Wer Caching bei personenbezogenen Flows einsetzt, muss es mandantenscharf und PII-bewusst konfigurieren oder abschalten. Der Kostenvorteil des Cachings und der Datenschutz stehen hier in direktem Zielkonflikt.

Und der Betreiber selbst wird zur Vertragsfrage

Der Gateway-Betreiber wird zum Vertragsgegenstand. Ein SaaS-Gateway ist ein Auftragsverarbeiter – mit allem, was Art. 28 DSGVO verlangt: AV-Vertrag, technisch-organisatorische Maßnahmen, Sub-Prozessor-Ketten, gegebenenfalls eigener Drittlandtransfer. Für Unternehmen unter DORA wird dieser Betreiber zusätzlich zum IKT-Drittdienstleister: mit Eintrag im Informationsregister, Ausstiegsstrategie und laufender Überwachung. Der Proxy, der die Third-Party-Frage lösen sollte, ist dann selbst eine Third Party.

Der LLM-Provider bleibt Empfänger. Das Gateway steuert und dokumentiert den Transfer – es beseitigt ihn nicht. Der AV-Vertrag mit dem Modell-Anbieter und die Transfergrundlage nach Kapitel V bleiben zwingend. Ein Gateway macht diese Pflichten sichtbar und steuerbar; es macht sie nicht überflüssig.

Auswahl aus Compliance-Sicht: Die Verantwortungsgrenze entscheidet

Für die Werkzeugwahl ist aus regulatorischer Sicht nicht die Featurezahl relevant, sondern eine einzige Achse: Wo verläuft die Grenze Ihres Verantwortungsbereichs?

Ein selbst betriebenes Gateway – etwa LiteLLM oder ein selbst gehostetes Kong – hält Logs, Redaction und Routing vollständig innerhalb Ihrer Kontrollsphäre. Maximale Kontrolle, maximale Eigenlast: Sie sind allein für Betrieb, Härtung und Aufbewahrung verantwortlich. Eine SaaS-Control-Plane nimmt Ihnen diese Last ab, fügt aber einen Auftragsverarbeiter und – im Finanzsektor – ein IKT-Drittparteienrisiko hinzu.

Die Fragen, die vor jeder Produktentscheidung stehen, sind entsprechend keine Feature-Fragen:

• Wo liegen die Logs, wie lange, mit welcher Rechtsgrundlage und welchem Löschkonzept?
• Wer hat Zugriff auf die protokollierten Prompts – und ist dieser Zugriff auditierbar?
• Ist der Betreiber Auftragsverarbeiter? Liegt ein Art.-28-Vertrag vor? Wo sitzen seine Sub-Prozessoren?
• Wohin routet das Gateway im Standardfall – EU, Drittland, on-prem?
• Ist Semantic Caching mandantenscharf und für personenbezogene Flows deaktivierbar?

Ein Nebenkriterium mit governance-Gewicht: Ein Gateway im Wartungsmodus, ohne aktive Feature-Entwicklung, ist ein strategisches Risiko – gerade weil sich die Regulatorik-Landschaft im Halbjahrestakt verschiebt. Die einsetzende Standardisierung rund um offene Gateway-Projekte (etwa unter dem Dach der Linux Foundation) ist deshalb kein technisches Detail, sondern eine Compliance-Frage: Wer sich an ein proprietäres, eingefrorenes Produkt bindet, verliert die Fähigkeit, auf neue Pflichten schnell zu reagieren.

Der vollständige Business Case: Compliance ist nicht der einzige Hebel

Compliance rechtfertigt selten allein ein neues Infrastrukturbudget – gegenüber CFO oder Geschäftsführung zählt der Gesamtnutzen. Ein KI-Gateway liefert diesen Gesamtnutzen über mehrere Dimensionen, die sich unabhängig von der Regulatorik rechnen:

Kostenkontrolle als unmittelbarer Effekt. Agentische Workflows lösen pro User-Request oft zehn bis fünfzig LLM-Calls im Hintergrund aus – ohne zentrales Tracking bleibt das eine Blackbox. Ein Gateway macht diese Kosten sichtbar und erlaubt kostenbasiertes Routing: einfache Anfragen wandern automatisch zu günstigeren Modellen, teure Frontier-Modelle bleiben reserviert für Aufgaben, die sie wirklich brauchen. Semantic Caching senkt zusätzlich die Tokenkosten bei inhaltlich ähnlichen Wiederholungsanfragen spürbar – vorausgesetzt, es ist datenschutzkonform konfiguriert (siehe oben).

Architektonische Flexibilität. Ohne Gateway ist ein Providerwechsel ein Refactoring-Projekt: jede Integration, jeder Client-Code muss angepasst werden. Mit einem einheitlichen, meist OpenAI-kompatiblen Schema wird der Wechsel zu einer Konfigurationsänderung. Das zahlt sich doppelt aus: Bei Preissteigerungen eines Anbieters lässt sich kurzfristig umschichten, und die Organisation bleibt unabhängig von der Preis- und Modellpolitik eines einzelnen Herstellers.

Verfügbarkeit und Resilienz. Intelligentes Routing mit Failover und Loadbalancing verhindert, dass ein Ausfall oder Rate-Limit bei einem Provider gleich den gesamten KI-gestützten Prozess lahmlegt – relevant überall dort, wo KI bereits in Kundenprozesse oder interne Abläufe eingebettet ist und Ausfälle direkte Kosten verursachen.

Entwicklerproduktivität. Eine einheitliche Schnittstelle erspart Teams, für jeden Provider eigenen Integrationscode zu pflegen. Das reduziert nicht nur Entwicklungszeit, sondern auch die Zahl der Stellen, an denen sich Fehler und Sicherheitslücken einschleichen können.

Verhandlungsposition gegenüber Providern. Zentral konsolidierte Nutzungsdaten – wer verbraucht wie viel, zu welchen Konditionen, mit welchen Ausreißern – sind die Grundlage für bessere Vertragsverhandlungen. Wer nur fragmentierte Billing-Portale einzelner Teams hat, verhandelt aus einer schwächeren Position.

In der Summe ist der Business Case selten Compliance oder Kosten – es ist beides gleichzeitig, und beides hängt an derselben Infrastrukturentscheidung. Das macht die Investition leichter zu rechtfertigen: Ein Gateway, das ohnehin für Governance nötig ist, zahlt sich zusätzlich über Kosteneffizienz, Ausfallsicherheit und Entwicklungsgeschwindigkeit aus – und umgekehrt.

Bevor die Frist zur Fußnote wird

Der 2. August 2026 (EU AI Act, Art. 50), DORA und NIS2 stehen im gleichen Kalender wie Ihre Deployment-Roadmap. Verschaffen Sie sich einen Überblick, welche Pflicht wann greift – und ob Ihr KI-Einsatz überhaupt betroffen ist.

• → Regulatorischer Fristenkalender
• → KI-Risikobewertung starten

Fazit: Kontrollpunkt, nicht Freibrief

Das KI-Gateway ist die Voraussetzung für einen compliance-fähigen KI-Betrieb – aber es ist nicht die Compliance. Es ist der Ort, an dem sich DSGVO, EU AI Act, NIS2 und DORA technisch durchsetzen lassen: Datenminimierung, Protokollierung, Zugriffskontrolle, Transfersteuerung, Kennzeichnung. Und es ist derselbe Ort, an dem eine unbedachte Einführung ein neues, zentrales und vollständiges Datenschutzrisiko konzentriert.

Daraus folgt eine Reihenfolge, die in der Praxis regelmäßig umgedreht wird: erst das Governance-Konzept, dann die Technik. Zwecke, Rechtsgrundlagen, Aufbewahrungsfristen, AV-Verträge und Transfergrundlagen müssen definiert sein, bevor der Proxy live geht – sonst schafft das Werkzeug, das Transparenz herstellen soll, eine neue, gut dokumentierte Sammlung von Rechtsverstößen.

Wer das beherzigt, gewinnt mehr als Kostentransparenz. Er gewinnt den einen architektonischen Punkt, an dem sich auf die Frage „Wer verarbeitet hier wessen Daten, zu welchem Zweck, an welchem Ort?" eine belastbare Antwort geben lässt. In einem regulatorischen Umfeld, das genau diese Antwort verlangt, ist das kein Nice-to-have. Es ist die Eintrittskarte.