Adatmegőrzési irányelv-útválasztó készítése többszolgáltatós LLM API-khoz

A több szolgáltatót használó LLM-router ne válassza ki először a modellt, és ne tegyen fel megőrzési kérdéseket később. Ha egy támogatási munkafolyamat megtartás nélküliként van megjelölve, az átjárónak tudnia kell, hogy a kiválasztott szolgáltató, végpont, régió, fiókbeállítás és szolgáltatáskombináció betartja-e ezt az ígéretet, mielőtt a kérés elhagyná a határait.

A hibamódot könnyű kihagyni. Egy csapat hontalan csevegés befejezésével kezdi. Az útvonal elfogadható. Később valaki fájlfeltöltést, tárolt beszélgetési előzményeket, webes földelést, kötegelt feldolgozást vagy vektortárolót ad hozzá. A modell neve változatlan maradhat, de az adatok viselkedése megváltozik. Egy egyszerű késleltetési vagy költségútválasztó csendben képes szabályozott vagy ügyfél-szerződéshez kötött felszólításokat küldeni egy olyan útvonalra, amely a munkaterhelésnél tovább tárolja a tartalmat.

A gyakorlati megoldás az, hogy az LLM-adatmegőrzési vezérlőket a modell útválasztása elé helyezzük. Az útválasztónak osztályoznia kell a kérelmet, össze kell hangolnia a kanonikus megőrzési szabályzattal, ki kell szűrnie a szolgáltatói képességeket, blokkolnia kell a nem engedélyezett funkciókat, és auditálható bizonyítékot kell kibocsátania a döntéshez.

Tények, amelyeket tervezési kényszerként kell kezelni

A szolgáltatói adatkezelés nem egységes, és csak ritkán rögzíti a szolgáltató neve. A következő tények számítanak egy megőrzés-tudatos útválasztó tervezésekor:

A
• OpenAI kimondja, hogy a API adatokat csak akkor használjuk fel modellek betanítására vagy fejlesztésére, ha az ügyfél beleegyezik. A jogosult ügyfelek a jóváhagyást követően szervezeti vagy projektszinten konfigurálhatják a módosított visszaélés-figyelést vagy a nulla adatmegőrzést.
A
• OpenAI nulla adatmegőrzése megváltoztatja a végpontok viselkedését, beleértve a store paramétert a válaszok és a csevegés befejezése esetén hamisként kezeli, de egyes végpontok és képességek továbbra is tárolhatják az alkalmazás állapotát, és nem jogosultak a nulla adatmegőrzésre.
A
• Anthropic a nulla adatmegőrzést dokumentálja a Claude API számára, mivel a API válasz visszaküldése után nem tárolja az ügyfélkéréseket vagy a nyugalmi válaszokat, de a lefedettség a végponttól és a funkció jogosultságától függ.
A
• Anthropic kimondja, hogy egyes Claude funkciók vagy lefedett modellek megőrzést igényelhetnek, és előfordulhat, hogy a Zero Data Retention alatt nem érhetők el, hacsak nincs külön engedély.
• Google A felhő dokumentálja, hogy Gemini Az Enterprise Agent Platform adatait nem használják az AI/ML-modellek betanítására vagy finomhangolására előzetes engedély vagy utasítás nélkül, de a nulla adatmegőrzés speciális műveleteket igényel, és előfordulhat, hogy egyes speciális funkciók esetében ez nem lehetséges.
• Google A Grounding with Google Search felhőalapú dokumentumok legfeljebb három napig tárolják a származtatott lekérdezéseket és kontextusnaplókat, és nem kapcsolhatják ki a tárolást az adott funkcióhoz. A Web Grounding for Enterprise alkalmazást javasolja, ha nincs szükség adatmegőrzésre.
• A Microsoft dokumentálja, hogy az Azure által értékesített Azure által üzemeltetett modellek nem tesznek elérhetővé OpenAI vagy más modellszolgáltatók számára a promptokat és a kiegészítéseket, és nem használják őket alapmodellek betanítására engedély vagy utasítás nélkül.
• A Microsoft dokumentálja, hogy az Azure-telepítési típus befolyásolja a feldolgozási helyet. A globális üzembe helyezések feldolgozhatják a kéréseket és válaszokat bármely földrajzi területen, ahol a modellt telepítették, míg a DataZone telepítések a kiválasztott zónára korlátozzák a feldolgozást. A tárolt adatok az ügyfél által kijelölt földrajzi területen maradnak.
• A Microsoft dokumentálja, hogy egyes állapotjelző Azure-szolgáltatások adatokat tárolnak, beleértve a fájlokat, vektortárakat, válaszüzenet-előzményeket, Assistant-szálakat, kötegelt feldolgozási bemeneteket és tárolt befejezéseket.
• A Microsoft-dokumentumok arról, hogy a jóváhagyott ügyfelek módosíthatják a visszaélések figyelését, és amelyek az Azure Portalon vagy a CLI ContentLogging=false megjelenítésére képesek, ha a visszaélés-figyelő adattárolás ki van kapcsolva.

Ezek nem élrészletek. Ezek azt jelentik, hogy az útválasztónak együtt kell értékelnie a végpontot, a szolgáltatást, a fiók jóváhagyását és a régiót. A szolgáltatóra kiterjedő címke, például a „ZDR engedélyezve” túl durva a termelési szabályzathoz.

Referenciaarchitektúra

Egy megőrzés-tudatos multi-model AI API gateway öt összetevőt igényel a kérés elérési útjában:

1. Kérésosztályozó: kivonja az adatérzékenységet, a bérlői szerződést, a régiókövetelményeket, a funkcióhasználatot, a fájlbevitelt, az eszközhasználatot és a naplózási engedélyeket.
2. Irányelvfeloldó: a kérelmet egy kanonikus megőrzési szabályzathoz rendeli hozzá, általában a bérlőtől, a projekttől, a környezettől, a API kulcstól és a munkaterhelés metaadataitól.
3. Szolgáltatói képességnyilvántartás: dátummal rögzíti a szolgáltatót, a végpontot, a modellt, a szolgáltatást, a régiót és a fiókszintű megőrzési képességeket.
4. Irányelvértékelő: kiszűri a jelölt útvonalakat, és egy jóváhagyott útvonalat vagy a szabályzat elutasítását adja vissza okkóddal.
5. Audit emitter: rögzíti a kiválasztott útvonalat, az egyező szabályzatot, a képességfeltevéseket, a régiót, a tárolásjelzőket és a tartalomnaplózási módot.

Ez az architektúra elkülöníti a megőrzési és tartózkodási helyekkel kapcsolatos döntéseket a költségektől, a várakozási időtől és a tartaléktól. A költségek átirányítása továbbra is megtörténhet, de csak azon útvonalakon belül, amelyek megfelelnek a megőrzési szabályzatnak.

Kononikus megőrzési irányelv meghatározása

Kezdje egy szolgáltató-semleges házirend-objektummal. Ne másolja be egy szolgáltató terminológiáját a belső szerződésébe. A belső szabályzatnak azt kell leírnia, hogy a munkaterhelés mit végezhet, nem pedig azt, hogy egy adott szolgáltató hogyan értékesíti az ellenőrzést.

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

Kevésbé korlátozott munkaterhelés esetén használjon explicit lazítást a hiányzó mezők helyett:

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

A fontos mezők nem csak a megőrzési időtartam. Az állapotalapú funkciók, a fájlok, a földelés, a kötegelt feldolgozás és a naplózási mód mind befolyásolják, hogy az útvonal elfogadható-e.

A Provider Capability Registry létrehozása

A képesség-nyilvántartás az útválasztó igazságforrása. Ellenőrzött konfigurációként kell karbantartani, nem pedig a szolgáltatói adaptereken keresztül szétszórva.

A hasznos rekord a következőket tartalmazza:

• provider: szolgáltató vagy felhőplatform.
• account_scope: szervezet, projekt, üzembe helyezés, előfizetés vagy bérlő, ahol a beállítást jóváhagyták.
• endpoint: csevegés, válaszok, üzenetek, köteg, fájlok, asszisztensek, beágyazások, földelés, vektortár vagy más API felület.
• model_family és opcionális model_id: mert a modell alkalmassága eltérő lehet.
• region_mode: globális, regionális, adatzóna, ügyfél által kijelölt földrajzi terület vagy szolgáltató-specifikus megfelelője.
• content_retention: nincs tárhely a válasz után, visszaélés-figyelés, alkalmazásállapot megőrzés, rögzített időtartamú származtatott naplók vagy ismeretlen.
• training_use: alapértelmezés szerint letiltva, feliratkozás vagy ismeretlen.
• human_review: engedélyezve, módosítva, letiltva vagy ismeretlen.
• stateful_storage: a végpont vagy a szolgáltatás tárolja-e a beszélgetés állapotát, fájlokat, vektoradatokat, befejezéseket vagy kötegelt bemeneteket.
• feature_flags: földelés, fájlok, eszközök, gyorsítótár, tárolt kimenetek, köteg, asszisztensek vagy ezzel egyenértékű képességek.
• evidence: a forrásdokumentum neve, URL-címe, lekérési dátuma és tulajdonosi ellenőrzés dátuma.

Példa:

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

Az a javaslat, hogy kényes munkaterhelések esetén az ismeretlent elutasítóként kezelje. Ha egy képességrekordból hiányzik a megőrzési mező, a régiómód vagy a funkció jogosultsága, akkor nem felel meg a szigorú irányelveknek.

Osztályozza a kérést az útválasztás előtt

A besorolást a modell kiválasztása előtt kell elvégezni. Egy jó osztályozó egyesíti a statikus metaadatokat és az ellenőrzési kérelmeket:

• API kulcs hatóköre: bérlő, csapat, környezet, alkalmazás és terhelés típusa.
• Szerződéscímkék: nem őrzik meg, csak EU-ban, HIPAA-szerű vezérlők, pénzügyi adatok, bizalmas ügyfelek vagy csak belső.
• Hasznos terhelés típusa: szabad szöveg, dokumentum, kép, fájlhivatkozás, beágyazási bevitel, eszköz eredménye vagy lekért kontextus.
• Funkcióhasználat: webes alapozás, fájlfeltöltés, vektortár, kötegelt munka, tárolt beszélgetési előzmények, eszközhívások vagy választárolás.
• Naplózási mód: teljes tartalom engedélyezett, szerkesztett tartalom engedélyezett, csak metaadatok, vagy nincs alkalmazásnapló-tartalom.
• Regionális tippek: a felhasználó helye, a bérlői adatok tartózkodási helye, a projekt régiója vagy a telepítési régió.

Ne hagyatkozzon csak az érzékeny adatok automatikus észlelésére. Használja a API kulcsból vagy projektből származó deklarált munkaterhelési szabályzatot elsődleges forrásként, majd osztályozók segítségével szigorítsa a szabályzatot, ha a hasznos teher kockázati jeleket tartalmaz.

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

A gyakorlatban ez azt jelenti, hogy az ügyfélszolgálati kulcs alapértelmezés szerint nem őrzi meg, míg a belső kísérleti kulcs szélesebb útválasztást tesz lehetővé. Ha ugyanaz a támogatási kulcs próbál meg fájlt feltölteni, a hatályos szabályzatnak tartalmaznia kell a file_storage_allowed=false számot, hacsak nem létezik jóváhagyott fájlképes útvonal.

Evaluate Policy Before Cost vagy Laency Routing

Az értékelőnek szűrőként kell működnie. Megkapja a szabályzatot, a kérési funkciókat és a jelölt szolgáltatói útvonalakat. Csak azokat az útvonalakat adja vissza, amelyek megfelelnek az irányelvnek.

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

Ez a sorrend számít. A tartalék útválasztás nem ugorhat nem jogosult szolgáltatóhoz kimaradás során. A kötegelt útválasztás nem helyezheti át a megőrzés nélküli kérelmeket egy aszinkron feladattárolóba. A földelés nem kapcsolhat be olyan szolgáltatást, amely származtatott naplókat vezet be, ha a házirend tiltja.

Ha az Ön platformja OpenAI-kompatibilis többmodellel API, tartsa őszintén a kompatibilitási réteget: ugyanaz a kéréstörzs különböző szolgáltatói natív funkciókra fordíthat le. Az irányelv értékelőjének az összeállított kérelmet kell megvizsgálnia, nem csak az eredeti SDK alakzatot.

A kockázatos funkciókombinációk kifejezetten blokkolása

A legbiztonságosabb megvalósítás az, ha explicit elutasítási szabályokat hoz létre az ismert, magas kockázatú kombinációkhoz. Példák:

• NO_RETENTION + FILE_UPLOAD: megtagadás, kivéve, ha az adott fájlvégpont és fiókbeállítás jóváhagyásra került az irányelvhez.
• NO_RETENTION + VECTOR_STORE: megtagadás, kivéve, ha a vektortár az Ön által ellenőrzött tárhelyen belül van, és a szolgáltató soha nem kap állandó fájlállapotot.
• NO_RETENTION + STORED_RESPONSE: kényszerítse ki a válasz tárolási jelzőit, vagy tiltsa le, ha a végpont nem tudja letiltani a tárolást.
• EU_ONLY + GLOBAL_DEPLOYMENT: tiltsa le, ha a feldolgozás az engedélyezett régión vagy adatzónán kívül történhet.
• NO_RETENTION + WEB_GROUNDING: tiltsa le, ha a földelési szolgáltatás a házirenden kívüli származtatott lekérdezési vagy kontextusnaplókat tárol.
• METADATA_ONLY_LOGGING + DEBUG_TRACE: az alkalmazásnaplókból és a nyomkövetésekből a prompt és befejező tartalom letiltása.
• ZDR_REQUIRED + STATEFUL_ASSISTANT_THREAD: elutasítás, kivéve, ha a funkció kifejezetten jogosult a fiók jóváhagyott vezérlői alapján.

Return specific errors. A hasznos elutasítás tájékoztatja a fejlesztőt, hogy mi nem sikerült, és mely jóváhagyott alternatívák léteznek.

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

Következtetési naplózás elkülönítése az operatív telemetriától

A megőrzési szabályzat nem kényszerítheti az átjáró vakítására. Általában megőrizheti működőképes telemetriát anélkül, hogy azonnali vagy befejező tartalmat tárolna.

For strict workloads, preserve:

• request ID and trace ID;
• bérlő, projekt, API kulcs és munkaterhelés azonosítók;
• policy ID and policy version;
• szolgáltató, végpont, modell, üzembe helyezés és használt régió;
• feature flags requested and allowed;
• decision reason codes;
• tokenszámok, várakozási idő, állapotkód és költség-metaadatok;
• kivonatok vagy stabil ujjlenyomatok a duplikáció megszüntetéséhez, ha a szabályzat jóváhagyja.

Suppress or redact:

• raw prompts;
• raw completions;
• uploaded file content;
• ügyféladatokat tartalmazó eszközkimenetek;
• kontextus lekérve érzékeny rendszerekből;
• szolgáltató hibakeresése a tartalmat megkettőző terheléseknél.

Itt csatlakozik a megőrzési útválasztás a szolgáltató-semleges LLM megfigyelhetőséghez. A megfigyelhetőségnek bizonyítania kell a történteket anélkül, hogy bővítené az érzékeny tartalmat megőrző rendszerek körét.

Emit Audit Evidence for Every Decision

Az ellenőrzési rekordnak meg kell magyaráznia, hogy miért engedélyezett vagy megtagadt egy útvonal. 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"
  ]
}

Elutasított kérések esetén tartsa meg ugyanazt a struktúrát a decision=deny és okkódokkal, például REGION_NOT_ALLOWED, GROUNDING_RETENTION_EXCEEDS_POLICY vagy STATEFUL_STORAGE_NOT_ALLOWED.

Use Contract Tests for Retention Rules

A megőrzési útválasztásnak automatizált tesztekkel kell rendelkeznie. A fontos tesztek nem csupán az egyes szolgáltatók egységtesztjei; ezek szerződéses tesztek a szolgáltatói kombinációk közötti szabályzat viselkedésére vonatkozóan.

High-value test cases include:

• A megőrzés tilalmára vonatkozó szabályzat és a fájlfeltöltés meg kell tagadnia, hacsak nem létezik egy adott jóváhagyott fájlképes útvonal.
• Csak az EU-ra vonatkozó irányelveknek és a globális bevezetésnek meg kell tagadnia, még akkor is, ha a modell egyébként elérhető.
• A nulla megőrzési irányelvnek és a tárolt beszélgetési előzményeknek meg kell tagadnia vagy ki kell kapcsolnia a tárolást, ha támogatott.
• A származtatott naplómegőrzéssel rendelkező földelési funkciót meg kell tiltani a megőrzés tilalmára vonatkozó szabályzat értelmében.
• A csak metaadatokra vonatkozó naplózási szabályzatnak el kell tiltania a nyomkövetési és befejezési tartalmat a nyomkövetésekből, naplókból és hibajelentésekből.
• Az ismeretlen megőrzésű szolgáltatói képességrekordot meg kell tagadni szabályozott munkaterhelések esetén.
• A szolgáltató leállása utáni tartaléknak a jogosult útvonalkészleten belül kell maradnia.
• A kötegelt feldolgozást meg kell tiltani, ha a kötegelt végpont a házirendnél hosszabb ideig tárolja a bemeneti fájlokat.

Tesztelje a sodródást is. Ha egy képességrekord módosul, a rendszernek meg kell mutatnia, hogy mely házirendeket és útvonalakat érinti, mielőtt a változtatás elérné a termelést.

Működési tulajdonjog

A nehéz rész nem az első értékelő megírása. Naprakészen tartja a rendszerleíró adatbázist, és megakadályozza a nem dokumentált kivételeket.

Tulajdonosok hozzárendelése a következőhöz:

• szolgáltatói dokumentáció áttekintési üteme;
• jóváhagyási állapot a fiókszintű vezérlőkhöz, például módosított visszaélés-figyelés vagy nulla adatmegőrzés;
• regionális telepítési készlet;
• Fájlokhoz, vektortárolókhoz, földeléshez, kötegelt és tárolt válaszokhoz való jogosultság;
• irányelv-kivétel munkafolyamat;
• audit rekordmegőrzés és hozzáférés-szabályozás;
• fejlesztői hibaüzenetek és jóváhagyott alternatívák.

Minden képességrekordnak rendelkeznie kell felülvizsgálati dátummal. Ha lejár, a szigorú irányelvek nem bíznak benne, vagy manuális jóváhagyást igényelnek. A szolgáltatói dokumentumok és a funkciók viselkedése túl gyakran változik ahhoz, hogy ez statikus konfiguráció legyen.

Trade-offs

A szigorú megőrzést biztosító útválasztó csökkenti a rendelkezésre álló modellek számát. Egyes előnézeti modellek, állapotjelző API-k, földelőeszközök és fájlmunkafolyamatok nem lesznek elérhetők érzékeny munkaterhelések esetén. Ez az ellenőrzés lényege, de a termékcsapatoknak egyértelmű alternatívákra van szükségük.

A regionális útválasztás növelheti a várakozási időt vagy a költségeket, ha a leggyorsabb üzembe helyezés globális, de a munkaterhelés meghatározott földrajzi vagy adatzónát igényel. Tegye ezt láthatóvá a telemetriában, hogy a csapatok megértsék, miért használt egy kérés drágább vagy lassabb útvonalat.

Az állapotjelző funkciók blokkolása arra késztetheti a csapatokat, hogy saját memóriaréteget építsenek fel. Lehet, hogy ez a megfelelő architektúra, de még mindig szüksége van tárolási házirendre, törlési munkafolyamatokra, titkosításra, hozzáférés-vezérlésre és naplózásra. Az állapot áthelyezése a szolgáltatóból nem szünteti meg az irányítási munkát.

Az azonnali és befejező szerkesztés védi a bizalmas adatokat, de gyengíti a hibakeresést és a minőségellenőrzést. Használjon reprodukálható kérés metaadatokat, determinisztikus tesztberendezéseket, ellenőrzött mintavételt a megengedett munkaterhelésekhez, és dokumentált üvegtörési hozzáférést, ahol a szabályzat ezt lehetővé teszi.

Ajánlások

• A megőrzés és a tartózkodási hely érvényesítése a modell útválasztása előtt, nem pedig utófeldolgozási ellenőrzésként.
• Modellképességek szolgáltató, végpont, szolgáltatás, régió és fiók-jóváhagyási szinten.
• Használjon alapértelmezett megtagadást a szabályozott vagy ügyfél-szerződéshez kötött munkaterhelésekhez.
• A fájlfeltöltést, a vektortárakat, a webes alapozást, a kötegelt feldolgozást és a tárolt beszélgetési előzményeket külön irányelvdimenzióként kezelje.
• Megtartja a működőképes telemetriát még akkor is, ha az azonnali és befejező tartalmat el kell tiltani.
• A szabályzatot, az útvonalat, a képességek bizonyítékait, a régiót, a tárolásjelzőket és az okkódokat tartalmazó ellenőrzési rekordok kiadása.
• Írjon szerződéses teszteket a magas kockázatú funkciók kombinációihoz és tartalék viselkedéséhez.

Előrejelzés: A megőrzési útválasztás szabványos átjáróréteggé válik

A valószínű irány az, hogy a megőrzési útválasztás szabványos réteggé válik a vállalati LLM-platformokon, hasonlóan a sebességkorlátokhoz, a költségvetés-szabályozáshoz és a megfigyelhetőséghez. Ahogy a szolgáltatók több állapotjelző eszközt, földelési lehetőséget, gyorsítótárat, fájlt, ügynököt és felügyelt memóriafunkciót adnak hozzá, a biztonságos útvonal kevésbé függ a modell nevétől, és inkább a teljes végrehajtási útvonaltól.

Ez egy előrejelzés, nem pedig egy jelenlegi univerzális követelmény. A jelenlegi követelmény egyszerűbb: ha csapata nem ígér megőrzést, regionális feldolgozást, oktatási felhasználást vagy emberi felülvizsgálatot, akkor az átjárónak elegendő házirend-logikára és bizonyítékra van szüksége annak bizonyítására, hogy minden kérés követte ezeket a megszorításokat.

Cselekvő következtetés

A megőrzési útválasztót házirend-kapuként készítse el a szolgáltató kiválasztása előtt. Határozzon meg egy kanonikus megőrzési szabályzatot, osztályozza az egyes kéréseket az útválasztás előtt, tartson fenn egy dátumozott szolgáltatói képesség-nyilvántartást, alapértelmezés szerint tagadja meg a nem biztonságos kombinációkat, és naplózza a vizsgálati bizonyítékokat az érzékeny tartalom megőrzése nélkül.

A tervezési cél nem az, hogy mindig biztonságos szolgáltatót találjunk. A cél annak bizonyítása, hogy egy adott kérelem egy adott végpontot és szolgáltatáskészletet használva, egy adott fiókban és régióban megfelelt az irányelvnek, mielőtt elküldte volna.

Kapcsolódó olvasmány

• szolgáltató-semleges LLM megfigyelhetőségi tervezés