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 kan worden verzonden naar een specifieke provider, eindpunt, regio, functie en logmodus.

Dat is moeilijker dan het klinkt. Een model kan acceptabel zijn voor gewone interne chat, maar niet voor PII van klanten. Een provider biedt mogelijk geen gegevensretentie voor één API-pad, terwijl een zoekfunctie 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 providers 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 voor de productierouting is het niet genoeg.

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 loggen?
• Kan fallback-routing hetzelfde verzoek naar een andere provider sturen?

Elk van deze keuzes kan het bewaarprofiel wijzigen. Een verzoek dat wel aan de regels voldeed in de gewone chatmodus, kan niet-conform worden als 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 actuele documenten van publieke aanbieders illustreren waarom dit nodig is:

• OpenAI: de locatie van API-gegevens 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 voor niet-Amerikaanse API-gegevenslocatie goedkeuring vereist is voor controles op misbruik en een gewijzigd retentie-amendement.
• Anthropic: Anthropic documenteert dat er geen gegevens worden bewaard 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 services kan 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 Developer API ZDR-documentatie zegt dat logboeken voor misbruikmonitoring van betaalde services normaal gesproken aanwijzingen en antwoorden gedurende een beperkte periode bewaren, terwijl goedgekeurde ZDR-projecten gebruikersinhoud en identificeerbare metagegevens wissen voordat ze inloggen.
• Functiespecifieke opslag: in de Gemini-documentatie staat 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-registratiedocumentatie zegt dat API-logboeken van ontwikkelaars 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: NIST's Generative AI Profile raadt aan om door AI gegenereerde inhoud te monitoren op privacyrisico's en generatief AI-beleid te koppelen aan bestaande gegevens-, software-, juridische, compliance- en risicobeheerprocessen.

Dit zijn feiten die vóór de uitrol moeten worden geverifieerd aan de hand van de huidige leveranciersdocumentatie. De architectuurles is stabiel: retentie is niet één Boolean 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 van de mogelijkheden van de provider: beschrijft het gedrag van de provider, het model, het eindpunt, de regio, de retentie, de logboekregistratie en de functies.
3. Beleid-als-code-regels: zet beveiligingsvereisten om in beslissingen over het toestaan, weigeren of beoordelen van runtime.
4. Feature Gate-laag: 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:

• openbaar: openbare documentatie, marketingteksten, openbare website-inhoud.
• intern: niet-openbare bedrijfsinformatie met lage gevoeligheid.
• vertrouwelijk: strategie, contracten, klantcontext, niet-vrijgegeven productdetails.
• klant_pii: namen, e-mailadressen, adressen, account-ID's, ondersteuningstranscripties.
• gereguleerd: gezondheidszorg-, financiële, juridische, onderwijs- of rechtsgebiedspecifieke beschermde gegevens.
• source_code: eigen code, configuratie, architectuurbestanden.
• inloggegevens: 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 toepassing geleverde header, zoals X-Data-Class: customer_pii.
• Tenantbeleid, waarbij al het verkeer van een gereguleerde klant als gereguleerd wordt behandeld, tenzij het wordt gedowngraded door een goedgekeurde regel.
• Eindpuntbeleid, waarbij de samenvatting van supporttickets standaard customer_pii is.
• Lichte inhoudsscans op inloggegevens, duidelijke PII of beleidsschendingen.

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

Stap 2: bouw een matrix voor de capaciteiten van een provider

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

Voorbeeldvelden:

{
  "profile_id": "provider_x.chat.eu.zdr",
  "provider": "provider_x",
  "model": "model-groot",
  "api_family": "chat_completions",
  "eindpunt": "https://eu.example-provider.com/v1",
  "regio": "eu",
  "processing_residentie": ["eu"],
  "storage_residency": ["eu"],
  "zdr_eligible": waar,
  "zdr_contract_required": waar,
  "training_use": "niet_gebruikt_voor_training_op_paid_api",
  "abuse_monitoring": "approved_modified_retention_required",
  "ontwikkelaar_log_retentie_dagen": 0,
  "raw_prompt_logging_allowed": false,
  "ondersteunde_functies": {
    "plain_chat": waar,
    "streaming": waar,
    "tool_calls": waar,
    "search_grounding": false,
    "maps_grounding": false,
    "file_upload": vals,
    "batch": vals,
    "opgeslagen_gesprekken": false
  },
  "last_reviewed": "01-08-2026",
  "source_refs": ["security-review-123", "vendor-doc-versie-abc"]

Gebruik modelprofielen in plaats van onbewerkte model-ID's. Een profiel combineert model, provider, eindpunt, regio, functieset en retentiehouding. Ontwikkelaars vragen om model_profile: compliant_summarization, niet alleen om model: snelste-grote-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 == "inloggegevens"
  reden "credentials_must_not_be_sent_to_model"
alleen toestaan als data_class in ["gereguleerd", "klant_pii"]
  en profile.zdr_eligible == waar
  en profile.zdr_contract_required_satisfied == waar
  reden_on_failure "model_profile_not_zdr_eligible"
weigeren als residency_required == "eu"
  en "eu" niet in profile.processing_residency
  reden "region_processing_not_supported"
deny if data_class in ["vertrouwelijk", "klant_pii", "gereguleerd"]en request.raw_prompt_logging == waar
  reden "raw_prompt_logging_not_allowed"
weigeren als request.features.search_grounding == waar
  en policy.requires_zdr == waar
  en profile.feature_storage.search_grounding_days > 0
  reden "grounding_requires_retained_content"
weigeren als fallback_profile.retention_level < primair_profiel.retention_level
  reden "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 alleen als een eigenschap van het basismodel. 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 locatiebepaling: kunnen locatiespecifieke logboeken of bewaarregels introduceren.
• Bestanden uploaden: kan bestanden afzonderlijk van prompts en reacties opslaan.
• Code-uitvoering: kan tijdelijke bestanden, uitvoeringslogboeken of sandbox-artefacten creëren.
• Batchtaken: kunnen een ander bewaar-, wachtrij- en resultaatopslaggedrag vertonen dan synchrone API-aanroepen.
• Opgeslagen gesprekken: houden de inhoud opzettelijk vast en mogen nooit verborgen worden achter een generieke 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 de regels voor functieopslag voordat het upstream wordt verzonden.

Stap 5: bewaar analyses 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 standaard telemetrievelden:

• huurder-ID en project-ID
• gehashte of interne API-sleutel-ID
• modelprofiel-ID en provider-ID
• vraag tijdstempel en regio aan
• Invoer-, uitvoer-, cache- en redeneringstoken telt indien beschikbaar
• latentie, statuscode, aantal nieuwe pogingen en terugvalbeslissing
• geschatte en afgerekende kosten
• gegevensclassificatielabel
• beleidsversie en reden van beleidsbeslissing
• functievlaggen aangevraagd en functievlaggen toegestaan

Vermijd het standaard 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
• beperkt tijdvenster
• steekproeflimiet
• redactiepas
• afzonderlijke 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 compliance.

Stap 6: retourneer bruikbare weigeringsredenen

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

Voorbeeldreactie:

{
  "fout": {
    "type": "beleid_geweigerd",
    "code": "aarding_vereist_30_dag_opslag",
    "message": "Zoekgronding is niet toegestaan voor werklasten die gemarkeerd zijn als require_zdr, omdat deze providerfunctie prompt-, context- en uitvoerinhoud opslaat.",
    "request_id": "req_123",
    "policy_version": "retentiebeleid-2026-08-01",
    "toegestane_acties": [
      "disable_search_grounding",
      "kies_profiel:zdr_plain_chat",
      "request_exception"
    ]
  }

Handige weigeringscodes zijn onder meer:

• model_profile_not_zdr_eligible
• region_processing_not_supported
• opslag_residentie_niet_ondersteund
• raw_prompt_logging_not_allowed
• feature_requires_content_storage
• fallback_weakens_retention_policy
• contract_prerequisite_missing
• referenties_gedetecteerd

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
• aanvragend team of huurder
• ticket- of risicobeoordelingslink
• zakelijke rechtvaardiging
• toegestane modelprofielen en -functies
• gedekte gegevensklassen
• vervaldatum
• aanvullende logboekvereisten

Aanbeveling: maak uitzonderingen beperkter dan bij 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 gevraagde functies declareren.
• Standaard vertrouwelijk en gereguleerd verkeer instellen op geen 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.
• Logboekbeleidsversie, 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 wrijving.

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

De matrix heeft onderhoud nodig. 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 functies die de retentie wijzigen per beleid, voorkom standaard loggen 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.

Bruikbare conclusie

Dataretentiebewuste 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 retentie-veranderende functies. Zorg er vervolgens voor dat de gateway duidelijke weigeringsredenen retourneert en de analyses behoudt 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 geeft 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 gebruik op gatewayniveau analytics
• het bouwen van een matrix met providercapaciteiten tijdens een OpenAI-compatibele API-migratie
• tools voor bestuursagenten met scopes, goedkeuringen en audittrails