Smerovanie AI API s ohľadom na uchovávanie údajov: Presadzujte zásady ZDR, bydliska a protokolovania na bráne

Bezpečnostné tímy nepotrebujú len vedieť, ktorý model je najlacnejší, najrýchlejší alebo najschopnejší. Potrebujú vedieť, či je možné konkrétnu žiadosť legálne a operatívne odoslať konkrétnemu poskytovateľovi, koncovému bodu, regiónu, funkcii a režimu protokolovania.

Je to ťažšie, ako to znie. Model môže byť prijateľný pre bežný interný chat, ale nie pre PII zákazníka. Poskytovateľ môže ponúknuť nulové uchovávanie údajov pre jednu cestu API, zatiaľ čo funkcia uzemňovania vyhľadávania ukladá výzvy a výstupy na pevne stanovené obdobie. Región môže podporovať umiestnenie úložiska, ale nie režim spracovania, ktorý ste očakávali. Denníky vlastnené vývojármi môžu byť konfigurovateľné, zatiaľ čo denníky sledovania zneužitia poskytovateľa sa riadia inými pravidlami.

Praktická odpoveď je presunúť rozhodnutia o uchovávaní z jednotlivých aplikácií do brány AI API. Brána by mala klasifikovať požiadavku, vyhodnotiť ju podľa matice schopností poskytovateľa, blokovať nekompatibilné funkcie, smerovať iba do schválených profilov modelu a zaznamenať rozhodnutie o politike bez ukladania nespracovaných výziev v predvolenom nastavení.

Problém s čítačkou: podmienky ochrany osobných údajov poskytovateľa nie sú ovládacími prvkami runtime

Väčšina tímov začína tabuľkou alebo bezpečnostnou kontrolou, ktorá hovorí, ktorí poskytovatelia AI sú schválení. To je užitočné, ale na smerovanie výroby to nestačí.

Aplikácie vyberajú možnosti spustenia:

• Ktoré ID modelu by malo spracovať túto žiadosť?
• Mala by žiadosť používať uzemnenie vyhľadávania, odovzdanie súboru, spustenie kódu, dávkové spracovanie, rýchle ukladanie do vyrovnávacej pamäte alebo uložené konverzácie?
• Ktorý región alebo koncový bod by mal spracovať žiadosť?
• Môže systém zaznamenať prvotnú výzvu na ladenie?
• Môže záložné smerovanie odoslať rovnakú požiadavku inému poskytovateľovi?

Každá z týchto možností môže zmeniť profil uchovávania. Žiadosť, ktorá bola v súlade v režime obyčajného rozhovoru, sa môže stať nevyhovujúcou, keď vývojár zapne uzemnenie alebo trvalé ukladanie konverzácií. Záložné pravidlo navrhnuté pre spoľahlivosť môže náhodne nasmerovať regulované údaje na cestu poskytovateľa, ktorá nebola schválená na nulové uchovávanie údajov, uchovávanie údajov alebo kontroly na monitorovanie zneužívania.

Odporúčanie: správajte sa k uchovávaniu ako k prvotriednemu obmedzeniu smerovania, nie ako k dokumentácii pripojenej k účtu poskytovateľa.

Fakty, ktoré je potrebné zakódovať pred návrhom politiky

Presné podmienky sa líšia v závislosti od poskytovateľa, produktu, zmluvy, regiónu, koncového bodu a funkcie. Nespoliehajte sa na pamäť ani jednorazovú recenziu. Vytvorte maticu vlastnenú zdrojom a aktualizujte ju, keď sa zmenia podmienky.

Niekoľko aktuálnych dokumentov verejného poskytovateľa ilustruje, prečo je to potrebné:

• OpenAI: Rezidencia údajov rozhrania API je zdokumentovaná ako projektovo nakonfigurovaná, pričom regionálne požiadavky vyžadujú predpony domény špecifické pre daný región. OpenAI tiež rozlišuje podporu úložiska od podpory spracovania podľa regiónu a berie na vedomie dodatočné požiadavky pre regióny mimo USA. OpenAI uvádza, že bydlisko údajov API mimo USA si vyžaduje schválenie ovládacích prvkov na monitorovanie zneužívania a dodatok k modifikovanému uchovávaniu.
• Anthropic: Anthropic dokumentuje nulové uchovávanie údajov pre prípady komerčného použitia súvisiaceho s rozhraním API, pričom poznamenáva, že niektoré súvisiace produkty alebo informačné kanály dodržiavania súladu majú samostatné modely uchovávania vrátane dlhšieho uchovávania pre informačný kanál aktivity a prepisy vzdialených relácií.
• Google Gemini: Termíny Gemini API rozlišujú neplatené a platené služby. V prípade neplatených služieb môže spoločnosť Google použiť odoslaný obsah a vygenerované odpovede na zlepšenie produktov; v prípade platených služieb Google hovorí, že výzvy a odpovede sa nepoužívajú na zlepšenie produktov. V dokumentácii ZDR Gemini Developer API sa uvádza, že protokoly monitorovania zneužitia platených služieb zvyčajne uchovávajú výzvy a odpovede počas obmedzeného obdobia, zatiaľ čo schválené projekty ZDR pred prihlásením vyčistia obsah používateľa a identifikovateľné metadáta.
• Ukladací priestor špecifický pre jednotlivé funkcie: V dokumentácii Gemini sa uvádza, že Uzemnenie pomocou Vyhľadávania Google a Uzemnenie s Mapami Google uchovávajú výzvy, kontextové informácie a generovaný výstup po dobu 30 dní, pričom pri používaní týchto funkcií nie je možné toto úložisko zakázať.
• Denníky vo vlastníctve vývojárov: V dokumentácii k protokolom Gemini API sa uvádza, že denníky rozhrania API vlastnené vývojármi môžu byť predvolene uchovávané až 55 dní v prípade projektov s povolenou fakturáciou a že vývojári si môžu zvoliť kratšie okná, napríklad 7, 14 alebo 28 dní.
• Riadenie rizík: NIST's Generative AI Profile odporúča monitorovať obsah generovaný AI z hľadiska rizík ochrany súkromia a spájať generatívne pravidlá AI s existujúcimi údajmi, softvérom, právnymi procesmi, procesmi dodržiavania predpisov a riadenia rizík.

Toto sú fakty, ktoré je potrebné pred zavedením overiť v porovnaní s aktuálnou dokumentáciou dodávateľa. Architektonická lekcia je stabilná: uchovávanie nie je logická hodnota na úrovni poskytovateľa.

Architektúra: nástroj politiky brány v ceste žiadosti

Brána s podporou uchovávania údajov má päť základných komponentov:

1. Klasifikátor citlivosti požiadavky: označuje pracovnú záťaž pred smerovaním.
2. Matrika schopností poskytovateľa: popisuje poskytovateľa, model, koncový bod, oblasť, uchovávanie, protokolovanie a správanie funkcií.
3. Pravidlá politiky ako kódu: konvertujte bezpečnostné požiadavky na rozhodnutia o povolení, odmietnutí alebo kontrole spustenia.
4. Vrstva brány funkcií: blokuje funkcie, ktoré menia uchovávanie, pokiaľ to nie je výslovne povolené.
5. Vrstva auditu a analýzy: zaznamenáva užitočné metadáta bez ukladania nespracovaných výziev v predvolenom nastavení.

Brána nemusí chápať všetky právne nuansy. Musí presadzovať rozhodnutia, ktoré schválili vaše právne tímy, tímy zabezpečenia, dodržiavania pravidiel a platformy.

Krok 1: klasifikujte citlivosť požiadavky pred výberom modelu

Začnite s malou klasifikačnou taxonómiou. Mal by byť dostatočne jednoduchý na používanie pre vývojárov, no zároveň dostatočne expresívny na to, aby riadil politiku.

Príklady označení citlivosti:

• verejné: verejná dokumentácia, marketingová kópia, verejný obsah webových stránok.
• interné: neverejné informácie o spoločnosti s nízkou citlivosťou.
• dôverné: stratégia, zmluvy, kontext zákazníka, podrobnosti o nevydaných produktoch.
• customer_pii: mená, e-maily, adresy, identifikátory účtov, prepisy podpory.
• regulované: chránené údaje týkajúce sa zdravotnej starostlivosti, financií, práva, vzdelávania alebo konkrétnej jurisdikcie.
• source_code: vlastný kód, konfigurácia, súbory architektúry.
• poverenia: tajomstvá, tokeny, heslá, súkromné kľúče. Vo väčšine systémov by to malo byť blokované, nie smerované.

Klasifikácia môže pochádzať z viacerých zdrojov:

• Hlavička dodaná aplikáciou, napríklad X-Data-Class: customer_pii.
• Pravidlá pre nájomníkov, kde sa všetka návštevnosť od regulovaného zákazníka považuje za regulovanú, pokiaľ nie je znížená na základe schváleného pravidla.
• Zásady koncového bodu, kde je sumarizácia lístkov podpory predvolene customer_pii.
• Odľahčený obsah skenuje poverenia, zjavné PII alebo porušenia pravidiel.

Odporúčanie: nezávisia úplne od automatickej detekcie. Vyžadovať, aby aplikácie deklarovali zamýšľanú dátovú triedu, a potom pomocou skenovania zachytiť zjavné nezhody alebo vynútiť bezpečnejšiu triedu.

Krok 2: zostavte maticu schopností poskytovateľa

Matrica schopností je zdrojom pravdy, ktorú router vyhodnocuje. Mala by byť aktualizovaná, kontrolovaná a testovaná ako produkčná konfigurácia.

Príklady polí:

{
  "profile_id": "poskytovateľ_x.chat.eu.zdr",
  "provider": "provider_x",
  "model": "model-veľký",
  "api_family": "dokončenie_chatu",
  "endpoint": "https://eu.example-provider.com/v1",
  "región": "eu",
  "processing_residency": ["eu"],
  "storage_residency": ["eu"],
  "zdr_eligible": pravda,
  "zdr_contract_required": pravda,
  "training_use": "nepoužíva sa_na_tréning_na_platenom_api",
  "abuse_monitoring": "požaduje sa schválená_upravená_uchovávanie",
  "developer_log_retention_days": 0,
  "raw_prompt_logging_allowed": nepravda,
  "supported_features": {
    "plain_chat": pravda,
    "streaming": 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žívajte radšej profily modelov ako nespracované ID modelov. Profil kombinuje model, poskytovateľa, koncový bod, región, sadu funkcií a polohu uchovávania. Vývojári požadujú model_profile: compliant_summarization, nielen model: najrýchlejší-veľký model.

Odporúčanie: zahrňte do matice zmluvné predpoklady. Trasa nie je schválená ZDR len preto, že predajca niekde ponúka ZDR. Schválené je iba vtedy, keď váš účet, projekt, región a koncový bod spĺňajú požadované podmienky.

Krok 3: napíšte pravidlá pre politiku ako kód

Pravidlá pravidiel by mali byť explicitné, testovateľné a čitateľné pre tímy zabezpečenia a platformy.

Príklady pravidiel v pseudokóde:

deny if data_class == "poverenia"
  dôvod "poverenia_nemusí_byť_odoslané_do_modelu"
povoliť, iba ak data_class v ["regulated", "customer_pii"]
  a profil.zdr_eligible == pravda
  a profil.zdr_contract_required_satisfied == pravda
  dôvod_zlyhania "model_profile_not_zdr_eligible"
zamietnuť, ak je residency_required == "eu"
  a „eu“ nie je v profile.processing_residency
  dôvod "region_processing_not_supported"
zamietnuť, ak data_class v ["dôverné", "customer_pii", "regulované"]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"

Tieto pravidlá by sa mali spustiť pred výberom poskytovateľa a znova pred záložným riešením. Záložné smerovanie je bežným zdrojom náhodného posunu politiky: primárna cesta môže byť kompatibilná, zatiaľ čo záložná cesta je len dostupná.

Krok 4: zaobchádzajte s nástrojmi a funkciami ako s možnosťami zmeny uchovávania

Neuchovávajte model ako vlastnosť samotného základného modelu. Funkcie často menia správanie úložiska, protokolovania alebo kontroly.

Priraďte každej funkcii vlastné príznaky politiky:

• Uzemnenie vyhľadávania: môže ukladať výzvy, načítaný kontext a generovaný výstup v závislosti od podmienok poskytovateľa.
• Uzemnenie máp alebo polohy: môže zaviesť protokoly alebo pravidlá uchovávania špecifické pre polohu.
• Odovzdávanie súborov: môže ukladať súbory oddelene od výziev a odpovedí.
• Spustenie kódu: môže vytvárať dočasné súbory, denníky spustenia alebo artefakty v karanténe.
• Dávkové úlohy: môžu mať iné správanie pri uchovávaní, radení a ukladaní výsledkov ako synchrónne volania rozhrania API.
• Uložené konverzácie: zámerne uchovávajú obsah a nikdy by sa nemali skrývať za všeobecnú možnosť rozhovoru.
• Panely hodnotenia alebo kontroly: môžu vytvárať pracovné postupy kontroly človekom alebo množiny údajov s dlhšou životnosťou.

Odporúčanie: aktivujte funkcie na zmenu uchovávania na úrovni nájomníka a trasy. Ak vývojár povolí grounding_search=true, brána by mala žiadosť pred odoslaním upstream prehodnotiť podľa pravidiel ukladania funkcií.

Krok 5: Zachovajte analýzy bez ukladania nespracovaných výziev

Smerovanie na základe zachovania údajov by nemalo zaslepiť tím platformy. Môžete si ponechať užitočnú analýzu používania AI a zároveň minimalizovať ukladanie obsahu.

Bezpečné predvolené telemetrické polia:

• ID nájomníka a ID projektu
• hašované alebo interné ID kľúča API
• ID profilu modelu a ID poskytovateľa
• požiadať o časovú pečiatku a región
• počet vstupných, výstupných, uložených a logických tokenov, ak sú k dispozícii
• latencia, stavový kód, počet opakovaní a záložné rozhodnutie
• odhadované a vyrovnané náklady
• štítok klasifikácie údajov
• verzia pravidiel a dôvod rozhodnutia o politike
• požadované príznaky funkcie a povolené príznaky funkcie

Pre dôvernú komunikáciu sa predvolene vyhýbajte ukladaniu nespracovaných výziev a výstupov modelu. Ak ladenie vyžaduje obsah, použite riadený pracovný postup:

• schválenie zákazníkom alebo nájomcom
• úzke časové okno
• limit odberu vzoriek
• redakčný preukaz
• samostatné riadenie prístupu
• krátke uplynutie platnosti
• v denníku auditu, kto a prečo to povolil

Ide o kompromis. Blokovanie nespracovaných protokolov výziev sťažuje ladenie, podporu, kontrolu kvality a vyšetrovanie zneužitia. Predvolené ukladanie všetkého však vytvára väčší priestor na ochranu súkromia, porušenie a dodržiavanie pravidiel.

Krok 6: Vráťte žalovateľné dôvody odmietnutia

Všeobecné 403 zakázané frustruje vývojárov a podporuje alternatívne riešenia. Vráťte stabilný strojovo čitateľný dôvod a ľudsky čitateľné vysvetlenie.

Príklad odpovede:

{
  "chyba": {
    "type": "policy_denied",
    "code": "grounding_requires_30_day_storage",
    "message": "Uzemnenie vyhľadávania nie je povolené pre pracovné zaťaženia označené require_zdr, pretože táto funkcia poskytovateľa ukladá 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"
    ]
  }
}

Medzi užitočné kódy odmietnutia patria:

• 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úca zmluva
• zistené poverenia

Krok 7: pridajte pracovný postup výnimky, nie skryté obídenie

Niektoré výnimky sú legitímne: reakcia na incident, ladenie schválené zákazníkom, testovanie migrácie alebo dočasné obmedzenie poskytovateľa. Brána by mala podporovať výnimky bez toho, aby ich zmenila na trvalú tieňovú politiku.

Každá výnimka by mala obsahovať:

• totožnosť schvaľovateľa
• požadujúci tím alebo nájomca
• odkaz na lístok alebo posúdenie rizika
• obchodné odôvodnenie
• povolené profily a funkcie modelov
• zahrnuté triedy údajov
• dátum vypršania platnosti
• ďalšie požiadavky na protokolovanie

Odporúčanie: urobte výnimky užšie ako bežné pravidlá. Vyhnite sa globálnym prepínačom, ako je napríklad disable_retention_policy=true. Uprednostňujte prepísania v rozsahu, ako napríklad „povoliť protokolovanie výzvy na ladenie pre nájomníka A, koncový bod B, na 24 hodín, s revíziou a schválením zabezpečenia.“

Prevádzkový kontrolný zoznam

• Vytvorte maticu funkcií poskytovateľa s verziou.
• Priraďte vlastníka pre podmienky poskytovateľa, predpoklady zmluvy a kontroly uchovávania.
• Vyžadovať, aby aplikácie deklarovali triedu údajov, požiadavku trvalého pobytu a požadované funkcie.
• Predvolene nastavte dôvernú a regulovanú návštevnosť na protokolovanie bez nespracovaných výziev.
• Nástroje, uzemnenie, nahrávanie súborov, dávky a uložené konverzácie predstavujú samostatné príznaky funkcií.
• Pred primárnym smerovaním a pred záložným smerovaním spustite kontroly pravidiel.
• Verzia politiky denníka, profil modelu, trieda údajov, príznaky funkcie a dôvod odmietnutia.
• Uchovávajte metadáta analýzy oddelene od obsahu výzvy a výstupu.
• Testovací zástupca povoľuje a zamieta prípady v CI.
• Skontrolujte zmenu pravidiel vždy, keď poskytovateľ zmení podmienky, regióny, koncové body alebo funkcie.

Vysvetlenie kompromisov

Prísne smerovanie znižuje výber. Obmedzenia ZDR a bydliska môžu brániť použitiu najnovšieho modelu, najlacnejšej trasy alebo koncového bodu s bohatými funkciami.

Regionálne smerovanie môže zvýšiť latenciu alebo náklady. Najbližší vyhovujúci región nemusí podporovať požadovaný režim spracovania alebo môže vyžadovať inú cestu poskytovateľa.

Funkčné brány prekvapujú vývojárov. Vývojár si môže myslieť, že povoľujú iba vyhľadávanie, ale zabezpečenie vidí nové správanie pri uchovávaní. Dokumentácia a správy o odmietnutí znižujú trenie.

Rýchla minimalizácia komplikuje ladenie. Tímy potrebujú zredigované vzorky, nájomníkmi schválené okná ladenia a silné metadáta, aby mohli preskúmať problémy bez ukladania všetkého.

Matrika vyžaduje údržbu. Podmienky poskytovateľa sa menia. Uvedenie nových modelov. Regióny sa rozširujú. Funkcie sa presúvajú z beta verzie do produkcie. Zastaraná matica je horšia ako žiadna, pretože vytvára falošnú dôveru.

Čo je odporúčanie a čo je predpoveď?

Odporúčania: vynútiť uchovávanie na bráne, klasifikovať požiadavky pred smerovaním, zostaviť maticu spôsobilostí poskytovateľa, blokovať funkcie zmeny uchovávania podľa politiky, predvolene sa vyhýbať protokolovaniu nespracovaných výziev a upravovať každé politické rozhodnutie.

Predpoveď: Tímy platformy AI budú čoraz viac pristupovať k ochrane súkromia ako súčasti výberu modelu. Namiesto otázky „aký model by sme mali použiť?“ aplikácie si vyžiadajú modelový profil, ktorý vyhovuje kapacite, nákladom, latencii, bydlisku a obmedzeniam zachovania.

Predpoveď: funkcie ochrany osobných údajov jednotlivých poskytovateľov sa budú naďalej líšiť. Brány, ktoré normalizujú iba formáty požiadaviek a odpovedí, nebudú stačiť; produkčné tímy budú tiež potrebovať normalizáciu politiky.

Uplatniteľný záver

Smerovanie s ohľadom na uchovávanie údajov nie je samostatným panelom súladu. Patrí do cesty žiadosti.

Začnite s tromi výstupmi: taxonómiou citlivosti požiadaviek, maticou spôsobilostí poskytovateľa verzií a malým súborom pravidiel politiky ako kódu pre funkcie ZDR, bydliska, nespracované protokolovanie, záložné zdroje a zmeny uchovávania. Potom zabezpečte, aby brána vracala jasné dôvody odmietnutia a zachovala analýzu bez ukladania nespracovaného obsahu v predvolenom nastavení.

Tento návrh centralizuje rozhodnutia, ktoré by inak boli rozptýlené medzi možnosťami súpravy SDK, premennými prostredia, konzolami poskytovateľa a konvenciami špecifickými pre tím. Poskytuje tiež bezpečnostným a platformovým tímom praktický audit trail: ktorá požiadavka bola povolená, ktorá verzia politiky bola použitá, ktorý profil modelu bol vybraný a prečo.

Súvisiace informácie

• analytika používania na úrovni brány
• vytvorenie matice schopností poskytovateľa počas migrácie API kompatibilného s OpenAI
• nástroje na riadenie agentov s rozsahmi, schváleniami a záznamami auditu