Data-Retention-Aware AI API Routing: Vynucování zásad ZDR, bydliště a protokolování na bráně

Bezpečnostní týmy nemusí jen vědět, který model je nejlevnější, nejrychlejší nebo nejschopnější. Potřebují vědět, zda lze konkrétní požadavek legálně a operativně odeslat konkrétnímu poskytovateli, koncovému bodu, regionu, funkci a režimu protokolování.

Je to těžší, než to zní. Model může být přijatelný pro běžný interní chat, ale ne pro zákazníka PII. Poskytovatel může nabízet nulové uchovávání dat pro jednu cestu API, zatímco funkce uzemňující vyhledávání ukládá výzvy a výstupy po pevně stanovenou dobu. Oblast může podporovat rezidenci úložiště, ale ne režim zpracování, který jste očekávali. Protokoly vlastněné vývojáři mohou být konfigurovatelné, zatímco protokoly sledování zneužití poskytovatele se řídí jinými zásadami.

Praktickou odpovědí je přesunout rozhodnutí o uchovávání z jednotlivých aplikací do brány AI API. Brána by měla klasifikovat požadavek, vyhodnotit jej podle matice schopností poskytovatele, blokovat nekompatibilní funkce, směrovat pouze do schválených profilů modelu a zaznamenat rozhodnutí o zásadách, aniž by ve výchozím nastavení ukládala nezpracované výzvy.

Problém se čtečkou: podmínky ochrany soukromí poskytovatele nejsou ovládacími prvky runtime

Většina týmů začíná tabulkou nebo bezpečnostní kontrolou, která říká, kteří poskytovatelé umělé inteligence jsou schváleni. To je užitečné, ale pro produkční směrování to nestačí.

Aplikace provádějí volby za běhu:

• Které ID modelu by mělo zpracovat tento požadavek?
• Měl by požadavek používat uzemnění vyhledávání, nahrání souboru, spuštění kódu, dávkové zpracování, rychlé ukládání do mezipaměti nebo uložené konverzace?
• Která oblast nebo koncový bod by měl požadavek zpracovat?
• Může systém zaznamenat nezpracovanou výzvu k ladění?
• Může záložní směrování odeslat stejný požadavek jinému poskytovateli?

Každá z těchto možností může změnit profil uchování. Požadavek, který byl v souladu v režimu prostého chatu, se může stát nevyhovujícím, když vývojář zapne uzemnění nebo trvalé ukládání konverzace. Záložní pravidlo navržené pro spolehlivost může náhodně přesměrovat regulovaná data na cestu poskytovatele, která nebyla schválena pro nulové uchovávání dat, rezidenci dat nebo kontroly sledování zneužití.

Doporučení: zacházejte s chováním uchovávání jako s prvotřídním omezením směrování, nikoli s dokumentací připojenou k účtu poskytovatele.

Fakta, která je třeba zakódovat před navržením zásad

Přesné podmínky se liší podle poskytovatele, produktu, smlouvy, regionu, koncového bodu a funkce. Nespoléhejte na paměť nebo jednorázovou recenzi. Vytvořte matici vlastněnou zdrojem a aktualizujte ji, když se podmínky změní.

Několik aktuálních dokumentů veřejného poskytovatele ilustruje, proč je to nutné:

• OpenAI: Rezidence dat API je zdokumentována jako projektově nakonfigurovaná, přičemž regionální požadavky vyžadují předpony domény specifické pro region. OpenAI také rozlišuje podporu úložiště od podpory zpracování podle regionu a bere na vědomí další požadavky pro regiony mimo USA. OpenAI uvádí, že rezidence dat API mimo USA vyžaduje schválení pro kontroly sledování zneužití a dodatek k modifikovanému uchovávání.
• Anthropic: Anthropic dokumentuje nulové uchovávání dat pro případy komerčního použití související s rozhraním API a zároveň uvádí, že některé související produkty nebo zdroje shody mají samostatné modely uchovávání, včetně delšího uchovávání pro zdroj aktivity a přepisy vzdálených relací.
• Google Gemini: Termíny Gemini API rozlišují neplacené a placené služby. U neplacených služeb může Google použít odeslaný obsah a vygenerované odpovědi ke zlepšení produktů; u placených služeb Google říká, že výzvy a odpovědi se nepoužívají ke zlepšování produktů. Dokumentace Gemini Developer API ZDR uvádí, že protokoly sledování zneužití placených služeb obvykle uchovávají výzvy a odpovědi po omezenou dobu, zatímco schválené projekty ZDR před protokolováním vyčistí uživatelský obsah a identifikovatelná metadata.
• Úložiště specifické pro jednotlivé funkce: Dokumentace Gemini uvádí, že Grounding with Google Search a Grounding with Google Maps ukládají výzvy, kontextové informace a generovaný výstup po dobu 30 dnů, přičemž není možné toto úložiště při použití těchto funkcí deaktivovat.
• Protokoly vlastněné vývojářem: Dokumentace protokolování rozhraní Gemini API uvádí, že protokoly rozhraní API vlastněné vývojářem lze u projektů s povolenou fakturací ve výchozím nastavení uchovávat až 55 dní a že vývojáři si mohou vybrat kratší okna, například 7, 14 nebo 28 dní.
• Řízení rizik: NIST's Generative AI Profile doporučuje monitorovat obsah generovaný umělou inteligencí z hlediska rizik ochrany soukromí a propojovat generativní zásady AI se stávajícími daty, softwarem, právními procesy, procesy dodržování předpisů a řízení rizik.

Toto jsou fakta, která je třeba před zavedením ověřit podle aktuální dokumentace dodavatele. Architektonická lekce je stabilní: retence není logická hodnota na úrovni poskytovatele.

Architektura: modul zásad brány v cestě požadavku

Brána podporující uchovávání informací má pět základních součástí:

1. Klasifikátor citlivosti požadavku: označuje pracovní zátěž před směrováním.
2. Matrika schopností poskytovatele: popisuje poskytovatele, model, koncový bod, region, uchovávání, protokolování a chování funkcí.
3. Pravidla zásad jako kód: převést požadavky na zabezpečení na rozhodnutí o povolení, zamítnutí nebo kontrole za běhu.
4. Vrstva brány funkcí: blokuje funkce měnící uchování, pokud to není výslovně povoleno.
5. Vrstva auditu a analýzy: zaznamenává užitečná metadata, aniž by ve výchozím nastavení ukládala nezpracované výzvy.

Brána nemusí rozumět všem právním nuancím. Potřebuje prosazovat rozhodnutí, která schválila vaše právní, bezpečnostní, compliance a platformová týmy.

Krok 1: Před výběrem modelu klasifikujte citlivost požadavku

Začněte malou klasifikační taxonomií. Měl by být pro vývojáře dostatečně jednoduchý na používání, ale dostatečně výmluvný, aby řídil politiku.

Příklady štítků citlivosti:

• veřejné: veřejná dokumentace, marketingová kopie, veřejný obsah webových stránek.
• interní: neveřejné informace o společnosti s nízkou citlivostí.
• důvěrné: strategie, smlouvy, zákaznický kontext, podrobnosti o nevydaných produktech.
• customer_pii: jména, e-maily, adresy, identifikátory účtů, přepisy podpory.
• regulované: zdravotnická, finanční, právní, vzdělávací nebo chráněná data specifická pro jurisdikci.
• source_code: proprietární kód, konfigurace, soubory architektury.
• přihlašovací údaje: tajemství, tokeny, hesla, soukromé klíče. Ve většině systémů by to mělo být blokováno, nikoli směrováno.

Klasifikace může pocházet z více zdrojů:

• Záhlaví dodané aplikací, například X-Data-Class: customer_pii.
• Zásady pro nájemce, kde je veškerý provoz od regulovaného zákazníka považován za regulovaný, pokud není snížen podle schváleného pravidla.
• Zásady koncového bodu, kde je sumarizace lístků podpory výchozí customer_pii.
• Odlehčený obsah prohledávání přihlašovacích údajů, zjevných PII nebo porušení zásad.

Doporučení: nezávisí zcela na automatické detekci. Vyžadujte, aby aplikace deklarovaly zamýšlenou datovou třídu, a poté použijte skenování k zachycení zjevných neshod nebo vynucení bezpečnější třídy.

Krok 2: Vytvořte matici schopností poskytovatele

Matice schopností je zdrojem pravdy, kterou router vyhodnocuje. Měl by být verzován, zkontrolován a testován jako produkční konfigurace.

Příklady polí:

{
  "profile_id": "poskytovatel_x.chat.eu.zdr",
  "provider": "provider_x",
  "model": "model-velký",
  "api_family": "chat_completions",
  "endpoint": "https://eu.example-provider.com/v1",
  "region": "eu",
  "processing_residency": ["eu"],
  "storage_residency": ["eu"],
  "zdr_eligible": pravda,
  "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": nepravda,
  "supported_features": {
    "plain_chat": pravda,
    "streamování": pravda,
    "tool_calls": true,
    "search_grounding": nepravda,
    "maps_grounding": nepravda,
    "file_upload": false,
    "dávka": nepravda,
    "stored_conversations": nepravda
  },
  "last_reviewed": "2026-08-01",
  "source_refs": ["security-review-123", "vendor-doc-version-abc"]
}

Používejte spíše profily modelů než nezpracovaná ID modelů. Profil kombinuje model, poskytovatele, koncový bod, region, sadu funkcí a retenční pozici. Vývojáři požadují model_profile: compliant_summarization, nejen model: nejrychlejší-velký-model.

Doporučení: zahrňte do matice smluvní předpoklady. Trasa není schválena ZDR pouze proto, že prodejce někde nabízí ZDR. Je schválen pouze tehdy, když váš účet, projekt, region a koncový bod splňují požadované podmínky.

Krok 3: Napište pravidla pro zásady jako kód

Pravidla zásad by měla být explicitní, testovatelná a čitelná pro týmy zabezpečení a platformy.

Příklady pravidel v pseudokódu:

deny if data_class == "přihlašovací údaje"
  důvod "credentials_must_not_be_sent_to_model"
povolit, pouze pokud data_class v ["regulated", "customer_pii"]
  a profil.zdr_eligible == true
  a profil.zdr_contract_required_satisfied == pravda
  důvod_neúspěchu "model_profile_not_zdr_eligible"
zamítnout, pokud je vyžadováno bydliště == "eu"
  a "eu" nejsou v profile.processing_residency
  důvod "region_processing_not_supported"
deny if data_class v ["důvěrné", "customer_pii", "regulated"]a request.raw_prompt_logging == true
  důvod "raw_prompt_logging_not_allowed"
deny if request.features.search_grounding == true
  a policy.requires_zdr == true
  a profile.feature_storage.search_grounding_days > 0
  důvod "grounding_requires_retained_content"
deny if fallback_profile.retention_level < primary_profile.retention_level
  důvod "fallback_weakens_retention_policy"

Tato pravidla by se měla spustit před výběrem poskytovatele a znovu před nouzovým řešením. Záložní směrování je běžným zdrojem náhodného posunu zásad: primární cesta může být kompatibilní, zatímco záložní cesta je pouze dostupná.

Krok 4: Považujte nástroje a funkce za funkce pro změnu uchování

Neuchovávejte model jako vlastnost samotného základního modelu. Funkce často mění chování úložiště, protokolování nebo kontroly.

Přidělte každé funkci vlastní příznaky zásad:

• Uzemnění vyhledávání: může ukládat výzvy, načtený kontext a generovaný výstup v závislosti na podmínkách poskytovatele.
• Mapy nebo uzemnění polohy: může zavádět protokoly nebo pravidla uchování specifické pro dané místo.
• Nahrání souboru: může ukládat soubory odděleně od výzev a odpovědí.
• Spouštění kódu: může vytvářet dočasné soubory, protokoly spouštění nebo artefakty izolovaného prostoru.
• Dávkové úlohy: mohou mít jiné chování uchovávání, řazení do fronty a ukládání výsledků než synchronní volání rozhraní API.
• Uložené konverzace: záměrně uchovávají obsah a nikdy by neměly být skryty za obecnou možností chatu.
• Panely hodnocení nebo kontroly: mohou vytvářet pracovní postupy kontroly člověkem nebo dlouhodobější datové sady.

Doporučení: aktivujte funkce pro změnu uchování na úrovni tenanta a trasy. Pokud vývojář povolí grounding_search=true, brána by měla požadavek znovu vyhodnotit podle pravidel pro ukládání funkcí, než jej odešle upstream.

Krok 5: Zachovejte analýzu bez ukládání nezpracovaných výzev

Směrování s ohledem na zachování by nemělo zaslepit tým platformy. Můžete si ponechat užitečnou analýzu využití AI a zároveň minimalizovat úložiště obsahu.

Bezpečná výchozí pole telemetrie:

• ID nájemce a ID projektu
• hašované nebo interní ID klíče API
• ID profilu modelu a ID poskytovatele
• požadavek na časové razítko a region
• počet vstupů, výstupů, mezipaměti a logických tokenů, pokud jsou k dispozici
• latence, stavový kód, počet opakování a záložní rozhodnutí
• odhadované a vypořádané náklady
• štítek klasifikace dat
• verze zásad a důvod rozhodnutí o zásadách
• Požadované příznaky funkcí a povolené příznaky funkcí

Neukládejte ve výchozím nastavení nezpracované výzvy a výstupy modelu pro důvěrný provoz. Pokud ladění vyžaduje obsah, použijte řízený pracovní postup:

• schválení zákazníkem nebo nájemcem
• úzké časové okno
• limit vzorkování
• redakce
• samostatné řízení přístupu
• krátká platnost
• protokol auditu, kdo a proč to povolil

Toto je kompromis. Blokování nezpracovaných protokolů výzev ztěžuje ladění, podporu, kontrolu kvality a vyšetřování zneužití. Ale ukládání všeho ve výchozím nastavení vytváří větší ochranu soukromí, porušení a dodržování předpisů.

Krok 6: Vraťte žalovatelné důvody zamítnutí

Obecné 403 zakázáno frustruje vývojáře a podporuje náhradní řešení. Vraťte stabilní strojově čitelný důvod a lidem čitelné vysvětlení.

Příklad odpovědi:

{
  "chyba": {
    "type": "policy_denied",
    "code": "grounding_requires_30_day_storage",
    "message": "Uzemnění vyhledávání není povoleno pro úlohy označené require_zdr, protože tato funkce poskytovatele ukládá obsah výzvy, kontext a výstupní obsah.",
    "request_id": "req_123",
    "policy_version": "retention-policy-2026-08-01",
    "allowed_actions": [
      "disable_search_grounding",
      "vyberte_profil:zdr_plain_chat",
      "request_exception"
    ]
  }
}

Mezi užitečné kódy odmítnutí patří:

• 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
• chýbající_předpoklad_smluvy
• zjištěna pověření

Krok 7: Přidejte pracovní postup výjimky, nikoli skryté obcházení

Některé výjimky jsou legitimní: reakce na incidenty, zákazníkem schválené ladění, testování migrace nebo dočasné omezení poskytovatele. Brána by měla podporovat výjimky, aniž by je změnila na trvalou stínovou politiku.

Každá výjimka by měla obsahovat:

• totožnost schvalovatele
• žádající tým nebo nájemce
• odkaz na vstupenku nebo posouzení rizik
• obchodní odůvodnění
• povolené profily a funkce modelů
• zahrnuté datové třídy
• datum vypršení platnosti
• další požadavky na protokolování

Doporučení: udělejte výjimky užší než běžné zásady. Vyhněte se globálním přepínačům, jako je disable_retention_policy=true. Upřednostňujte přepsání rozsahu, jako je „povolit protokolování výzvy k ladění pro tenanta A, koncový bod B, po dobu 24 hodin, se schválením redakce a zabezpečení.“

Provozní kontrolní seznam

• Vytvořte matici schopností verzovaného poskytovatele.
• Přiřaďte vlastníka pro podmínky poskytovatele, podmínky smlouvy a kontroly udržení.
• Vyžadovat, aby aplikace deklarovaly datovou třídu, požadavek na bydliště a požadované funkce.
• Výchozí důvěrný a regulovaný provoz na protokolování bez nezpracovaných výzev.
• Nástroje, uzemnění, nahrávání souborů, dávky a uložené konverzace představují samostatné příznaky funkcí.
• Před primárním směrováním a před záložním směrováním spusťte kontrolu zásad.
• Verze zásad protokolu, profil modelu, datová třída, příznaky funkcí a důvod zamítnutí.
• Uchovávejte metadata analýzy odděleně od obsahu výzvy a výstupu.
• Testovací zástupce povoluje a zamítá případy v CI.
• Zkontrolujte změnu zásad, kdykoli poskytovatel změní podmínky, oblasti, koncové body nebo funkce.

Vyjádření kompromisů

Přísné směrování snižuje výběr. Omezení ZDR a bydliště mohou bránit použití nejnovějšího modelu, nejlevnější trasy nebo koncového bodu s bohatými funkcemi.

Regionální směrování může zvýšit latenci nebo náklady. Nejbližší vyhovující region nemusí podporovat požadovaný režim zpracování nebo může vyžadovat jinou cestu poskytovatele.

Funkční brány překvapují vývojáře. Vývojář si může myslet, že povolují pouze vyhledávání, ale zabezpečení vidí nové chování uchovávání. Dokumentace a zprávy o zamítnutí snižují tření.

Rychlá minimalizace komplikuje ladění. Týmy potřebují upravené vzorky, okna ladění schválená tenantem a silná metadata, aby mohly prozkoumat problémy, aniž by vše ukládaly.

Matice vyžaduje údržbu. Podmínky poskytovatele se mění. Uvedení nových modelů. Regiony se rozšiřují. Funkce se přesouvají z beta verze do produkce. Zastaralá matice je horší než žádná matice, protože vytváří falešnou důvěru.

Co je doporučení a co je předpověď?

Doporučení: vynucovat uchovávání na bráně, klasifikovat požadavky před směrováním, vytvářet matici schopností poskytovatele, blokovat funkce měnící uchovávání podle zásad, ve výchozím nastavení se vyhýbat protokolování nezpracovaných výzev a upravovat všechna rozhodnutí o zásadách.

Předpověď: Týmy platformy AI budou stále více přistupovat k ochraně soukromí jako k součásti výběru modelu. Místo toho, abyste se zeptali „který model bychom měli použít?“ aplikace si vyžádají modelový profil, který splňuje omezení schopností, nákladů, latence, bydliště a zachování.

Předpověď: Funkce ochrany soukromí specifické pro poskytovatele se budou i nadále lišit. Brány, které normalizují pouze formáty požadavků a odpovědí, nebudou stačit; produkční týmy budou také potřebovat normalizaci zásad.

Akční závěr

Směrování s ohledem na uchovávání dat není samostatný řídicí panel shody. Patří do cesty požadavku.

Začněte se třemi výstupy: taxonomií citlivosti požadavků, maticí schopností verzovaného poskytovatele a malou sadou pravidel pro zásady jako kód pro funkce ZDR, rezidence, nezpracované protokolování, záložní funkce a změny uchování. Poté zajistěte, aby brána vracela jasné důvody zamítnutí a zachovala analýzu, aniž by ve výchozím nastavení ukládala nezpracovaný obsah.

Tento návrh centralizuje rozhodnutí, která by jinak byla rozptýlena mezi možnostmi sady SDK, proměnnými prostředí, konzolami poskytovatelů a konvencemi specifickými pro tým. Poskytuje také bezpečnostním a platformovým týmům praktickou auditní stopu: který požadavek byl povolen, která verze zásad byla použita, který profil modelu byl vybrán a proč.

Související informace

• Analýza využití na úrovni brány
• vytvoření matice schopností poskytovatele během migrace API kompatibilní s OpenAI
• nástroje pro správu agentů s rozsahy, schváleními a auditními záznamy