Model-agnostisk PII-detektion med LLM'er

De fleste virksomheder, der arbejder med GDPR-compliance i

De fleste virksomheder, der arbejder med GDPR-compliance i AI-systemer, kender problemet: en PII-detektor, der er trænet til at finde CPR-numre og telefonnumre, opdager ikke automatisk et nyt felt som "medarbejder-ID" eller "patientjournalnummer", medmindre nogen gentræner modellen fra bunden. En ny metode viser, at store sprogmodeller kan løse det problem ved simpelthen at få entitetstyperne beskrevet i en prompt, i stedet for at være hardkodet til bestemte kategorier.

PII-detektion

En detektor, der lærer nye datatyper på stedet

Traditionelle PII-detektorer bygger på faste lister af entitetstyper. Skal systemet finde en ny type følsom data, kræver det typisk ny træning, nye labels og en ny model i produktion. Det er dyrt, langsomt, og det holder ikke trit med, hvor hurtigt virksomheder ændrer på, hvilke data de behandler.

Den model-agnostiske tilgang vender problemet på hovedet. I stedet for at hardkode entitetstyper ind i modellens vægte, beskrives de i selve prompten, som instruktioner til en sprogmodel, der allerede er god til at forstå kontekst og betydning. Vil man have modellen til at finde "interne projektkoder" eller "kundenumre fra et bestemt CRM-format", skriver man det ind i prompten, og modellen begynder at genkende det, uden en eneste ny træningsrunde.

Det gør metoden relevant for enhver virksomhed, der behandler data, der ikke passer ind i de klassiske kategorier som navne, adresser og CPR-numre. Mange danske virksomheder har brancespecifikke identifikatorer, interne sagsnumre eller kundedata, der aldrig ville stå på en generisk liste over persondata, men som stadig er følsomme og GDPR-relevante.

Test

Testen mod ni etablerede detektorer

Metoden er afprøvet direkte op mod ni konkurrerende PII-detektionsværktøjer, en bred sammenligning der dækker både regelbaserede systemer og maskinlæringsmodeller af den type, mange virksomheder allerede har i drift. Testen kørte på Amazon Bedrock, hvor den prompt-baserede tilgang blev sat til at identificere samme sæt følsomme dataelementer som konkurrenterne, men uden forudgående træning på de specifikke datasæt. Tilgangen minder om en framework-agnostisk evalueringstilgang, hvor systemer sammenlignes på tværs af platforme frem for isoleret.

Resultatet var, at den model-agnostiske tilgang klarede sig bedre end alle ni sammenlignede systemer på nøjagtighed. Den pointe rykker ved en antagelse, mange har haft om PII-detektion: at specialisering slår generalisering.

Her er det generaliseringsevnen, sprogmodellens forståelse for kontekst og betydning, der giver den bedre træfsikkerhed, fordi den kan ræsonnere sig frem til, om noget er følsomt, i stedet for blot at matche mønstre.

Tilpasning

Hvorfor prompt-styring slår faste kategorier i praksis

Den afgørende forskel ligger i, hvor hurtigt systemet kan tilpasses. En hardkodet detektor er statisk: den kender de entitetstyper, den er trænet til, og intet andet. Skal den udvides, kræver det data, træning og validering, en proces der typisk tager uger.

Med en prompt-baseret tilgang bliver tilpasningen et spørgsmål om at omskrive instruktionen. Det betyder, at en virksomhed kan reagere på nye datatyper, nye regulatoriske krav eller nye interne standarder, uden at vente på en genudviklingscyklus. Det er en driftsmæssig fordel, der ikke kun handler om nøjagtighed, men om hvor hurtigt organisationen kan følge med sine egne data.

Vi ser den samme dynamik i andre dele af agentisk AI-arkitektur, hvor fleksibilitet i selve instruktionslaget ofte slår statiske, hardkodede komponenter. Det er et mønster, der går igen, når man arbejder med produktionsklare AI-systemer: jo mere logik man kan flytte ud i prompten eller politiklaget, jo lettere bliver det at holde systemet opdateret uden at ændre selve modellen eller infrastrukturen.

GDPR

Hvad det betyder for danske virksomheder med GDPR-krav

For danske virksomheder, der bygger eller drifter AI-systemer med adgang til persondata, er det praktiske spørgsmål ikke om PII-detektion er vigtigt, det er det, men om detektionslaget kan holde trit med, hvordan data faktisk ser ud i virksomhedens egne systemer. Mange organisationer opdager først under en GDPR-gennemgang, at deres eksisterende detektionsværktøjer ikke fanger de brancespecifikke eller interne datatyper, der reelt udgør en risiko.

Vi har set gennem større AI-projekter, at netop det led, fleksibel klassificering af følsomme data, ofte bliver overset i den indledende problemafklaring, og først dukker op som en hindring, når systemet skal i produktion under skærpede compliance-krav. En model-agnostisk tilgang løser det ved at flytte tilpasningen fra et teknisk projekt til en konfigurationsopgave.

Det ændrer også hvem der kan vedligeholde systemet. Når nye entitetstyper kan tilføjes via en prompt i stedet for en gentræningsproces, kan en compliance-ansvarlig eller en driftsansvarlig opdatere detektionslogikken uden at involvere et helt udviklerteam. For virksomheder, der arbejder med Amazon Bedrock som platform for deres AI-drift, er det en konkret mulighed for at styrke databeskyttelsen uden at bygge en ny detektionsmodel fra bunden hver gang forretningen ændrer sig.

01 / 01

Et øjeblik…

Henter spørgsmål…

1 / 4

Vælg ydelse

Henter ydelser…