Varför självdrivna PII-verktyg misslyckas med efterlevnadsrevisioner
GDPR kräver bevis. Du måste visa att PII-borttagning gjordes på samma sätt varje gång. DPA-revisorer kontrollerar detta. De vill se en tydlig, konsekvent metod som används för all data.
Självdrift av Presidio har ett verkligt problem här. Det är inte en konfigurationsfråga. Det är en grundläggande begränsning för självdrivna NLP-verktyg.
Vad är miljödrift?
Självdrift av Presidio körs i dev, staging och produktion. Var och en av dessa kan bete sig på olika sätt. Så samma input kan ge olika resultat i var och en av dem.
Detta kallas miljödrift. Det har fyra huvudorsaker.
Modellversionsdrift
spaCy-modeller är versionerade. Modell en_core_web_lg 3.4.4 och en_core_web_lg 3.5.1 tränade på olika data. De använder också olika design. Så samma dokument kan ge olika NER-resultat med varje version.
Ett vanligt konfigurationsscenario ser ut så här:
- Dev:
en_core_web_lg 3.4.4— installerat vid projektstart - Staging:
en_core_web_lg 3.5.0— uppdaterat under rutinarbete - Produktion:
en_core_web_lg 3.5.1— uppdaterat under en säkerhetsfixning
Det är tre konfigurationer. Tre modellversioner. Tre olika detekteringsresultat. Tester klarar staging. Men produktion kör en annan modell. Så gapet förblir dolt.
Beroendedrift
spaCy 3.4.x och 3.5.x skiljer sig i hur de delar upp meningar. Den förändringen påverkar hur namn hittas nära meningsgränser. Dessa förändringar finns i spaCy-versionsnoteringarna. Men de flesta team kontrollerar dem inte för PII-påverkan.
Konfigurationsdrift
Poänggränser inställda i dev kanske inte överförs till produktion. Anpassade ordlistor kan också skilja sig mellan konfigurationer. Dessa luckor är vanliga. De spåras sällan. Se vår GDPR-efterlevnadsguide för vad revisorer letar efter.
Hårdvaruskillnader
Matematik i NLP-modeller är inte identisk på alla processorer och grafikkort. En konsumentdator och en server kan ge lite olika poängresultat. Så vissa namn kan hittas på en maskin men inte på en annan.
En verklig revisionsresultat
En bank testade sin självdrivna Presidio-konfiguration.
Testkonfiguration: Presidio med spaCy 3.4.4 på stagingklustret. Livekonfiguration: Presidio med spaCy 3.5.1 på produktionsklustret.
De körde samma dokumentuppsättning genom båda. Sedan jämförde de resultaten. Resultatet: 3% av dokumenten hade olika PII-borttagningsresultat. Vissa namn fångades i staging men inte i produktion. Vissa hade olika detekterade textintervall.
Revisionsresultatet var direkt: "Företaget kan inte visa konsekvent användning av tekniska PII-borttagningsåtgärder på grund av konfigurationsspecifika skillnader i detekteringsutdata."
GDPR artikel 32 kräver lämpliga tekniska åtgärder. EDPB-regler om PII-borttagning kräver konsekvens och repeterbarhet. En frekvens på 3% över 100 000 dokument per månad innebär 3 000 dokument med inkonsekventa resultat varje månad. Vissa är falska negativa. PII som staging skulle fånga finns kvar i live-utdata. Det är ett efterlevnadsfel.
Banken bytte sedan till hanterad SaaS. Revisionsresultatet stängdes. Se vår säkerhets- och efterlevnadssida för hur hanterade konfigurationer hanterar detta.
Varför hanterade tjänster är annorlunda
En hanterad tjänst kör en motorversion. Alla användare kör samma version vid samma tidpunkt. Modelluppdateringar tillämpas från ett ställe. Konfigurationen hanteras också från ett ställe, med en fullständig ändringslogg. Användarhårdvara påverkar inte resultaten.
Så samma dokument som behandlas idag ger samma resultat nästa månad. Om motorversionen ändrades loggas och versioneras den förändringen.
Skillnaden i granskningsspåret är avgörande.
Självdrift granskningsspår:
- "Använde Presidio 2.2.35 med spaCy
en_core_web_lg 3.5.1på Ubuntu 22.04." - Var detta samma version som i staging? Okänt.
- Har modellen ändrats sedan detta dokument bearbetades? Okänt om det inte spårades.
- Är poänggränsen densamma som i testning? Det beror på konfigurationshantering.
Hanterat tjänst granskningsspår:
- "Använde anonym.legal API, motorversion 4.22.1, vid 2025-03-15T14:22:31Z."
- Samma version för alla användare? Ja.
- Har den ändrats? Motorversioner är låsta. Version 4.22.1 innebär alltid samma motor.
- Är konfigurationen repeterbar? Ja. Förinställnings-ID loggas. Konfigurationen vid den versionen kan hämtas.
Det hanterade spåret är tydligt. Det självdrivna spåret kräver noggrann spårning som de flesta team hoppar över.
Hur man förbättrar konsistens vid självdrift
Om självdrift krävs kan du minska drift med fyra steg.
Först, låsa modellversioner. Lås exakta modellversioner i alla distributionsfiler. Blockera automatiska uppdateringar. Spåra versioner i källkodskontroll.
Sedan, frysa containeravbilder. Bygg Docker-avbilder med exakta modellversioner inbyggda. Tagga varje avbild med modellversionen, Presidio-versionen och datumet. Uppdatera inte basavbilder utan att testa först.
Dessutom, håll konfiguration i kod. Lagra alla Presidio-inställningar i filer som spåras i versionskontroll. Det inkluderar detektorer, poänggränser och aktiva språk. Distribuera konfigurationen med appen.
Slutligen, testa över konfigurationer. Efter varje uppdatering, kör en fast testdokumentuppsättning genom den nya konfigurationen. Jämför resultaten med en lagrad referens. Automatisera denna kontroll. Se FAQ:n för vanliga frågor om automatisk PII-regressionstest.
Dessa steg hjälper. Men de lägger också till arbete. En hanterad tjänst ger samma konsekvens utan extra ansträngning.
Slutsatsen
Konsekvent PII-borttagning syns inte på produktblad. Men det blir kritiskt när revisorer ber om bevis.
Utan aktiv omsorg driver självdrivna PII-verktyg iväg. Versionsförändringar lägger till tysta luckor. Dessa luckor dyker upp som revisionsresultat.
Hanterade tjänster ger konsekvens som standard. Motorn körs från ett ställe. Användarkonfigurationer påverkar inte resultaten. För efterlevnadsfokuserade team är detta en direkt fördel.