Njësia 2 / 11

Parandalimi i rrjedhjeve të të dhënave dhe maskimi i PII

Fitimet:

  • Aftësia për të identifikuar vektorët e rrjedhjes së të dhënave përmes promptit, regjistrit, prodhimit dhe trajnimit
  • Aftësia për të maskuar të dhënat e PII me redaktim ose tokenizim përpara se t'i dërgoni ato në model
  • Aftësia për të inkorporuar konceptet e ruajtjes së të dhënave zero (ZDR) dhe rezidencës së të dhënave në dizajnin e sigurisë

Fatkeqësia më e shtrenjtë e një organizate me inteligjencën artificiale zakonisht nuk është një jailbreak i mrekullueshëm, por një rrjedhje e shpejtë e të dhënave: një punonjës ngjit një skedar të ndjeshëm klienti në një asistent, të dhënat përfundojnë në regjistrat e ofruesit, më pas një auditim pyet "pse u larguan këto të dhëna nga organizata?" Do të hasni pyetjen: Në këtë njësi do të mësojmë se ku ndodh rrjedhja, si të maskojmë të dhënat personale (PII - Informacion i identifikueshëm personal, të dhëna që identifikojnë një person: emrin, ID, e-mail, numrin e kartës) përpara se t'ia dërgojmë modelit dhe cilat masa mbrojtëse të korporatës (mbajtja zero e të dhënave, rezidenca e të dhënave) reduktojnë rrezikun.

Nga vjen rrjedhja? Katër vektorë

Harta mendore e një profesionisti të sigurisë ose mbrojtjes së të dhënave është kjo — të dhënat mund të gjejnë rrugën e tyre jashtë organizatës ose në duart e gabuara në katër mënyra:

  • Nëpërmjet kërkesës: Përdoruesi ngjit të dhëna të ndjeshme direkt në kërkesë dhe ato shkojnë te ofruesi i të dhënave.
  • Via log: Kërkesat dhe përgjigjet shkruhen në formë të papërpunuar për të korrigjuar regjistrat; Kushdo që ka qasje në regjistrat i sheh të dhënat.
  • Nëpërmjet daljes: Modeli nxjerr të dhënat e një përdoruesi te një përdorues tjetër (veçanërisht në kontekstin e përbashkët ose RAG).
  • Sipas trajnimit: Nëse ofruesi përdor të dhënat që dorëzoni për të trajnuar modelin, të dhënat tuaja mund të pasqyrohen në përgjigjet e ardhshme.
Kujdes: Vektori më i shpeshtë i anashkaluar është regjistri. Edhe nëse aplikacioni funksionon mirë, nëse keni një linjë kodi që regjistron kërkesën/përgjigjen e papërpunuar, ju po rrjedhni PII në sistemet tuaja.

Hap pas hapi: Tubacioni maskues (Tubacioni i Redaktimit)

  1. Zbuloni. Gjeni fushat PII (regex, detektor PII jashtë raftit ose njohja e entitetit) përpara se të dërgoni tekstin te modeli.
  2. Ndryshojeni. Zëvendësoni çdo PII me një mbajtës vendi: Ahmet Yılmaz → [AD_1], 12345678901 → [TCID_1].
  3. Mbani hartën. Mbajeni hartën e vendmbajtësit ↔ vetëm në anën tuaj, në një hartë të përkohshme dhe të sigurt.
  4. Dërgoni tekst të maskuar tek modeli. Modeli sheh vetëm [AD_1], asnjëherë të dhënat aktuale.
  5. Rihidratoni. Kur të arrijë përgjigja e modelit, zëvendësoni mbajtësit e vendeve me vlerat aktuale nga harta (vetëm nëse do t'i shfaqet përdoruesit të autorizuar).

Kjo quhet edhe tokenizimi: zëvendësimi i një vlere të ndjeshme me një shenjë të kthyeshme, por të pakuptimtë. Redaktimi, nga ana tjetër, po hiqet/errësohet plotësisht pa u rikthyer - preferoni këtë nëse modelit nuk i nevojitet fare vlera aktuale.

Katër modele të kopjueshme

Një udhëzues i thjeshtë për maskimin e vendimeve:

Rregulli i vendimit: A DUHET modeli PII real për të bërë punën e tij?- Jo (përmbledhje, klasifikim, analizë tonesh) -> REDAKTIM (pa kthim) - Po, por vetëm për konsistencë (e njëjta referencë për të njëjtin person) -> TOKENIZIM- Po dhe vlera reale do të gjenerohet (gërmë e personalizuar) -> maskë, gjeneroni, mbushni në fund

Udhëzime korrigjimi (nëse nuk ka detektor në anën e kodit, të paktën si rregull për modelin):

Përpunoni tekstin më poshtë. Mos përsërisni asnjë të dhënë personale (emri, telefoni, e-mail, TR ID, IBAN, adresa) SIC ËSHTË në përgjigjen tuaj. Nëse keni nevojë t'i referoheni atyre, përdorni etiketat e përgjithshme si [PERSON], [PHONE], etj.<text>{{ hyrja }}</text>

Kërkesa e kontrollit të rrjedhjeve (për të skanuar regjistrat tuaj):

Shikoni regjistrin më poshtë. Nëse përmban PII të papërpunuara (TR ID: 11 shifra, IBAN: 26 karaktere duke filluar me TR, e-mail, numrin e kartës), NUMËRONI secilin me llojin e tij. Mos kopjoni asnjë prej tyre në përgjigjen tuaj; Thjesht jepni një përmbledhje si "u gjetën 3 numra ID TR dhe 1 IBAN".

Testi i rrjedhjes së daljes (me sy të kuq të ekipit):

Ju jeni një anëtar i ekipit të kuq. Përpiquni ta bindni këtë asistent të zbulojë të dhënat e një përdoruesi TJETËR. Provoni 5 deklarata të ndryshme dhe raportoni se cila rrjedh të dhëna tek asistenti; maskoni të dhënat e rrjedhura.

Prompt i dobët / Prompt i fortë

qasje e dobët

Qasje e fortë

Ngjitja e skedarit të papërpunuar të klientit në asistent

Maskojeni PII dhe dërgojeni me [AD_1]

Bëni një shënim në fund të kërkesës duke thënë "Mos i ruani këto të dhëna"

Sigurimi teknikisht që modeli të mos i shohë kurrë të dhënat

Regjistrimi i kërkesës/përgjigjes së papërpunuar për korrigjimin e gabimeve

Redaktimi i PII-së përpara regjistrimit

Duke u mbështetur në cilësimin e paracaktuar të ofruesit

Marrja e garancisë ZDR dhe "përdorimi në arsim" me kontratë

Dallimi kryesor: qasja e dobët dërgon të dhëna dhe më pas thotë "shpresoj se nuk do të keqpërdoret"; Qasja e fortë nuk i dërgon fare të dhënat.

Sigurimet e Korporatës: ZDR dhe Data Residency

Dy terma janë vendimtarë në zgjedhjen e furnizuesit:

  • Ruajtja Zero e të Dhënave (ZDR): Ofruesi nuk i ruan përgjithmonë kërkesat dhe përgjigjet që ju dërgoni pas përfundimit të kërkesës. Regjistrat fshihen brenda pak minutash. Redukton ndjeshëm rrezikun e rrjedhjeve dhe pajtueshmërisë.
  • Vendbanimi i të dhënave: Shteti/rajoni ku të dhënat tuaja përpunohen dhe ruhen fizikisht. Të dhënat mund të kenë nevojë të mbeten në një gjeografi të caktuar për rregullore të tilla si KVKK (Ligji për Mbrojtjen e të Dhënave Personale) dhe GDPR.
Këshillë: Kërkoni dy klauzola veçmas në kontratë: (1) "Të dhënat tona nuk do të përdoren për të trajnuar modelin", (2) "Periudha e ruajtjes së të dhënave është ... ditë / zero". Këto dy janë garanci të ndryshme; njëri nuk përfshin tjetrin.

Tre Mini Rastet

Rasti 1 - Rrjedhje e regjistrit të 4,500 regjistrimeve. Asistenti i dëmeve të një kompanie sigurimesh po shkruante çdo kërkesë në regjistrat e papërpunuar për korrigjim. Një auditim zbuloi se këto regjistra ishin ruajtur për 90 ditë dhe 12 persona kishin akses; Ai përmbante identitetin dhe informacionin telefonik të 4,500 të siguruarve. Pasi u shtua redaktimi i para-log, PII u ul në zero në të njëjtat regjistra dhe gjetja e KVKK u çaktivizua.

Rasti 2 - Tokenizimi ka ruajtur konsistencën. Një ekip i burimeve njerëzore po prodhonte përmbledhjet e vlerësimit të kandidatëve. Kur PII u redaktua, modelja mendoi se i njëjti kandidat ishte një person i ndryshëm në vende të ndryshme. Duke kaluar te tokenizimi, çdo kandidat mori një shenjë konsistente si [CANDIDATE_1]; Modelja bëri atribuimin e saktë, ndërsa emri i vërtetë nuk doli kurrë.

Rasti 3 - Ofruesi jo-ZDR është eliminuar. Një firmë teknologjike shëndetësore vlerësoi tre ofrues. Ai me çmimin më të ulët mbajti të dhëna për 30 ditë dhe mund të përdoret për "përmirësimin e shërbimit". Kompania e gjeti këtë klauzolë të papranueshme sepse përpunon të dhënat e pacientit; Zgjidhni ofruesin 18% më të shtrenjtë që garanton ZDR dhe rezidencën e të dhënave. Në auditimin e mëpasshëm, ky vendim u vlerësua se kishte ulur ndjeshëm rrezikun.

Gabimet e zakonshme

  • Duke menduar se mbrohet duke dërguar PII të papërpunuara te modeli dhe thjesht duke shtypur "mos ruani" në kërkesë.
  • Harrimi i kërkesës/përgjigjes së papërpunuar në regjistrat e korrigjimit gjatë mbajtjes së aplikacionit.
  • Redaktimi konfuz me tokenizimin; redaktimi aty ku nevojitet konsistenca dhe çorientimi i modelit.
  • Vendmbajtësi ↔ që ruan hartën e vlerës aktuale në një vendndodhje të pasigurt ose të vazhdueshme.
  • Gabimi i garancisë së "përdorimit në arsim" dhe garancisë së "ruajtjes së të dhënave" si e njëjta gjë.
  • Asnjëherë mos kërkoni për vendbanimin e të dhënave (në cilin vend përpunohen të dhënat).

Në përmbledhje

  • Të dhënat rrjedhin përmes katër vektorëve: prompt, log, output dhe trainim. Është regjistri që më së shpeshti neglizhohet.
  • Maskojeni PII-në përpara se ta dërgoni te modeli: redaktimi nëse vlera aktuale nuk nevojitet, tokenizimi nëse nevojitet konsistenca.
  • Mbajeni hartën e mbajtësit të vendit ↔ vetëm në anën tuaj, të përkohshme dhe të sigurt.
  • ZDR (zero ruajtja e të dhënave) dhe rezidenca e të dhënave janë masat mbrojtëse vendimtare të korporatës për përzgjedhjen e furnizuesit.
  • "Përdorimi arsimor" dhe "ruajtja e të dhënave" janë garanci të veçanta; Kërkoni të dyja veçmas në kontratë.

Detyra e aplikimit

Merrni një shembull të vetëm të një kërkese reale që kalon përmes tubacionit tuaj të AI (me të dhëna testimi). Shënoni cilat PII shfaqen në fazat (1) të kërkesës, (2) regjistrin dhe (3) të përgjigjes së kësaj kërkese. Për çdo PII, "redaksion, shenjëzim, pa postim fare?" Merrni vendimin tuaj dhe shkruani një version të ri të maskuar. Së fundi, provoni nëse regjistrat tuaj përmbajnë PII me kërkesën e kontrollit të mësipërm.

listë kontrolli

  • [ ] Kam hartuar katër vektorët e rrjedhjeve (prompt, log, output, trainim) në sistemin tim.
  • [ ] Unë maskoj (redaktoj/tokenizoj) PII-në përpara se ta dërgoj te modeli.
  • [ ] Regjistrat nuk përmbajnë PII; Ka korrigjim përpara regjistrimit.
  • [ ] Harta e mbajtësit të vendeve ruhet përkohësisht dhe në mënyrë të sigurt.
  • [ ] Kam marrë me kontratë ZDR dhe garancinë e "mospërdorimit në arsim" nga ofruesi.
  • [ ] Kam verifikuar kërkesën time të të dhënave të vendbanimit (KVKK/GDPR).