Dataretentiebewuste AI API-routering: dwing ZDR-, ingezetenschap- en logboekbeleid af bij de gateway

Beveiligingsteams moeten niet alleen weten welk model het goedkoopste, snelste of meest capabele is. Ze moeten weten of een specifiek verzoek juridisch en operationeel naar een specifieke provider, eindpunt, regio, functie en logmodus kan worden verzonden.

Dat is moeilijker dan het klinkt. Een model kan acceptabel zijn voor gewone interne chat, maar niet voor PII van klanten. Een provider kan geen gegevensretentie aanbieden voor één API-pad, terwijl een functie voor het aarden van zoekopdrachten aanwijzingen en uitvoer voor een vaste periode opslaat. Een regio ondersteunt mogelijk opslaglocatie, maar niet de verwerkingsmodus die u verwachtte. Logboeken die eigendom zijn van ontwikkelaars kunnen configureerbaar zijn, terwijl logboeken voor misbruikmonitoring van de provider een ander beleid volgen.

Het praktische antwoord is om bewaarbeslissingen uit individuele applicaties te verplaatsen naar de AI API-gateway. De gateway moet het verzoek classificeren, evalueren aan de hand van een matrix met mogelijkheden van een provider, incompatibele functies blokkeren, alleen doorsturen naar goedgekeurde modelprofielen en een beleidsbeslissing vastleggen zonder standaard ruwe aanwijzingen op te slaan.

Het lezersprobleem: de privacyvoorwaarden van de provider zijn geen runtime-controles

De meeste teams beginnen met een spreadsheet of beveiligingsbeoordeling waarin staat welke AI-providers zijn goedgekeurd. Dat is handig, maar niet genoeg voor productierouting.

Applicaties maken runtime-keuzes:

• Welke model-ID moet dit verzoek afhandelen?
• Moet het verzoek gebruikmaken van zoekbasis, bestandsupload, code-uitvoering, batchverwerking, promptcaching of opgeslagen gesprekken?
• Welke regio of eindpunt moet het verzoek verwerken?
• Kan het systeem de onbewerkte prompt voor foutopsporing registreren?
• Kan fallback-routing hetzelfde verzoek naar een andere provider sturen?

Elk van deze keuzes kan het bewaarprofiel wijzigen. Een verzoek dat in de gewone chatmodus aan de regels voldoet, kan niet-conform worden wanneer de ontwikkelaar aarding of permanente gespreksopslag inschakelt. Een fallback-regel die is ontworpen voor betrouwbaarheid kan gereguleerde gegevens per ongeluk routeren naar een providerpad dat niet is goedgekeurd voor nulgegevensretentie, gegevenslocatie of controle op misbruik.

Aanbeveling: behandel bewaargedrag als een eersteklas routeringsbeperking, niet als documentatie die is gekoppeld aan een provideraccount.

Feiten die moeten worden gecodeerd voordat beleid wordt ontworpen

De exacte voorwaarden variëren per provider, product, contract, regio, eindpunt en functie. Vertrouw niet op geheugen of een eenmalige beoordeling. Bouw een matrix die eigendom is van de bron en update deze wanneer de voorwaarden veranderen.

Verschillende huidige documenten van openbare aanbieders illustreren waarom dit nodig is:

• OpenAI: API gegevenslocatie is gedocumenteerd als projectgeconfigureerd, waarbij regionale verzoeken regiospecifieke domeinvoorvoegsels vereisen. OpenAI maakt ook onderscheid tussen opslagondersteuning en verwerkingsondersteuning per regio en vermeldt aanvullende vereisten voor niet-Amerikaanse regio's. OpenAI stelt dat niet-Amerikaanse API datalocatie goedkeuring vereist voor controles op misbruik en een aangepast retentieamendement.
• Anthropic: Anthropic documenteert geen gegevensretentie voor API-gerelateerde commerciële gebruiksscenario's, maar merkt op dat sommige gerelateerde producten of nalevingsfeeds afzonderlijke bewaarmodellen hebben, waaronder langere bewaartermijnen voor activiteitenfeeds en transcripties van sessies op afstand.
• Google Gemini: Gemini API termen maken onderscheid tussen onbetaalde en betaalde services. Voor onbetaalde diensten mag Google ingediende inhoud en gegenereerde reacties gebruiken om producten te verbeteren; voor betaalde services zegt Google dat prompts en reacties niet worden gebruikt om producten te verbeteren. Gemini Ontwikkelaar API ZDR-documentatie zegt dat logboeken voor misbruikcontrole van betaalde services normaal gesproken aanwijzingen en antwoorden gedurende een beperkte periode bewaren, terwijl goedgekeurde ZDR-projecten gebruikersinhoud en identificeerbare metagegevens wissen voordat ze worden geregistreerd.
• Functiespecifieke opslag: Gemini documentatie stelt dat Grounding with Google Search en Grounding with Google Maps aanwijzingen, contextuele informatie en gegenereerde uitvoer gedurende 30 dagen opslaan, zonder dat deze opslag kan worden uitgeschakeld wanneer deze functies worden gebruikt.
• Logboeken van ontwikkelaars: Gemini API logboekdocumentatie zegt dat logboeken van API die eigendom zijn van de ontwikkelaar standaard maximaal 55 dagen kunnen worden bewaard voor projecten waarvoor facturering is ingeschakeld en dat ontwikkelaars kortere perioden kunnen kiezen, zoals 7, 14 of 28 dagen.
• Risicobeheer: Het Generatieve AI-profiel van NIST raadt aan om door AI gegenereerde inhoud te monitoren op privacyrisico's en het beleid inzake generatieve AI te koppelen aan bestaande gegevens-, software-, juridische, compliance- en risicobeheerprocessen.

Dit zijn feiten die vóór de implementatie moeten worden geverifieerd aan de hand van de huidige leveranciersdocumentatie. De architectuurles is stabiel: retentie is niet één Booleaanse waarde op providerniveau.

Architectuur: een gateway-beleidsengine in het verzoekpad

Een retentiebewuste gateway heeft vijf kerncomponenten:

1. Verzoekgevoeligheidsclassificatie: labelt de werklast vóór routering.
2. Matrix voor providermogelijkheden: beschrijft provider, model, eindpunt, regio, retentie, logboekregistratie en functiegedrag.
3. Beleid-als-code-regels: zet beveiligingsvereisten om in beslissingen over het toestaan, weigeren of beoordelen van runtime.
4. Feature Gate Layer: blokkeert retentie-veranderende features tenzij expliciet toegestaan.
5. Audit- en analyselaag: registreert nuttige metagegevens zonder standaard ruwe aanwijzingen op te slaan.

De gateway hoeft niet elke juridische nuance te begrijpen. Het moet de beslissingen afdwingen die uw juridische, beveiligings-, compliance- en platformteams hebben goedgekeurd.

Stap 1: classificeer de verzoekgevoeligheid voordat u een model selecteert

Begin met een kleine classificatietaxonomie. Het moet eenvoudig genoeg zijn voor ontwikkelaars om te gebruiken, maar expressief genoeg om beleid te sturen.

Voorbeeld van gevoeligheidslabels:

• public: openbare documentatie, marketingteksten, inhoud van openbare websites.
• internal: niet-openbare bedrijfsinformatie met lage gevoeligheid.
• confidential: strategie, contracten, klantcontext, niet-vrijgegeven productdetails.
• customer_pii: namen, e-mailadressen, adressen, account-ID's, ondersteuningstranscripties.
• regulated: gezondheidszorg-, financiële, juridische, onderwijs- of rechtsgebiedspecifieke beschermde gegevens.
• source_code: eigen code, configuratie, architectuurbestanden.
• credentials: geheimen, tokens, wachtwoorden, privésleutels. In de meeste systemen moet dit worden geblokkeerd en niet worden gerouteerd.

Classificatie kan uit meerdere bronnen komen:

• Een door de applicatie geleverde header, zoals X-Data-Class: customer_pii.
• Tenantbeleid, waarbij al het verkeer van een gereguleerde klant wordt behandeld als gereguleerd tenzij het wordt gedowngraded door een goedgekeurde regel.
• Eindpuntbeleid, waarbij de samenvatting van supporttickets standaard is ingesteld op customer_pii.
• Lichte inhoudsscans op inloggegevens, duidelijke PII of beleidsschendingen.

Aanbeveling: zijn niet volledig afhankelijk van automatische detectie. Vereist dat applicaties de beoogde gegevensklasse declareren en gebruik vervolgens scannen om duidelijke mismatches op te sporen of een veiligere klasse te forceren.

Stap 2: bouw een matrix met providercapaciteiten

De mogelijkhedenmatrix is de bron van waarheid die de router evalueert. Het moet worden bijgewerkt, beoordeeld en getest zoals de productieconfiguratie.

Voorbeeldvelden:

{
  "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_residency": ["eu"],
  "storage_residency": ["eu"],
  "zdr_eligible": true,
  "zdr_contract_required": true,
  "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": true,
    "streaming": true,
    "tool_calls": true,
    "search_grounding": false,
    "maps_grounding": false,
    "file_upload": false,
    "batch": false,
    "stored_conversations": false
  },
  "last_reviewed": "2026-08-01",
  "source_refs": ["security-review-123", "vendor-doc-version-abc"]
}

Gebruik modelprofielen in plaats van onbewerkte model-ID's. Een profiel combineert model, provider, eindpunt, regio, functieset en retentiehouding. Ontwikkelaars vragen model_profile: compliant_summarization, niet alleen model: fastest-large-model.

Aanbeveling: neem contractuele vereisten op in de matrix. Een route is niet ZDR-goedgekeurd alleen maar omdat een leverancier ergens ZDR aanbiedt. Het wordt alleen goedgekeurd als uw account, project, regio en eindpunt aan de vereiste voorwaarden voldoen.

Stap 3: schrijf beleid-als-code-regels

Beleidsregels moeten expliciet, testbaar en leesbaar zijn voor beveiligings- en platformteams.

Voorbeeldregels in pseudocode:

deny if data_class == "credentials"
  reason "credentials_must_not_be_sent_to_model"

allow only if data_class in ["regulated", "customer_pii"]
  and profile.zdr_eligible == true
  and profile.zdr_contract_required_satisfied == true
  reason_on_failure "model_profile_not_zdr_eligible"

deny if residency_required == "eu"
  and "eu" not in profile.processing_residency
  reason "region_processing_not_supported"

deny if data_class in ["confidential", "customer_pii", "regulated"]
  and request.raw_prompt_logging == true
  reason "raw_prompt_logging_not_allowed"

deny if request.features.search_grounding == true
  and policy.requires_zdr == true
  and profile.feature_storage.search_grounding_days > 0
  reason "grounding_requires_retained_content"

deny if fallback_profile.retention_level < primary_profile.retention_level
  reason "fallback_weakens_retention_policy"

Deze regels moeten worden uitgevoerd vóór de providerselectie en opnieuw vóór de fallback. Fallback-routering is een veel voorkomende bron van onbedoelde beleidsafwijkingen: de primaire route voldoet mogelijk aan de regels, terwijl de fallback-route alleen maar beschikbaar is.

Stap 4: behandel tools en functies als mogelijkheden om de retentie te veranderen

Modeleer retentie niet als een eigenschap van het basismodel alleen. Functies veranderen vaak het opslag-, logboek- of beoordelingsgedrag.

Geef elke functie zijn eigen beleidsvlaggen:

• Zoekgronding: kan aanwijzingen, opgehaalde context en gegenereerde uitvoer opslaan, afhankelijk van de termen van de provider.
• Kaarten of locatie-gronding: kan locatiespecifieke logboeken of bewaarregels introduceren.
• Bestanden uploaden: kan bestanden afzonderlijk van prompts en reacties opslaan.
• Code-uitvoering: kan tijdelijke bestanden, uitvoeringslogboeken of sandbox-artefacten maken.
• Batchtaken: kunnen een ander bewaar-, wachtrij- en resultaatopslaggedrag vertonen dan synchrone API-oproepen.
• Opgeslagen gesprekken: houden de inhoud opzettelijk vast en mogen nooit verborgen worden achter een algemene chatoptie.
• Evaluatie- of beoordelingsdashboards: kunnen workflows voor menselijke beoordeling of datasets met een langere levensduur creëren.

Aanbeveling: zorg ervoor dat functies die de retentie wijzigen zich aanmelden op tenant- en routeniveau. Als een ontwikkelaar grounding_search=true inschakelt, moet de gateway het verzoek opnieuw beoordelen aan de hand van functieopslagregels voordat het upstream wordt verzonden.

Stap 5: analyses bewaren zonder onbewerkte aanwijzingen op te slaan

Retentiebewuste routering mag het platformteam niet verblinden. U kunt nuttige AI-gebruiksanalyses behouden terwijl u de inhoudsopslag minimaliseert.

Veilige standaardtelemetrievelden:

• huurder-ID en project-ID
• gehashte of interne API sleutel-ID
• modelprofiel-ID en provider-ID
• tijdstempel en regio aanvragen
• Aantallen invoer-, uitvoer-, in het cachegeheugen opgeslagen en redeneringstokens, indien beschikbaar
• latentie, statuscode, aantal nieuwe pogingen en reservebeslissing
• geschatte en verrekende kosten
• gegevensclassificatielabel
• beleidsversie en reden van beleidsbeslissing
• functievlaggen aangevraagd en functievlaggen toegestaan

Vermijd standaard het opslaan van onbewerkte aanwijzingen en modeluitvoer voor vertrouwelijk verkeer. Als voor foutopsporing inhoud nodig is, gebruik dan een gecontroleerde workflow:

• goedkeuring van klant of huurder
• beperkte tijdsperiode
• steekproeflimiet
• redactiepas
• aparte toegangscontrole
• korte vervaldatum
• controlelogboek van wie dit heeft ingeschakeld en waarom

Dit is een afweging. Het blokkeren van onbewerkte promptlogboeken maakt foutopsporing, ondersteuning, kwaliteitsbeoordeling en onderzoek naar misbruik moeilijker. Maar als u alles standaard opslaat, ontstaat er een groter oppervlak voor privacy, inbreuk en naleving.

Stap 6: retourneer bruikbare weigeringsredenen

Een generieke 403 forbidden frustreert ontwikkelaars en moedigt oplossingen aan. Retourneer een stabiele, machinaal leesbare reden en een voor mensen leesbare uitleg.

Voorbeeldantwoord:

{
  "error": {
    "type": "policy_denied",
    "code": "grounding_requires_30_day_storage",
    "message": "Search grounding is not allowed for workloads marked requires_zdr because this provider feature stores prompt, context, and output content.",
    "request_id": "req_123",
    "policy_version": "retention-policy-2026-08-01",
    "allowed_actions": [
      "disable_search_grounding",
      "choose_profile:zdr_plain_chat",
      "request_exception"
    ]
  }
}

Handige weigeringscodes zijn onder meer:

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

Stap 7: voeg een uitzonderingsworkflow toe, geen verborgen bypass

Sommige uitzonderingen zijn legitiem: reactie op incidenten, door de klant goedgekeurde foutopsporing, migratietests of een tijdelijke providerbeperking. De gateway moet uitzonderingen ondersteunen zonder deze om te zetten in permanent schaduwbeleid.

Elke uitzondering moet het volgende bevatten:

• Identiteit van de goedkeurder
• verzoekend team of huurder
• ticket- of risicobeoordelingslink
• zakelijke rechtvaardiging
• toegestane modelprofielen en -functies
• gedekte gegevensklassen
• vervaldatum
• aanvullende logboekvereisten

Aanbeveling: maak uitzonderingen beperkter dan gewoon beleid. Vermijd globale schakelaars zoals disable_retention_policy=true. Geef de voorkeur aan bereikoverschrijvingen, zoals 'logboekregistratie van foutopsporingsprompts toestaan voor tenant A, eindpunt B, gedurende 24 uur, met redactie en beveiligingsgoedkeuring.'

Operationele checklist

• Maak een matrix met de mogelijkheden van een provider met versiebeheer.
• Wijs een eigenaar toe voor de voorwaarden van de provider, contractvoorwaarden en retentiebeoordelingen.
• Vereisen dat applicaties de gegevensklasse, ingezetenschapsvereiste en aangevraagde functies declareren.
• Standaard vertrouwelijk en gereguleerd verkeer zonder onbewerkte promptregistratie.
• Representeer tools, aarding, bestandsupload, batch- en opgeslagen gesprekken als afzonderlijke mogelijkhedenvlaggen.
• Voer beleidscontroles uit vóór primaire routering en vóór fallback-routering.
• Logboekbeleidversie, modelprofiel, gegevensklasse, functievlaggen en reden van weigering.
• Houd analytische metadata gescheiden van prompt- en uitvoerinhoud.
• Testvertegenwoordiger staat cases in CI toe en weigert deze.
• Bekijk de beleidsafwijking wanneer een provider voorwaarden, regio's, eindpunten of functies wijzigt.

Afwegingen om expliciet te maken

Strikte routering vermindert de keuze. ZDR- en verblijfsbeperkingen kunnen het gebruik van het nieuwste model, de goedkoopste route of een eindpunt met veel functies verhinderen.

Regionale routering kan de latentie of de kosten verhogen. De dichtstbijzijnde compatibele regio ondersteunt mogelijk niet de gewenste verwerkingsmodus, of vereist mogelijk een ander providerpad.

Functiepoorten verrassen ontwikkelaars. Een ontwikkelaar denkt misschien dat ze alleen zoeken inschakelen, maar de beveiliging ziet een nieuw bewaargedrag. Documentatie en weigeringsberichten verminderen de wrijving.

Prompte minimalisatie bemoeilijkt het opsporen van fouten. Teams hebben geredigeerde voorbeelden, door de huurder goedgekeurde foutopsporingsvensters en sterke metagegevens nodig om problemen te onderzoeken zonder alles op te slaan.

De matrix vereist onderhoud. Providervoorwaarden veranderen. Lancering van nieuwe modellen. Regio's breiden zich uit. Functies gaan van bèta naar productie. Een verouderde matrix is erger dan geen matrix, omdat het vals vertrouwen schept.

Wat is een aanbeveling en wat is een voorspelling?

Aanbevelingen: dwing retentie af bij de gateway, classificeer verzoeken voordat ze worden doorgestuurd, bouw een matrix met providercapaciteiten, blokkeer retentie-veranderende functies per beleid, vermijd standaard logboekregistratie van onbewerkte prompts en versie elke beleidsbeslissing.

Voorspelling: AI-platformteams zullen de privacyhouding steeds meer beschouwen als onderdeel van de modelselectie. In plaats van te vragen “welk model moeten we gebruiken?” toepassingen vragen om een modelprofiel dat voldoet aan de beperkingen op het gebied van mogelijkheden, kosten, latentie, verblijfplaats en retentie.

Voorspelling: providerspecifieke privacyfuncties zullen blijven uiteenlopen. Gateways die alleen verzoek- en antwoordformaten normaliseren zullen niet voldoende zijn; productieteams zullen ook beleidsnormalisatie nodig hebben.

Conclusie waar actie op ondernomen kan worden

Gegevensretentiebewuste routering is geen afzonderlijk nalevingsdashboard. Het hoort thuis in het verzoekpad.

Begin met drie resultaten: een taxonomie voor de gevoeligheid van verzoeken, een matrix voor de mogelijkheden van een provider met versiebeheer en een kleine set beleid-als-code-regels voor ZDR, residentie, onbewerkte logboekregistratie, fallback en functies voor het wijzigen van de retentie. Zorg er vervolgens voor dat de gateway duidelijke weigeringsredenen retourneert en de analyses behouden zonder standaard onbewerkte inhoud op te slaan.

Dat ontwerp centraliseert beslissingen die anders verspreid zouden zijn over SDK opties, omgevingsvariabelen, providerconsoles en teamspecifieke conventies. Het biedt beveiligings- en platformteams ook een praktisch audittraject: welk verzoek is toegestaan, welke beleidsversie is toegepast, welk modelprofiel is geselecteerd en waarom.

Gerelateerd lezen

• veilige promptregistratie en gebruiksanalyses op gatewayniveau
• het bouwen van een matrix met providercapaciteiten tijdens een OpenAI-compatibele API migratie
• tools voor bestuursagenten met bereik, goedkeuringen en audittrails