Data Redaction Guide 2026: Mask PII for GDPR and AI

Every payslip, contract, exit interview transcript, and customer email your team handles contains personal data that must be removed before the document is shared, archived, or fed to an AI model. Data redaction — the deliberate removal of personally identifiable information (PII) from documents — is no longer a niche compliance chore. It is the operational gate that determines whether your firm can use generative AI safely, share files with third parties without breaching the GDPR, and survive a supervisory authority inquiry without producing logs you wish you had never written. PII redaction (also written pseudonymisation in UK English, or document anonymization when the result is permanent) is the umbrella term we will use throughout this guide.

This guide is the long-form reference we wish existed when we built Redactic. It covers what data redaction actually is and is not, how the GDPR frames it (Article 4 pseudonymization versus Recital 26 anonymization), the two redaction modes you will use in practice, the PII categories that absolutely must be masked before any AI use, a five-step workflow that scales from a single PDF to a multi-sheet payroll spreadsheet, the real GDPR risk of shadow AI inside professional services firms, an eight-point checklist for choosing a redaction tool, and a FAQ with the questions clients ask us every week.

You can read the whole article top to bottom — it is written to be skimmable — or jump to the section that matches your immediate problem. If your firm has already had the "what do we do about ChatGPT" conversation and lost it, start with the shadow AI section. If your worry is supervisory authority inspections, start with the GDPR framework.

1. What data redaction is — and what it is not

Data redaction is the process of identifying personal or otherwise sensitive information inside a document and removing it from the version that will be shared, processed, or stored downstream. The word comes from the legal practice of blacking out passages of court filings before publication; in digital workflows it covers a much wider set of operations, from replacing a name with a placeholder token to permanently destroying a region of an image with a pixel-perfect blackout.

People often use "redaction", "anonymization", "pseudonymization", "masking", "encryption", and "deletion" interchangeably. They are not interchangeable, and the difference matters under the GDPR. We will return to the legal nuances in section 2; for now hold the following distinctions in mind.

• Redaction is the umbrella operation: turning a document containing PII into a version that no longer contains that PII (or no longer contains it in a way attackers or unauthorized readers can recover).
• Masking (or PII masking, sometimes called data masking) is one technique: replace each detected PII span with a placeholder such as [PERSON_1] or ⟦NAME⟧. The placeholder is meaningful to a downstream process (e.g. an LLM) but contains no identifier itself. To redact PII in practice is to choose between this masking path and a permanent blackout, depending on the destination of the document.
• Pseudonymization is masking plus a controlled, separately stored mapping back to the original values. The GDPR recognises this explicitly in Article 4(5) and rewards it across the legal text, but it does not turn the data into "anonymous" data.
• Anonymization is one-way and irreversible. After anonymization no one — including you — should be able to re-identify the data subject. The GDPR sets this bar in Recital 26 and anonymous data falls outside the regulation entirely.
• Encryption is reversible by anyone with the key. Encrypted PII is still personal data under the GDPR; encryption is a security control, not a redaction technique.
• Deletion removes the document; redaction removes the PII from a document you keep.

The practical implication for any team adopting redaction software is this: if you only ever want to share a single, clean version with a third party and never look at the original again, anonymization (a permanent blackout) is the right tool. If you want to feed the document to an AI model for analysis and then read the answer with the real names restored, you want pseudonymization — that is, reversible masking. Most professional workflows need both, often within the same document. A good data redaction tool supports both modes natively rather than forcing you to choose one path for the whole pipeline.

The other anti-pattern we see constantly is treating redaction as a one-off pre-share step. In a multi-tenant firm with shared drives, weekly LLM use, and outsourced subprocessors, redaction has to live inside the workflow — at upload, at AI request time, at export — not as a once-a-month manual review by a paralegal with a black highlighter.

2. The GDPR framework: Article 4(5) pseudonymization vs Recital 26 anonymization

Three GDPR references shape every meaningful conversation about data redaction in the EU.

GDPR Article 4(5) defines pseudonymization as "the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information". The additional information must be "kept separately and subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person." Pseudonymized data remains personal data: GDPR still applies, you still need a lawful basis, and the data subject still has access and erasure rights.

Recital 26 GDPR draws the line for anonymization: "The principles of data protection should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable." Anonymous data is out of scope. The bar is high and is best understood through the three criteria the WP29 Opinion 05/2014 set out: singling out, linkability, and inference. If a redacted document still allows you to single out one individual, link records across datasets, or infer attributes about a specific person, you have pseudonymized — not anonymized.

Article 25 (Data Protection by Design and by Default) and Article 32 (Security of Processing) together push pseudonymization as the prudent technical measure for risky processing. Article 32(1)(a) names it explicitly. That is why a GDPR compliance programme that has invested in proper pseudonymization is rewarded by supervisory authorities: it is a control the regulation itself prescribes by name.

The EU AI Act (sometimes referenced together as the GDPR AI Act overlap), in force since 2024 and with high-risk provisions phasing in through 2026 and 2027, adds another layer. AI systems used for HR (recruitment, performance evaluation, promotion decisions) are classified high-risk under Annex III. They require risk management, data governance, technical documentation, transparency, human oversight, accuracy/robustness/cybersecurity controls, and a fundamental rights impact assessment. The Act does not require you to pseudonymize before AI use, but in practice it is the cleanest way to satisfy data minimization (Art. 5 GDPR) and the AI Act's data governance article (Art. 10) at the same time. AI compliance GDPR is not two regulations stacked on top of each other; it is one operating model.

One myth that needs killing: many vendors market their tool as "GDPR anonymization" when it is in fact pseudonymization. If the mapping from placeholder back to the original value exists anywhere — on your filesystem, in the user's browser, in a service we operate — the data is pseudonymized, not anonymous. GDPR pseudonymization is a valuable safeguard, and there is nothing wrong with offering it; calling it anonymization is misleading and exposes the customer to a compliance trap. Redactic's redaction certificate explicitly distinguishes the two and labels every reversible job as pseudonymization under Article 4(5).

Case law has tightened the line further. In Breyer v. Germany (C-582/14, 2016) the CJEU ruled that an IP address held by a website operator is personal data if the operator has reasonable legal means to obtain the additional identifying information from a third party. The "reasonable means" test is broader than many engineers assume: data your service alone cannot identify can still be personal data if a court order or contractual arrangement could supply the missing pieces. For redaction, this means a placeholder-plus-map split across two organisations is not automatically anonymization — if either party can lawfully compel the other to disclose the map, the data is pseudonymized for both. The 2023 SRB v. EDPS ruling (T-557/20) reinforced the contextual nature of the test by distinguishing pseudonymized data in the hands of a recipient who cannot re-identify from the same data in the hands of the controller who can.

The WP29 Opinion 05/2014 (now endorsed by the EDPB) operationalises Recital 26 with three concrete attack models. Singling out: can an attacker isolate one record corresponding to one individual? Linkability: can two records from the same dataset, or across datasets, be linked to the same individual? Inference: can a value of an attribute be deduced from a combination of the others? If the answer to any of the three is yes, the document is pseudonymized, not anonymized. The practical takeaway is that masking the name on a payroll spreadsheet does not anonymize it — the row still singles out one employee — and that the genuinely anonymous case is rarer than vendors imply.

3. The two redaction modes: reversible (placeholder map) and irreversible (blackout)

In production you will use two modes constantly. Understanding the difference is the difference between a workflow that survives an inspection and one that leaks names because you used the wrong tool for the job.

Reversible redaction (pseudonymization) replaces each detected entity with a stable placeholder and stores a separate map from placeholder to original value. The map is what makes the operation reversible: feed the redacted text to an LLM, get the answer back referencing the placeholders, and substitute the original values in the rendered output. The user sees the real names; the model never did. This is the only mode that lets you redact sensitive information and still use AI in a useful way. The trade-off is that you must protect the map. If the map leaks, the pseudonymization is undone for every record that map covered.

Reversibility has two architectures. Client-side maps live in the user's browser and never reach the server: the most paranoid mode, useful when you cannot trust any service-side state. Server-side maps live in an ephemeral store (Redis with a short TTL is the common pattern) so the user can pick the job back up from a different device. Redactic uses ephemeral server-side maps cifrate Fernet con TTL 120 secondi sull'input e 300 secondi sull'output, plus an explicit local-restoration mode in the browser for the most sensitive workflows. Both modes route the AI request through pseudonymized text, so the LLM provider never sees the original PII.

Irreversible redaction (anonymization-style blackout) permanently destroys the region of the document where the PII lived. To anonymize a document in this strict sense — to anonymize a PDF permanently — is what most regulators have in mind when they say "anonymization". On a digital PDF the redaction tool removes the text content and overlays a black rectangle; on a scanned PDF or an image, the tool runs OCR to find the PII and then paints over the pixels. There is no map. The output is the document your law firm shares with opposing counsel; there is no way back. This is the only mode you should use when the goal is "this file leaves the building and we never need the original to follow it." Irreversible blackout is the closest you can get to Recital 26 anonymization on document-level data, but be honest about the limits: if the document still allows singling-out (a small organisation, a unique role title, a specific date), the legal status is "pseudonymized in practice" even though there is no map. Document anonymization at the legal threshold is rarer than the marketing material implies.

The mistake we see most often is the inverse: a firm runs an "anonymization" pass that is in fact reversible masking, shares the file externally, and keeps the map on a shared drive that the recipient eventually gains access to. The result is a re-identifiable record on a third party's server. Choose the mode by destination, not by habit.

Redactic exposes both modes from the same upload: a reversibility switch on the upload screen and a confirm button on the irreversible path that requires explicit acknowledgment. The reversible mode supports text-first formats end-to-end (TXT, DOCX run-preserving, XLSX cell-preserving, Markdown, JSON, CSV, HTML, XML); for PDF the format-preserving reversible path goes through a plain-text intermediate, which is honest and works for analysis workflows but is not a true reversible PDF. True PDF redaction in Redactic is blackout-only, and we tell customers so.

4. PII categories that must be redacted before AI use

Not every personal datum carries the same regulatory weight. The GDPR distinguishes "personal data" (Art. 4(1)) — anything that identifies or could identify a natural person — from "special categories" (Art. 9) such as health data, biometric identifiers, racial or ethnic origin, political opinions, religious beliefs, trade union membership, sexual orientation, and genetic data. For special categories the bar for processing is significantly higher (explicit consent, vital interests, public interest in health, etc.) and the risk of an unintended LLM-side disclosure is correspondingly larger.

The following table is the operational shortlist we use. Before any document goes to ChatGPT, Claude, Gemini, Mistral, or any other LLM provider, every entry below should be either masked with a placeholder or blacked out, depending on whether the workflow needs reversibility.

Category	Examples	Why it matters
Direct identifiers	Full name, email, phone, postal address	The minimum-viable PII set; trivially re-identifying.
National identifiers	Italian Codice Fiscale, French NIR/INSEE, German Steuer-ID, Spanish DNI/NIE, EU passport numbers	Often missed by generic English-trained models. Redactic uses GLiNER multilingual + national regex.
Financial	IBAN, SWIFT, payment card numbers, bank account, tax ID/VAT	Trigger PCI-DSS adjacent risk and direct fraud risk.
Employment	Employee ID, payroll line, hire date, salary, performance rating	Re-identifying inside a small org even without a name.
Health (Art. 9)	Diagnoses, medication, sick-leave reasons, occupational health notes	Special category data, explicit consent or another Art. 9 basis required.
Biometric / identity documents	ID card numbers, driver's licence, passport, photographs of faces	Special category if used for unique identification.
Quasi-identifiers	Birth date + ZIP + gender, exact role + department, rare job title	Used in linkage attacks. Sweeney's 87% rule: ZIP+DOB+gender re-identifies most US adults.
Free-text disclosures	Exit interview transcripts, customer complaints, support tickets	The hardest category. Often slip past pattern-based redactors and need ML NER.

Automatic PII detection on free-text documents is the hard problem — the part of PII anonymization that separates a real product from a regex wrapper. To mask PII reliably across a corpus you need ML, not just patterns. Regular expressions catch IBANs, tax IDs, emails, and phone numbers reliably; they do not catch the names of people you have never heard of in three languages on a scanned PDF. This is where PII detection becomes a machine-learning problem and where the choice of model matters. Redactic uses urchade/gliner_multi_pii-v1, a multilingual GLiNER model fine-tuned on PII categories that runs on CPU with no per-language model swap. Documents are chunked into 180-word windows with overlap to avoid GLiNER's 384-subword-token truncation — a subtle but critical detail: without chunking a long PDF loses every entity past page two.

For scanned PDFs and images, the pipeline first runs Tesseract OCR with the eng+ita+fra+deu+spa language pack to extract the text, then runs detection, then paints the redaction back onto the original pixels. This is how redact pdf works on scans — not by hoping the file was digital all along. Quality on rotated or skewed scans varies; Redactic skips heavily rotated pages and surfaces them for manual review rather than producing a confidently-wrong output.

5. The five-step redaction workflow that scales

The single biggest reason redaction programmes fail in professional services firms is that they live entirely inside a paralegal's head: an ad-hoc Word-and-highlighter ritual that does not survive the paralegal's holiday week. The workflow below is the one we recommend as a baseline; it is the workflow Redactic implements end-to-end and the one we have audited against the GDPR's accountability principle.

1. Upload. Drop the source file (PDF, DOCX, XLSX, image, plain text, CSV, HTML, XML, Markdown). For multi-document workflows, batch the upload but keep each document's audit trail separate. The upload should land in an ephemeral encrypted store, not on a disk that survives the request. Redactic stores inputs in Redis with Fernet encryption and a 120-second TTL.
2. Detect. Run the cascade: dictionary exact-match (for known rosters such as your client list), national regex (Italian CF, French NIR, German Steuer-ID, Spanish DNI/NIE, IBAN, email), multilingual NER (GLiNER multilingual on residual names, organisations, locations), and OCR fallback for scans and images. Surface the detected spans grouped by category with confidence scores.
3. Review. Show the user every span with a keep/redact toggle. Recall-biased detection over-redacts on purpose — false positives are cheap to correct, false negatives leak. Let the user uncheck spans that are not actually PII (a brand name detected as a person, a number that looks like a tax ID but is a product code) and re-run server-side with keep_values. This step is non-negotiable for legal-grade workflows.
4. Apply. Choose mode: reversible (placeholder map kept client-side or in ephemeral server store) or irreversible (blackout). For reversible, store the map separately, encrypted, with a short TTL. For irreversible, also strip document metadata (PDF /Info + XMP, DOCX core-properties, XLSX properties) — many redaction failures leak the author's name from the document properties even when the body is clean.
5. Share or restore. Download the masked file, send it to an LLM, share it with a third party. For reversible workflows, when the answer comes back, restore the original values inside the user's browser so the real names never round-trip through the model. For audit, generate a SHA-256 redaction certificate listing input hash, output hash, redaction counts per category, mode, and timestamp — but never the original values themselves. The certificate is the document you produce if the supervisory authority asks how a given output was generated.

The certificate point deserves emphasis. A redaction certificate is the artefact that turns "we used a redaction tool" into "here is the cryptographic record of this specific job". It is also the artefact that proves you did not store the document or its PII, because it contains only hashes and category counts, not content. Redactic generates one for every job, downloadable as a PDF, and signs it with the application key.

A worked example: redacting a payroll spreadsheet. Suppose an accounting firm uploads a 12-sheet XLSX with 80 employees, columns for name, tax ID, IBAN, gross salary, deductions, and notes. Generic find-and-replace would corrupt the salary formulas; manual highlighter editing in Excel would take half a day. The right workflow processes each sheet's string cells via a structured library (openpyxl in our stack), leaves the numeric and formula cells untouched, and runs the cascade — dictionary lookup on the employee roster the firm uploads, Codice Fiscale regex on the tax ID column, IBAN regex on the bank column, GLiNER on the notes column for free-text names. The review screen surfaces 240 detected spans grouped by column; the reviewer accepts the canonical maps and rejects three false positives (a product code that matched the IBAN pattern, two organisation names misclassified as people). The export is a XLSX with placeholders on the string cells, formulas and numeric cells intact, document properties stripped of the producer's name. The accompanying certificate logs the SHA-256 of the input and output, the count per category (80 names, 80 tax IDs, 80 IBANs, 14 free-text names from the notes), the mode (reversible), and the timestamp. Total elapsed time: under 60 seconds for the detection, under three minutes including the manual review. The map is held in Redis for the LLM round-trip and destroyed automatically when the TTL expires.

6. Shadow AI: why blind ChatGPT use breaks the GDPR

The conversation we have most often with clients begins like this: "We banned ChatGPT for sensitive data. Then we discovered everyone is pasting things in anyway, from personal accounts, on their phones, after hours." This is shadow AI: the use of public LLM endpoints with sensitive data, without IT visibility, often with the best of intentions. It is the dominant AI risk inside professional services firms in 2026.

Shadow AI breaks the GDPR in three specific ways. First, the LLM provider becomes a data processor without a Data Processing Agreement. Article 28 requires a DPA — Article 28(3) lists the eight clauses it must contain — before any processing on the controller's behalf. A user pasting client names into a personal ChatGPT account creates processing without a DPA, with no record of processing activities (Art. 30), no Article 28 vetting, no documented sub-processor chain. Second, depending on the consumer-tier provider's defaults, the input may be used to train the next model, creating an irreversible disclosure that erasure (Art. 17) cannot undo. Third, the data transfers cross the EU border to a US data centre without the controller having performed a transfer impact assessment after Schrems II.

The honest answer is not "ban it harder". Users will route around the ban every time the official tool is slower or worse than the consumer one. The answer is to make the official path the path of least resistance — a secure AI chat (sometimes marketed as safe AI chat or compliant AI) that masks PII before the message leaves the browser, sends the pseudonymized text to an EU-hosted LLM under a signed DPA, and restores the real values in the answer locally. This is what genuine AI data privacy looks like operationally, not as a checkbox in a security questionnaire. This is what Redactic Secure Chat does: PII is masked in-browser via the same detection pipeline as the document workflow, the request goes to OpenAI, Anthropic, Google, or Mistral on their EU endpoints (zero retention, no training on input), and the restoration happens client-side so the original values never sit on a server log anywhere.

This is not a theoretical concern. Samsung banned ChatGPT and other generative AI tools in May 2023 after staff reportedly entered corporate information, including source code, into the chatbot. Italy's Garante temporarily suspended ChatGPT on 30 March 2023 over Art. 6 (lawful basis), Art. 13 (information notice), and the lack of age verification; the service was restored on 28 April 2023 only after OpenAI implemented an age gate, an opt-out, and an explicit information notice. The Garante then issued a final decision on 20 December 2024 with a €15 million fine. In parallel, the Spanish AEPD opened an investigation in April 2023, and the European Data Protection Board formed a dedicated ChatGPT task force in April 2023 that published its preliminary findings in May 2024. Cleansum's 2023 Cyberhaven study found that 11% of corporate ChatGPT prompts contained sensitive data — payroll records, source code, customer information — uploaded from inside firewalls. The EU AI Act adds general-purpose AI obligations from August 2025 onward that further constrain how consumer LLM endpoints can be used in regulated contexts. Building a chatgpt privacy story for your firm is not optional any more; it is the operational pre-condition for AI adoption.

The pattern is consistent across every incident: the technical breach is rarely sophisticated, the policy response is always reactive, and the cost is paid by the firm whose paralegal pasted the contract into a free chatbot at 11pm. Enterprise AI privacy is not a top-down policy problem; it is a bottom-up user-experience problem. If the safe path is slower, the unsafe path wins. Redactic Secure Chat is faster than ChatGPT on the redaction-then-chat round-trip because masking happens client-side in milliseconds, the model still answers in normal latency, and the restoration is local. The user does not perceive a tax for compliance; they perceive a smoother flow than the consumer alternative because the answers come back with the real names already restored, no copy-paste cleanup needed.

LLM data privacy as a procurement question has three concrete answers. (1) Does the provider operate an EU endpoint with EU data residency and a clear sub-processor list? (2) Is your input excluded from model training by default, with a signed processor agreement to that effect? (3) Is the retention zero or strictly bounded, with an audit trail you can reproduce? Anything weaker than yes to all three pushes the burden of compliance back onto your firm — and onto the lawyer, accountant, or HR lead who has neither the time nor the training to carry it. ChatGPT data privacy defaults on the consumer tier do not pass this test; the enterprise tiers do, but require both procurement diligence and a redaction layer in front of them to be defensible.

When sizing the shadow AI risk for your own firm, treat the statistics that circulate with care: our audit of the most repeated shadow AI statistics traces each figure to its primary source and shows several that do not measure what they are usually quoted as measuring.

7. Choosing a redaction tool: an 8-point evaluation checklist

If you are buying a redaction tool — or more specifically a document redaction software or AI redaction tool — or evaluating an internal build versus an off-the-shelf product, the following checklist is what we use with prospects. Score each item 0-2 (no / partial / yes) and weight the privacy posture items double. If you finish below 18 out of a possible 32, you have a compliance risk; below 12, you have a productivity risk too.

1. No-trace architecture. Does the service process the document in memory and immediately discard it? Are inputs encrypted at rest in the ephemeral store, with short TTL, and never written to a persistent log? Why it matters: a stored copy is still personal data — the redaction process itself becomes a separate processing activity if the input survives the request.
2. Multilingual PII detection. Does the model handle Italian Codice Fiscale, French NIR, German Steuer-ID, Spanish DNI/NIE, Polish PESEL, etc., or only English names and US SSNs? Why it matters: Anglo-centric detectors miss 30-50% of national identifiers on EU documents.
3. OCR for scans. Can the tool redact a scanned PDF or a photographed ID card with pixel-perfect blackout? Why it matters: the cases that scare your DPO most — old contracts, photographed documents — are exactly the cases a text-only redactor cannot help with.
4. Two-mode support. Can the tool produce both reversible (placeholder) and irreversible (blackout) outputs from the same upload? Why it matters: single-mode tools force you to maintain two pipelines.
5. Manual review. Does the UI let a human accept or reject each detected span before applying the redaction? Why it matters: recall-biased detection is the right default but produces false positives that need a fast review path.
6. Metadata stripping. Does the tool also remove document properties (author, last-modified-by, XMP, EXIF)? Why it matters: the most common production leak is a clean body with an author name in the PDF properties.
7. Audit certificate. Does the tool generate a per-job cryptographic record of what was processed, with hashes and category counts but no content? Why it matters: the certificate is what you show the supervisory authority, the insurance underwriter, and the client.
8. Compliance posture. EU data residency, DPA included on signup, sub-processor registry, click-wrap consent with cryptographic snapshot, role separation (your tool acts as processor, not controller). Why it matters: these are the items that determine whether the tool fits into your existing GDPR programme or creates new processing activities you now have to govern.

Tools that ship as a Chrome extension can be elegant but score badly on (1) and (8) — there is rarely a real DPA behind a free extension. Open-source libraries like Presidio or Piiranha score well on (2) but you own the operational footprint (no-trace, OCR, audit, certificate) which is most of the work. Hosted commercial tools score variably; the question to ask is not "do you have a feature called redaction?" but "show me the certificate from a sample job and the sub-processor list."

Build vs buy. The build-it-internally argument usually comes from CTOs who notice that GLiNER, Tesseract, and the national-regex layer are all open source. The argument is right about the components and wrong about the total cost. The actual work is not the detection engine — that is a weekend prototype — but the operational layer: an ephemeral encrypted store with TTL discipline that survives crashes, a manual-review UI that handles thousands of spans without trashing the browser, a redaction certificate generator that signs with a stable key, a metadata stripper that handles every PDF producer's quirks, a DPA workflow with click-wrap consent capture, a sub-processor change-notification flow, and the ongoing maintenance to keep up with new national identifiers, new OCR languages, new LLM endpoints. The vendor's value is rarely the model; it is the discipline around the model. If your firm has a security engineer who will own all of the above as their main job for 18 months, build is rational. If they are doing it on the side, you will end up with a half-finished tool and a paper DPA your DPO cannot defend. We have seen both outcomes; buy is usually cheaper than the second.

Redactic was designed against this checklist from day one: no-trace by design (Fernet-encrypted Redis with TTL 120s/300s, no DB models, no content logs), multilingual GLiNER with national-regex fallback, Tesseract OCR with five-language pack, both reversible and irreversible modes, manual review console, metadata stripper across PDF/DOCX/XLSX, SHA-256 audit certificate with downloadable PDF, EU residency on Hetzner Helsinki and Cloudflare R2 EU jurisdiction, signed DPA on signup with click-wrap consent snapshot, and the explicit processor role in the trust pages. The DPA and sub-processor list are public; the architecture is documented; the redaction certificate is downloadable from the dashboard for every job.

Honest caveats: PDF reversible redaction in Redactic goes through a plain-text intermediate (true PDF is blackout-only); the OCR blackout path was end-to-end tested in browser only at production deploy in June 2026; in multi-form name cases ("Mario Rossi" and the partial "Mario" later in the document), the server-side keep-as-canonical-form rule may leave a partial mask that the client UI shows as kept. We tell prospects this on the first call rather than after the contract.

8. Frequently asked questions

What is the difference between data redaction and data anonymization?

Redaction is the operation; anonymization is one possible result. Data redaction can produce either pseudonymized output (reversible, GDPR Art. 4(5)) or anonymized output (irreversible, GDPR Recital 26). Anonymization removes the data from GDPR scope entirely; pseudonymization keeps the data inside GDPR but reduces risk.

Is pseudonymization the same as encryption?

No. Encryption is reversible by anyone with the key and is a security control; pseudonymization replaces identifying values with placeholders and keeps the back-map under stricter access control. The GDPR explicitly recognises pseudonymization in Art. 4(5) and Art. 32(1)(a); encrypted personal data is still personal data.

Can I use ChatGPT with redacted documents safely under GDPR?

Yes, with two conditions. First, the redaction must happen before the document leaves your environment — masking after the upload to ChatGPT does not help. Second, the LLM endpoint should ideally be the EU/enterprise tier with a Data Processing Agreement and no-training defaults. A secure AI chat that masks PII in the browser before the request and restores the real values in the answer locally is the cleanest pattern.

Does automatic PII detection work on scanned PDFs?

Only if the tool runs OCR first. A redaction tool that handles only digital text will silently produce a "redacted" scan with all PII intact. Tesseract with the right language pack is the standard open-source path; commercial cloud OCR exists but introduces a sub-processor that needs its own DPA. Redactic runs Tesseract on the worker with the eng+ita+fra+deu+spa pack. If you searched for "anonymize PDF" or "anonymize document" expecting a one-click solution, the honest answer is that scans need OCR before any masking is possible — and the OCR quality bounds the redaction quality.

How long should the placeholder map be retained?

As short as the workflow requires. For an LLM round-trip the map is needed only between the request and the response — minutes, not days. Redactic uses 120 seconds on the input store and 300 seconds on the output store. For a multi-document case file the map may need to live for the duration of the case, in which case it should be encrypted at rest, access-logged, and explicitly listed in your records of processing activities.

What is shadow AI and why is it a GDPR problem?

Shadow AI is the use of public LLM endpoints with sensitive data, outside IT visibility, typically via personal accounts. It creates processing without a DPA (Art. 28), undocumented international transfers (Schrems II), and possible training-time exposure of the input. The mitigation is not a stricter ban — bans get routed around — but an official path that is faster and safer than the shadow one.

Does the EU AI Act change anything about redaction?

Yes. High-risk AI systems under Annex III (HR, recruitment, performance evaluation) must comply with data governance obligations (Art. 10), risk management (Art. 9), and human oversight (Art. 14). Pseudonymizing input data before feeding it to such a system is the cleanest way to satisfy data minimization simultaneously under GDPR Art. 5 and AI Act Art. 10. The AI Act does not require redaction explicitly but rewards it operationally.

What is a redaction certificate and why do I need one?

A cryptographic record of a redaction job: input hash, output hash, mode, redaction counts per category, timestamp, application signature. It contains no content and no PII, so it is safe to store and share. You need it to demonstrate Article 5(2) accountability — that you can show how a given output was generated months later, without keeping the document.

Can I redact an Excel spreadsheet with employee data without breaking the formulas?

Yes if the tool understands the difference between a string cell and a number/formula cell. Generic find-and-replace breaks formulas. Redactic processes string cells per sheet via openpyxl while leaving numbers, formulas, and formatting intact — this is the workflow we use for multi-employee payroll files and what the recent multi-sheet column-redaction work has been refining.

Where does Redactic store my data?

Nowhere persistent. Documents live in Redis with Fernet encryption and short TTL during the job, and are destroyed by the worker's finally block regardless of outcome. The application does not have a database model for document content. The redaction certificate stores hashes and counts only. Compute and metadata storage are EU (Hetzner Helsinki + Cloudflare R2 with EU jurisdiction). The sub-processor list and DPA are public on the trust pages.

If you read only one thing in this guide, read section 6 on shadow AI. The single biggest risk in your firm in 2026 is not a botched manual redaction; it is the cumulative effect of a thousand small ChatGPT pastes from personal accounts. The answer is not stricter rules — those will be routed around — but a faster official path with proper data redaction and a signed DPA. Build the path before the regulator builds it for you.

If you want to see how this works in practice, the Redactic landing walks through the four use-case modes (Redact, Anonymize, Use with AI, Secure Chatbot) with a live demo on a sample contract. The Solo plan covers a single professional at €19/month; the Firm plan adds the secure AI chat and up to fifty seats at €49/month; Enterprise is custom. The DPA is signed at signup and the redaction certificate is downloadable from every completed job.