Adatmegőrzés-tudatos AI API-útválasztás: ZDR, tartózkodási hely és naplózási szabályzatok érvényesítése az átjárón

A biztonsági csapatoknak nem csak azt kell tudniuk, hogy melyik modell a legolcsóbb, leggyorsabb vagy legtökéletesebb. Tudniuk kell, hogy egy adott kérés jogilag és működésileg elküldhető-e egy adott szolgáltatónak, végpontnak, régiónak, szolgáltatásnak és naplózási módnak.

Ez nehezebb, mint amilyennek hangzik. Egy modell elfogadható lehet a szokásos belső csevegéshez, de nem az ügyfél személyazonosításra alkalmas adataihoz. Egy szolgáltató kínálhat nulla adatmegőrzést egy API-útvonalhoz, míg a keresési földelési funkció meghatározott ideig tárolja a promptokat és a kimeneteket. Előfordulhat, hogy egy régió támogatja a tárolási rezidenciát, de nem a várt feldolgozási módot. A fejlesztők tulajdonában lévő naplók konfigurálhatók, míg a szolgáltatói visszaéléseket figyelő naplók eltérő szabályzatot követnek.

A gyakorlati megoldás az, hogy a megőrzési döntéseket ki kell helyezni az egyes alkalmazásokból az AI API átjáróba. Az átjárónak osztályoznia kell a kérelmet, értékelnie kell a szolgáltatói képességmátrix alapján, blokkolnia kell az inkompatibilis funkciókat, csak a jóváhagyott modellprofilokhoz kell irányítania, és rögzítenie kell a házirend-döntést anélkül, hogy alapértelmezés szerint tárolna nyers promptokat.

Az olvasó probléma: a szolgáltató adatvédelmi feltételei nem futásidejű vezérlők

A legtöbb csapat egy táblázattal vagy biztonsági felülvizsgálattal kezdi, amely tartalmazza, hogy mely mesterségesintelligencia-szolgáltatók vannak jóváhagyva. Ez hasznos, de nem elég a termelési útválasztáshoz.

Az alkalmazások futásidejű döntéseket hoznak:

• Melyik modellazonosító kezelje ezt a kérést?
• A kérelemnek keresési földelést, fájlfeltöltést, kódvégrehajtást, kötegelt feldolgozást, gyorsítótárazást vagy tárolt beszélgetéseket kell használnia?
• Melyik régiónak vagy végpontnak kell feldolgoznia a kérést?
• A rendszer naplózhatja a nyers hibakeresési promptot?
• A tartalék útválasztás elküldheti ugyanazt a kérést egy másik szolgáltatónak?

Ezek a lehetőségek mindegyike módosíthatja a megőrzési profilt. Egy egyszerű csevegési módban megfelelő kérés nem megfelelővé válhat, amikor a fejlesztő bekapcsolja a földelést vagy a folyamatos beszélgetések tárolását. A megbízhatóságra tervezett tartalékszabály véletlenül olyan szolgáltatói elérési útra irányíthatja a szabályozott adatokat, amely nincs jóváhagyva a nulla adatmegőrzésre, az adatok tartózkodási helyére vagy a visszaélések felügyeletére.

Javaslat: kezelje a megőrzési viselkedést első osztályú útválasztási megkötésként, ne pedig a szolgáltatói fiókhoz csatolt dokumentációként.

A szabályzat megtervezése előtt kódolandó tények

A pontos feltételek szolgáltatótól, terméktől, szerződéstől, régiótól, végponttól és szolgáltatástól függően változnak. Ne hagyatkozzon a memóriára vagy az egyszeri áttekintésre. Hozzon létre egy forrástulajdonú mátrixot, és frissítse, ha a feltételek megváltoznak.

Számos jelenlegi nyilvános szolgáltatói dokumentum szemlélteti, miért van erre szükség:

• OpenAI: Az API-adatok tartózkodási helye a projekt által konfiguráltként van dokumentálva, a regionális kérésekhez régióspecifikus tartomány-előtagok szükségesek. Az OpenAI ezenkívül megkülönbözteti a tárolási támogatást a régiónkénti feldolgozási támogatástól, és megjegyzi a nem egyesült államokbeli régiókra vonatkozó további követelményeket. Az OpenAI kijelenti, hogy a nem egyesült államokbeli API-adatokhoz való tartózkodáshoz jóváhagyásra van szükség a visszaélés-felügyeleti vezérlőkhöz és a módosított megőrzési módosításhoz.
• Antropikus: Az antropikus dokumentumok nulla adatmegőrzést biztosítanak az API-val kapcsolatos kereskedelmi felhasználási esetekben, miközben megjegyzik, hogy egyes kapcsolódó termékek vagy megfelelőségi hírcsatornák külön megőrzési modellekkel rendelkeznek, beleértve a tevékenységi hírcsatornák és a távoli munkamenetek átiratainak hosszabb megőrzését.
• Google Gemini: A Gemini API feltételei megkülönböztetik a nem fizetett és a fizetős szolgáltatásokat. A nem fizetett szolgáltatások esetében a Google felhasználhatja a beküldött tartalmat és a generált válaszokat a termékek fejlesztésére; a fizetős szolgáltatások esetében a Google szerint a felszólításokat és válaszokat nem használják fel a termékek fejlesztésére. A Gemini Developer API ZDR-dokumentációja szerint a fizetős szolgáltatásokkal kapcsolatos visszaélés-figyelő naplók általában korlátozott ideig őrzik meg az értesítéseket és válaszokat, míg a jóváhagyott ZDR-projektek a naplózás előtt törlik a felhasználói tartalmat és az azonosítható metaadatokat.
• Funkcióspecifikus tárhely: A Gemini dokumentációja szerint a Grounding with Google Search és a Grounding with Google Maps 30 napig tárolja az utasításokat, a kontextusra vonatkozó információkat és a generált kimenetet, anélkül, hogy a tárhelyet letilthatja e funkciók használatakor.
• Fejlesztői tulajdonú naplók: A Gemini API naplózási dokumentációja szerint a fejlesztői tulajdonú API-naplók alapértelmezés szerint akár 55 napig is megőrizhetők a számlázásra alkalmas projekteknél, és a fejlesztők választhatnak rövidebb időtartamot is, például 7, 14 vagy 28 napot.
• Kockázatkezelés: A NIST Generative AI Profile azt javasolja, hogy figyelje a mesterséges intelligencia által generált tartalmat az adatvédelmi kockázatok szempontjából, és kapcsolja össze a generatív mesterséges intelligencia irányelveit a meglévő adatokkal, szoftverekkel, jogi, megfelelőségi és kockázatkezelési folyamatokkal.

Ezeket a tényeket a közzététel előtt ellenőrizni kell a jelenlegi szállítói dokumentációval. Az építészeti lecke stabil: a megtartás nem egy szolgáltatói szintű logikai érték.

Architektúra: átjáróházirend-motor a kérési útvonalon

A megőrzés-tudatos átjáró öt fő összetevőből áll:

1. Érzékenységi osztályozó kérése: az útválasztás előtt felcímkézi a munkaterhelést.
2. Szolgáltatói képességmátrix: leírja a szolgáltatót, a modellt, a végpontot, a régiót, a megőrzést, a naplózást és a funkciók viselkedését.
3. Kódként kódolt szabályzat: a biztonsági követelmények futásidejű engedélyezési, megtagadási vagy felülvizsgálati döntésekké alakítása.
4. Funkciókapu réteg: blokkolja a megőrzést módosító funkciókat, hacsak nincs kifejezetten engedélyezve.
5. Audit és elemzési réteg: hasznos metaadatokat rögzít anélkül, hogy alapértelmezés szerint nyers üzeneteket tárolna.

Az átjárónak nem kell minden jogi árnyalatot megértenie. Végre kell hajtania a jogi, biztonsági, megfelelőségi és platformcsapatai által jóváhagyott döntéseket.

1. lépés: a modell kiválasztása előtt osztályozza a kérésérzékenységet

Kezdje egy kis osztályozási taxonómiával. Elég egyszerűnek kell lennie a fejlesztők számára, de elég kifejezőnek kell lennie ahhoz, hogy vezérelje a szabályzatot.

Példa érzékenységi címkékre:

• nyilvános: nyilvános dokumentáció, marketingpéldány, nyilvános webhelytartalom.
• belső: nem nyilvános, alacsony érzékenységű vállalati információk.
• bizalmas: stratégia, szerződések, ügyfélkörnyezet, kiadatlan termékadatok.
• customer_pii: nevek, e-mail-címek, címek, fiókazonosítók, támogatási átiratok.
• szabályozott: egészségügyi, pénzügyi, jogi, oktatási vagy joghatóság-specifikus védett adatok.
• forráskód: saját kód, konfigurációs, architektúra fájlok.
• hitelesítési adatok: titkok, tokenek, jelszavak, privát kulcsok. A legtöbb rendszerben ezt blokkolni kell, nem átirányítani.

Az osztályozás több forrásból származhat:

• Alkalmazás által biztosított fejléc, például X-Data-Class: customer_pii.
• Bérlői szabályzat, ahol a szabályozott ügyfelektől érkező összes forgalom szabályozottnak minősül, kivéve, ha egy jóváhagyott szabály leminősíti.
• Végpont-szabályzat, ahol a támogatási jegyek összegzése alapértelmezés szerint a customer_pii.
• Könnyű tartalomellenőrzés hitelesítő adatok, nyilvánvaló személyazonosításra alkalmas adatok vagy irányelvsértések keresésére.

Javaslat: ne függjön teljesen az automatikus észleléstől. Követelje meg az alkalmazásoknak, hogy deklarálják a tervezett adatosztályt, majd szkennelést alkalmazzanak a nyilvánvaló eltérések észlelésére vagy egy biztonságosabb osztály kikényszerítésére.

2. lépés: hozzon létre egy szolgáltatói képességmátrixot

A képességmátrix az útválasztó által kiértékelt igazság forrása. Verziót kell készíteni, felül kell vizsgálni és tesztelni kell, mint az éles konfigurációt.

Példamezők:

{
  "profile_id": "provider_x.chat.eu.zdr",
  "szolgáltató": "szolgáltató_x",
  "modell": "model-large",
  "api_family": "chat_completions",
  "végpont": "https://eu.example-provider.com/v1",
  "régió": "eu",
  "processing_residency": ["eu"],
  "storage_residency": ["eu"],
  "zdr_eligible": igaz,
  "zdr_contract_required": igaz,
  "training_use": "not_used_for_training_on_paid_api",
  "abuse_monitoring": "approved_modified_retention_required",
  "developer_log_retention_days": 0,
  "raw_prompt_logging_allowed": hamis,
  "támogatott_szolgáltatások": {
    "plain_chat": igaz,
    "streaming": igaz,
    "tool_calls": igaz,
    "search_grounding": hamis,
    "maps_grounding": hamis,
    "file_upload": hamis,
    "batch": hamis,
    "tárolt_beszélgetések": hamis
  },
  "last_reviewed": "2026-08-01",
  "source_refs": ["security-review-123", "vendor-doc-version-abc"]
}

Használjon modellprofilokat a nyers modellazonosítók helyett. A profil egyesíti a modellt, a szolgáltatót, a végpontot, a régiót, a szolgáltatáskészletet és a megőrzési pozíciót. A fejlesztők kérik a model_profile: compliant_summarisation-t, nem csak a model: leggyorsabb-nagy-modell-t.

Javaslat: tartalmazza a szerződéses előfeltételeket a mátrixban. Egy útvonal nem rendelkezik ZDR-jóváhagyással, pusztán azért, mert az eladó valahol ZDR-t kínál. Csak akkor hagyjuk jóvá, ha fiókja, projektje, régiója és végpontja megfelel a szükséges feltételeknek.

3. lépés: írjon szabályzat kódként szabályokat

A szabályzati szabályoknak egyértelműnek, tesztelhetőnek és a biztonsági és platformcsoportok számára olvashatónak kell lenniük.

Példaszabályok pszeudokódban:

deny if data_class == "hitelesítési adatok"
  ok: "credentials_must_not_be_send_to_model"
csak akkor engedélyezi, ha data_class in ["regulated", "customer_pii"]
  és profile.zdr_eligible == igaz
  és profile.zdr_contract_required_satisfied == igaz
  error_on_failure "model_profile_not_zdr_eligiible"
deny if residency_required == "eu"
  és az "eu" nem a profile.processing_residency
  ok "region_processing_not_supported"
deny if data_class in ["confidential", "customer_pii", "regulated"]és request.raw_prompt_logging == igaz
  ok "raw_prompt_logging_not_allowed"
deny if request.features.search_grounding == igaz
  és policy.requires_zdr == igaz
  és profile.feature_storage.search_grounding_days > 0
  oka "földelés_megtartott_tartalom"
deny if fallback_profile.retention_level < primer_profile.retention_level
  oka "fallback_weakens_retention_policy"

Ezeknek a szabályoknak le kell futniuk a szolgáltató kiválasztása előtt, majd a tartalék visszaállítás előtt. A tartalék útvonal az irányelvek véletlen eltolódásának gyakori forrása: az elsődleges útvonal megfelelhet a szabályoknak, míg a tartalék útvonal csak elérhető.

4. lépés: kezelje az eszközöket és funkciókat megőrzést megváltoztató képességként

Ne modellezze a megtartást önmagában az alapmodell tulajdonságaként. A funkciók gyakran megváltoztatják a tárolási, naplózási vagy felülvizsgálati viselkedést.

Minden funkciónak saját házirend-jelzőket kell megadnia:

• Keresési földelés: a szolgáltatói feltételektől függően üzeneteket, lekért kontextust és generált kimenetet tárolhat.
• Térképek vagy helyföldelés: helyspecifikus naplókat vagy megőrzési szabályokat vezethet be.
• Fájlfeltöltés: a kérésektől és válaszoktól elkülönítve tárolhatja a fájlokat.
• Kódvégrehajtás: ideiglenes fájlokat, végrehajtási naplókat vagy sandbox melléktermékeket hozhat létre.
• A kötegelt feladatok: eltérő megőrzési, sorba állítási és eredménytárolási viselkedést mutathatnak, mint a szinkron API-hívások.
• Tárolt beszélgetések: szándékosan megmaradnak a tartalmak, és soha nem rejthetők el egy általános csevegési lehetőség mögé.
• Értékelési vagy felülvizsgálati irányítópultok: emberi ellenőrzési munkafolyamatokat vagy hosszabb élettartamú adatkészleteket hozhatnak létre.

Javaslat: engedélyezze a megőrzést módosító funkciókat a bérlő és az útvonal szintjén. Ha a fejlesztő engedélyezi a grounding_search=true beállítást, az átjárónak újra kell értékelnie a kérést a szolgáltatás tárolási szabályai szerint, mielőtt felfelé küldi.

5. lépés: az elemzések megőrzése nyers promptok tárolása nélkül

A megőrzés-tudatos útválasztás nem vakíthatja el a platform csapatát. Hasznos AI-használati elemzéseket tarthat meg, miközben minimalizálja a tartalomtárolást.

Biztonságos alapértelmezett telemetriai mezők:

• bérlőazonosító és projektazonosító
• kivonatolt vagy belső API-kulcsazonosító
• modellprofil-azonosító és szolgáltató-azonosító
• időbélyeg és régió kérése
• A bemeneti, a kimeneti, a gyorsítótárazott és az érvelési token számít, ha elérhető
• késés, állapotkód, újrapróbálkozások száma és tartalék döntés
• becsült és kiegyenlített költség
• adatosztályozási címke
• irányelv verziója és döntésének oka
• funkciójelzők kérve, és funkciójelzők engedélyezettek

A bizalmas forgalom érdekében alapértelmezés szerint kerülje a nyers promptok és modellkimenetek tárolását. Ha a hibakeresés tartalmat igényel, használjon ellenőrzött munkafolyamatot:

• ügyfél vagy bérlő jóváhagyása
• szűk időablak
• mintavételi korlát
• szerkesztési engedély
• külön hozzáférés-szabályozás
• rövid lejárat
• napló arról, hogy ki engedélyezte és miért

Ez egy kompromisszum. A nyers prompt naplók blokkolása megnehezíti a hibakeresést, a támogatást, a minőségellenőrzést és a visszaélések kivizsgálását. De ha mindent alapértelmezés szerint tárol, az nagyobb adatvédelmi, jogsértési és megfelelőségi felületet hoz létre.

6. lépés: kereshető elutasítási okok visszaküldése

Az általános 403 tiltott frusztrálja a fejlesztőket, és megkerülő megoldásokra ösztönöz. Adjon vissza egy stabil, gépileg olvasható okot és egy ember által olvasható magyarázatot.

Példa válasz:

{
  "hiba": {
    "type": "policy_denied",
    "code": "grounding_requires_30_day_storage",
    "message": "A keresési földelés nem engedélyezett a request_zdr megjelölésű munkaterheléseknél, mert ez a szolgáltatói funkció prompt, kontextus- és kimeneti tartalmat tárol."
    "request_id": "req_123",
    "policy_version": "retention-policy-2026-08-01",
    "allowed_actions": [
      "disable_search_grounding",
      "choose_profile:zdr_plain_chat",
      "request_exception"
    ]
  }
}

A hasznos elutasító kódok a következők:

• modell_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
• contract_prerequisite_missing
• credentials_detected

7. lépés: adjon hozzá kivétel munkafolyamatot, ne rejtett megkerülést

Néhány kivétel jogos: incidensre adott válasz, ügyfél által jóváhagyott hibakeresés, migrációs tesztelés vagy ideiglenes szolgáltatói korlátozás. Az átjárónak támogatnia kell a kivételeket anélkül, hogy állandó árnyékpolitikává alakítaná azokat.

Minden kivételnek tartalmaznia kell:

• jóváhagyó személyazonossága
• kérő csapat vagy bérlő
• jegy vagy kockázatértékelés link
• üzleti indoklás
• engedélyezett modellprofilok és -funkciók
• lefedett adatosztályok
• lejárati dátum
• további naplózási követelmények

Javaslat: a kivételeket a szokásosnál szűkebbre kell szabni. Kerülje az olyan globális kapcsolókat, mint a disable_retention_policy=true. Előnyben részesítse a hatókörű felülírásokat, például „hibakeresési felszólítás naplózásának engedélyezése A bérlő B végpontja számára 24 órán keresztül, szerkesztési és biztonsági jóváhagyással”.

Működési ellenőrzőlista

• Hozzon létre egy verziózott szolgáltatói képességmátrixot.
• Jelöljön ki egy tulajdonost a szolgáltatói feltételekhez, a szerződés előfeltételeihez és a megőrzési felülvizsgálatokhoz.
• Az alkalmazásoknak meg kell adniuk az adatosztályt, a lakóhely-követelményt és a kért funkciókat.
• Alapértelmezett bizalmas és szabályozott forgalom a nyers azonnali naplózás nélkül.
• Az eszközöket, a földelést, a fájlfeltöltést, a kötegelt és a tárolt beszélgetéseket külön képességjelzőként jelenítse meg.
• Futtasson házirend-ellenőrzést az elsődleges és a tartalék útválasztás előtt.
• Naplóházirend-verzió, modellprofil, adatosztály, jellemzőjelzők és az elutasítás oka.
• Tartsa elkülönítve az analitikai metaadatokat a prompt és kimeneti tartalomtól.
• A tesztképviselő engedélyezi és tiltja az eseteket a CI-ben.
• Minden alkalommal, amikor egy szolgáltató módosítja a feltételeket, a régiókat, a végpontokat vagy a funkciókat, ellenőrizze az irányelvek változását.

Egyértelmű kompromisszumok

A szigorú útválasztás csökkenti a választási lehetőségeket. A ZDR és a tartózkodási hely korlátozásai megakadályozhatják a legújabb modell, a legalacsonyabb költségű útvonal vagy a funkciókban gazdag végpont használatát.

A regionális útválasztás növelheti a várakozási időt vagy a költségeket. Előfordulhat, hogy a legközelebbi megfelelő régió nem támogatja a kívánt feldolgozási módot, vagy más szolgáltatói elérési utat igényelhet.

A funkciókapuk meglepik a fejlesztőket. A fejlesztők azt gondolhatják, hogy csak a keresést engedélyezik, de a biztonság új megőrzési viselkedést lát. A dokumentálás és az elutasító üzenetek csökkentik a súrlódást.

Az azonnali minimalizálás megnehezíti a hibakeresést. A csapatoknak törölt mintákra, bérlő által jóváhagyott hibakereső ablakokra és erős metaadatokra van szükségük a problémák kivizsgálásához anélkül, hogy mindent elmentenének.

A mátrix karbantartást igényel. Változnak a szolgáltatói feltételek. Új modellek indulnak. A régiók bővülnek. A funkciók béta verzióról élesre kerülnek. Az elavult mátrix rosszabb, mint a mátrix hiánya, mert hamis bizalmat kelt.

Mi az ajánlás, és mi az előrejelzés?

Javaslatok: érvényesítse a megőrzést az átjárón, osztályozza a kéréseket az útválasztás előtt, hozzon létre egy szolgáltatói képességmátrixot, blokkolja a megőrzést módosító funkciókat házirend szerint, kerülje el a nyers azonnali naplózást alapértelmezés szerint, és verziózza az összes irányelvet.

Előrejelzés: Az AI platform csapatai egyre inkább a modellválasztás részeként kezelik a magánélet védelmét. Ahelyett, hogy azt kérdezné: „melyik modellt használjuk?” Az alkalmazások olyan modellprofilt fognak kérni, amely megfelel a képességekre, a költségekre, a késleltetésre, a tartózkodási időre és a megőrzésre vonatkozó korlátoknak.

Előrejelzés: a szolgáltatóspecifikus adatvédelmi funkciók továbbra is eltérnek egymástól. Azok az átjárók, amelyek csak a kérés- és válaszformátumokat normalizálják, nem lesznek elegendőek; a gyártási csapatoknak is szükségük lesz a szabályzat normalizálására.

Intézhető következtetés

Az adatmegőrzés-tudatos útválasztás nem egy külön megfelelőségi irányítópult. A kérés elérési útjába tartozik.

Kezdje három teljesítménnyel: egy kérésérzékenységi taxonómiával, egy verziózott szolgáltatói képességmátrixszal és egy kis házirend-kód-szabályokkal a ZDR-hez, a tartózkodási helyhez, a nyers naplózáshoz, a tartalék és a megőrzést módosító funkciókhoz. Ezután állítsa be az átjárót, hogy egyértelmű elutasítási okokat adjon meg, és őrizze meg az elemzéseket anélkül, hogy alapértelmezés szerint nyers tartalmat tárolna.

Ez a kialakítás központosítja azokat a döntéseket, amelyek egyébként szétszórtan lennének az SDK-beállítások, környezeti változók, szolgáltatói konzolok és csapatspecifikus konvenciók között. Praktikus ellenőrzési nyomvonalat is biztosít a biztonsági és platformcsoportok számára: melyik kérést engedélyezték, melyik házirend-verziót alkalmazták, melyik modellprofilt választották ki, és miért.

Kapcsolódó olvasnivaló

• prompts-ledgepromps naplózási és átjárószintű használati elemzés
• szolgáltatói képességmátrix felépítése OpenAI-kompatibilis API-migráció során
• irányító ügynöki eszközök hatókörrel, jóváhagyással és ellenőrzési nyomvonalakkal