Hvorfor selvhostede PII-verktoy mislykkes i compliance-revisjoner
GDPR krever bevis. Du må vise at PII-fjerning ble gjort på samme måte hver gang. DPA-revisorer sjekker dette. De vil se en tydelig, konsistent metode brukt på tvers av alle data.
Selvhostet Presidio har et reelt problem her. Det er ikke et konfigurasjonsproblem. Det er en kjernebegrensning i selvhostede NLP-verktoy.
Hva er miljoavvik?
Selvhostet Presidio kjorer i utvikling, staging og produksjon. Hvert av disse kan oppfore seg på en annen måte. Så den samme inndataen kan gi forskjellige resultater i hvert miljo.
Dette kalles miljoavvik. Det har fire hovedårsaker.
Modellversjonsavvik
spaCy-modeller er versjonerte. Modellene en_core_web_lg 3.4.4 og en_core_web_lg 3.5.1 ble traent på forskjellige data. De bruker også forskjellige modelldesign. Så det samme dokumentet kan gi forskjellige NER-resultater med hver versjon.
Et vanlig oppsett ser slik ut:
- Utvikling:
en_core_web_lg 3.4.4— installert ved prosjektstart - Staging:
en_core_web_lg 3.5.0— oppdatert under rutinemessig arbeid - Produksjon:
en_core_web_lg 3.5.1— oppdatert under en sikkerhetsrettelse
Det er tre oppsett. Tre modellversjoner. Tre forskjellige deteksjonsresultater. Tester besta i staging. Men produksjon kjorer en annen modell. Så gapet forblir skjult.
Avhengighetsversjonsavvik
spaCy 3.4.x og 3.5.x skiller seg i hvordan de deler opp setninger. Den endringen påvirker hvordan navn oppdages nær setningsbrudd. Disse endringene er i spaCys utgivelsesnoter. Men de fleste team sjekker dem ikke for PII-påvirkning.
Konfigurasjonsavvik
Score-stokkler satt i utvikling kan hende ikke overforesteges til produksjon. Egendefinerte ordlister kan også variere mellom oppsett. Disse gapene er vanlige. De er sjelden sporet. Se vår GDPR-samvarsveiledning for hva revisorer ser etter.
Maskinvareforskjeller
Matematikk i NLP-modeller er ikke identisk på tvers av alle CPUer og GPUer. En forbrukerlaptop og en server kan gi litt forskjellige score-resultater. Så noen navn kan bli funnet på én maskin, men ikke på en annen.
Et virkelig revisjonsfunn
En bank testet sitt selvhostede Presidio-oppsett.
Testoppsett: Presidio med spaCy 3.4.4 på staging-klyngen. Live oppsett: Presidio med spaCy 3.5.1 på produksjonsklyngen.
De kjorte det samme settet med dokumenter gjennom begge. Deretter sammenlignet de resultatene. Funnet: 3 % av dokumentene hadde forskjellige PII-fjerningsresultater. Noen navn ble fanget opp i staging, men ikke i produksjon. Noen hadde forskjellige oppdagede tekstomfang.
Revisjonsfunnet var direkte: "Firmaet kan ikke vise konsistent bruk av tekniske PII-fjernetiltak på grunn av oppsettsspesifikke forskjeller i deteksjonsoutput."
GDPR artikkel 32 krever riktige tekniske tiltak. EDPB-regler om PII-fjerning krever konsistens og gjentakelighet. En rate på 3 % på tvers av 100 000 dokumenter per måned betyr 3 000 dokumenter med inkonsistente resultater hver måned. Noen er falske negativer. PII som staging ville ha fanget opp, forblir i live-output. Det er et compliance-brudd.
Banken byttet deretter til administrert SaaS. Revisjonsfunnet ble lukket. Se vår sikkerhets- og samvarssside for hvordan administrerte oppsett håndterer dette.
Hvorfor administrerte tjenester er annerledes
En administrert tjeneste kjorer én motorversjon. Alle brukere kjorer samme versjon til samme tid. Modelloppdateringer brukes fra ett sted. Konfigurasjon administreres også fra ett sted, med en fullstendig endringslogg. Brukermaskinvare påvirker ikke resultatene.
Så det samme dokumentet behandlet i dag gir det samme resultatet neste måned. Hvis motorversjonen endret seg, er denne endringen logget og versjonert.
Revisjonslogforskjellen er nokkel.
Selvhostet revisjonslogg:
- "Brukte Presidio 2.2.35 med spaCy
en_core_web_lg 3.5.1på Ubuntu 22.04." - Var dette samme versjon som i staging? Ukjent.
- Har modellen endret seg siden dette dokumentet ble behandlet? Ukjent med mindre det spores.
- Er score-stokkelen den samme som i testing? Det avhenger av konfigurasjonsforvaltning.
Administrert tjeneste revisjonslogg:
- "Brukte anonym.legal API, motorversjon 4.22.1, kl. 2025-03-15T14:22:31Z."
- Samme versjon for alle brukere? Ja.
- Har det endret seg? Motorversjoner er festet. Versjon 4.22.1 betyr alltid den samme motoren.
- Er konfigurasjonen repeterbar? Ja. Forhåndsinnstillings-ID er logget. Konfigurasjon ved den versjonen kan hentes frem.
Den administrerte loggen er tydelig. Den selvhostede loggen krever noy sporing som de fleste team hopper over.
Slik forbedrer du selvhostet konsistens
Hvis selvhosting er nodvendig, kan du redusere avvik med fire trinn.
For det forste, fest modellversjoner. Lås eksakte modellversjoner i alle distribusjonfiler. Blokkere automatiske oppdateringer. Spor versjoner i kildekontroll.
Deretter, frys containerbilder. Bygg Docker-bilder med eksakte modellversjoner innebygd. Merk hvert bilde med modellversjonen, Presidio-versjonen og datoen. Ikke oppdater grunnbilder uten testing forst.
Bevar også konfigurasjon i kode. Lagre alle Presidio-innstillinger i filer sporet i versjonskontroll. Dette inkluderer detektorer, score-stokkler og aktive språk. Distribuer konfigurasjon med appen.
Test til slutt på tvers av oppsett. Etter enhver oppdatering, kjor et fast testdokumentsett gjennom det nye oppsettet. Sammenlign resultater med en lagret referanse. Automatiser denne sjekken. Se FAQ-en for vanlige sporsmal om automatisert PII-regresjonstesting.
Disse trinnene hjelper. Men de legger også til arbeid. En administrert tjeneste gir den samme konsistensen uten den ekstra innsatsen.
Konklusjonen
Konsistent PII-fjerning vises ikke på produktark. Men det blir kritisk når revisorer ber om bevis.
Uten aktiv omsorg driver selvhostede PII-verktoy av kurs. Versjonsendringer legger til stille gap. Disse gapene dukker opp som revisjonsfunn.
Administrerte tjenester gir konsistens som standard. Motoren kjorer fra ett sted. Brukeroppsett påvirker ikke resultater. For compliance-fokuserte team er dette en direkte fordel.