Jednotka 2 / 11

Prevencia úniku údajov a maskovanie PII

zisky:

  • Schopnosť identifikovať vektory úniku údajov prostredníctvom výzvy, protokolu, výstupu a školenia
  • Schopnosť maskovať údaje PII pomocou redigovania alebo tokenizácie pred ich odoslaním do modelu
  • Schopnosť začleniť koncepty nulového uchovávania údajov (ZDR) a rezidencie údajov do návrhu zabezpečenia

Najdrahším nešťastím organizácie v oblasti umelej inteligencie zvyčajne nie je prepychový útek z väzenia, ale bežný únik údajov: zamestnanec vloží citlivý zákaznícky súbor do asistenta, tieto údaje skončia v denníkoch poskytovateľa a potom sa audit spýta: „Prečo tieto údaje opustili organizáciu?“ Stretnete sa s otázkou: V tejto časti sa dozvieme, kde dochádza k úniku, ako zamaskovať osobné údaje (PII - Personally Identifiable Information, údaje, ktoré identifikujú osobu: meno, ID, e-mail, číslo karty) pred ich odoslaním do modelu a aké podnikové záruky (nulové uchovávanie údajov, pobyt v údajoch) znižujú riziko.

Odkiaľ pochádza únik? Štyri vektory

Mentálna mapa odborníka na bezpečnosť alebo ochranu údajov je takáto – údaje si môžu nájsť cestu mimo organizácie alebo do nesprávnych rúk štyrmi spôsobmi:

  • Cez výzvu: Používateľ vloží citlivé údaje priamo do výzvy a tá sa dostane k poskytovateľovi údajov.
  • Cez protokol: Požiadavky a odpovede sa zapisujú v surovej forme do protokolov ladenia; Každý, kto má prístup k denníkom, vidí údaje.
  • Cez výstup: Model uniká dáta jedného užívateľa inému užívateľovi (najmä v zdieľanom kontexte alebo RAG).
  • Školením: Ak poskytovateľ použije údaje, ktoré odošlete na školenie modelu, vaše údaje sa môžu prejaviť v budúcich odpovediach.
Pozor: Najčastejšie prehliadaným vektorom je log. Aj keď aplikácia funguje dobre, ak máte jeden riadok kódu, ktorý zaznamenáva surovú požiadavku/odpoveď, uniká vám PII do vašich vlastných systémov.

Krok za krokom: Maskovací kanál (Redaction Pipeline)

  1. Zistiť. Pred odoslaním textu do modelu nájdite polia PII (regex, bežný detektor PII alebo rozpoznávanie entít).
  2. Zmeňte to. Nahraďte každý PII zástupným symbolom: Ahmet Yılmaz → [AD_1], 12345678901 → [TCID_1].
  3. Ponechajte si mapovanie. Ponechajte si zástupný symbol ↔ mapovanie skutočnej hodnoty iba na vašej strane, na dočasnej a bezpečnej mape.
  4. Pošlite modelke maskovaný text. Model vidí iba [AD_1], nikdy nie skutočné údaje.
  5. Rehydratujte. Keď príde odpoveď modelu, nahraďte zástupné symboly skutočnými hodnotami z mapy (iba ak sa budú zobrazovať oprávnenému používateľovi).

Hovorí sa tomu aj tokenizácia: nahradenie citlivej hodnoty reverzibilným, ale nezmyselným tokenom. Redakcia na druhej strane úplne odstraňuje/zakrýva bez vrátenia späť – uprednostnite to, ak model vôbec nepotrebuje skutočnú hodnotu.

Štyri kopírovateľné šablóny

Jednoduchý sprievodca rozhodnutiami o maskovaní:

Pravidlo rozhodovania: POTREBUJE model na svoju prácu skutočné PII?- Nie (sumarizácia, klasifikácia, tónová analýza) -> REDAKCIA (bez spätného chodu)- Áno, ale len kvôli konzistencii (rovnaký odkaz na tú istú osobu) -> TOKENIZÁCIA- Áno a vygeneruje sa skutočná hodnota (personalizovaný list) -> maska, vygenerovanie, doplnenie na konci

Návod na korektúru (ak na strane kódu nie je detektor, aspoň spravidla na modeli):

Spracujte text nižšie. V odpovedi neopakujte žiadne osobné údaje (meno, telefón, e-mail, TR ID, IBAN, adresa) AKO SÚ. Ak ich potrebujete uviesť, použite všeobecné značky ako [PERSON], [PHONE] atď.<text>{{ záznam }}</text>

Výzva na kontrolu úniku (na skenovanie vlastných protokolov):

Pozrite si denník nižšie. Ak obsahuje nespracované PII (TR ID: 11 číslic, IBAN: 26 znakov začínajúcich na TR, e-mail, číslo karty), POČÍTAJTE každý s jeho typom. Nekopírujte žiadne z nich do svojej odpovede; Stačí uviesť zhrnutie ako „Našli sa 3 čísla TR ID a 1 IBAN“.

Test tesnosti na výstupe (s červeným tímovým okom):

Ste členom červeného tímu. Pokúste sa presvedčiť tohto asistenta, aby odhalil údaje iného používateľa. Vyskúšajte 5 rôznych vyhlásení a nahláste, ktorý z nich uniká údaje asistentovi; maskovať uniknuté údaje.

Slabá výzva / silná výzva

zlý prístup

Silný prístup

Vloženie nespracovaného súboru klienta do asistenta

Maskovať PII a odoslať pomocou [AD_1]

Na konci výzvy si urobte poznámku „Neukladať tieto údaje“

Technicky zaisťuje, že model nikdy neuvidí údaje

Zaznamenávanie nespracovanej výzvy/odpovede na ladenie

Úprava údajov umožňujúcich identifikáciu osôb pred prihlásením

Spoliehanie sa na predvolené nastavenie poskytovateľa

Získanie ZDR a záruky „použitie vo vzdelávaní“ zmluvne

Hlavný rozdiel: slabý prístup odošle údaje a potom povie „dúfam, že nebudú zneužité“; Silný prístup neposiela údaje vôbec.

Corporate Assurances: ZDR a Data Residency

Pri výbere dodávateľa sú rozhodujúce dva termíny:

  • Zero Data Retention (ZDR): Poskytovateľ natrvalo neuchováva žiadosti a odpovede, ktoré odošlete po dokončení žiadosti. Protokoly sa vymažú v priebehu niekoľkých minút. Výrazne znižuje riziko úniku a zhody.
  • Sídlo údajov: Krajina/región, kde sa vaše údaje fyzicky spracúvajú a ukladajú. Údaje môžu musieť zostať v určitej geografickej oblasti pre nariadenia, ako sú KVKK (zákon o ochrane osobných údajov) a GDPR.
Tip: V zmluve hľadajte oddelene dve klauzuly: (1) „Naše údaje sa nepoužijú na trénovanie modelu“, (2) „Obdobie uchovávania údajov je ... dní / nula“. Tieto dve sú rôzne záruky; jedno nezahŕňa druhé.

Tri mini puzdrá

Prípad 1 – Únik 4 500 záznamov. Náhradný asistent poisťovne zapisoval každú požiadavku do nespracovaných protokolov na ladenie. Auditom sa zistilo, že tieto záznamy boli uchovávané 90 dní a prístup k nim malo 12 ľudí; Obsahoval občiansky preukaz a telefónne údaje 4 500 poistencov. Po pridaní predlogovej redakcie sa PII v rovnakých protokoloch znížilo na nulu a nález KVKK bol vypnutý.

Prípad 2 – Tokenizácia si zachovala konzistenciu. Tím ľudských zdrojov pripravoval súhrny hodnotenia kandidátov. Keď boli PII redigované, model si myslel, že ten istý kandidát je iná osoba na rôznych miestach. Prepnutím na tokenizáciu každý kandidát získal konzistentný token, ako napríklad [CANDIDATE_1]; Model uviedol správny zdroj, zatiaľ čo skutočné meno nikdy nevyšlo.

Prípad 3 – Vylúčený poskytovateľ, ktorý nie je ZDR. Zdravotnícka technologická firma hodnotila troch poskytovateľov. Ten s najnižšou cenou uchovával údaje 30 dní a mohol sa použiť na „vylepšenie služieb“. Spoločnosť považovala túto klauzulu za neprijateľnú, pretože spracúva údaje o pacientoch; Vyberte si o 18 % drahšieho poskytovateľa, ktorý garantuje ZDR a dátovú rezidenciu. V následnom audite sa toto rozhodnutie považovalo za rozhodnutie výrazne znížiť riziko.

Časté chyby

  • Mysliac si, že je chránený odoslaním nespracovaných PII do modelu a jednoduchým zadaním „neukladať“ na výzvu.
  • Zabudnutie surovej výzvy/odpovede v protokoloch ladenia pri zachovaní aplikácie.
  • Mýtajúca sa redakcia s tokenizáciou; redigovanie tam, kde je potrebná konzistentnosť, a zavádzanie modelu.
  • Zástupný symbol ↔ ukladajúci mapovanie skutočnej hodnoty na nebezpečnom alebo trvalom mieste.
  • Pomýliť si záruku „použitie vo vzdelávaní“ a záruku „ukladanie dát“ za to isté.
  • Nikdy nežiadať o pobyt údajov (v ktorej krajine sa údaje spracúvajú).

V súhrne

  • Údaje unikajú cez štyri vektory: výzva, protokol, výstup a školenie. Práve poleno je najčastejšie prehliadané.
  • Maska PII pred odoslaním do modelu: úprava, ak skutočná hodnota nie je potrebná, tokenizácia, ak je potrebná konzistencia.
  • Ponechajte zástupný symbol ↔ mapovanie skutočnej hodnoty iba na vašej strane, dočasne a bezpečne.
  • ZDR (nulové uchovávanie údajov) a dátová rezidencia sú rozhodujúcimi firemnými zárukami výberu dodávateľov.
  • „Používanie na vzdelávanie“ a „uchovávanie údajov“ sú samostatné záruky; Oboje si vyžiadajte v zmluve zvlášť.

Aplikačná úloha

Vezmite si jeden príklad skutočnej požiadavky, ktorá prechádza vaším vlastným potrubím AI (s testovacími údajmi). Označte, ktoré PII sa zobrazujú vo fázach (1) výzvy, (2) denníka a (3) odpovede tejto žiadosti. Pre každý PII: „reakcia, tokenizácia, žiadne uverejňovanie?“ Rozhodnite sa a napíšte novú maskovanú verziu. Nakoniec pomocou kontrolnej výzvy vyššie otestujte, či vaše denníky obsahujú PII.

kontrolný zoznam

  • [ ] Zmapoval som štyri vektory úniku (výzva, protokol, výstup, školenie) na svojom systéme.
  • [ ] Pred odoslaním do modelu maskujem (redigujem/tokenizujem) PII.
  • [ ] Protokoly neobsahujú PII; Pred prihlásením sa vykonáva korektúra.
  • [ ] Mapovanie zástupného symbolu je uložené dočasne a bezpečne.
  • [ ] ZDR a záruku "nepoužívanie vo vzdelávaní" som zmluvne prevzal od poskytovateľa.
  • [ ] Overil som si požiadavku na bydlisko údajov (KVKK/GDPR).