By · Last updated 2026-06-04

Tilbage til BlogTeknisk

Reproducerbar privacy: ML-forudindstillinger

Anonymisering af ML-træningsdata skal være konsistent og reproducerbar. Hvis datavidenskabsmænd A og B anvender forskellige entitetstyper, er træningsdatasæt.

June 4, 20266 min læsning
ML training datareproducible privacyGDPR AI ActCNIL enforcementdata science compliance

Reproducerbar privacy: Hvorfor ML-teams har brug for forudindstillinger, ikke bare dokumentation

DPO'en godkendte anonymiseringsplanen. Den dækker fire punkter: navne, e-mails, telefonnumre og fødselsdatoer. Metoden er Erstat. Planen er fire sider og lever i compliance-wikien.

Tolv datavidenskabsmænd læste den ved kickoff. Hver opsatte værktøjet på egen hånd. Nogle tilføjede national-ID'er. Nogle tilføjede IP-adresser. Nogle skiftede til Redigér. Tre måneder senere er sættene ikke konsistente.

CNIL kontrollerede flere AI-virksomheder i 2024. Problemet: forkert brug af personoplysninger i modelsæt. De spurgte ikke bare om, hvorvidt anonymisering skete. De spurgte, hvor konsistent den blev anvendt.

Dokumentation er nødvendig. Det er ikke nok. Løsningen er forudindstillingen.

Hvorfor ML-modelsæt har brug for deres egen konfiguration

Opbygning af modelsæt har unikke behov. Generel dokumentanonymisering deler dem ikke.

Erstat, ikke Redigér. Modeller trænet på tekst, hvor navne bliver [REDACTED], lærer det token som et navnpositionmarkør. Dette skader modellen. Erstat bytter "John Smith" med "David Chen." Modellen ser rigtige navnemønstre. Den ser ikke et masketoken.

Samme proces for alle poster. Et sæt, hvor 70 % af navnene er erstattet og 30 % er [REDACTED], sender blandede signaler. Hver post skal gennemgå de samme trin.

Samme entitetsliste. Hvis sættet indeholder sundhedsoplysninger, vil fjernelse af navne, men at lade fødselsdatoer blive i nogle poster, skabe huller. Alle tolv datavidenskabsmænd skal fjerne de samme typer.

Ingen overfjernelse. At fjerne datoer, der er tidsstempler — ikke fødselsdatoer — reducerer sætkvaliteten uden compliancegevinst. Den godkendte forudindstilling siger præcist, hvilke elementer der skal fjernes.

Reproducerbart output. Hvis et sæt skal køres igen — siger vi, efter at en manglende entitetstype er fundet — giver forudindstillingen det samme resultat hver gang. Ad hoc-konfigurationer gør det ikke.

Problemet med tolv datavidenskabsmænd

Et fintech ML-team i Europa bruger sæt fra kundelogs. DPO'en godkendte formålet — svindeldetektering — med én regel: alle kundenavne, e-mails, telefonnumre og betalings-ID'er skal erstattes, inden modelarbejde starter.

Uden forudindstillinger:

  • Person 1 fjerner navne, e-mails og telefonnumre — men overser betalings-ID'er
  • Person 2 inkluderer betalings-ID'er, men bruger Redigér, ikke Erstat
  • Person 3 følger plandokumentet nøjagtigt
  • Personerne 4–12 varierer

Det fusionerede sæt er delvist ikke-compliant og delvist overbehandlet. En DPO kan ikke certificere det.

Med en DPO-godkendt forudindstilling:

  • DPO'en opretter "ML Dev — Svindeldetektering" med præcise entitetstyper og erstatningsmetoden
  • Forudindstillingen distribueres til alle tolv med én regel: brug denne til alt sætarbejde
  • Ingen kan ændre forudindstillingen uden DPO-godkendelse

Hver person producerer nu det samme output. Det fusionerede sæt er konsistent. Den årlige AI-revision består med nul fund. Det foregående år havde tre fund fra inkonsistent sætarbejde.

GDPR og AI Act

Opdateret for 2026

EU AI Act trådte fuldt i kraft i august 2024. Det tilføjer regler for AI-systemer, der bruger personoplysninger til modelarbejde. Høj-risiko AI-systemer skal dokumentere deres sæt, herunder hvilken anonymisering der blev anvendt.

GDPR Artikel 5(1)(b) — formålsbegrænsningsreglen — blokerer brug af personoplysninger uden et klart retsgrundlag. CNILs sager fra 2024 fokuserede på dette hul: oplysninger indsamlet til én tjeneste, brugt til modelarbejde uden gyldigt grundlag eller anonymisering.

Forudindstillinger hjælper med at opfylde begge sæt regler:

  • Forudindstillingens navn og konfiguration: den dokumenterede metode
  • Behandlingslogge: bevis for, at metoden blev anvendt
  • DPO-godkendelse: en registreret godkendelse af konfigurationen

Dette skaber det revisionsspor, begge love kræver. For Artikel 10-forpligtelser i detaljer, se EU AI Act-guiden til træningsdata.

Forudindstillingskonfiguration til NLP-modelsæt

Typer at inkludere i de fleste NLP-modelsæt:

  • PERSON — Erstat med lignende navne
  • EMAIL_ADDRESS — Erstat med syntetiske adresser
  • PHONE_NUMBER — Erstat med syntetiske numre
  • CREDIT_CARD / IBAN — Erstat eller Redigér
  • LOCATION — Erstat med lignende steder, hvis placering er relevant; Redigér, hvis ikke
  • DATE_OF_BIRTH — Redigér; aldersgruppering er ofte nødvendig

Typer der ofte udelades:

  • Generelle datoer — tidsstempler hjælper temporale modeller
  • Organisationsnavne — hjælper navngivne-entitetsmodeller
  • URL'er — hjælper link- og referencemodeller

ML-lederen og DPO'en fastlægger disse regler i den godkendte forudindstilling. Teammedlemmer anvender den. De træffer ikke konfigurationsvalg.

Forudindstillinger som institutionel hukommelse

Før forudindstillinger. Den rette entitetskonfiguration levede i hovederne på tre datavidenskabsmænd. De havde arbejdet sig igennem compliancegennemgangen. To forlod i Q3. Viden fulgte med dem.

Efter forudindstillinger. Konfigurationen lever i "ML Dev — Kundejournaler v2.1." Versionsloggen viser, hvornår den blev oprettet, hvem der godkendte den, og hvad der ændrede sig fra v2.0. Nye teammedlemmer bruger forudindstillingen og får al den viden, der er bygget ind i den.

Version 2.1 tilføjede IBAN-detektion efter en gennemgang fandt, at den manglede. Version 2.0 blev godkendt i februar 2025. Loggen er komplet.

For hvordan behandlingslogge og DPO-gennemgangsflows fungerer, se GDPR ML-træningsanonymiseringsguiden.

Forudindstillinger vs. CNIL-mønsteret

CNILs AI-sager fra 2024 fastlagde et klart mønster. De spørger ikke bare hvad der blev fjernet, men hvordan det blev styret. En delt forudindstilling med en DPO-godkendelsesregistrering og behandlingslogge besvarer dette direkte.

En ad hoc-konfiguration gør det ikke. Det samme hul eksisterer i andre EU DPA-sager, der følger CNIL-logikken. For mere om CNILs AI-tilgang, se CNIL GDPR AI-complianceguiden.

Konklusion

Dokumentation fortæller teammedlemmer, hvad de skal gøre. Forudindstillinger gør det nemt — og håndhæveligt — at gøre det på samme måde hver gang.

For ML-modelsæt er konsistens både et juridisk behov og et teknisk. Forudindstillingen opfylder begge på én gang.

DPA'er, der ser på AI-praksis, ønsker bevis for ensartet anonymisering. En forudindstilling, der anvendes på samme måde på tværs af alt sætarbejde, er det klareste bevis, du kan give dem.

Kilder

Klar til at beskytte dine data?

Begynd at anonymisere PII med 285+ enhedstyper på tværs af 48 sprog.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.