Kako zgraditi usmerjevalnik pravilnika o hrambi podatkov za API-je LLM za več ponudnikov

Usmerjevalnik LLM z več ponudniki ne bi smel najprej izbrati modela in pozneje postavljati vprašanj o hrambi. Če je delovni tok podpore označen kot brez zadrževanja, mora prehod vedeti, ali lahko izbrani ponudnik, končna točka, regija, nastavitev računa in kombinacija funkcij spoštujejo to obljubo, preden zahteva zapusti vašo mejo.

Način napake je enostavno spregledati. Ekipa začne z zaključkom klepeta brez stanja. Pot je sprejemljiva. Pozneje nekdo doda nalaganje datotek, shranjeno zgodovino pogovorov, spletno ozemljitev, paketno obdelavo ali vektorsko shrambo. Ime modela lahko ostane enako, spremeni pa se vedenje podatkov. Preprost usmerjevalnik z zakasnitvami ali stroški lahko tiho pošlje predpisane pozive ali pozive, vezane na stranko, na pot, ki shranjuje vsebino dlje, kot dovoljuje delovna obremenitev.

Praktični popravek je, da se kontrolniki hrambe podatkov LLM postavijo pred usmerjanje modela. Usmerjevalnik mora razvrstiti zahtevo, jo primerjati s kanoničnim pravilnikom o hrambi, filtrirati zmožnosti ponudnika, blokirati nedovoljene funkcije in izdati revizijske dokaze za odločitev.

Dejstva, ki jih je treba obravnavati kot oblikovne omejitve

Ravnanje s podatki ponudnika ni enotno in le redko jih zajame samo ime ponudnika. Naslednja dejstva so pomembna pri načrtovanju usmerjevalnika, ki podpira zadrževanje:

• OpenAI navaja, da se API podatki ne uporabljajo za usposabljanje ali izboljšanje modelov, razen če se stranka odloči za to. Upravičene stranke lahko po odobritvi konfigurirajo spremljanje spremenjenih zlorab ali ničelno hrambo podatkov na ravni organizacije ali projekta.
• OpenAI's Zero Data Retention spremeni vedenje končne točke, vključno z obravnavanjem parametra store za odgovore in zaključke klepeta kot napačnega, vendar lahko nekatere končne točke in zmogljivosti še vedno shranjujejo stanje aplikacije in niso primerne za Zero Data Retention.
• Anthropic dokumentira Zero Data Retention za Claude API, saj ne shranjuje pozivov strank ali odgovorov v mirovanju po vrnjenem odgovoru API, vendar je pokritost odvisna od končne točke in primernosti funkcij.
• Anthropic navaja, da nekatere Claude funkcije ali zajeti modeli morda zahtevajo hrambo in morda niso na voljo v okviru ničelne hrambe podatkov, razen če so posebej pooblaščeni.
• Google Oblak dokumentira, da se Gemini podatki Enterprise Agent Platform ne uporabljajo za usposabljanje ali natančno prilagajanje modelov AI/ML brez predhodnega dovoljenja ali navodil, vendar ničelna hramba podatkov zahteva posebna dejanja in morda ne bo mogoča za nekatere napredne funkcije.
• Google Dokumenti v oblaku, ki jih Grounding with Google Search shranjuje izpeljane dnevnike poizvedb in konteksta do tri dni in ne more onemogočiti tega shranjevanja za to funkcijo. Priporoča spletno ozemljitev za podjetja, kadar ni potrebno hrambe podatkov.
• Microsoft dokumentira, da modeli, ki jih gosti Azure in jih prodaja Azure, ne dajejo pozivov in dokončanj OpenAI ali drugim ponudnikom modelov in jih ne uporabljajo za usposabljanje temeljnih modelov brez dovoljenja ali navodil.
• Microsoft dokumentira, da vrsta uvedbe Azure vpliva na lokacijo obdelave. Globalne uvedbe lahko obdelujejo pozive in odgovore v kateri koli geografski regiji, kjer je uveden model, medtem ko uvedbe DataZone omejijo obdelavo na izbrano območje. Shranjeni podatki ostanejo v geografskem območju, ki ga določi stranka.
• Microsoft dokumentira, da nekatere funkcije Azure z zaznavanjem stanja shranjujejo podatke, vključno z datotekami, vektorskimi shrambami, zgodovino sporočil odzivov, nitmi pomočnikov, vnosi paketne obdelave in shranjenimi dokončanji.
• Microsoftovi dokumenti, ki so strankam odobrili spreminjanje spremljanja zlorab in da lahko portal Azure ali CLI prikaže ContentLogging=false, ko je shranjevanje podatkov za spremljanje zlorab izklopljeno.

To niso podrobnosti robov. Pomenijo, da mora usmerjevalnik skupaj oceniti končno točko, funkcijo, odobritev računa in regijo. Oznaka za vse ponudnike, kot je »ZDR omogočeno«, je pregroba za produkcijsko politiko.

Referenčna arhitektura

Prehod umetne inteligence z več modeli API, ki upošteva zadrževanje, potrebuje pet komponent na poti zahteve:

1. Razvrstilnik zahtev: izvleče občutljivost podatkov, najemniško pogodbo, regionalne zahteve, uporabo funkcij, vnose datotek, uporabo orodja in dovoljenja za beleženje.
2. Reševalec pravilnika: preslika zahtevo v kanonični pravilnik o hrambi, običajno iz najemnika, projekta, okolja, API ključa in metapodatkov delovne obremenitve.
3. Register zmogljivosti ponudnika: beleži ponudnika, končno točko, model, funkcijo, regijo in zmogljivosti hrambe na ravni računa z datiranimi dokazi.
4. Ocenjevalec pravilnika: filtrira kandidatne poti in vrne odobreno pot ali zavrnitev pravilnika s kodo vzroka.
5. Oddajnik revizije: zabeleži izbrano pot, ujemajočo se politiko, predpostavke zmogljivosti, regijo, zastavice za shranjevanje in način beleženja vsebine.

Ta arhitektura ohranja odločitve o hrambi in rezidentstvu ločene od stroškov, zakasnitve in nadomestne možnosti. Usmerjanje stroškov se lahko še vedno izvaja, vendar le znotraj nabora poti, ki izpolnjujejo pravilnik o hrambi.

Določite kanonično politiko hrambe

Začnite s predmetom pravilnika, nevtralnega glede ponudnika. Ne kopirajte terminologije enega ponudnika v interno pogodbo. Vaša notranja politika bi morala opisovati, kaj sme delati obremenitev, ne pa, kako določen ponudnik trži nadzor.

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

Za manj omejene delovne obremenitve uporabite eksplicitno sprostitev namesto manjkajočih polj:

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

Pomembna polja niso le trajanje hrambe. Funkcije za spremljanje stanja, datoteke, ozemljitev, paketna obdelava in način beleženja vplivajo na to, ali je pot sprejemljiva.

Izdelava registra zmogljivosti ponudnika

Register zmogljivosti je vir resnice za usmerjevalnik. Ohranjati ga je treba kot nadzorovano konfiguracijo, ne pa raztreseno po adapterjih ponudnika.

Uporaben zapis vključuje:

• provider: ponudnik ali platforma v oblaku.
• account_scope: organizacija, projekt, uvedba, naročnina ali najemnik, kjer je nastavitev odobrena.
• endpoint: klepet, odgovori, sporočila, paket, datoteke, pomočniki, vdelave, ozemljitev, vektorska shramba ali druga API površina.
• model_family in neobvezno model_id: ker se primernost modela lahko razlikuje.
• region_mode: globalno, regionalno, podatkovno območje, geografija, ki jo določi stranka, ali enakovredno, specifično za ponudnika.
• content_retention: brez shranjevanja po odgovoru, hramba nadzora zlorabe, hramba stanja aplikacije, izpeljani dnevniki za določen čas ali neznano.
• training_use: privzeto onemogočeno, dovoljeno ali neznano.
• human_review: omogočeno, spremenjeno, onemogočeno ali neznano.
• stateful_storage: ali končna točka ali funkcija shranjuje stanje pogovora, datoteke, vektorske podatke, zaključke ali paketne vnose.
• feature_flags: ozemljitev, datoteke, orodja, predpomnilnik, shranjeni izhodi, serija, pomočniki ali enakovredne zmogljivosti.
• evidence: ime izvornega dokumenta, URL, datum pridobitve in datum pregleda lastnika.

Primer:

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

Priporočilo je, da neznano obravnavate kot zavrnitev za občutljive delovne obremenitve. Če zapis zmogljivosti nima polja za hrambo, načina regije ali primernosti funkcij, ne bi smel biti v skladu s strogimi pravilniki.

Razvrstite zahtevo pred usmerjanjem

Razvrstitev je treba izvesti pred izbiro modela. Dober klasifikator združuje statične metapodatke in zahtevo za pregled:

• API ključni obseg: najemnik, ekipa, okolje, aplikacija in vrsta delovne obremenitve.
• Pogodbene oznake: brez hrambe, samo za EU, kontrole, podobne HIPAA, finančni podatki, zaupno za stranke ali samo interno.
• Vrsta koristnega tovora: prosto besedilo, dokument, slika, sklic na datoteko, vdelani vnos, rezultat orodja ali pridobljeni kontekst.
• Uporaba funkcij: spletno ozemljitev, nalaganje datotek, shranjevanje vektorjev, paketno opravilo, shranjena zgodovina pogovorov, klici orodij ali shranjevanje odgovorov.
• Način beleženja: dovoljena je celotna vsebina, dovoljena urejena vsebina, samo metapodatki ali brez vsebine dnevnika aplikacije.
• Regionalni namigi: lokacija uporabnika, prebivališče podatkov najemnika, regija projekta ali regija uvedbe.

Ne zanašajte se le na samodejno zaznavanje občutljivih podatkov. Uporabite deklarirano politiko delovne obremenitve iz ključa API ali projekta kot primarni vir, nato uporabite klasifikatorje za poostritev politike, ko koristna obremenitev vsebuje signale tveganja.

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 praksi to pomeni, da lahko ključ za podporo strankam privzeto nastavi brez hrambe, medtem ko lahko interni eksperimentalni ključ omogoči širše usmerjanje. Če isti podporni ključ poskuša naložiti datoteko, mora veljavni pravilnik vključevati file_storage_allowed=false, razen če obstaja odobrena pot, ki podpira datoteko.

Ocenite pravilnik pred usmerjanjem stroškov ali zakasnitve

Ocenjevalec bi moral delovati kot filter. Prejme pravilnik, funkcije zahtev in poti kandidatov za ponudnike. Vrne samo poti, ki izpolnjujejo pravilnik.

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

Ta vrstni red je pomemben. Nadomestno usmerjanje med izpadom ne sme preskočiti na neupravičenega ponudnika. Paketno usmerjanje ne sme premakniti zahteve brez hrambe v asinhrono shrambo opravil. Ozemljitev ne bi smela vklopiti funkcije, ki uvaja izpeljane dnevnike, če pravilnik to prepoveduje.

Če vaša platforma razkriva OpenAI-združljiv večmodel API, naj bo združljivostna plast poštena: isto telo zahteve se lahko prevede v različne izvorne funkcije ponudnika. Ocenjevalec pravilnika mora pregledati sestavljeno zahtevo, ne samo izvirne SDK oblike.

Izrecno blokiraj tvegane kombinacije funkcij

Najvarnejša izvedba je ustvariti izrecna pravila zavrnitve za znane kombinacije z visokim tveganjem. Primeri:

• NO_RETENTION + FILE_UPLOAD: zavrni, razen če sta določena končna točka datoteke in nastavitev računa odobreni za pravilnik.
• NO_RETENTION + VECTOR_STORE: zavrni, razen če je vektorska shramba znotraj vašega nadzorovanega pomnilnika in ponudnik nikoli ne prejme trajnega stanja datoteke.
• NO_RETENTION + STORED_RESPONSE: vsili odziv na shranjevanje zastavic ali zavrni, če končna točka ne more onemogočiti shranjevanja.
• EU_ONLY + GLOBAL_DEPLOYMENT: zavrni, če lahko pride do obdelave zunaj dovoljene regije ali podatkovnega območja.
• NO_RETENTION + WEB_GROUNDING: zavrni, če funkcija ozemljitve shranjuje izpeljane dnevnike poizvedb ali konteksta zunaj pravilnika.
• METADATA_ONLY_LOGGING + DEBUG_TRACE: onemogočite vsebino poziva in dokončanja iz dnevnikov in sledi aplikacije.
• ZDR_REQUIRED + STATEFUL_ASSISTANT_THREAD: zavrni, razen če je funkcija izrecno upravičena v okviru odobrenih kontrol računa.

Vrni določene napake. Uporabna zavrnitev pove razvijalcu, kaj ni uspelo in katere odobrene alternative obstajajo.

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

Ločeno beleženje sklepanja od operativne telemetrije

Politika zadrževanja ne sme prisiliti prehoda, da postane slep. Običajno lahko ohranite delujočo telemetrijo brez shranjevanja vsebine poziva ali dokončanja.

Za stroge delovne obremenitve ohranite:

• ID zahteve in ID sledenja;
• najemnik, projekt, API ključ in identifikatorji delovne obremenitve;
• ID pravilnika in različica pravilnika;
• ponudnik, končna točka, model, uvedba in uporabljena regija;
• oznake funkcij zahtevane in dovoljene;
• kode razlogov za odločitev;
• število žetonov, zakasnitev, koda stanja in metapodatki o stroških;
• zgoščene vrednosti ali stabilne prstne odtise za odstranjevanje podvojitev, če to dovoljuje pravilnik.

Izbriši ali popravi:

• neobdelani pozivi;
• neobdelana dokončanja;
• vsebina naložene datoteke;
• izhodi orodij, ki vsebujejo podatke o strankah;
• pridobljen kontekst iz občutljivih sistemov;
• koristne obremenitve ponudnika za odpravljanje napak, ki podvajajo vsebino.

Tukaj se usmerjanje zadrževanja poveže z nevtralno opazovanjem LLM-ja ponudnika. Opazljivost bi morala dokazati, kaj se je zgodilo, ne da bi razširili nabor sistemov, ki hranijo občutljivo vsebino.

Pošiljanje revizijskih dokazov za vsako odločitev

Revizijski zapis mora razložiti, zakaj je bila pot dovoljena ali zavrnjena. Za uporabnost ne potrebuje celotne vsebine.

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

Za zavrnjene zahteve ohranite isto strukturo z decision=deny in kodami vzrokov, kot so REGION_NOT_ALLOWED, GROUNDING_RETENTION_EXCEEDS_POLICY ali STATEFUL_STORAGE_NOT_ALLOWED.

Uporaba preizkusov pogodbe za pravila hrambe

Usmerjanje zadrževanja mora imeti avtomatizirane teste. Pomembni testi niso samo testi enot za posamezne ponudnike; so pogodbeni testi za vedenje pravilnika med kombinacijami ponudnikov.

Preskusni primeri visoke vrednosti vključujejo:

• Politika prepovedi hrambe in nalaganje datotek bi morala zavrniti, razen če obstaja posebna odobrena pot, ki podpira datoteke.
• Politika samo za EU in globalna uvedba bi morala zavrniti, tudi če je model drugače na voljo.
• Pravilnik ničelne hrambe in shranjena zgodovina pogovorov bi moral zavrniti ali prisilno izklopiti shranjevanje, če je podprt.
• Funkcija ozemljitve z hrambo izpeljanega dnevnika bi morala biti zavrnjena v skladu s pravilnikom o prepovedi hrambe.
• Politika beleženja samo metapodatkov bi morala preprečiti vsebino poziva in dokončanja iz sledenj, dnevnikov in poročil o napakah.
• Zapis zmogljivosti ponudnika z neznano hrambo bi moral zavrniti za regulirane delovne obremenitve.
• Nadomestna možnost po izpadu ponudnika mora ostati znotraj ustreznega nabora poti.
• Paketna obdelava bi morala zavrniti, ko končna točka paketa shranjuje vhodne datoteke dlje, kot dovoljuje pravilnik.

Preizkusite tudi drsenje. Ko se zapis zmogljivosti spremeni, mora sistem pokazati, na katere politike in poti to vpliva, preden sprememba doseže proizvodnjo.

Operativno lastništvo

Težji del je, da ne napišete prvega ocenjevalca. Ohranja posodobljen register in preprečuje nedokumentirane izjeme.

Dodelitev lastnikov za:

• kadenca pregleda dokumentacije ponudnika;
• stanje odobritve za kontrole na ravni računa, kot je spremenjeno spremljanje zlorab ali ničelna hramba podatkov;
• inventar regionalne uvedbe;
• primernost do funkcij za datoteke, vektorske shrambe, ozemljitev, pakete in shranjene odgovore;
• potek dela izjem pravilnika;
• zadrževanje revizijskih zapisov in nadzor dostopa;
• sporočila o napakah za razvijalce in odobrene alternative.

Vsak zapis o zmogljivosti mora imeti datum pregleda. Če poteče, bi mu morali strogi pravilniki prenehati zaupati ali zahtevati ročno odobritev. Dokumenti ponudnika in vedenje funkcij se prepogosto spreminjajo, da bi bila to statična konfiguracija.

Kompromisi

Usmerjevalnik s strogim zadrževanjem zmanjša razpoložljive izbire modelov. Nekateri modeli predogleda, API-ji s stanjem, orodja za ozemljitev in delovni tokovi datotek ne bodo na voljo za občutljive delovne obremenitve. To je bistvo nadzora, vendar produktne ekipe potrebujejo jasne alternative.

Regionalno usmerjanje lahko poveča zakasnitev ali stroške, ko je najhitrejša uvedba globalna, vendar delovna obremenitev zahteva določeno geografsko ali podatkovno območje. Naj bo to vidno v telemetriji, da bodo ekipe razumele, zakaj je zahteva uporabila dražjo ali počasnejšo pot.

Blokiranje funkcij za ohranjanje stanja lahko spodbudi ekipe, da zgradijo lastno pomnilniško plast. To je morda prava arhitektura, vendar še vedno potrebuje politiko shranjevanja, poteke dela za brisanje, šifriranje, nadzor dostopa in revizijske dnevnike. Premik stanja izven ponudnika ne odstrani dela upravljanja.

Redakcija ob pozivu in dokončanju ščiti občutljive podatke, vendar oslabi odpravljanje napak in pregled kakovosti. Uporabite ponovljive metapodatke o zahtevah, deterministične preskusne napeljave, nadzorovano vzorčenje za dovoljene delovne obremenitve in dokumentiran dostop do razbitega stekla, kjer pravilnik to dovoljuje.

Priporočila

• Uveljavi zadrževanje in rezidenčnost pred usmerjanjem modela, ne kot preverjanje po obdelavi.
• Zmogljivosti modela na ravni ponudnika, končne točke, funkcije, regije in odobritve računa.
• Uporabite vedenje zavrnitve po privzetku za regulirane delovne obremenitve ali delovne obremenitve, vezane na pogodbe.
• Nalaganje datotek, vektorske shrambe, spletno ozemljitev, paketno obdelavo in shranjeno zgodovino pogovorov obravnavajte kot ločene dimenzije pravilnika.
• Ohranite delujočo telemetrijo, tudi če je treba zavrniti vsebino poziva in dokončanja.
• Oddajanje revizijskih zapisov, ki vključujejo pravilnik, pot, dokaze o zmogljivosti, regijo, zastavice za shranjevanje in kode vzrokov.
• Napišite pogodbene preizkuse za kombinacije funkcij z visokim tveganjem in nadomestno vedenje.

Napoved: Usmerjanje zadrževanja bo postalo standardna plast prehoda

Verjetna smer je, da usmerjanje zadrževanja postane standardna plast v podjetniških platformah LLM, podobno kot omejitve stopnje, nadzor proračuna in opazovanje. Ker ponudniki dodajo več orodij za spremljanje stanja, možnosti ozemljitve, predpomnilnike, datoteke, agente in funkcije upravljanega pomnilnika, bo varna pot manj odvisna od imena modela in bolj od celotne izvedbene poti.

To je napoved, ne trenutna univerzalna zahteva. Trenutna zahteva je enostavnejša: če vaša ekipa ne obljublja zadrževanja, regionalne obdelave, uporabe usposabljanja ali človeškega pregleda, vaš prehod potrebuje dovolj logike pravilnika in dokazov, da dokaže, da je vsaka zahteva sledila tem omejitvam.

Uporabni sklep

Izdelajte zadrževalni usmerjevalnik kot vrata pravilnika pred izbiro ponudnika. Določite kanonično politiko hrambe, razvrstite vsako zahtevo pred usmerjanjem, vzdržujte datumski register zmogljivosti ponudnika, privzeto zavrnite nevarne kombinacije in beležite revizijske dokaze, ne da bi obdržali občutljivo vsebino.

Cilj oblikovanja ni najti ponudnika, ki je vedno varen. Cilj je dokazati, da je določena zahteva z uporabo določene končne točke in nabora funkcij, pod določenim računom in regijo, izpolnjevala pravilnik, preden je bila poslana.

Sorodno branje

• provider-neutral LLM observability design