GDPR-dataminimering: Realtids-API
Opdateret til 2026
GDPR Artikel 5(1)(c) siger: indsaml kun det, du har brug for. Dette er reglen om dataminimering. De fleste teams bryder den gennem formulardesign, ikke dårlige hensigter. Fritekstfelter trækker navne, adresser og ID-numre ind, som ingen planlagde for.
Rensning af databasen bagefter løser det ikke. Overtrædelsen skete, da du indsamlede dataene. At stoppe det ved kilden er den eneste reelle løsning. En realtids-API-kontrol ved formularindsendelse stopper overindsamling, inden den starter.
Se vores complianceoversigt og sikkerhedspraksis for, hvordan vi understøtter GDPR Artikel 5.
Hvorfor formularer overindsamler
Fritekstfelter i webapps samler PII, som ingen planlagde for:
- Supportbillet "årsag"-felter udfyldt med medicinsk historik og forsikringsnumre
- Undersøgelsens "andre kommentarer"-sektioner med fulde navne og telefonnumre
- HR "noter"-kolonner med års ustrukturerede personoplysninger
- Bestillings "noter"-felter med kundID-numre indtastet for at hjælpe med problemer
Minimeringreglen kræver, at denne PII aldrig kommer ind i dine systemer. Retroaktiv rensning behandler symptomet. Realtidsdetektion fjerner årsagen.
Hvorfor retroaktiv rensning er utilstrækkelig
Teams, der renser gemte PII, står over for fire problemer.
Fuldstændighed. Mønstermatchning finder åbenlys PII som e-mailadresser og ID-numre. Det misser kontekstbaserede referencer. "Min søster Sophie havde det samme problem" indeholder et navn, som de fleste skanninger springer over.
Juridisk timing. Overtrædelsen sker ved indsamling. At rense dataene måneder senere løser det ikke. Hvis en regulator gennemgår den periode, hvor dataene var opbevaret, er bruddet allerede registreret.
Ufuldstændig sletning. Databaser sikkerhedskopieres. Systemer skriver logge. Analyseværktøjer eksporterer data. Selv efter du sletter fra hoveddatabasen, kan kopier forblive i sikkerhedsfiler og revisionslogge.
Brudeksponering. Mellem indsamling og rensning sidder den ekstra PII i dine systemer. Et brud i det vindue sætter de overindsamlede data i spil.
At stoppe indsamling ved kilden løser alle fire. Data, der aldrig kommer ind, kan ikke bringes til brud, behøver ikke sletning og tæller ikke som overtrædelse.
Detektionsmønstre til formularvalidering
Der er tre måder at tilføje realtids-PII-detektion til en formular.
Klientside (Chrome-udvidelse). Udvidelsen overvåger indsæt-hændelser i browserfelter. Når en bruger indsætter tekst med PII, fremhæver den entiteterne med det samme. Brugeren fjerner dem inden indsendelse. Ingen API-kald er nødvendig — detektion kører lokalt. Se ordlisten for definitioner af entitetstyper.
Serverside (API-integration). Formularen sendes til din server. Inden databaseskrivning kalder din kode detektion-API'en. API'en returnerer entitetstyper med konfidensscore. Høj-konfidensmatches blokerer indsendelsen med en klar besked. Mellemkonfidensmatches anmoder om et gennemgangsrtrin. Data er rene, inden de gemmes.
Hybrid (anbefalet). Klientside-fremhævning giver brugere hurtig feedback. Serverside-kontroller giver compliancegarantien. Hvis en bruger ignorerer klientadvarslen, griber serverkontrollen stadig PII'en. Intet når databasen ukontrolleret. Se vores FAQ for hyppige spørgsmål om detektionstærskler.
Eksempel: Sundhedsvæsenets patientportal
En patientportal lader patienter beskrive deres symptomer i et fritekstfelt inden bestilling. Feltet modtager regelmæssigt oplysninger, der inkluderer andre patienters navne, ID-numre og hjemadresser. Intet af dette hører hjemme i planlægningssystemet.
Før realtidsdetektion:
- PII i symptomfeltet: ca. 12 % af indsendelserne
- Oprydningsmetode: ugentlig batchproces
- Compliancestatus: reaktiv — Artikel 5(1)(c)-overtrædelsen skete ved indsamling
Efter API-integration ved indsendelse:
- API'en registrerer høj-konfidens PII inden nogen skrivning til databasen
- Patienten ser: "Din besked ser ud til at indeholde personoplysninger. Fjern det venligst inden indsendelse."
- Patienten reviderer og genindsender
- Databasen modtager kun symptombeskrivelsen
I dette scenarie faldt PII i feltet fra ca. 12 % til under 1 % af indsendelserne. Compliance demonstreres nu through serverside-detektionslogge snarere end retrospektive renseafviklinger.
Revisionsregistre ved indsamlingspunktet
Regulatorer behandler reaktive teams anderledes end dem med kontroller på plads. GDPR Artikel 25 — beskyttelse ved design og som standard — belønner sidstnævnte.
Indsamlingspunkt-detektion skaber nyttige revisionsregistre:
- Detektionslog. Hver formularscanning gemmes med fundne entitetstyper, konfidensscore, foretaget handling og resultat.
- Månedlige rapporter. Resuméer viser detektionsrate pr. felt og entitetstype, og hvordan brugerne reagerer.
- Konfigurationsregistre. Tærskelindstillinger, dækkede felter og overvågede entitetstyper — dette viser en klar, styret politik.
Disse registre hjælper i regulatorgennemgange. De understøtter også intern revision og behandlingsregistre. Se vores casestudier for eksempler på indsamlingspunktskontroller i praksis.
AI-værktøjer og dataminimering
Supportagenter indsætter ofte kundemails i AI-utkastningsværktøjer. Disse mails kan indeholde navne, adresser og kontonumre. At sende det til en AI-model kan gå ud over, hvad der er nødvendigt.
MCP-serveren tilføjer et detektionstrin, inden teksten når modellen. Kundenavne bliver [KUNDE]. Specifikke detaljer renses. AI'en udkaster et svar ved hjælp af den rensede tekst. Agenten tilføjer kun det tilbage, som svaret har brug for.
Dette opfylder dataminimeringsreglen for AI-brug. Modellen får kun det nødvendige — hvilket normalt slet ikke er PII. Se entiteter for den fulde liste over entitetstyper vi registrerer.