Datenaufbewahrungsfähiges KI-API-Routing: ZDR-, Aufenthalts- und Protokollierungsrichtlinien am Gateway durchsetzen

Sicherheitsteams müssen nicht nur wissen, welches Modell das günstigste, schnellste oder leistungsfähigste ist. Sie müssen wissen, ob eine bestimmte Anfrage rechtlich und betrieblich an einen bestimmten Anbieter, Endpunkt, eine bestimmte Region, eine bestimmte Funktion und einen bestimmten Protokollierungsmodus gesendet werden kann.

Das ist schwieriger als es klingt. Für gewöhnliche interne Chats ist ein Modell möglicherweise akzeptabel, für Kunden-PII jedoch nicht. Ein Anbieter bietet möglicherweise keine Datenaufbewahrung für einen API-Pfad an, während eine Funktion zur Sucherdung Eingabeaufforderungen und Ausgaben für einen festgelegten Zeitraum speichert. Eine Region unterstützt möglicherweise die Speicherresidenz, jedoch nicht den erwarteten Verarbeitungsmodus. Entwicklereigene Protokolle können möglicherweise konfiguriert werden, während Protokolle zur Missbrauchsüberwachung von Anbietern einer anderen Richtlinie folgen.

Die praktische Antwort besteht darin, Aufbewahrungsentscheidungen aus einzelnen Anwendungen in das AI API-Gateway zu verlagern. Das Gateway sollte die Anfrage klassifizieren, sie anhand einer Anbieterfähigkeitsmatrix bewerten, inkompatible Funktionen blockieren, nur an genehmigte Modellprofile weiterleiten und eine Richtlinienentscheidung aufzeichnen, ohne standardmäßig rohe Eingabeaufforderungen zu speichern.

Das Leserproblem: Die Datenschutzbestimmungen des Anbieters sind keine Laufzeitkontrollen

Die meisten Teams beginnen mit einer Tabelle oder einer Sicherheitsüberprüfung, aus der hervorgeht, welche KI-Anbieter zugelassen sind. Das ist nützlich, reicht aber für das Produktionsrouting nicht aus.

Anwendungen treffen Laufzeitentscheidungen:

• Welche Modell-ID soll diese Anfrage bearbeiten?
• Sollte die Anfrage Suchunterstützung, Datei-Upload, Codeausführung, Stapelverarbeitung, Zwischenspeicherung von Eingabeaufforderungen oder gespeicherte Konversationen verwenden?
• Welche Region oder welcher Endpunkt soll die Anfrage verarbeiten?
• Kann das System die Roheingabeaufforderung zum Debuggen protokollieren?
• Kann Fallback-Routing dieselbe Anfrage an einen anderen Anbieter senden?

Jede dieser Optionen kann das Aufbewahrungsprofil ändern. Eine Anfrage, die im einfachen Chat-Modus konform war, kann zu einer nicht konformen Anfrage werden, wenn der Entwickler die Sperrung oder dauerhafte Konversationsspeicherung aktiviert. Eine auf Zuverlässigkeit ausgelegte Fallback-Regel kann versehentlich regulierte Daten an einen Anbieterpfad weiterleiten, der nicht für keine Datenaufbewahrung, Datenresidenz oder Missbrauchsüberwachungskontrollen zugelassen ist.

Empfehlung: Behandeln Sie das Aufbewahrungsverhalten als erstklassige Routing-Beschränkung und nicht als Dokumentation, die an ein Anbieterkonto angehängt ist.

Fakten, die vor dem Entwerfen von Richtlinien kodiert werden müssen

Die genauen Bedingungen variieren je nach Anbieter, Produkt, Vertrag, Region, Endpunkt und Funktion. Verlassen Sie sich nicht auf Ihr Gedächtnis oder eine einmalige Rezension. Erstellen Sie eine quelleneigene Matrix und aktualisieren Sie sie, wenn sich Begriffe ändern.

Mehrere aktuelle Dokumente öffentlicher Anbieter veranschaulichen, warum dies notwendig ist:

• OpenAI: Die API-Datenresidenz wird als projektkonfiguriert dokumentiert, wobei regionale Anfragen regionalspezifische Domänenpräfixe erfordern. OpenAI unterscheidet außerdem die Speicherunterstützung von der Verarbeitungsunterstützung nach Region und weist auf zusätzliche Anforderungen für Nicht-US-Regionen hin. OpenAI gibt an, dass die Nicht-US-API-Datenresidenz eine Genehmigung für Missbrauchsüberwachungskontrollen und eine geänderte Aufbewahrungsänderung erfordert.
• Anthropic: Anthropic dokumentiert keine Datenaufbewahrung für API-bezogene kommerzielle Anwendungsfälle, weist jedoch darauf hin, dass einige verwandte Produkte oder Compliance-Feeds separate Aufbewahrungsmodelle haben, einschließlich einer längeren Aufbewahrung für Aktivitäts-Feeds und Remote-Sitzungsprotokolle.
• Google Gemini: Die Gemini-API-Begriffe unterscheiden zwischen unbezahlten und kostenpflichtigen Diensten. Bei unbezahlten Diensten kann Google übermittelte Inhalte und generierte Antworten zur Verbesserung von Produkten verwenden. Bei kostenpflichtigen Diensten werden Eingabeaufforderungen und Antworten laut Google nicht zur Verbesserung von Produkten verwendet. In der ZDR-Dokumentation der Gemini Developer API heißt es, dass in Protokollen zur Missbrauchsüberwachung kostenpflichtiger Dienste Eingabeaufforderungen und Antworten normalerweise für einen begrenzten Zeitraum gespeichert werden, während genehmigte ZDR-Projekte Benutzerinhalte und identifizierbare Metadaten vor der Protokollierung löschen.
• Funktionsspezifischer Speicher: In der Gemini-Dokumentation heißt es, dass „Grounding with Google Search“ und „Grounding with Google Maps“ Eingabeaufforderungen, Kontextinformationen und generierte Ausgaben 30 Tage lang speichern. Es besteht keine Möglichkeit, diesen Speicher zu deaktivieren, wenn diese Funktionen verwendet werden.
• Entwicklereigene Protokolle: In der Gemini-API-Protokollierungsdokumentation heißt es, dass entwicklereigene API-Protokolle für abrechnungsfähige Projekte standardmäßig bis zu 55 Tage aufbewahrt werden können und dass Entwickler kürzere Zeitfenster wie 7, 14 oder 28 Tage wählen können.
• Risikomanagement: Das Generative AI Profile des NIST empfiehlt, KI-generierte Inhalte auf Datenschutzrisiken zu überwachen und generative KI-Richtlinien mit bestehenden Daten-, Software-, Rechts-, Compliance- und Risikomanagementprozessen zu verknüpfen.

Dies sind Fakten, die vor der Einführung anhand der aktuellen Herstellerdokumentation überprüft werden müssen. Die architektonische Lektion ist stabil: Beibehaltung ist kein boolescher Wert auf Anbieterebene.

Architektur: eine Gateway-Richtlinien-Engine im Anforderungspfad

Ein aufbewahrungsfähiges Gateway besteht aus fünf Kernkomponenten:

1. Vertraulichkeitsklassifikator anfordern: beschriftet die Arbeitslast vor dem Routing.
2. Anbieterfähigkeitsmatrix: beschreibt Anbieter, Modell, Endpunkt, Region, Aufbewahrung, Protokollierung und Funktionsverhalten.
3. Policy-as-Code-Regeln: Wandeln Sie Sicherheitsanforderungen in Laufzeitentscheidungen zum Zulassen, Verweigern oder Überprüfen um.
4. Feature-Gate-Ebene: blockiert Funktionen, die die Aufbewahrung ändern, sofern dies nicht ausdrücklich erlaubt ist.
5. Audit- und Analyseschicht: zeichnet nützliche Metadaten auf, ohne standardmäßig Roheingabeaufforderungen zu speichern.

Das Gateway muss nicht jede rechtliche Nuance verstehen. Es muss die Entscheidungen durchsetzen, die Ihre Rechts-, Sicherheits-, Compliance- und Plattformteams genehmigt haben.

Schritt 1: Klassifizieren Sie die Empfindlichkeit der Anfrage, bevor Sie ein Modell auswählen

Beginnen Sie mit einer kleinen Klassifizierungstaxonomie. Es sollte für Entwickler einfach genug sein, aber ausdrucksstark genug, um Richtlinien voranzutreiben.

Beispiele für Vertraulichkeitsbezeichnungen:

• öffentlich: öffentliche Dokumentation, Marketingtext, öffentlicher Website-Inhalt.
• intern: nicht öffentliche Unternehmensinformationen mit geringer Sensibilität.
• vertraulich: Strategie, Verträge, Kundenkontext, unveröffentlichte Produktdetails.
• customer_pii: Namen, E-Mails, Adressen, Kontokennungen, Supportprotokolle.
• reguliert: Gesundheits-, Finanz-, Rechts-, Bildungs- oder rechtsgebietsspezifische geschützte Daten.
• source_code: proprietärer Code, Konfiguration, Architekturdateien.
• Anmeldeinformationen: Geheimnisse, Token, Passwörter, private Schlüssel. In den meisten Systemen sollte dies blockiert und nicht weitergeleitet werden.

Die Klassifizierung kann aus mehreren Quellen stammen:

• Ein von der Anwendung bereitgestellter Header, z. B. X-Data-Class: customer_pii.
• Mandantenrichtlinie, bei der der gesamte Datenverkehr eines regulierten Kunden als reguliert behandelt wird, sofern er nicht durch eine genehmigte Regel herabgestuft wird.
• Endpunktrichtlinie, bei der die Support-Ticket-Zusammenfassung standardmäßig customer_pii ist.
• Einfaches Scannen von Inhalten auf Anmeldeinformationen, offensichtliche personenbezogene Daten oder Richtlinienverstöße.

Empfehlung: Verlassen Sie sich nicht ausschließlich auf die automatische Erkennung. Fordern Sie Anwendungen auf, die beabsichtigte Datenklasse zu deklarieren, und verwenden Sie dann das Scannen, um offensichtliche Nichtübereinstimmungen zu erkennen oder eine sicherere Klasse zu erzwingen.

Schritt 2: Erstellen Sie eine Anbieterfähigkeitsmatrix

Die Fähigkeitsmatrix ist die Quelle der Wahrheit, die der Router auswertet. Es sollte wie eine Produktionskonfiguration versioniert, überprüft und getestet werden.

Beispielfelder:

{
  „profile_id“: „provider_x.chat.eu.zdr“,
  „provider“: „provider_x“,
  „model“: „model-large“,
  „api_family“: „chat_completions“,
  „endpoint“: „https://eu.example-provider.com/v1“,
  „region“: „eu“,
  „processing_sidency“: [„eu“],
  „storage_residence“: [„eu“],
  „zdr_eligible“: wahr,
  „zdr_contract_required“: wahr,
  „training_use“: „not_used_for_training_on_paid_api“,
  „abuse_monitoring“: „approved_modified_retention_required“,
  „developer_log_retention_days“: 0,
  „raw_prompt_logging_allowed“: false,
  „supported_features“: {
    „plain_chat“: wahr,
    „Streaming“: wahr,
    „tool_calls“: wahr,
    „search_grounding“: false,
    „maps_grounding“: false,
    „file_upload“: false,
    „Batch“: falsch,
    „stored_conversations“: false
  },
  „last_reviewed“: „01.08.2026“,
  „source_refs“: [„security-review-123“, „vendor-doc-version-abc“]

Verwenden Sie Modellprofile anstelle von Rohmodell-IDs. Ein Profil kombiniert Modell, Anbieter, Endpunkt, Region, Funktionsumfang und Aufbewahrungsstatus. Entwickler fordern model_profile: Compliant_summarization, nicht nur model: fastest-large-model.

Empfehlung: Vertragsvoraussetzungen in die Matrix aufnehmen. Eine Route ist nicht ZDR-zugelassen, nur weil ein Anbieter irgendwo ZDR anbietet. Die Genehmigung erfolgt nur, wenn Ihr Konto, Projekt, Ihre Region und Ihr Endpunkt die erforderlichen Bedingungen erfüllen.

Schritt 3: Policy-as-Code-Regeln schreiben

Richtlinienregeln sollten explizit, testbar und für Sicherheits- und Plattformteams lesbar sein.

Beispielregeln im Pseudocode:

deny if data_class == "credentials"
  Grund „credentials_must_not_be_sent_to_model“
Nur zulassen, wenn data_class in ["regulated", "customer_pii"] ist
  und Profile.zdr_eligible == true
  und Profile.zdr_contract_required_satisfied == true
  reason_on_failure „model_profile_not_zdr_eligible“
verweigern, wenn residentency_required == "eu"
  und „eu“ nicht in „profile.processing_residency“.
  Grund „region_processing_not_supported“
verweigern, wenn data_class in [„confidential“, „customer_pii“, „regulated“]und request.raw_prompt_logging == true
  Grund „raw_prompt_logging_not_allowed“
verweigern, wenn request.features.search_grounding == true
  und Policy.requires_zdr == true
  und profile.feature_storage.search_grounding_days > 0
  Grund „grounding_requires_retained_content“
verweigern, wenn fallback_profile.retention_level < Primary_profile.retention_level
  Grund „fallback_weakens_retention_policy“

Diese Regeln sollten vor der Anbieterauswahl und erneut vor dem Fallback ausgeführt werden. Fallback-Routing ist eine häufige Ursache für versehentliche Richtlinienabweichungen: Die primäre Route ist möglicherweise konform, während die Fallback-Route lediglich verfügbar ist.

Schritt 4: Behandeln Sie Tools und Funktionen als bindungsverändernde Funktionen

Modellieren Sie die Aufbewahrung nicht allein als Eigenschaft des Basismodells. Funktionen ändern häufig das Speicher-, Protokollierungs- oder Überprüfungsverhalten.

Geben Sie jeder Funktion ihre eigenen Richtlinienflags:

• Sucherdung: kann je nach Anbieterbedingungen Eingabeaufforderungen, abgerufenen Kontext und generierte Ausgaben speichern.
• Karten oder Standortbeschränkungen: können standortspezifische Protokolle oder Aufbewahrungsregeln einführen.
• Datei-Upload: kann Dateien getrennt von Eingabeaufforderungen und Antworten speichern.
• Codeausführung: kann temporäre Dateien, Ausführungsprotokolle oder Sandbox-Artefakte erstellen.
• Batch-Jobs: können ein anderes Aufbewahrungs-, Warteschlangen- und Ergebnisspeicherverhalten aufweisen als synchrone API-Aufrufe.
• Gespeicherte Konversationen: Inhalte bleiben absichtlich erhalten und sollten niemals hinter einer generischen Chat-Option versteckt werden.
• Bewertungs- oder Überprüfungsdashboards: können Arbeitsabläufe für die menschliche Überprüfung oder langlebigere Datensätze erstellen.

Empfehlung: Aktivieren Sie die Funktion zur Aufbewahrungsänderung auf Mandanten- und Routenebene. Wenn ein Entwickler grounding_search=true aktiviert, sollte das Gateway die Anfrage erneut anhand der Feature-Speicherregeln bewerten, bevor es sie an den Upstream sendet.

Schritt 5: Behalten Sie die Analysen bei, ohne rohe Eingabeaufforderungen zu speichern

Aufbewahrungsbewusstes Routing sollte das Plattformteam nicht blenden. Sie können nützliche KI-Nutzungsanalysen durchführen und gleichzeitig den Inhaltsspeicher minimieren.

Sichere Standardtelemetriefelder:

• Mandanten-ID und Projekt-ID
• gehashte oder interne API-Schlüssel-ID
• Modellprofil-ID und Anbieter-ID
• Zeitstempel und Region anfordern
• Anzahl der Eingabe-, Ausgabe-, zwischengespeicherten und Begründungstoken, sofern verfügbar
• Latenz, Statuscode, Anzahl der Wiederholungsversuche und Fallback-Entscheidung
• geschätzte und abgerechnete Kosten
• Datenklassifizierungsbezeichnung
• Richtlinienversion und Richtlinienentscheidungsgrund
• Feature-Flags angefordert und Feature-Flags erlaubt

Vermeiden Sie die standardmäßige Speicherung von Roheingabeaufforderungen und Modellausgaben für vertraulichen Datenverkehr. Wenn zum Debuggen Inhalte erforderlich sind, verwenden Sie einen kontrollierten Workflow:

• Genehmigung durch den Kunden oder Mieter
• enges Zeitfenster
• Probenahmelimit
• Redaktionsdurchlauf
• separate Zugangskontrolle
• kurzer Ablauf
• Überwachungsprotokoll darüber, wer es aktiviert hat und warum

Dies ist ein Kompromiss. Das Blockieren von unformatierten Eingabeaufforderungsprotokollen erschwert das Debuggen, den Support, die Qualitätsprüfung und die Untersuchung von Missbrauch. Aber wenn alles standardmäßig gespeichert wird, entsteht eine größere Oberfläche für Datenschutz, Verstöße und Compliance.

Schritt 6: Umsetzbare Ablehnungsgründe zurückgeben

Ein allgemeiner 403 verboten frustriert Entwickler und ermutigt zu Problemumgehungen. Geben Sie einen stabilen, maschinenlesbaren Grund und eine für Menschen lesbare Erklärung zurück.

Beispielantwort:

{
  „Fehler“: {
    „type“: „policy_denied“,
    „code“: „grounding_requires_30_day_storage“,
    „message“: „Suchsperre ist für Workloads mit der Markierung „requires_zdr“ nicht zulässig, da diese Anbieterfunktion Eingabeaufforderungs-, Kontext- und Ausgabeinhalte speichert.“,
    „request_id“: „req_123“,
    „policy_version“: „retention-policy-2026-08-01“,
    „allowed_actions“: [
      „disable_search_grounding“,
      „choose_profile:zdr_plain_chat“,
      „request_Exception“
    ]
  }

Nützliche Ablehnungscodes sind:

• model_profile_not_zdr_eligible
• region_processing_not_supported
• storage_residence_not_supported
• raw_prompt_logging_not_allowed
• feature_requires_content_storage
• fallback_weakens_retention_policy
• contract_prerequisite_missing
• credentials_detected

Schritt 7: Fügen Sie einen Ausnahme-Workflow hinzu, keine versteckte Umgehung

Einige Ausnahmen sind legitim: Reaktion auf Vorfälle, vom Kunden genehmigtes Debugging, Migrationstests oder eine vorübergehende Anbieterbeschränkung. Das Gateway sollte Ausnahmen unterstützen, ohne sie in permanente Schattenrichtlinien umzuwandeln.

Jede Ausnahme sollte Folgendes enthalten:

• Genehmigeridentität
• anforderndes Team oder Mieter
• Ticket- oder Risikobewertungslink
• geschäftliche Begründung
• Zulässige Modellprofile und Funktionen
• abgedeckte Datenklassen
• Ablaufdatum
• zusätzliche Protokollierungsanforderungen

Empfehlung: Ausnahmen enger fassen als normale Richtlinien. Vermeiden Sie globale Schalter wie disable_retention_policy=true. Bevorzugen Sie bereichsbezogene Außerkraftsetzungen wie „Erlauben Sie die Protokollierung von Debug-Eingabeaufforderungen für Mandant A, Endpunkt B, für 24 Stunden, mit Schwärzung und Sicherheitsgenehmigung.“

Betriebscheckliste

• Erstellen Sie eine versionierte Anbieterfähigkeitsmatrix.
• Weisen Sie einen Eigentümer für Anbieterbedingungen, Vertragsvoraussetzungen und Aufbewahrungsüberprüfungen zu.
• Anwendungen müssen die Datenklasse, die Wohnsitzanforderungen und die angeforderten Funktionen angeben.
• Standardmäßig wird vertraulicher und regulierter Datenverkehr ohne Protokollierung von Rohaufforderungen eingestellt.
• Stellen Sie Tools, Grounding, Datei-Upload, Batch und gespeicherte Konversationen als separate Funktionsflags dar.
• Führen Sie Richtlinienprüfungen vor dem primären Routing und vor dem Fallback-Routing aus.
• Protokollieren Sie Richtlinienversion, Modellprofil, Datenklasse, Funktionsflags und Ablehnungsgrund.
• Halten Sie Analysemetadaten vom Eingabeaufforderungs- und Ausgabeinhalt getrennt.
• Testvertreter erlauben und verweigern Fälle in CI.
• Überprüfen Sie Richtlinienabweichungen, wenn ein Anbieter Bedingungen, Regionen, Endpunkte oder Funktionen ändert.

Kompromisse, die explizit gemacht werden müssen

Striktes Routing verringert die Auswahl. ZDR- und Wohnsitzbeschränkungen können die Verwendung des neuesten Modells, der kostengünstigsten Route oder eines funktionsreichen Endpunkts verhindern.

Regionales Routing kann die Latenz oder die Kosten erhöhen. Die nächstgelegene kompatible Region unterstützt möglicherweise nicht den gewünschten Verarbeitungsmodus oder erfordert möglicherweise einen anderen Anbieterpfad.

Feature-Gates überraschen Entwickler. Ein Entwickler könnte denken, dass er nur die Suche aktiviert, aber aus Sicherheitsgründen erkennt er ein neues Aufbewahrungsverhalten. Dokumentation und Ablehnungsnachrichten verringern die Reibung.

Eine zeitnahe Minimierung erschwert das Debuggen. Teams benötigen redigierte Beispiele, vom Mandanten genehmigte Debug-Fenster und starke Metadaten, um Probleme zu untersuchen, ohne alles zu speichern.

Die Matrix muss gewartet werden. Die Bedingungen des Anbieters ändern sich. Neue Modelle kommen auf den Markt. Regionen expandieren. Funktionen werden von der Beta-Phase in die Produktion verschoben. Eine veraltete Matrix ist schlimmer als keine Matrix, weil sie falsches Vertrauen schafft.

Was ist eine Empfehlung und was ist eine Vorhersage?

Empfehlungen: erzwingen Sie die Aufbewahrung am Gateway, klassifizieren Sie Anfragen vor der Weiterleitung, erstellen Sie eine Anbieterfähigkeitsmatrix, blockieren Sie die Aufbewahrung ändernde Funktionen nach Richtlinien, vermeiden Sie standardmäßig die Rohprotokollierung von Eingabeaufforderungen und versionieren Sie jede Richtlinienentscheidung.

Vorhersage: KI-Plattformteams werden den Datenschutz zunehmend als Teil der Modellauswahl berücksichtigen. Anstatt zu fragen: „Welches Modell sollten wir verwenden?“ Anwendungen fragen nach einem Modellprofil, das die Einschränkungen in Bezug auf Funktionalität, Kosten, Latenz, Aufenthaltsort und Aufbewahrung erfüllt.

Vorhersage: Die anbieterspezifischen Datenschutzfunktionen werden weiterhin unterschiedlich sein. Gateways, die nur Anfrage- und Antwortformate normalisieren, werden nicht ausreichen; Produktionsteams benötigen ebenfalls eine Normalisierung der Richtlinien.

Umsetzbare Schlussfolgerung

Datenaufbewahrungsbewusstes Routing ist kein separates Compliance-Dashboard. Es gehört in den Anforderungspfad.

Beginnen Sie mit drei Ergebnissen: einer Anforderungssensitivitätstaxonomie, einer versionierten Anbieterfähigkeitsmatrix und einem kleinen Satz von Policy-as-Code-Regeln für ZDR, Residenz, Rohprotokollierung, Fallback und Funktionen zur Aufbewahrungsänderung. Stellen Sie dann sicher, dass das Gateway eindeutige Ablehnungsgründe zurückgibt und die Analysen beibehalten, ohne standardmäßig Rohinhalte zu speichern.

Dieses Design zentralisiert Entscheidungen, die sonst über SDK-Optionen, Umgebungsvariablen, Anbieterkonsolen und teamspezifische Konventionen verstreut wären. Außerdem erhalten Sicherheits- und Plattformteams einen praktischen Prüfpfad: Welche Anfrage wurde zugelassen, welche Richtlinienversion angewendet, welches Modellprofil ausgewählt wurde und warum.

Verwandte Lektüre

• sichere Eingabeaufforderungsprotokollierung und Nutzung auf Gateway-Ebene Analytics
• Aufbau einer Anbieterfähigkeitsmatrix während einer OpenAI-kompatiblen API-Migration
• Steuerung von Agententools mit Bereichen, Genehmigungen und Prüfpfaden