Hoe u een router voor gegevensretentiebeleid kunt bouwen voor LLM-API's van meerdere providers

Een LLM-router met meerdere providers mag niet eerst een model kiezen en later retentievragen stellen. Als een ondersteuningsworkflow is getagd als 'geen retentie', moet de gateway weten of de geselecteerde provider, eindpunt, regio, accountinstelling en functiecombinatie deze belofte kan nakomen voordat het verzoek uw grens verlaat.

De foutmodus is gemakkelijk te missen. Een team begint met het voltooien van staatloze chats. Het traject is acceptabel. Later voegt iemand het uploaden van bestanden, opgeslagen gespreksgeschiedenis, webgronding, batchverwerking of een vectoropslag toe. De modelnaam blijft mogelijk hetzelfde, maar het gegevensgedrag verandert. Een eenvoudige latentie- of kostenrouter kan in stilte gereguleerde of klantcontractgebonden aanwijzingen sturen naar een pad waar inhoud langer wordt opgeslagen dan de werklast toestaat.

De praktische oplossing is om LLM-controles voor het bewaren van gegevens vóór modelrouting te plaatsen. De router moet het verzoek classificeren, vergelijken met een canoniek bewaarbeleid, de mogelijkheden van de provider filteren, niet-toegestane functies blokkeren en controleerbaar bewijs voor de beslissing afgeven.

Feiten die als ontwerpbeperkingen moeten worden behandeld

De verwerking van providergegevens is niet uniform en wordt zelden alleen op basis van de providernaam vastgelegd. De volgende feiten zijn van belang bij het ontwerpen van een retentiebewuste router:

• OpenAI stelt dat API gegevens niet worden gebruikt om modellen te trainen of te verbeteren, tenzij de klant zich daarvoor aanmeldt. In aanmerking komende klanten kunnen na goedkeuring Modified Abuse Monitoring of Zero Data Retention op organisatie- of projectniveau configureren.
• OpenAI's Zero Data Retention verandert het gedrag van eindpunten, inclusief het behandelen van de store parameter voor reacties en chatvoltooiingen als false, maar sommige eindpunten en mogelijkheden kunnen nog steeds de applicatiestatus opslaan en komen niet in aanmerking voor Zero Data Retention.
• Anthropic documenteert Zero Data Retention voor de Claude API omdat er geen klantprompts of reacties in rust worden opgeslagen nadat het antwoord API is geretourneerd, maar de dekking is afhankelijk van het eindpunt en de geschiktheid van de functie.
• Anthropic stelt dat sommige Claude functies of gedekte modellen mogelijk moeten worden bewaard en mogelijk niet beschikbaar zijn onder Zero Data Retention, tenzij specifiek toegestaan.
• Google Clouddocumenten die Gemini Enterprise Agent Platform-gegevens niet worden gebruikt om AI/ML-modellen te trainen of te verfijnen zonder voorafgaande toestemming of instructie, maar geen gegevensretentie vereist specifieke acties en is mogelijk niet mogelijk voor sommige geavanceerde functies.
• Google Clouddocumenten waarin Grounding with Google Search afgeleide zoekopdrachten en contextlogboeken maximaal drie dagen opslaat en die opslag voor die functie niet kunnen uitschakelen. Het raadt Web Grounding for Enterprise aan als er geen gegevensretentie vereist is.
• Microsoft-documenten waarin door Azure gehoste modellen die door Azure worden verkocht, geen aanwijzingen en aanvullingen beschikbaar stellen aan OpenAI of andere modelaanbieders en gebruiken deze niet om basismodellen te trainen zonder toestemming of instructie.
• Microsoft-documenten waarvan het Azure-implementatietype van invloed is op de verwerkingslocatie. Globale implementaties kunnen aanwijzingen en antwoorden verwerken in elke regio waar het model wordt geïmplementeerd, terwijl DataZone-implementaties de verwerking beperken tot de geselecteerde zone. Opgeslagen gegevens blijven in de door de klant aangegeven regio.
• Microsoft-documenten waarin sommige stateful Azure-functies gegevens opslaan, waaronder bestanden, vectoropslag, berichtgeschiedenis van reacties, assistent-threads, batchverwerkingsinvoer en opgeslagen voltooiingen.
• Microsoft-documenten waaruit blijkt dat goedgekeurde klanten misbruikcontrole kunnen wijzigen, en dat de Azure Portal of CLI ContentLogging=false kan weergeven wanneer gegevensopslag voor misbruikcontrole is uitgeschakeld.

Dit zijn geen randdetails. Ze betekenen dat de router het eindpunt, de functie, de accountgoedkeuring en de regio samen moet evalueren. Een providerbreed label zoals 'ZDR ingeschakeld' is te grof voor productiebeleid.

Referentiearchitectuur

Een retentiebewuste multi-model AI API gateway heeft vijf componenten nodig in het verzoekpad:

1. Verzoekclassificatie: extraheert gegevensgevoeligheid, huurderscontract, regiovereisten, functiegebruik, bestandsinvoer, toolgebruik en logboekregistratierechten.
2. Beleidsoplosser: wijst het verzoek toe aan een canoniek bewaarbeleid, meestal van tenant, project, omgeving, API sleutel en metagegevens van de werkbelasting.
3. Register met mogelijkheden voor providers: registreert de bewaarmogelijkheden van de provider, het eindpunt, het model, de functie, de regio en accountniveau met gedateerd bewijs.
4. Beleidsevaluator: filtert kandidaat-routes en retourneert een goedgekeurde route of een beleidsweigering met een redencode.
5. Audit-emitter: registreert de gekozen route, het overeenkomende beleid, de aannames over mogelijkheden, de regio, opslagvlaggen en de modus voor het loggen van inhoud.

Deze architectuur houdt beslissingen over bewaring en verblijfplaats gescheiden van kosten, latentie en terugval. Kostenroutering kan nog steeds plaatsvinden, maar alleen binnen de reeks routes die voldoen aan het bewaarbeleid.

Definieer een canoniek bewaarbeleid

Begin met een providerneutraal beleidsobject. Kopieer niet de terminologie van één provider in uw interne contract. Uw interne beleid moet beschrijven wat de werklast mag doen, en niet hoe een specifieke provider een controle op de markt brengt.

{
  "policy_id": "support_no_retention_eu_v1",
  "max_content_retention": "none_after_response",
  "training_allowed": false,
  "human_review_allowed": false,
  "allowed_regions": ["EU"],
  "stateful_storage_allowed": false,
  "file_storage_allowed": false,
  "grounding_allowed": false,
  "batch_processing_allowed": false,
  "full_content_logging_allowed": false,
  "redacted_content_logging_allowed": true,
  "audit_level": "route_decision_with_provider_evidence"
}

Gebruik voor minder beperkte productietaken expliciete versoepeling in plaats van ontbrekende velden:

{
  "policy_id": "internal_analytics_standard_v1",
  "max_content_retention": "30_days",
  "training_allowed": false,
  "human_review_allowed": false,
  "allowed_regions": ["US", "EU"],
  "stateful_storage_allowed": true,
  "file_storage_allowed": true,
  "grounding_allowed": true,
  "batch_processing_allowed": true,
  "full_content_logging_allowed": false,
  "redacted_content_logging_allowed": true,
  "audit_level": "metadata_and_decision"
}

De belangrijke velden zijn niet alleen de bewaarduur. Stateful functies, bestanden, aarding, batchverwerking en logmodus hebben allemaal invloed op de vraag of een route acceptabel is.

Bouw het register voor providermogelijkheden op

Het capaciteitenregister is de bron van waarheid voor de router. Het moet worden onderhouden als een gecontroleerde configuratie, en niet verspreid via provideradapters.

Een nuttig record omvat:

• provider: provider of cloudplatform.
• account_scope: organisatie, project, implementatie, abonnement of tenant waarbij een instelling is goedgekeurd.
• endpoint: chat, reacties, berichten, batch, bestanden, assistenten, insluitingen, aarding, vectoropslag of ander API oppervlak.
• model_family en optioneel model_id: omdat de geschiktheid van modellen kan verschillen.
• region_mode: mondiaal, regionaal, datazone, door de klant aangewezen geografie of providerspecifiek equivalent.
• content_retention: geen opslag na reactie, retentie door misbruikcontrole, retentie van applicatiestatus, afgeleide logboeken met een vaste duur of onbekend.
• training_use: standaard uitgeschakeld, aangemeld of onbekend.
• human_review: ingeschakeld, aangepast, uitgeschakeld of onbekend.
• stateful_storage: of het eindpunt of de functie de gespreksstatus, bestanden, vectorgegevens, voltooiingen of batchinvoer opslaat.
• feature_flags: aarding, bestanden, tools, cache, opgeslagen uitvoer, batch, assistenten of gelijkwaardige mogelijkheden.
• evidence: naam van het brondocument, URL, ophaaldatum en datum van beoordeling door de eigenaar.

Voorbeeld:

{
  "capability_id": "azure-openai-gpt4o-datazone-chat-zdrlike-v3",
  "provider": "azure_openai",
  "account_scope": "prod-subscription-123",
  "endpoint": "chat_completions",
  "model_family": "gpt-4o",
  "region_mode": "datazone_eu",
  "content_retention": "abuse_monitoring_disabled_when_contentlogging_false",
  "training_use": "disabled_without_permission",
  "human_review": "modified_abuse_monitoring_approved",
  "stateful_storage": false,
  "features": {
    "files": false,
    "vector_store": false,
    "stored_completions": false,
    "grounding": false,
    "batch": false
  },
  "evidence": {
    "source": "provider_data_privacy_and_abuse_monitoring_docs",
    "retrieved_at": "2026-10-08",
    "review_owner": "security-architecture"
  }
}

De aanbeveling is om onbekend als weigeren te behandelen voor gevoelige productietaken. Als een capaciteitsrecord geen bewaarveld, regiomodus of geschiktheid voor een functie mist, mag deze niet aan strikte beleidsregels voldoen.

Classificeer het verzoek vóór routering

Classificatie moet plaatsvinden vóór modelselectie. Een goede classificator combineert statische metadata en verzoekinspectie:

• API sleutelbereik: tenant, team, omgeving, applicatie en productiebelastingtype.
• Contracttags: geen retentie, alleen voor de EU, HIPAA-achtige controles, financiële gegevens, vertrouwelijk voor klanten of alleen voor intern.
• Type payload: vrije tekst, document, afbeelding, bestandsreferentie, ingesloten invoer, toolresultaat of opgehaalde context.
• Gebruik van functies: webgrounding, bestandsupload, vectoropslag, batchtaak, opgeslagen gespreksgeschiedenis, toolaanroepen of antwoordopslag.
• Logboekmodus: volledige inhoud toegestaan, geredigeerde inhoud toegestaan, alleen metagegevens of geen inhoud van het applicatielogboek.
• Regionale tips: gebruikerslocatie, locatie van tenantgegevens, projectregio of implementatieregio.

Vertrouw niet alleen op automatische detectie van gevoelige gegevens. Gebruik het gedeclareerde werklastbeleid van de API sleutel of het project als de primaire bron en gebruik vervolgens classificaties om het beleid aan te scherpen wanneer de nettolading risicosignalen bevat.

function resolvePolicy(request) {
  const base = policyForApiKey(request.apiKeyId);
  const tenant = tenantContractPolicy(request.tenantId);
  const features = detectRequestedFeatures(request);
  const sensitivity = classifyPayload(request);

  return strictestApplicablePolicy([base, tenant, features, sensitivity]);
}

In de praktijk betekent dit dat een klantondersteuningssleutel standaard niet kan worden bewaard, terwijl een interne experimentsleutel een bredere routering mogelijk kan maken. Als dezelfde ondersteuningssleutel probeert een bestand te uploaden, moet het effectieve beleid file_storage_allowed=false bevatten, tenzij er een goedgekeurde route bestaat die geschikt is voor bestanden.

Evalueer het beleid vóór routering van kosten of latentie

De evaluator moet als filter werken. Het ontvangt een beleid, verzoekfuncties en routes voor kandidaat-providers. Er worden alleen routes geretourneerd die aan het beleid voldoen.

function eligibleRoutes(request, policy, capabilities) {
  return capabilities.filter((route) => {
    if (!regionAllowed(route, policy.allowed_regions)) return false;
    if (!retentionAllowed(route, policy.max_content_retention)) return false;
    if (!trainingAllowed(route, policy.training_allowed)) return false;
    if (!humanReviewAllowed(route, policy.human_review_allowed)) return false;
    if (request.usesFiles && !policy.file_storage_allowed) return false;
    if (request.usesFiles && route.features.files !== true) return false;
    if (request.usesGrounding && !policy.grounding_allowed) return false;
    if (request.requiresState && !policy.stateful_storage_allowed) return false;
    if (route.content_retention === "unknown") return false;
    return true;
  });
}

function routeRequest(request) {
  const policy = resolvePolicy(request);
  const candidates = capabilityRegistry.findByModelIntent(request.modelIntent);
  const eligible = eligibleRoutes(request, policy, candidates);

  if (eligible.length === 0) {
    return deny("RETENTION_POLICY_NO_ELIGIBLE_ROUTE", policy.policy_id);
  }

  return chooseByCostLatencyAndHealth(eligible);
}

Deze volgorde is belangrijk. Fallback-routering mag tijdens een storing niet naar een niet in aanmerking komende provider springen. Batchroutering mag een aanvraag zonder retentie niet naar een asynchrone taakopslag verplaatsen. Aarding mag geen functie inschakelen die afgeleide logboeken introduceert wanneer het beleid dit verbiedt.

Als uw platform een OpenAI-compatibel multi-model API beschikbaar stelt, houd de compatibiliteitslaag dan eerlijk: dezelfde verzoektekst kan compileren met verschillende providereigen functies. De beleidsevaluator moet het gecompileerde verzoek inspecteren, en niet alleen de originele SDK vorm.

Risicovolle functiecombinaties expliciet blokkeren

De veiligste implementatie is het creëren van expliciete weigeringsregels voor bekende risicovolle combinaties. Voorbeelden:

• NO_RETENTION + FILE_UPLOAD: weigeren tenzij het specifieke bestandseindpunt en de accountinstelling zijn goedgekeurd voor het beleid.
• NO_RETENTION + VECTOR_STORE: weigeren tenzij de vectoropslag zich in uw eigen gecontroleerde opslag bevindt en de provider nooit een persistente bestandsstatus ontvangt.
• NO_RETENTION + STORED_RESPONSE: forceer responsopslagvlaggen uit of weigeren als het eindpunt de opslag niet kan uitschakelen.
• EU_ONLY + GLOBAL_DEPLOYMENT: weigeren als verwerking buiten de toegestane regio of datazone kan plaatsvinden.
• NO_RETENTION + WEB_GROUNDING: weigeren als de aardingsfunctie afgeleide zoekopdrachten of contextlogboeken opslaat die verder gaan dan het beleid.
• METADATA_ONLY_LOGGING + DEBUG_TRACE: onderdruk prompt- en voltooiingsinhoud uit applicatielogboeken en traceringen.
• ZDR_REQUIRED + STATEFUL_ASSISTANT_THREAD: weigeren tenzij de functie specifiek in aanmerking komt onder de goedgekeurde controles van het account.

Retourneer specifieke fouten. Een nuttige weigering vertelt de ontwikkelaar wat er is mislukt en welke goedgekeurde alternatieven er zijn.

{
  "error": {
    "code": "RETENTION_POLICY_DENIED",
    "reason": "NO_RETENTION_POLICY_DISALLOWS_FILE_STORAGE",
    "policy_id": "support_no_retention_eu_v1",
    "requested_feature": "file_upload",
    "approved_alternatives": [
      "send extracted text without provider file storage",
      "use internal document retrieval with metadata-only provider call",
      "request policy approval for controlled file processing"
    ]
  }
}

Gescheiden registratie van gevolgtrekkingen en operationele telemetrie

Bewaarbeleid mag de gateway niet dwingen blind te worden. Normaal gesproken kunt u operationele telemetrie behouden zonder prompt- of voltooiingsinhoud op te slaan.

Behoud voor strikte productietaken het volgende:

• verzoek-ID en trace-ID;
• Tenant-, project-, API-sleutel- en productiebelasting-ID's;
• beleids-ID en beleidsversie;
• gebruikte provider, eindpunt, model, implementatie en regio;
• functievlaggen aangevraagd en toegestaan;
• beslissingsredencodes;
• tokenaantallen, latentie, statuscode en metagegevens over kosten;
• hashes of stabiele vingerafdrukken voor deduplicatie, indien goedgekeurd door het beleid.

Onderdrukken of redigeren:

• ruwe aanwijzingen;
• ruwe voltooiingen;
• geüploade bestandsinhoud;
• tooluitvoer die klantgegevens bevat;
• context opgehaald van gevoelige systemen;
• provider debugt payloads die inhoud dupliceren.

Dit is waar retentieroutering aansluit op providerneutrale LLM-observatie. Waarneembaarheid moet bewijzen wat er is gebeurd, zonder de reeks systemen uit te breiden die gevoelige inhoud vasthouden.

Controleer bewijsmateriaal voor elke beslissing

Een auditrecord moet uitleggen waarom een route is toegestaan of geweigerd. Het heeft geen volledige inhoud nodig om nuttig te zijn.

{
  "request_id": "req_01J...",
  "tenant_id": "tenant_42",
  "policy_id": "support_no_retention_eu_v1",
  "policy_version": 7,
  "decision": "allow",
  "provider": "anthropic",
  "endpoint": "messages",
  "model_family": "claude",
  "region_mode": "approved_region",
  "features": {
    "files": false,
    "grounding": false,
    "stateful_storage": false,
    "batch": false
  },
  "logging_mode": "metadata_only",
  "capability_record_id": "anthropic-claude-messages-zdr-v5",
  "capability_evidence_date": "2026-10-08",
  "reason_codes": [
    "POLICY_MATCHED_NO_RETENTION",
    "REGION_ALLOWED",
    "STATELESS_ENDPOINT",
    "CONTENT_LOGGING_SUPPRESSED"
  ]
}

Behoud voor afgewezen verzoeken dezelfde structuur met decision=deny en redencodes zoals REGION_NOT_ALLOWED, GROUNDING_RETENTION_EXCEEDS_POLICY of STATEFUL_STORAGE_NOT_ALLOWED.

Gebruik contracttests voor bewaarregels

Bewaarrouting moet geautomatiseerde tests hebben. De belangrijke tests zijn niet alleen eenheidstests voor individuele aanbieders; het zijn contracttests voor beleidsgedrag bij verschillende providercombinaties.

Hoge waarde testgevallen omvatten:

• Beleid tegen bewaren en het uploaden van bestanden moet worden geweigerd, tenzij er een specifieke goedgekeurde route bestaat die geschikt is voor bestanden.
• Alleen EU-beleid plus wereldwijde implementatie zouden moeten weigeren, zelfs als het model anderszins beschikbaar is.
• Zero-retentiebeleid plus opgeslagen gespreksgeschiedenis zouden opslag moeten weigeren of afdwingen indien ondersteund.
• De aardingsfunctie met het bewaren van afgeleide logbestanden zou moeten worden geweigerd onder het beleid voor niet-bewaren.
• Het beleid voor logboekregistratie met alleen metadata moet prompt- en voltooiingsinhoud uit traceringen, logboeken en foutrapporten onderdrukken.
• Providercapaciteitsrecord met onbekende retentie moet worden geweigerd voor gereguleerde productietaken.
• Fallback na een providerstoring moet binnen de in aanmerking komende routeset blijven.
• Batchverwerking zou moeten weigeren wanneer het batcheindpunt invoerbestanden langer opslaat dan het beleid toestaat.

Ook drift testen. Wanneer een capaciteitsrecord verandert, moet het systeem laten zien welk beleid en welke routes worden beïnvloed voordat de wijziging de productie bereikt.

Operationeel eigendom

Het moeilijkste deel is niet het schrijven van de eerste beoordelaar. Het houdt het register actueel en voorkomt ongedocumenteerde uitzonderingen.

Eigenaren toewijzen voor:

• de beoordelingsfrequentie van de documentatie van de leverancier;
• goedkeuringsstatus voor controles op accountniveau, zoals aangepast toezicht op misbruik of geen gegevensretentie;
• regionale implementatie-inventaris;
• geschiktheid voor bestanden, vectoropslag, aarding, batch- en opgeslagen reacties;
• workflow voor beleidsuitzonderingen;
• bewaren van auditrecords en toegangscontrole;
• foutmeldingen voor ontwikkelaars en goedgekeurde alternatieven.

Elke capaciteitsrecord moet een beoordelingsdatum hebben. Als het verloopt, moet het strikte beleid er niet meer op vertrouwen of handmatige goedkeuring vereisen. Providerdocumentatie en functiegedrag veranderen te vaak om van een statische configuratie te kunnen spreken.

Afwegingen

Een strikte retentierouter beperkt de beschikbare modelkeuzes. Sommige preview-modellen, stateful API's, aardingstools en bestandsworkflows zijn niet beschikbaar voor gevoelige workloads. Dat is het punt van controle, maar productteams hebben duidelijke alternatieven nodig.

Regionale routering kan de latentie of kosten verhogen wanneer de snelste implementatie wereldwijd is, maar de werklast een specifieke geografie of datazone vereist. Maak dit zichtbaar in telemetrie, zodat teams begrijpen waarom een verzoek een duurdere of langzamere route gebruikte.

Het blokkeren van stateful functies kan teams ertoe aanzetten hun eigen geheugenlaag te bouwen. Dat is misschien de juiste architectuur, maar er zijn nog steeds opslagbeleid, verwijderingsworkflows, encryptie, toegangscontrole en auditlogboeken nodig. Als u de status uit de provider verplaatst, wordt het beheerwerk niet verwijderd.

Snelle en volledige redactie beschermt gevoelige gegevens, maar verzwakt de foutopsporing en kwaliteitsbeoordeling. Gebruik reproduceerbare metadata van verzoeken, deterministische testopstellingen, gecontroleerde steekproeven voor toegestane werkbelastingen en gedocumenteerde toegang tot breekglas waar het beleid dit toestaat.

Aanbevelingen

• Dwing retentie en verblijfplaats af vóór modelrouting, niet als controle na verwerking.
• Modelmogelijkheden op provider-, eindpunt-, functie-, regio- en accountgoedkeuringsniveau.
• Gebruik standaard weigeren-gedrag voor gereguleerde of klantcontractgebonden productietaken.
• Behandel bestandsuploads, vectoropslag, webgrounding, batchverwerking en opgeslagen gespreksgeschiedenis als afzonderlijke beleidsdimensies.
• Behoud operationele telemetrie, zelfs wanneer prompt- en voltooiingsinhoud moet worden onderdrukt.
• Auditrecords verzenden die het beleid, de route, het capaciteitsbewijs, de regio, opslagvlaggen en redencodes bevatten.
• Schrijf contracttests voor risicovolle functiecombinaties en fallback-gedrag.

Voorspelling: Retentieroutering wordt een standaard gatewaylaag

De waarschijnlijke richting is dat retentieroutering een standaardlaag wordt in zakelijke LLM-platforms, vergelijkbaar met tarieflimieten, budgetcontroles en waarneembaarheid. Naarmate providers meer stateful tools, aardingsopties, caches, bestanden, agenten en beheerde geheugenfuncties toevoegen, zal de veilige route minder afhankelijk zijn van de modelnaam en meer van het volledige uitvoeringspad.

Dat is een voorspelling, geen huidige universele vereiste. De huidige vereiste is eenvoudiger: als uw team geen retentie, regionale verwerking, geen trainingsgebruik of geen menselijke beoordeling belooft, heeft uw gateway voldoende beleidslogica en bewijs nodig om te bewijzen dat elk verzoek aan deze beperkingen voldoet.

Conclusie waar actie op ondernomen kan worden

Bouw de retentierouter als beleidspoort vóór de providerselectie. Definieer een canoniek bewaarbeleid, classificeer elk verzoek voordat het wordt doorgestuurd, houd een gedateerd register van providermogelijkheden bij, weiger standaard onveilige combinaties en registreer auditbewijsmateriaal zonder gevoelige inhoud te behouden.

Het ontwerpdoel is niet om een aanbieder te vinden die altijd veilig is. Het doel is om te bewijzen dat een specifiek verzoek, met behulp van een specifiek eindpunt en een specifieke functieset, onder een specifiek account en een specifieke regio, aan het beleid voldeed voordat het werd verzonden.

Gerelateerd lezen

• providerneutraal LLM-observatieontwerp