PII Masking Architecture

1. Overview

LegalDocs-Assist processes insurer correspondence and case details using AI to generate legal analysis and draft responses. To support UK GDPR data-minimisation principles (Article 5(1)(c)), the platform implements a three-layer privacy and integrity architecture:

2. Layer 1, Text handling of source documents

Text‑based PDFs are read in the user's browser using pdfjs-dist (Mozilla's PDF.js) and only the extracted text is transmitted, for the drafting tools and for the Witness Statement document slots alike. Word and plain‑text documents submitted to the document slots are reduced to text on the server and masked before any AI processing. Three documented exceptions apply where an original file does reach the server: (i) scanned or image‑only documents, briefly processed so the text can be read at all; (ii) photographs and audio recordings submitted to the document slots, which the AI reads directly because there is no text to mask first; and (iii) the Medical Pagination tool (see 2.1). All exception paths run under Zero Data Retention terms, prompts and outputs are not stored by the AI provider, and the platform's automated deletion controls apply.

2.1 Medical Pagination Exception

The Medical Pagination tool is a documented exception to browser‑side parsing. Because medical bundles are typically scanned PDFs that require server-side OCR to produce an indexed bundle, the source PDF is uploaded to encrypted storage for processing. Retention is tightly scoped:

• As soon as the paginated bundle is produced, the source medical PDF is deleted from storage.
• The output bundle is held for one hour so the user can download it, after which it is deleted automatically.
• Nothing is kept beyond that window.

The Medical Pagination function does not invoke the PII Masking Gateway, because the function produces a navigable bundle rather than sending free text to an AI model.

2.2 Document-Slots Extraction (July 2026)

The guided intake posts documents for structured field extraction. Text‑bearing documents pass through the masking gateway with a reversible map before the model call: the model sees neutral placeholders, and the extracted fields are restored to their real values on the server afterwards. The model never sees the unmasked text of these documents. Scanned documents, photographs and audio recordings are the exception class described above. From 24 July 2026 the gateway also masks HMRC tax identifiers (Unique Taxpayer References and PAYE references), added ahead of tax return uploads through the loss-of-profit slot.

3. Layer 2, PII Masking Gateway

3.1 Architecture

The masking gateway (piiRedactor.ts) is a shared server-side module invoked by every AI-facing Edge Function before any text is sent to the language model. Every AI‑facing function that receives text invokes the masking gateway before the model call; there is no text path that bypasses it. Inputs that arrive as scans, photographs or audio cannot be masked before reading, because masking requires text. Those paths are documented exceptions protected by Zero Data Retention terms and automated deletion, and any structured fields they produce are masked again in later drafting steps.

3.2 Data Categories Detected

The gateway attempts to detect and mask the following UK-specific identifier types:

3.3 Processing Order

Patterns are applied in a specific sequence (most specific first) to prevent partial matches or false positives:

1. Emails → 2. NINOs → 3. NHS Numbers (Mod-11 validated) → 4. UTR (check-digit validated) → 5. PAYE References → 6. Driving Licences → 7. VRMs → Postcodes preserved (see 3.2) → 8. Phone Numbers → 9. DOBs → 10. IBANs → 11. Card Numbers (Luhn-checked) → 12. Sort Codes → 13. Bank Account Numbers → 14. References → 15. Addresses → 16. Titled Names → 17. Bare Names in high-precision contexts (field labels, salutations, sign-offs). An aggressive output-side re-scrub then runs on AI responses to catch bare First-Last name pairs that slipped past the input gateway, with guards for case citations and company names.

3.4 Logging

Each invocation logs the count and types of items masked (e.g. PII redaction: 3 items redacted (types: EMAIL, VRM, PHONE)). No original PII values are logged.

4. Integration Points

The PII Masking Gateway is invoked in the following backend functions. Each function is listed with the user-facing path that triggers it, so a reviewer can map the architectural claim onto the deployed product surface.

Every AI‑facing function that receives text invokes the masking gateway before the model call; there is no text path that bypasses it. Inputs that arrive as scans, photographs or audio cannot be masked before reading, because masking requires text. Those paths are documented exceptions protected by Zero Data Retention terms and automated deletion, and any structured fields they produce are masked again in later drafting steps.

5. GTA vs Case Law Data Separation

The platform enforces strict separation between GTA protocol data and case law:

This ensures GTA claims receive advice grounded solely in GTA protocol and rate tables, while non-GTA claims receive case law citations. The separation prevents cross-contamination of authority sources and reduces hallucination risk.

EV Handling Under GTA

Electric vehicles not listed in standard GTA rate tables are mapped to ICE equivalent groups with mandatory explanatory notes. Accident dates are preserved as non-identifying data.

6. Anti-Hallucination Controls

7. Limitations & Honest Framing

The platform UI and Privacy Policy use deliberately honest language:

• "attempts to mask", acknowledges that pattern‑based detection cannot catch every possible PII format. We do not claim full redaction, 100% coverage, or guaranteed removal.
• "where detected", frames the capability as best-effort pattern matching, not absolute removal.
• Automated safety net, the masking gateway is a mandatory server-side processing step. Users are not required to manually redact documents before upload.

Known Limitations

• Names: Titled names (Mr, Mrs, Ms, Miss, Dr, Prof plus surname) are always masked as [NAME_REDACTED]. Bare / untitled names are masked when they appear in high-precision contexts — structured field labels (Claimant:, Driver:, Insured:, Witness:), letter salutations and sign-offs. An aggressive output-side re-scrub catches bare First-Last pairs in AI responses, guarded against case citations (X v Y) and known organisation names. A bare name buried in free prose with no surrounding cue may pass the input gateway, but remains a candidate for the output re-scrub. The Witness Statement Generator is a deliberate carve-out: it skips masking of names, vehicle registration marks and reference numbers on its inputs, because a statement must attribute evidence and identifiers verbatim; all other categories are masked and the system-prompt overlays pass through the same redactor.
• Novel Formats: Unusual or non-standard reference numbers may not match existing patterns.
• Contextual Data: Information that is only personally identifiable in combination (e.g. "the claimant's blue Ford Focus") is not masked, as it requires semantic understanding beyond regex capability.

8. Data Flow Summary

9. Regulatory Alignment

10. Validation Evidence

The PII masking gateway has been tested against a controlled suite of dummy UK PII samples across the categories listed in Section 3.2. The test report is available for due diligence review on request. Re-validation is performed after any change to the pattern set.

11. Recommendations for Further Hardening

• Periodic Pattern Review: Review and update regex patterns quarterly as new identifier formats emerge.
• Ongoing Validation: Re-run the PII masking test suite after each pattern update to maintain documented evidence of effectiveness.
• DPIA Integration: Reference this document and the PII masking test report in the platform's Data Protection Impact Assessment.