Jak vytvořit směrovač zásad uchovávání dat pro LLM API s více poskytovateli

Směrovač LLM s více poskytovateli by si neměl nejprve vybrat model a později klást otázky týkající se uchovávání informací. Pokud je pracovní postup podpory označen jako no-retention, brána musí vědět, zda vybraný poskytovatel, koncový bod, region, nastavení účtu a kombinace funkcí může splnit tento slib, než požadavek opustí vaše hranice.

Režim selhání lze snadno přehlédnout. Tým začíná dokončením bezstavového chatu. Trasa je přijatelná. Později někdo přidá nahrávání souborů, uloženou historii konverzací, uzemnění webu, dávkové zpracování nebo úložiště vektorů. Název modelu může zůstat stejný, ale chování dat se změní. Jednoduchý směrovač s latencí nebo cenou může tiše odesílat regulované výzvy nebo výzvy vázané na smlouvu zákazníka na cestu, která ukládá obsah déle, než umožňuje pracovní zátěž.

Praktická oprava spočívá v umístění ovládacích prvků uchovávání dat LLM před směrování modelu. Směrovač by měl požadavek klasifikovat, porovnat jej s kanonickou zásadou uchovávání, filtrovat možnosti poskytovatele, blokovat nepovolené funkce a vydávat auditovatelné důkazy pro rozhodnutí.

Fakta, která je třeba považovat za omezení návrhu

Zpracování dat poskytovatele není jednotné a jen zřídka je zachyceno pouze jménem poskytovatele. Při navrhování směrovače s podporou retence jsou důležité následující skutečnosti:

• OpenAI uvádí, že data API se nepoužívají k trénování nebo vylepšování modelů, pokud se zákazník nepřihlásí. Oprávnění zákazníci mohou po schválení nakonfigurovat Modified Abuse Monitoring nebo Zero Data Retention na úrovni organizace nebo projektu.
• OpenAI's Zero Data Retention mění chování koncového bodu, včetně toho, že parametr store pro odpovědi a dokončení chatu považuje za nepravdivý, ale některé koncové body a funkce mohou stále ukládat stav aplikace a nejsou způsobilé pro nulové uchovávání dat.
• Anthropic dokumenty s nulovým uchováváním dat pro Claude API, protože neukládají zákaznické výzvy ani neaktivní odpovědi po vrácení odpovědi API, ale pokrytí závisí na způsobilosti koncového bodu a funkcí.
• Anthropic uvádí, že některé funkce Claude nebo zahrnuté modely mohou vyžadovat uchování a nemusí být dostupné v rámci nulového uchovávání dat, pokud nejsou výslovně povoleny.
• Google Cloudové dokumenty, které Gemini data platformy Enterprise Agent Platform se nepoužívají k trénování nebo dolaďování modelů AI/ML bez předchozího povolení nebo pokynů, ale nulové uchovávání dat vyžaduje konkrétní akce a u některých pokročilých funkcí nemusí být možné.
• Google Cloudové dokumenty, které Grounding with Google Search ukládá odvozené protokoly dotazů a kontextu po dobu až tří dnů a nelze toto úložiště pro tuto funkci zakázat. Pokud je vyžadováno nulové uchovávání dat, doporučuje Web Grounding for Enterprise.
• Dokumenty společnosti Microsoft, že modely hostované v Azure prodávané Azure nezpřístupňují výzvy a dokončení OpenAI ani jiným poskytovatelům modelů a nepoužívají je k trénování základních modelů bez povolení nebo pokynů.
• Dokumenty společnosti Microsoft, že typ nasazení Azure ovlivňuje umístění zpracování. Globální nasazení může zpracovávat výzvy a odpovědi v jakékoli geografické oblasti, kde je model nasazen, zatímco nasazení DataZone omezují zpracování na vybranou zónu. Uložená data zůstávají v geografické oblasti určené zákazníkem.
• Dokumenty společnosti Microsoft, že některé stavové funkce Azure ukládají data, včetně souborů, vektorových úložišť, historie zpráv odpovědí, vláken Asistenta, vstupů pro dávkové zpracování a uložených dokončení.
• Dokumenty společnosti Microsoft, ve kterých mohou schválení zákazníci upravovat sledování zneužití a které může Azure Portal nebo CLI zobrazovat ContentLogging=false, když je úložiště dat pro monitorování zneužití vypnuté.

Toto nejsou detaily okraje. Znamená to, že router musí společně vyhodnotit koncový bod, funkci, schválení účtu a region. Štítek na úrovni poskytovatele, například „ZDR povoleno“, je pro produkční zásady příliš hrubý.

Referenční architektura

Brána s podporou zachování multimodelové umělé inteligence APIbrána potřebuje pět komponent v cestě požadavku:

1. Klasifikátor požadavků: extrahuje citlivost dat, smlouvu s nájemcem, požadavky regionu, použití funkcí, vstupy do souborů, použití nástrojů a oprávnění k protokolování.
2. Policy resolver: mapuje požadavek na kanonickou zásadu uchovávání, obvykle z tenanta, projektu, prostředí, klíče API a metadat pracovního zatížení.
3. Registr možností poskytovatele: Poskytovatel záznamů, koncový bod, model, funkce, oblast a možnosti uchování na úrovni účtu s datovanými důkazy.
4. Policy evaluator: filtruje kandidátské trasy a vrací buď schválenou trasu, nebo odmítnutí zásady s kódem důvodu.
5. Emitor auditu: zaznamenává vybranou trasu, odpovídající zásady, předpoklady schopností, region, příznaky úložiště a režim protokolování obsahu.

Tato architektura udržuje rozhodnutí o uchování a pobytu oddělená od nákladů, latence a záložních řešení. Ke směrování nákladů stále může dojít, ale pouze v rámci sady tras, které splňují zásady uchovávání.

Definujte kanonické zásady uchovávání

Začněte s objektem zásad, který je neutrální vůči poskytovateli. Nekopírujte terminologii jednoho poskytovatele do své interní smlouvy. Vaše interní zásady by měly popisovat, co může pracovní zátěž dělat, nikoli to, jak konkrétní poskytovatel prodává kontrolu.

{
  "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"
}

Pro méně omezené pracovní vytížení použijte spíše explicitní uvolnění než chybějící pole:

{
  "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"
}

Důležitá pole nejsou pouze doba uchování. Stavové funkce, soubory, uzemnění, dávkové zpracování a režim protokolování ovlivňují to, zda je trasa přijatelná.

Vytvoření registru schopností poskytovatele

Registr schopností je zdrojem pravdy routeru. Mělo by být udržováno jako řízená konfigurace, nikoli rozptýlené prostřednictvím adaptérů poskytovatele.

Užitečný záznam zahrnuje:

• provider: poskytovatel nebo cloudová platforma.
• account_scope: organizace, projekt, nasazení, předplatné nebo tenant, kde je schváleno nastavení.
• endpoint: chat, odpovědi, zprávy, dávka, soubory, asistenti, vkládání, uzemnění, vektorový obchod nebo jiná API plocha.
• model_family a volitelné model_id: protože způsobilost modelu se může lišit.
• region_mode: globální, regionální, datová zóna, geografická oblast určená zákazníkem nebo ekvivalent specifický pro poskytovatele.
• content_retention: žádné úložiště po odpovědi, uchovávání při sledování zneužití, uchovávání stavu aplikace, odvozené protokoly s pevnou dobou trvání nebo neznámé.
• training_use: ve výchozím nastavení zakázáno, přihlášeno nebo neznámé.
• human_review: povoleno, upraveno, zakázáno nebo neznámo.
• stateful_storage: zda koncový bod nebo funkce ukládá stav konverzace, soubory, vektorová data, dokončení nebo dávkové vstupy.
• feature_flags: uzemnění, soubory, nástroje, mezipaměť, uložené výstupy, dávka, asistenti nebo ekvivalentní možnosti.
• evidence: název zdrojového dokumentu, adresa URL, datum načtení a datum kontroly vlastníka.

Příklad:

{
  "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"
  }
}

Doporučení je u citlivých úloh považovat neznámé za odmítnutí. Pokud záznam schopnosti postrádá pole uchování, režim regionu nebo způsobilost funkce, neměl by splňovat přísné zásady.

Klasifikace požadavku před směrováním

Klasifikace by měla proběhnout před výběrem modelu. Dobrý klasifikátor kombinuje statická metadata a kontrolu požadavků:

• API klíčový rozsah: tenant, tým, prostředí, aplikace a typ zátěže.
• Značky smlouvy: bez uchovávání, pouze pro EU, kontroly podobné HIPAA, finanční údaje, důvěrné informace o zákaznících nebo pouze pro interní účely.
• Typ užitečného zatížení: volný text, dokument, obrázek, odkaz na soubor, vstup pro vložení, výsledek nástroje nebo načtený kontext.
• Použití funkcí: uzemnění webu, nahrávání souborů, úložiště vektorů, dávková úloha, uložená historie konverzací, volání nástrojů nebo úložiště odpovědí.
• Režim protokolování: povolen úplný obsah, povolen redigovaný obsah, pouze metadata nebo žádný obsah protokolu aplikace.
• Regionální rady: umístění uživatele, umístění dat tenanta, oblast projektu nebo oblast nasazení.

Nespoléhejte se pouze na automatickou detekci citlivých dat. Použijte deklarovanou zásadu pracovní zátěže z klíče nebo projektu API jako primární zdroj a poté pomocí klasifikátorů zpřísněte zásady, pokud datová zátěž obsahuje rizikové signály.

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]);
}

V praxi to znamená, že klíč zákaznické podpory může být ve výchozím nastavení neuchováván, zatímco interní experimentální klíč může umožnit širší směrování. Pokud se stejný klíč podpory pokusí o nahrání souboru, účinná zásada by měla zahrnovat file_storage_allowed=false, pokud neexistuje schválená cesta umožňující soubory.

Vyhodnoťte zásady před směrováním nákladů nebo latence

Hodnotitel by měl fungovat jako filtr. Přijímá zásady, funkce požadavků a trasy kandidátů na poskytovatele. Vrací pouze trasy, které splňují zásady.

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);
}

Na tomto pořadí záleží. Záložní směrování by během výpadku nemělo přeskočit na nezpůsobilého poskytovatele. Dávkové směrování by nemělo přesunout požadavek bez uchování do úložiště asynchronních úloh. Uzemnění by nemělo zapínat funkci, která zavádí odvozené protokoly, když to zásady zakazují.

Pokud vaše platforma odhaluje OpenAIkompatibilní multimodel API, udržujte vrstvu kompatibility poctivou: stejné tělo požadavku se může zkompilovat pro různé funkce nativního poskytovatele. Hodnotitel zásad musí zkontrolovat zkompilovaný požadavek, nejen původní tvar SDK.

Explicitně blokovat rizikové kombinace funkcí

Nejbezpečnější implementací je vytvořit explicitní pravidla odmítnutí pro známé vysoce rizikové kombinace. Příklady:

• NO_RETENTION + FILE_UPLOAD: zakázat, pokud není pro zásady schválen konkrétní koncový bod souboru a nastavení účtu.
• NO_RETENTION + VECTOR_STORE: zakázat, pokud se úložiště vektorů nenachází ve vašem vlastním řízeném úložišti a poskytovatel nikdy neobdrží trvalý stav souboru.
• NO_RETENTION + STORED_RESPONSE: vynucení příznaků úložiště odpovědi nebo odmítnutí, pokud koncový bod nemůže úložiště zakázat.
• EU_ONLY + GLOBAL_DEPLOYMENT: zakázat, pokud může ke zpracování dojít mimo povolenou oblast nebo datovou zónu.
• NO_RETENTION + WEB_GROUNDING: zakázat, pokud funkce uzemnění ukládá odvozené protokoly dotazů nebo kontextu nad rámec zásad.
• METADATA_ONLY_LOGGING + DEBUG_TRACE: potlačit obsah výzev a dokončení z aplikačních protokolů a trasování.
• ZDR_REQUIRED + STATEFUL_ASSISTANT_THREAD: zamítnout, pokud daná funkce není konkrétně způsobilá podle schválených ovládacích prvků účtu.

Return specific errors. Užitečné odmítnutí sdělí vývojáři, co selhalo a jaké existují schválené alternativy.

{
  "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"
    ]
  }
}

Oddělené protokolování odvození od provozní telemetrie

Zásady uchovávání by neměly bránu nutit k oslepení. Obvykle můžete udržovat provozní telemetrii bez ukládání obsahu výzvy nebo dokončení.

For strict workloads, preserve:

• request ID and trace ID;
• nájemce, projekt, API klíč a identifikátory pracovní zátěže;
• policy ID and policy version;
• použitý poskytovatel, koncový bod, model, nasazení a region;
• feature flags requested and allowed;
• decision reason codes;
• počet tokenů, latence, stavový kód a metadata nákladů;
• haše nebo stabilní otisky prstů pro deduplikaci, pokud to zásady schválí.

Suppress or redact:

• nezpracované výzvy;
• raw completions;
• uploaded file content;
• výstupy nástroje, které obsahují zákaznická data;
• načtený kontext z citlivých systémů;
• poskytovatel ladí obsah, který duplikuje obsah.

Tady se směrování uchovávání připojuje k neutrální pozorovatelnosti LLM na poskytovateli. Pozorovatelnost by měla prokázat, co se stalo, aniž by se rozšiřovala sada systémů, které uchovávají citlivý obsah.

Emit Audit Evidence for Every Decision

Záznam auditu by měl vysvětlit, proč byla trasa povolena nebo zamítnuta. It does not need full content to be useful.

{
  "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"
  ]
}

U zamítnutých požadavků ponechte stejnou strukturu jako decision=deny a kódy důvodu, jako je REGION_NOT_ALLOWED, GROUNDING_RETENTION_EXCEEDS_POLICY nebo STATEFUL_STORAGE_NOT_ALLOWED.

Use Contract Tests for Retention Rules

Směrování uchovávání by mělo mít automatické testy. Důležité testy nejsou jen jednotkové testy pro jednotlivé poskytovatele; jsou to smluvní testy chování zásad napříč kombinacemi poskytovatelů.

High-value test cases include:

• Zásady zákazu uchovávání plus nahrávání souborů by měly být zamítnuty, pokud neexistuje konkrétní schválená cesta umožňující soubory.
• Zásady pouze pro EU a globální nasazení by měly být zamítnuty, i když je model jinak dostupný.
• Zásady nulového uchovávání plus uložená historie konverzací by měly zakázat nebo vynutit vypnutí úložiště, pokud je podporováno.
• Funkce uzemnění s uchováváním odvozených protokolů by měla být podle zásad neuchovávání zakázána.
• Zásady protokolování pouze na základě metadat by měly potlačit obsah výzev a dokončení z tras, protokolů a chybových zpráv.
• Záznam schopností poskytovatele s neznámým uchováváním by měl být pro regulované pracovní zatížení zamítnut.
• Záložní opatření po výpadku poskytovatele by měla zůstat uvnitř vhodné sady tras.
• Dávkové zpracování by mělo být odmítnuto, když koncový bod dávky ukládá vstupní soubory déle, než dovolují zásady.

Také otestujte drift. Když se záznam schopností změní, systém by měl ukázat, které zásady a cesty jsou ovlivněny, než se změna dostane do produkce.

Provozní vlastnictví

Nejtěžší na tom není napsat prvního hodnotitele. Udržuje registr aktuální a zabraňuje nezdokumentovaným výjimkám.

Přiřadit vlastníky pro:

• kadence kontroly dokumentace poskytovatele;
• stav schválení pro ovládací prvky na úrovni účtu, jako je modifikované sledování zneužití nebo nulové uchovávání dat;
• inventář regionálního nasazení;
• způsobilost funkcí pro soubory, vektorová úložiště, uzemnění, dávkové a uložené odpovědi;
• pracovní postup výjimek ze zásad;
• uchovávání záznamů o auditu a řízení přístupu;
• chybové zprávy pro vývojáře a schválené alternativy.

Každý záznam o způsobilosti by měl mít datum kontroly. Pokud vyprší, přísné zásady by mu měly přestat důvěřovat nebo vyžadovat ruční schválení. Chování dokumentů a funkcí poskytovatele se příliš často mění na to, aby šlo o statickou konfiguraci.

Ústupky

Přísný retenční směrovač snižuje dostupné možnosti modelů. Některé modely náhledu, stavová rozhraní API, uzemňovací nástroje a pracovní postupy souborů nebudou pro citlivé úlohy k dispozici. To je smysl kontroly, ale produktové týmy potřebují jasné alternativy.

Regionální směrování může zvýšit latenci nebo náklady, když je nejrychlejší nasazení globální, ale zátěž vyžaduje konkrétní geografickou nebo datovou zónu. Zviditelnit to v telemetrii, aby týmy pochopily, proč požadavek použil dražší nebo pomalejší trasu.

Blokování stavových funkcí může přimět týmy k vytvoření vlastní paměťové vrstvy. To může být správná architektura, ale stále potřebuje zásady úložiště, pracovní postupy mazání, šifrování, řízení přístupu a protokoly auditu. Přesunutím stavu od poskytovatele neodstraníte práci na správě.

Výzva a dokončení redigování chrání citlivá data, ale oslabuje ladění a kontrolu kvality. Používejte reprodukovatelná metadata požadavků, deterministické testovací přípravky, řízené vzorkování pro povolené pracovní zátěže a dokumentovaný přístup k rozbití, pokud to zásady dovolují.

Doporučení

• Vynutit uchování a umístění před směrováním modelu, nikoli jako kontrolu po zpracování.
• Možnosti modelu na úrovni poskytovatele, koncového bodu, funkcí, regionu a schvalování účtu.
• Použít chování deny-by-default pro regulované úlohy nebo úlohy vázané na zakázku zákazníka.
• Nahrávání souborů, úložiště vektorů, uzemnění webu, dávkové zpracování a uložená historie konverzací považujte za samostatné dimenze zásad.
• Zachovat provozní telemetrii, i když je třeba potlačit obsah výzvy a dokončení.
• Vysílejte záznamy auditu, které zahrnují zásady, trasu, důkazy o schopnostech, region, příznaky úložiště a kódy příčiny.
• Napište smluvní testy pro vysoce rizikové kombinace funkcí a záložní chování.

Prediction: Směrování retence se stane standardní vrstvou brány

Pravděpodobně se směrování uchovávání stane standardní vrstvou v podnikových platformách LLM, podobně jako limity sazeb, kontroly rozpočtu a pozorovatelnost. S tím, jak poskytovatelé přidávají další stavové nástroje, možnosti uzemnění, mezipaměti, soubory, agenty a funkce spravované paměti, bude bezpečná cesta záviset méně na názvu modelu a více na úplné cestě provedení.

To je předpověď, nikoli současný univerzální požadavek. Současný požadavek je jednodušší: pokud váš tým neslibuje žádné uchovávání, regionální zpracování, žádné školení nebo kontrolu člověkem, vaše brána potřebuje dostatek logiky zásad a důkazů, které prokážou, že každý požadavek dodržoval tato omezení.

Uplatnitelný závěr

Vybudujte směrovač pro uchovávání informací jako bránu zásad před výběrem poskytovatele. Definujte kanonické zásady uchovávání, klasifikujte každý požadavek před směrováním, udržujte datovaný registr schopností poskytovatele, ve výchozím nastavení odmítejte nebezpečné kombinace a protokolujte důkazy auditu bez uchování citlivého obsahu.

Cílem návrhu není najít poskytovatele, který je vždy bezpečný. Cílem je prokázat, že konkrétní požadavek s použitím konkrétního koncového bodu a sady funkcí v rámci konkrétního účtu a oblasti splňuje zásady před odesláním.

Související informace

• provider-neutral design pozorovatelnosti LLM