PIIRemover — Redaction, Off the Critical Path

Sheet PII-01 · Rev A · Status: Proof of Concept · 2026-07-31

A local-first PII detection and redaction core. The proof of concept show how to turn document redaction from a bottleneck on GDPR, FOI, and Subject Access Request deadlines into a review task instead of a search task.

01 — The problem it solves

A Subject Access Request or Freedom of Information request doesn't arrive with a page limit. A data protection officer gets a folder of contracts, emails, scanned intake forms, and case notes, and a statutory clock already running — thirty days for a SAR under UK GDPR, twenty working days for an FOI request. Redaction today mostly means someone reading every page by hand, drawing black boxes in a PDF tool, like Adobe Acrobat Pro. The issue with this approach is the quality of output can be variable as this mundane task makes it hard for trained experts to be right all of the time. Added to this, recoverable names or account numbers in a "redacted" disclosure is a data breach.

PIIRemover is a working prototype of the part of that process a machine is actually good at: finding candidate PII across a whole document set in seconds, and producing an export that is provably redacted rather than just visually covered. The human still decides what goes — the tool just stops making them read every line to find it.

02 — What's actually running

Everything runs locally, with no network access — the detection core has no cloud dependency, which matters specifically here: SAR and FOI bundles are the personal data the regulation exists to protect, so a tool that phones a third-party API with documents you're redacting requires a lot more scrutiny from a Data Impact Assessment perspective.

Detection combines two layers. A dependency-free regex + validator layer catches direct identifiers with no ambiguity — email, US SSN, credit card (Luhn-checked), phone, IP, IBAN. On top of that, an optional contextual NER pass (Presidio + spaCy) auto-activates when installed, catching the harder cases regex can't — a person's name in a signature block, a location embedded in prose. Scanned pages and images go through Tesseract OCR first, producing word-level bounding boxes so PII inside a scan is detected and redacted with the same precision as born-digital text.

Ingest (txt/md/PDF/scan/image)
        │
        ▼
   OCR (scans only) ──> word boxes
        │
        ▼
   Detect: regex+validators  ∥  Presidio+spaCy NER
        │
        ▼
   Merge & score findings ──> side-by-side review
        │                      accept / reject / manual redact
        ▼
   Export: burn in redactions, rasterize page
        │
        ▼
   Verify: assert zero extractable text ──> pass/fail gate

The export step is where you can be sure the data underneath is inaccessible: every redacted file is a flattened, rasterised PDF — pixels, not text — so there is no text layer left to select, copy, or recover. That's not a UI setting; for PDF sources it drops the original text layer entirely. And it isn't taken on trust: verification re-opens the export and asserts it contains no extractable text before the tool calls the job done. That check is the safety gate a compliance sign-off actually needs — not "we drew a box over it," but "we opened the output and there is nothing there."

03 — What ships from one review pass

Scan	JSON findings — entity type, matched text, character span, confidence, which detector fired — across text, PDF, scanned PDF, and images.
Review	Side-by-side original vs. flagged replica, color-coded by entity type; accept/reject per finding; drag-to-add manual redactions for anything a detector missed.
Redacted export	Flattened, rasterized PDF per document — no text layer, nothing extractable, regardless of source format.
Findings report	A separate CSV/JSON audit trail of what was redacted, by type and location — for the file that goes to the requester and the file that proves what left the building.
Projects	Named projects group many documents on disk, each with persistent review state — decisions survive a restart, so a large disclosure bundle doesn't have to be reviewed in one sitting.

04 — Where the time actually comes back

A single redacted PDF is a demo. The real question for a SAR/FOI team is what changes when the bundle is forty documents instead of four, due in thirty days.

01 — Detection turns "search" into "review." Reading a hundred-page bundle to find PII is the slow part; deciding whether a flagged span should actually be redacted is fast. Moving the human from the first job to the second is most of the time saving, before anything about automation-per-se.

02 — Batch scan works across a whole disclosure bundle, not one file at a time. A project holds every document for a request — scan-all runs detection across the entire set in one pass, and the document table shows exactly which files are still pending, scanned, reviewed, or redacted, so nothing in a forty-file bundle gets forgotten under deadline pressure.

03 — The verification gate replaces "did we definitely get it all" with a yes/no answer. Instead of a second reviewer manually re-checking a redacted PDF for leaks — the traditional QA step before disclosure — the export step itself asserts programmatically that zero text is extractable. That's a check a person doesn't have to perform by eye, on every page, every time.

04 — The findings report is the audit trail regulators ask for. A SAR/FOI response often needs to show what was withheld and why, separate from the response itself. The report is generated as a byproduct of review, not as a follow-up task someone has to reconstruct afterward.

05 — Local-only processing removes a governance blocker, not just a nice-to-have. For a public body or legal team. Running with networking disabled and no telemetry of document content is what gets the tool is the easiest way to compliance.

The honest framing. This isn't a "redact everything automatically" tool — high recall is deliberately prioritised over precision, so it will over-flag, and review stays mandatory by design. The saving is in collapsing "find every instance across N documents" into "confirm or dismiss what's already flagged," and in replacing a manual leak-check with an automated one. Median review time per document is exactly the kind of number this PoC should be timed on next, not asserted from here.

05 — What this is not, yet

It's a Phase-1–5 prototype (per the PRD's own phasing), and the gaps matter for the specific SAR/FOI use case:

Deferred	Why it matters here
UK NINO / passport / driver's licence recognisers	The current regex layer validates US SSN, credit card, email, phone, IP, IBAN — not yet UK National Insurance Numbers, which is the direct identifier a UK SAR/FOI redaction most often needs.
.docx ingestion	Case notes and correspondence are often Word files; today they'd need converting to PDF/text first.
GLiNER custom labels / optional local-LLM pass	The PRD's harder contextual categories (job title + employer combinations, medical conditions, vehicle registrations) aren't wired in yet — today's contextual layer covers PERSON/LOCATION via Presidio+spaCy.
Allow/deny lists, custom regex, per-type toggles in the UI	Needed before a team can tune the profile per request type (e.g. always redact case IDs, never redact the requester's own name).
Desktop packaging (Tauri/Electron)	The browser UI is the MVP; a caseworker runs it as a local web server today, not a signed native app.
Legal/compliance certification	This is explicitly an assistive tool, not a compliance guarantee — the PRD is direct about that, and any rollout plan should be too.

None of these are architectural blockers — the detection/redaction core, the review UI, and the verification safety gate are proven, and that part already runs headlessly, is unit-tested, and produces a provably clean export today.

---

PIIRemover · PoC — local web UI at python3 -m piiremover serve (127.0.0.1:8765) — Sheet PII-01, Rev A