Ako vytvoriť smerovač na politiku uchovávania údajov pre LLM API s viacerými poskytovateľmi

Smerovač LLM od viacerých poskytovateľov by si nemal najskôr vybrať model a neskôr klásť otázky týkajúce sa uchovávania. Ak je pracovný postup podpory označený ako no-retention, brána musí vedieť, či vybraný poskytovateľ, koncový bod, región, nastavenie účtu a kombinácia funkcií môžu splniť tento prísľub predtým, ako požiadavka opustí vašu hranicu.

Režim zlyhania je ľahké prehliadnuť. Tím začína dokončením chatu bez stavu. Trasa je prijateľná. Neskôr niekto pridá nahrávanie súborov, uloženú históriu konverzácií, uzemnenie webu, dávkové spracovanie alebo vektorový obchod. Názov modelu môže zostať rovnaký, ale zmení sa správanie údajov. Jednoduchý smerovač latencie alebo nákladov môže potichu odosielať regulované výzvy alebo výzvy viazané na zmluvu zákazníka na cestu, ktorá ukladá obsah dlhšie, než umožňuje pracovné zaťaženie.

Praktická oprava je umiestniť ovládacie prvky uchovávania údajov LLM pred smerovanie modelu. Smerovač by mal klasifikovať požiadavku, porovnať ju s kanonickou politikou uchovávania, filtrovať možnosti poskytovateľa, blokovať nepovolené funkcie a vydávať overiteľné dôkazy pre rozhodnutie.

Fakty, ktoré treba považovať za obmedzenia dizajnu

Zaobchádzanie s údajmi poskytovateľa nie je jednotné a len zriedka je zachytené iba názvom poskytovateľa. Pri navrhovaní smerovača s podporou uchovávania údajov sú dôležité tieto skutočnosti:

• OpenAI uvádza, že údaje API sa nepoužívajú na trénovanie alebo zlepšovanie modelov, pokiaľ sa zákazník neprihlási. Oprávnení zákazníci môžu po schválení nakonfigurovať modifikované monitorovanie zneužívania alebo nulové uchovávanie údajov na úrovni organizácie alebo projektu.
Zero Data Retention od
• OpenAI mení správanie koncového bodu vrátane toho, že parameter store pre odpovede a dokončenia rozhovoru považuje za nepravdivý, ale niektoré koncové body a funkcie môžu stále ukladať stav aplikácie a nie sú vhodné na nulové uchovávanie údajov.
• Anthropic dokumenty s nulovým uchovávaním údajov pre Claude API, pretože neukladajú výzvy zákazníkov ani pokojné odpovede po vrátení odpovede API, ale pokrytie závisí od vhodnosti koncového bodu a funkcie.
• Anthropic uvádza, že niektoré Claude funkcie alebo zahrnuté modely môžu vyžadovať uchovanie a nemusia byť dostupné v rámci nulového uchovávania údajov, pokiaľ nie sú výslovne povolené.
• Google Cloudové dokumenty, ktoré Gemini Údaje platformy Enterprise Agent Platform sa nepoužívajú na trénovanie alebo dolaďovanie modelov AI/ML bez predchádzajúceho povolenia alebo pokynov, ale nulové uchovávanie údajov si vyžaduje špecifické akcie a pri niektorých pokročilých funkciách nemusí byť možné.
• Google Cloudové dokumenty, ktoré Grounding with Google Search uchováva odvodené denníky dopytov a kontextu až na tri dni a nemôže zakázať toto úložisko pre túto funkciu. Odporúča Web Grounding for Enterprise, keď sa vyžaduje nulové uchovávanie údajov.
• Dokumenty spoločnosti Microsoft, že modely hostené v Azure predávané spoločnosťou Azure nesprístupňujú výzvy a vyplnenia OpenAI ani iným poskytovateľom modelov a nepoužívajú ich na trénovanie základných modelov bez povolenia alebo pokynov.
• Dokumenty spoločnosti Microsoft, ktorých typ nasadenia Azure ovplyvňuje umiestnenie spracovania. Globálne nasadenia môžu spracovávať výzvy a odpovede v akejkoľvek geografickej oblasti, kde je model nasadený, zatiaľ čo nasadenia DataZone obmedzujú spracovanie na vybranú zónu. Uložené údaje zostávajú v geografickej oblasti určenej zákazníkom.
• Dokumenty spoločnosti Microsoft, v ktorých niektoré stavové funkcie Azure ukladajú údaje vrátane súborov, vektorových úložísk, histórie správ odpovedí, vlákien Asistenta, vstupov dávkového spracovania a uložených dokončení.
• Dokumenty spoločnosti Microsoft, ktoré môžu schváleným zákazníkom upravovať monitorovanie zneužitia a ktoré môžu na portáli Azure alebo CLI zobraziť ContentLogging=false, keď je ukladanie údajov na monitorovanie zneužitia vypnuté.

Toto nie sú detaily okrajov. Znamená to, že smerovač musí spoločne vyhodnotiť koncový bod, funkciu, schválenie účtu a región. Označenie celého poskytovateľa, ako napríklad „ZDR povolené“, je príliš hrubé pre produkčnú politiku.

Referenčná architektúra

Brána multimodelovej AI API, ktorá podporuje uchovávanie údajov, potrebuje päť komponentov v ceste žiadosti:

1. Klasifikátor požiadaviek: extrahuje citlivosť údajov, zmluvu nájomcu, regionálne požiadavky, používanie funkcií, vstupy do súborov, používanie nástrojov a povolenia na zapisovanie do denníka.
2. Policy resolver: mapuje požiadavku na kanonickú politiku uchovávania, zvyčajne z nájomníka, projektu, prostredia, kľúča API a metadát pracovného zaťaženia.
3. Register schopností poskytovateľa: poskytovateľ záznamov, koncový bod, model, funkcia, región a možnosti uchovávania na úrovni účtu s datovanými dôkazmi.
4. Policy evaluator: filtruje kandidátske trasy a vracia buď schválenú cestu, alebo odmietnutie pravidiel s kódom príčiny.
5. Vysielač auditu: zaznamená zvolenú trasu, zhodnú politiku, predpoklady schopností, región, príznaky úložiska a režim zaznamenávania obsahu.

Táto architektúra oddeľuje rozhodnutia o uchovávaní a pobyte od nákladov, latencie a záložných zdrojov. K smerovaniu nákladov stále môže dôjsť, ale iba v rámci súboru trás, ktoré spĺňajú pravidlá uchovávania.

Definujte kanonické pravidlá uchovávania

Začnite s objektom politiky neutrálnym voči poskytovateľovi. Nekopírujte terminológiu jedného poskytovateľa do svojej internej zmluvy. Vaše interné pravidlá by mali popisovať, čo môže pracovné zaťaženie robiť, nie to, ako konkrétny poskytovateľ ponúka 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"
}

Pre menej obmedzené pracovné zaťaženie použite radšej explicitné uvoľnenie ako chýbajúce polia:

{
  "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é polia nie sú len trvanie uchovávania. Stavové funkcie, súbory, uzemnenie, dávkové spracovanie a režim protokolovania ovplyvňujú, či je trasa prijateľná.

Vytvoriť register spôsobilostí poskytovateľa

Register schopností je zdrojom pravdy smerovača. Mala by byť udržiavaná ako riadená konfigurácia, nie rozptýlená cez adaptéry poskytovateľa.

Užitočný záznam obsahuje:

• provider: poskytovateľ alebo cloudová platforma.
• account_scope: organizácia, projekt, nasadenie, predplatné alebo nájomník, kde je schválené nastavenie.
• endpoint: čet, odpovede, správy, dávka, súbory, asistenti, vkladanie, uzemnenie, vektorový obchod alebo iná API plocha.
• model_family a voliteľné model_id: pretože vhodnosť modelu sa môže líšiť.
• region_mode: globálna, regionálna, dátová zóna, geografická oblasť určená zákazníkom alebo ekvivalent špecifický pre poskytovateľa.
• content_retention: žiadne úložisko po odozve, uchovávanie pri monitorovaní zneužitia, uchovávanie stavu aplikácie, odvodené protokoly s pevnou dobou trvania alebo neznáme.
• training_use: v predvolenom nastavení zakázané, prihlásené alebo neznáme.
• human_review: povolené, upravené, zakázané alebo neznáme.
• stateful_storage: či koncový bod alebo funkcia ukladá stav konverzácie, súbory, vektorové údaje, dokončenia alebo dávkové vstupy.
• feature_flags: uzemnenie, súbory, nástroje, vyrovnávacia pamäť, uložené výstupy, dávka, asistenti alebo ekvivalentné funkcie.
• evidence: názov zdrojového dokumentu, adresa URL, dátum načítania a dátum kontroly vlastníka.

Prí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"
  }
}

Odporúčanie je považovať neznáme za odmietnutie pre citlivé pracovné zaťaženie. Ak záznamu schopnosti chýba pole uchovávania, režim regiónu alebo vhodnosť funkcie, nemal by spĺňať prísne pravidlá.

Klasifikácia požiadavky pred smerovaním

Klasifikácia by mala prebehnúť pred výberom modelu. Dobrý klasifikátor kombinuje statické metadáta a kontrolu požiadaviek:

• API kľúčový rozsah: nájomník, tím, prostredie, aplikácia a typ pracovného zaťaženia.
• Značky zmluvy: bez uchovávania, len pre EÚ, kontroly podobné HIPAA, finančné údaje, dôverné informácie o zákazníkovi alebo iba interné.
• Typ užitočného zaťaženia: voľný text, dokument, obrázok, odkaz na súbor, vstup na vkladanie, výsledok nástroja alebo načítaný kontext.
• Použitie funkcií: uzemnenie webu, nahrávanie súborov, ukladanie vektorov, dávková úloha, uložená história konverzácií, volania nástrojov alebo ukladanie odpovedí.
• Režim protokolovania: povolený úplný obsah, povolený redigovaný obsah, iba metadáta alebo žiadny obsah protokolu aplikácie.
• Regionálne rady: umiestnenie používateľa, umiestnenie údajov nájomníka, región projektu alebo región nasadenia.

Nespoliehajte sa len na automatické zisťovanie citlivých údajov. Použite deklarovanú politiku pracovného zaťaženia z kľúča API alebo projektu ako primárny zdroj a potom použite klasifikátory na sprísnenie pravidiel, keď užitočné zaťaženie 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 kľúč zákazníckej podpory môže byť predvolene neuchovaný, zatiaľ čo interný experimentálny kľúč môže umožniť širšie smerovanie. Ak sa rovnaký kľúč podpory pokúsi o nahranie súboru, účinná zásada by mala zahŕňať file_storage_allowed=false, pokiaľ neexistuje schválená trasa podporujúca súbory.

Vyhodnoťte pravidlá pred smerovaním nákladov alebo latencie

Hodnotiteľ by mal fungovať ako filter. Prijíma politiku, funkcie požiadaviek a trasy kandidátov na poskytovateľa. Vracia iba trasy, ktoré spĺňajú pravidlá.

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 poradí záleží. Záložné smerovanie by počas výpadku nemalo preskočiť na nevhodného poskytovateľa. Dávkové smerovanie by nemalo presunúť požiadavku bez uchovávania do skladu asynchrónnych úloh. Uzemnenie by nemalo zapínať funkciu, ktorá zavádza odvodené protokoly, keď to pravidlá zakazujú.

Ak vaša platforma odhaľuje OpenAIkompatibilný multimodel API, ponechajte vrstvu kompatibility čestnú: rovnaké telo žiadosti sa môže kompilovať pre rôzne funkcie natívneho poskytovateľa. Hodnotiteľ pravidiel musí skontrolovať skompilovanú žiadosť, nielen pôvodný tvar SDK.

Výslovné blokovanie rizikových kombinácií funkcií

Najbezpečnejšou implementáciou je vytvorenie explicitných pravidiel odmietnutia pre známe vysoko rizikové kombinácie. Príklady:

• NO_RETENTION + FILE_UPLOAD: zamietnuť, pokiaľ nie je pre dané pravidlo schválený konkrétny koncový bod súboru a nastavenie účtu.
• NO_RETENTION + VECTOR_STORE: zamietnuť, pokiaľ sa vektorový ukladací priestor nenachádza vo vašom vlastnom kontrolovanom úložisku a poskytovateľ nikdy nedostane trvalý stav súboru.
• NO_RETENTION + STORED_RESPONSE: vynútiť vypnutie alebo odmietnutie príznakov úložiska odpovede, ak koncový bod nemôže zakázať úložisko.
• EU_ONLY + GLOBAL_DEPLOYMENT: zamietnuť, ak k spracovaniu môže dôjsť mimo povolenej oblasti alebo dátovej zóny.
• NO_RETENTION + WEB_GROUNDING: zamietnuť, ak funkcia uzemnenia ukladá odvodené protokoly dopytov alebo kontextu nad rámec pravidiel.
• METADATA_ONLY_LOGGING + DEBUG_TRACE: potlačenie obsahu výziev a dokončení z denníkov a sledovania aplikácie.
• ZDR_REQUIRED + STATEFUL_ASSISTANT_THREAD: zamietnuť, pokiaľ funkcia nie je špecificky vhodná podľa schválených ovládacích prvkov účtu.

Vrátiť konkrétne chyby. Užitočné odmietnutie povie vývojárovi, čo zlyhalo a ktoré schválené alternatívy existujú.

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

Oddelené protokolovanie inferencie od prevádzkovej telemetrie

Zásady uchovávania by nemali nútiť bránu, aby oslepla. Zvyčajne môžete zachovať prevádzkovú telemetriu bez uloženia obsahu výzvy alebo dokončenia.

Pre prísne pracovné zaťaženie zachovajte:

• ID žiadosti a ID sledovania;
• nájomca, projekt, API kľúč a identifikátory pracovného zaťaženia;
• ID pravidiel a verzia pravidiel;
• použitý poskytovateľ, koncový bod, model, nasadenie a región;
• požadované a povolené príznaky funkcie;
• kódy príčiny rozhodnutia;
• počet tokenov, latencia, stavový kód a metadáta nákladov;
• haše alebo stabilné odtlačky prstov na deduplikáciu, ak sú schválené pravidlami.

Potlačiť alebo revidovať:

• surové výzvy;
• surové dokončenia;
• obsah odovzdaného súboru;
• výstupy nástrojov, ktoré obsahujú údaje o zákazníkoch;
• získaný kontext z citlivých systémov;
• poskytovateľ ladí obsah, ktorý duplikuje obsah.

Toto je miesto, kde sa smerovanie uchovávania pripája k pozorovateľnosti LLM neutrálnej voči poskytovateľovi. Pozorovateľnosť by mala dokázať, čo sa stalo, bez rozšírenia množiny systémov, ktoré uchovávajú citlivý obsah.

Vydať audítorské dôkazy pre každé rozhodnutie

Audítorský záznam by mal vysvetliť, prečo bola trasa povolená alebo zamietnutá. Na to, aby bola užitočná, nepotrebuje úplný obsah.

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

V prípade zamietnutých žiadostí ponechajte rovnakú štruktúru ako decision=deny a kódy príčiny, ako napríklad REGION_NOT_ALLOWED, GROUNDING_RETENTION_EXCEEDS_POLICY alebo STATEFUL_STORAGE_NOT_ALLOWED.

Na pravidlá uchovávania použite testy zmluvy

Smerovanie uchovávania by malo mať automatické testy. Dôležité testy nie sú len jednotkové testy pre jednotlivých poskytovateľov; sú to zmluvné testy správania pravidiel pre kombinácie poskytovateľov.

Testovacie prípady s vysokou hodnotou zahŕňajú:

• Pravidlá neuchovávania a nahrávanie súborov by malo byť odmietnuté, pokiaľ neexistuje špecifická schválená cesta pre súbory.
• Pravidlá platné len pre EÚ a globálne nasadenie by mali byť odmietnuté, aj keď je model inak dostupný.
• Pravidlá nulového uchovávania plus uložená história konverzácií by mali zakázať alebo vynútiť vypnutie úložiska, ak je podporované.
• Funkcia uzemnenia s uchovávaním odvodených protokolov by mala byť odmietnutá v rámci zásady neuchovávania.
• Zásady protokolovania iba pre metaúdaje by mali potláčať obsah riadku a dokončenia zo sledovania, denníkov a chybových hlásení.
• Záznam spôsobilosti poskytovateľa s neznámym uchovávaním by mal byť odmietnutý pre regulované pracovné zaťaženie.
• Záložná funkcia po výpadku poskytovateľa by mala zostať v rámci vhodnej nastavenej trasy.
• Dávkové spracovanie by malo byť odmietnuté, keď dávkový koncový bod ukladá vstupné súbory dlhšie, než povoľuje politika.

Tiež skúšobný posun. Keď sa záznam o spôsobilosti zmení, systém by mal ukázať, ktoré pravidlá a cesty sú ovplyvnené, kým sa zmena dostane do produkcie.

Prevádzkové vlastníctvo

Ťažká časť nie je napísať prvého hodnotiteľa. Udržuje register aktuálny a zabraňuje nezdokumentovaným výnimkám.

Priradiť vlastníkov pre:

• kadencia kontroly dokumentácie poskytovateľa;
• stav schválenia pre ovládacie prvky na úrovni účtu, ako je upravené monitorovanie zneužívania alebo nulové uchovávanie údajov;
• inventár regionálneho nasadenia;
• vhodnosť funkcií pre súbory, vektorové úložiská, uzemnenie, dávkové a uložené odpovede;
• pracovný postup výnimky z pravidiel;
• uchovávanie záznamov o audite a riadenie prístupu;
• chybové správy pre vývojárov a schválené alternatívy.

Každý záznam spôsobilosti by mal mať dátum kontroly. Ak jej platnosť vyprší, prísne pravidlá by jej mali prestať dôverovať alebo by si mali vyžadovať manuálne schválenie. Správanie dokumentov a funkcií poskytovateľa sa príliš často mení na to, aby išlo o statickú konfiguráciu.

Východy

Prísny smerovač uchovávania redukuje dostupné možnosti modelov. Niektoré ukážkové modely, stavové rozhrania API, uzemňovacie nástroje a pracovné toky súborov nebudú pre citlivé pracovné zaťaženia k dispozícii. To je podstata kontroly, ale produktové tímy potrebujú jasné alternatívy.

Regionálne smerovanie môže zvýšiť latenciu alebo náklady, keď je najrýchlejšie nasadenie globálne, ale pracovné zaťaženie vyžaduje špecifickú geografickú oblasť alebo dátovú zónu. Zviditeľnite to v telemetrii, aby tímy pochopili, prečo žiadosť použila drahšiu alebo pomalšiu trasu.

Blokovanie stavových funkcií môže prinútiť tímy vybudovať si vlastnú pamäťovú vrstvu. To môže byť správna architektúra, ale stále potrebuje politiku ukladania, pracovné postupy odstraňovania, šifrovanie, riadenie prístupu a protokoly auditu. Presunutím stavu mimo poskytovateľa sa neodstráni práca na správe.

Výzva a úprava dokončenia chráni citlivé údaje, ale oslabuje ladenie a kontrolu kvality. Používajte reprodukovateľné metadáta požiadaviek, deterministické testovacie prípravky, kontrolované vzorkovanie pre povolené pracovné zaťaženia a zdokumentovaný prístup k rozbitiu skla tam, kde to pravidlá povoľujú.

Odporúčania

• Vynútiť uchovanie a pobyt pred smerovaním modelu, nie ako kontrolu po spracovaní.
• Možnosti modelu na úrovni poskytovateľa, koncového bodu, funkcie, regiónu a schválenia účtu.
• Použite predvolené správanie odmietnutia pre regulované úlohy alebo úlohy viazané na zmluvu zákazníka.
• Nahrávanie súborov, vektorové úložiská, uzemnenie webu, dávkové spracovanie a uložená história konverzácií považujte za samostatné dimenzie pravidiel.
• Zachovať funkčnú telemetriu aj vtedy, keď musí byť potlačený obsah výzvy a dokončenia.
• Vysielajte záznamy auditu, ktoré zahŕňajú pravidlá, trasu, dôkazy o schopnostiach, región, príznaky úložiska a kódy príčin.
• Napíšte zmluvné testy pre vysoko rizikové kombinácie funkcií a záložné správanie.

Predpoveď: Smerovanie uchovávania sa stane štandardnou vrstvou brány

Pravdepodobným smerom je, že smerovanie uchovávania sa stane štandardnou vrstvou v podnikových platformách LLM, podobne ako limity sadzieb, rozpočtové kontroly a pozorovateľnosť. Keďže poskytovatelia pridávajú viac stavových nástrojov, možností uzemnenia, vyrovnávacích pamätí, súborov, agentov a funkcií spravovanej pamäte, bezpečná cesta bude menej závisieť od názvu modelu a viac od úplnej cesty spustenia.

To je predpoveď, nie súčasná univerzálna požiadavka. Súčasná požiadavka je jednoduchšia: ak váš tím nesľubuje žiadne uchovávanie údajov, regionálne spracovanie, žiadne školenie alebo kontrolu človekom, vaša brána potrebuje dostatok logiky politiky a dôkazov, aby dokázala, že každá žiadosť spĺňala tieto obmedzenia.

Uplatniteľný záver

Postavte smerovač uchovávania údajov ako bránu pravidiel pred výberom poskytovateľa. Definujte kanonickú politiku uchovávania, klasifikujte každú požiadavku pred smerovaním, udržiavajte dátumovaný register schopností poskytovateľa, štandardne odmietnite nebezpečné kombinácie a zaznamenávajte dôkazy auditu bez uchovávania citlivého obsahu.

Cieľom dizajnu nie je nájsť poskytovateľa, ktorý je vždy bezpečný. Cieľom je dokázať, že konkrétna žiadosť s použitím konkrétneho koncového bodu a sady funkcií v rámci konkrétneho účtu a regiónu spĺňala pravidlá pred odoslaním.

Súvisiace čítanie

• návrh pozorovateľnosti LLM neutrálny voči poskytovateľovi