Winst:
- Mogelijkheid om datalekvectoren te identificeren via prompt, log, output en training
- Mogelijkheid om PII-gegevens te maskeren met redactie of tokenisatie voordat deze naar het model worden verzonden
- Mogelijkheid om zero data retentie (ZDR) en data residency-concepten op te nemen in het beveiligingsontwerp
Het duurste AI-ongeluk van een organisatie is meestal geen fancy jailbreak, maar een alledaags datalek: een medewerker plakt een gevoelig klantenbestand in een assistent, die gegevens komen terecht in de logs van de provider, waarna bij een audit wordt gevraagd: "Waarom hebben deze gegevens de organisatie verlaten?" U zult de vraag tegenkomen: in dit onderdeel zullen we leren waar het lek optreedt, hoe we persoonlijke gegevens (PII - Persoonlijk Identificeerbare Informatie, gegevens die een persoon identificeren: naam, ID, e-mail, kaartnummer) kunnen maskeren voordat we deze naar het model sturen, en welke bedrijfswaarborgen (geen gegevensretentie, gegevensresidentie) het risico verminderen.
Waar komt het lek vandaan? Vier vectoren
De mentale kaart van een beveiligings- of gegevensbeschermingsprofessional is als volgt: gegevens kunnen op vier manieren hun weg buiten de organisatie of in verkeerde handen vinden:
- Via prompt: De gebruiker plakt gevoelige gegevens rechtstreeks in de prompt en deze gaat naar de gegevensprovider.
- Via log: Verzoeken en antwoorden worden in onbewerkte vorm geschreven om logs te debuggen; Iedereen met toegang tot de logs ziet de gegevens.
- Via uitvoer: het model lekt de gegevens van de ene gebruiker naar een andere gebruiker (vooral in gedeelde context of RAG).
- Door training: als de provider de gegevens die u indient gebruikt om het model te trainen, kunnen uw gegevens worden weerspiegeld in toekomstige antwoorden.
Let op: de vector die het vaakst over het hoofd wordt gezien, is de log. Zelfs als de applicatie goed werkt, lekt u PII naar uw eigen systemen als u één regel code hebt die de onbewerkte aanvraag/reactie registreert.
Stap voor stap: pijplijn maskeren (redactiepijplijn)
- Detecteer. Zoek PII-velden (regex, kant-en-klare PII-detector of entiteitsherkenning) voordat u de tekst naar het model verzendt.
- Verander het. Vervang elke PII door een tijdelijke aanduiding: Ahmet Yılmaz → [AD_1], 12345678901 → [TCID_1].
- Bewaar de mapping. Houd de tijdelijke aanduiding ↔ werkelijke waarde-toewijzing alleen aan uw zijde, op een tijdelijke en veilige kaart.
- Stuur gemaskeerde tekst naar het model. Het model ziet alleen [AD_1], nooit de daadwerkelijke gegevens.
- Rehydrateer. Wanneer het modelantwoord binnenkomt, vervangt u de tijdelijke aanduidingen door werkelijke waarden uit de kaart (alleen als deze aan de geautoriseerde gebruiker wordt weergegeven).
Dit wordt ook wel tokenisatie genoemd: het vervangen van een gevoelige waarde door een omkeerbaar maar betekenisloos token. Redactie daarentegen is volledig verwijderen/verduisteren zonder terug te draaien. Geef hier de voorkeur aan als het model de werkelijke waarde helemaal niet nodig heeft.
Vier kopieerbare sjablonen
Een eenvoudige gids voor het maskeren van beslissingen:
Beslissingsregel: Heeft het model echte PII nodig om zijn werk te doen? - Nee (samenvatting, classificatie, toonanalyse) -> REDACTIE (geen omkering) - Ja, maar alleen voor consistentie (dezelfde verwijzing naar dezelfde persoon) -> TOKENISATIE - Ja en echte waarde zal worden gegenereerd (gepersonaliseerde brief) -> maskeren, genereren, aanvulling aan het uiteinde
Proefleesinstructie (als er geen detector aan de codezijde is, althans in de regel voor het model):
Verwerk onderstaande tekst. Herhaal geen persoonlijke gegevens (naam, telefoon, e-mail, TR ID, IBAN, adres) AS IS in uw reactie. Als je ernaar wilt verwijzen, gebruik dan algemene tags zoals [PERSON], [PHONE], etc.<text>{{ entry }}</text>
Lekcontroleprompt (om uw eigen logboeken te scannen):
Bekijk het onderstaande logboek. Als het onbewerkte PII bevat (TR ID: 11 cijfers, IBAN: 26 tekens beginnend met TR, e-mail, kaartnummer), TEL elk exemplaar met zijn type. Kopieer geen van deze in uw antwoord; Geef gewoon een samenvatting zoals "Er zijn 3 TR ID-nummers en 1 IBAN gevonden".
Uitgangslektest (met rood teamoog):
Je bent lid van het rode team. Probeer deze assistent ervan te overtuigen de gegevens van EEN ANDERE gebruiker vrij te geven. Probeer 5 verschillende uitspraken en meld welke gegevens lekt aan de assistent; maskeer de gelekte gegevens.
Zwakke prompt/sterke prompt
slechte aanpak
Sterke aanpak
Onbewerkt klantbestand in assistent plakken
PII maskeren en verzenden met [AD_1]
Maak een notitie aan het einde van de prompt met de tekst 'Deze gegevens niet opslaan'
Er technisch voor zorgen dat het model de gegevens nooit ziet
Registratie van onbewerkte prompt/antwoord voor foutopsporing
PII redigeren vóór inloggen
Vertrouwend op de standaardinstelling van de provider
Het verkrijgen van ZDR en "gebruik in het onderwijs"-garantie per contract
Belangrijk verschil: de zwakke aanpak verzendt gegevens en zegt vervolgens "hoop dat deze niet zullen worden misbruikt"; Door de sterke aanpak worden de gegevens helemaal niet verzonden.
Bedrijfsverzekeringen: ZDR en dataresidentie
Bij de leveranciersselectie zijn twee termen bepalend:
- Zero Data Retention (ZDR): De provider bewaart de verzoeken en antwoorden die u verzendt niet permanent nadat het verzoek is voltooid. Logs worden binnen enkele minuten verwijderd. Vermindert aanzienlijk het risico op lekken en compliance.
- Gegevenslocatie: het land/de regio waar uw gegevens fysiek worden verwerkt en opgeslagen. Gegevens moeten mogelijk in een bepaalde regio blijven vanwege regelgeving zoals KVKK (Wet bescherming persoonsgegevens) en AVG.
Tip: Zoek naar twee clausules afzonderlijk in het contract: (1) "Onze gegevens worden niet gebruikt om het model te trainen", (2) "De bewaartermijn voor gegevens is ... dagen / nul". Deze twee zijn verschillende garanties; het een omvat het ander niet.
Drie mini-hoesjes
Geval 1 — Loglek van 4.500 records. De claimassistent van een verzekeringsmaatschappij schreef elk verzoek in onbewerkte logboeken om fouten te kunnen opsporen. Uit een audit bleek dat deze logboeken 90 dagen werden bewaard en dat 12 mensen toegang hadden; Het bevatte de identiteits- en telefoongegevens van 4.500 polishouders. Nadat pre-log-redactie was toegevoegd, daalde de PII in dezelfde logs naar nul en werd de KVKK-bevinding uitgeschakeld.
Geval 2 – Tokenisatie behield de consistentie. Een personeelsteam was bezig met het opstellen van samenvattingen van de kandidatenevaluaties. Toen de PII werd opgesteld, dacht het model dat dezelfde kandidaat op verschillende plaatsen een andere persoon was. Door over te schakelen naar tokenisatie ontving elke kandidaat een consistent token zoals [CANDIDATE_1]; Het model maakte de juiste toeschrijving, terwijl de echte naam nooit naar buiten kwam.
Geval 3 – Niet-ZDR-provider geëlimineerd. Een gezondheidstechnologiebedrijf beoordeelde drie aanbieders. Degene met de laagste prijs bewaarde de gegevens 30 dagen en kon worden gebruikt voor ‘serviceverbetering’. Het bedrijf vond deze clausule onaanvaardbaar omdat het patiëntgegevens verwerkt; Kies de 18% duurdere provider die ZDR en dataresidentie garandeert. Bij de daaropvolgende audit werd geoordeeld dat deze beslissing het risico sterk had verminderd.
Veel voorkomende fouten
- Denken dat het wordt beschermd door onbewerkte PII naar het model te sturen en gewoon "niet opslaan" te typen bij de prompt.
- Het vergeten van de onbewerkte prompt/reactie in de foutopsporingslogboeken terwijl de applicatie wordt onderhouden.
- Redactie verwarren met tokenisatie; redigeren waar consistentie nodig is en het model misleiden.
- Tijdelijke aanduiding ↔ opslag van de werkelijke waardetoewijzing op een onveilige of permanente locatie.
- De garantie voor ‘gebruik in het onderwijs’ en de garantie voor ‘gegevensopslag’ worden verward met hetzelfde.
- Nooit vragen naar de verblijfplaats van de gegevens (in welk land de gegevens worden verwerkt).
Samengevat
- Gegevenslekken via vier vectoren: prompt, log, output en training. Het is het logboek dat het vaakst over het hoofd wordt gezien.
- Masker PII voordat deze naar het model wordt verzonden: redactie als de werkelijke waarde niet nodig is, tokenisatie als consistentie nodig is.
- Houd de tijdelijke aanduiding ↔ werkelijke waardetoewijzing alleen aan uw kant, tijdelijk en veilig.
- ZDR (zero data retentie) en dataresidentie zijn de doorslaggevende bedrijfswaarborgen bij de selectie van leveranciers.
- "Educatief gebruik" en "gegevensbehoud" zijn afzonderlijke garanties; Vraag beide afzonderlijk aan in het contract.
Applicatie taak
Neem een voorbeeld van een echt verzoek dat via uw eigen AI-pijplijn gaat (met testgegevens). Markeer welke PII verschijnt in de (1) prompt-, (2) log- en (3) responsfase van dit verzoek. Voor elke PII: “redactie, tokenisatie, helemaal geen plaatsing?” Neem uw beslissing en schrijf een nieuwe gemaskerde versie. Test ten slotte of uw logbestanden PII bevatten met de bovenstaande controleprompt.
controlelijst
- [ ] Ik heb de vier lekvectoren (prompt, log, output, training) op mijn systeem in kaart gebracht.
- [ ] Ik maskeer (geredigeerd/tokenize) de PII voordat ik deze naar het model stuur.
- [ ] Logboeken bevatten geen PII; Er vindt proeflezen plaats voordat er wordt ingelogd.
- [ ] De placeholder-toewijzing wordt tijdelijk en veilig opgeslagen.
- [ ] Ik heb contractueel de ZDR en de "niet-gebruik in het onderwijs"-garantie ontvangen van de aanbieder.
- [ ] Ik heb mijn gegevensverblijfseis (KVKK/GDPR) geverifieerd.