anonym.legal

By · Last updated 2026-06-05

Tilbage til BlogTeknisk

Dokumentformatfragmentering i PII-værktøjer

Et enkelt DSAR-svar kan spænde over Word-kontrakter, PDF-fakturaer, Excel-kundelister og CSV-eksporter. Brug af forskellige værktøjer til hvert format skaber overensstemmelsesgab.

June 5, 20267 min læsning
document formatsPDF anonymizationExcel GDPRbatch processingDSAR compliance

Problemet med flere formater i PII-compliance

Opdateret for 2026

Spørg en compliance-medarbejder, hvilke formater de anonymiserer til DSAR-svar. Listen er altid den samme: Word-kontrakter, PDF-fakturaer, Excel-kundedata, CSV-eksporter og JSON-logfiler.

Spørg derefter, hvilke værktøjer de bruger. Svaret er normalt tre til fem. Hvert værktøj har forskellig enhedsdækning. Hvert har forskellige indstillinger. Hvert producerer en anden revisionslog.

Dette er formatfragmentering. Det skaber reelle overensstemmelsesgab.

Hvorfor fragmentering opstår

Intet enkelt værktøj har håndteret alle produktionsformater med samme kvalitet. Specialiserede værktøjer opstod til hvert format. Et til PDF'er. Et til regneark. En makro til CSV. Hvert har sin egen enhedsliste. Ingen deler en revisionssti.

Resultatet er forudsigeligt. Et DSAR-svar spænder over flere filtyper. Flere værktøjer behandler det. Hvert værktøj bruger forskellige standarder. Enhed X opdages i PDF'en, men overses i Excel-filen. DPA-revisioner afslører denne inkonsistens.

Formatspecifikke tekniske udfordringer

Hvert format skaber sine egne detektionsproblemer.

PDF

PDF'er kommer i to typer: native tekst og billedbaserede scanninger. Scannede PDF'er kræver OCR først. OCR introducerer fejl. Native PDF'er gemmer ofte hvert ord som et separat tekstobjekt. Dette bryder enhedsdetektionen på tværs af ordgrænser. Flerkolonne-layouts kræver rekonstruktion af læserækkefølge, inden analyse kan begynde.

Word (DOCX)

DOCX-filer indeholder tekst i XML. Men også i sidehoved, sidefod, kommentarer, sporerede ændringer og tekstbokse. En brevhovedadresse i sidetopfen er persondata. De fleste værktøjer overser den. Sporerede ændringer kan indeholde slettet persondata. Den tekst er usynlig i den renderede visning, men til stede i filen.

Excel (XLSX)

Excel gemmer persondata på tværs af enhver celle i hundredvis af kolonner og tusinder af rækker. Kolonneoverskrifter som "CPR" eller "E-mail" giver kontekst, som NER-modeller overser fra råtekst. Datoer og CPR-numre er ofte gemt som tal. Fritekstfelter som "ledernoter" indeholder ustruktureret persondata. Kolonnebaserede værktøjer springer disse felter over.

CSV

CSV mangler Excels struktur. Fritekstfelter i "noter"-kolonner blander persondata med andet indhold. Kodningsproblemer — UTF-8 versus Latin-1 — forårsager fejl for ikke-ASCII-tegn i europæiske navne og adresser.

JSON

Nested JSON begraverer persondata dybt: user.address.street.line1. Arrays kræver iteration. Det samme feltnavn kan indeholde forskellige datatyper i forskellige objekter. God detektering kræver skema-bevidsthed og indholdsanalyse tilsammen.

Inkonsistens er en juridisk risiko

Her er et konkret GDPR DSAR-scenarie.

En registreret anmoder om alle persondata, der er gemt om dem. Compliance-teamet finder disse filer:

  • 3 Word-dokumenter (kontrakter, korrespondance).
  • 2 PDF-dokumenter (fakturaer, supportudskrifter).
  • 1 Excel-regneark (kundekontodata).
  • 1 CSV-eksport (systemadgangslogfiler).

De bruger Værktøj A til PDF'er. Værktøj B til Word. En makro til XLSX. Manuel gennemgang til CSV. Hvert værktøj har forskellig enhedsdækning.

Den registrerede modtager den anonymiserede pakke. Excel-kolonnen "ledernoter" blev ikke behandlet. Word-brevhovedadressen blev overset. Begge indeholder persondata, som den registrerede bad om at få anonymiseret.

Under GDPR artikel 15 (ret til indsigt) eller artikel 17 (ret til sletning) er dette et ufuldstændigt DSAR-svar. Hvis den registrerede eller en tilsynsmyndighed finder gabet, er den inkonsistente brug af værktøjer en dokumenteret medvirkende faktor.

Argumentet for en ensartet standard

Stærk DSAR-compliance angiver ikke blot, hvilke PII-typer der skal anonymiseres. Det kræver den samme standard på tværs af alle formater i svarsættet.

Det betyder:

  • Samme enhedstyper kontrolleret i Word, PDF, Excel, CSV og JSON.
  • Samme konfidenstærskler anvendt på alle filer.
  • Samme erstatnings-tokens brugt. Hvis "Jens Hansen" optræder i tre dokumenter, erstatter ét token navnet i alle tre.
  • Ét revisionsnotat dækkende alle formater.

En enkelt-platform-løsning gør dette muligt via forudsætninger. Én "DSAR EU Individer"-forudsætning kontrollerer de samme 32 enhedstyper. Den kører på en PDF-kontrakt, en Excel-post og en CSV-log. Den samme motor behandler alle tre.

For mere om, hvordan forudsætninger fungerer på tværs af batch-job, se vores guide til GDPR DSAR-batchbehandling i stor skala.

Batchbehandling af blandede formatsæt

GDPR-compliance i stor skala betyder behandling af mapper med blandede formater som en enhed.

Input: En mappe med 15 filer — PDF'er, DOCX, XLSX, CSV — der repræsenterer alle data gemt for én registreret.

Behandlingstrin:

  • Detekter formatet på hver fil.
  • Anvend den rigtige parser. PDF-tekstudtræk. DOCX XML-parsing. XLSX-cellegennemløb. CSV-feltparsing.
  • Kør den samme NLP-pipeline på udtrukket tekst fra alle filer.
  • Anvend den samme forudsætning på hver fil i batchen.
  • Brug en delt token-pulje. Det samme navn får det samme erstatnings-token på tværs af alle 15 filer.

Output:

  • Anonymiserede versioner af alle 15 filer i deres originale formater.
  • Én tværformat-revisionsrapport. Den viser hver detekteret enhed, dens kildedokument, dens konfidensscor og den trufne handling.

Den revisionsrapport er compliance-dokumentet. Det beviser, at alle 15 filer blev behandlet med den samme standard. For en DPA-revision er dette langt stærkere end stykkevis brug af værktøjer.

Relateret: real-tids PII-forebyggelse for AI-datalækager.

Kendte begrænsninger ved samlede pipelines

Formatsamling løser fragmentering. Men det introducerer sine egne begrænsninger.

Konverteringsnøjagtighed: Konvertering af DOCX til et behandlingsformat og tilbage kan miste sporændringers historik eller beskadige indlejrede objekter. Juridiske dokumenter kræver ekstra validering efter behandling.

Per-format vedligeholdelse: Enhedsgenkendere til CSV adskiller sig fra dem til scannede formularer. En "samlet" pipeline kræver stadig per-format forbehandling. Den forbehandling skal opdateres, efterhånden som formater udvikler sig.

Nøjagtighed på ualmindelige formater: De fleste NLP-modeller træner på webtekst og almindelige kontordokumenter. Ældre formater — gamle EDI-filer, tilpassede XML-skemaer, CAD-metadata — producerer ofte dårligere nøjagtighed end benchmarks antyder.

Ikke-rekonstruerbare formater: Visse PDF-typer og kun-billedfiler kan ikke anonymiseres på stedet. De kræver visuel redigering. Visuel redigering ødelægger maskinlæsbar struktur. Hvis du har brug for søgning eller indeksering efter anonymisering, kan dette komme til kort.

Praktisk DSAR-arbejdsgang

For compliance-teams med regelmæssige DSAR-mængder:

  1. Saml alle dokumenter for den registrerede
  2. Opret en DSAR-batch — træk alle filer ind uanset format
  3. Vælg forudsætningen "DSAR EU Individer"
  4. Kør batchen
  5. Download anonymiserede outputs og den samlede revisionsrapport
  6. Stikprøvekontroller to eller tre dokumenter fra outputtet
  7. Pak de anonymiserede dokumenter til den registreredes svar
  8. Vedhæft revisionsrapporten til DSAR-sagens record

Trin 1 (manuel indsamling) er stadig den største tidsomkostning. Trin 2 til 8 tager under 10 minutter for en typisk batch. Revisionsrapporten fra trin 5 opfylder GDPR's ansvarlighedsprincip.

anonym.legal håndterer DOCX, PDF, XLSX, CSV og JSON. Hver fil bruger den samme forudsætning. Én revisionsrapport dækker batchen.

Kilder

Relaterede Artikler

Teknisk

Cross-Platform PII: Mac, Linux, and Windows

Privacy officers on Mac, legal on Windows, data engineers on Linux — all processing the same data with different tools. Here's why OS-agnostic detection.

Teknisk

Cross-Application PII: Word, Chrome, and AI

Customer data flows from browser research to Word drafts to Claude prompts. Each context switch is a potential leakage point.

Teknisk

GDPR in App Logs: JSON PII Compliance

Application logs contain customer email addresses, IPs, and account numbers that GDPR Article 5(1)(e) requires be managed.

Klar til at beskytte dine data?

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

Start Gratis PrøveperiodeSe Funktioner

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.