If you run an accounting firm in 2026, you are arguably the highest-volume PII processor in the European economy, and you operate under a tighter constraint than most data controllers: you have not only the GDPR but also a national professional secrecy regime, the EU anti-money-laundering stack, and a client base whose data you process on their behalf and not on yours. Document redaction for accountants — masking names, tax IDs, IBANs, and payroll line items from every client document that moves through the firm — is not an optional best practice any more. It is the operational gate that determines whether your firm can use AI tools at all, share files with foreign correspondents safely, and survive both a supervisory authority inquiry and a Financial Intelligence Unit audit.
This is the third article in our redaction guide series. The pillar guide covers the underlying technology and the general GDPR framework. This article zooms into accounting specifically — payroll processing, tax filings, KYC/AML, audit working papers, client correspondence — where the volume of personal data per practitioner is the highest in any professional services category and the regulatory stack is the most layered.
It is also the cluster article most directly useful to firms doing cross-border work. Accountants serving Italian residents from a French office, French clients reporting through an Irish holding, German Mittelstand using Spanish subsidiaries — every cross-border tax workflow generates PII flow that crosses two or three jurisdictions before settling on a return. The redaction layer is what keeps that flow defensible.
Terminology note: in this article we use "document redaction accountants" workflows, "PII redaction accountants" practices, and "redaction software accountants" depend on as synonyms for the same operational layer; we use "tax ID anonymization", "VAT number redaction", and "EORI number redaction" as sub-cases of the same multi-national identifier problem; and "GDPR accounting firm" obligations cover both the controller and processor sides. We use "AI accountants GDPR" compliance as the umbrella for the combined GDPR + AI Act + AML stack discussed below, and "accountant AI compliance" interchangeably when emphasising the deployer side.
1. Why accounting firms are the highest-volume PII processors in the EU
Five structural facts together explain why PII redaction for accountants is materially more complex than for any other professional services category.
First, volume. A mid-sized accounting firm handles hundreds of clients, each generating monthly payroll runs, quarterly VAT returns, annual tax filings, KYC onboarding documents, and continuous client correspondence. The single firm processes more individual personal data records per year than many marketing platforms — and the data is structurally richer (national identifier + financial + employment + sometimes health).
Second, sensitivity. The data is not just identifying; it is regulated under multiple regimes. National identifiers (Codice Fiscale in Italy, NIR in France, Steuer-ID in Germany, DNI/NIE in Spain) are PII under GDPR but also instrument-of-fraud risk targets. Payroll data overlaps with GDPR Article 9 special categories whenever it captures sick leave reasons, disability pay, union dues, or pension scheme religious entitlements. AML/KYC documents (passports, ID cards, ultimate beneficial owner declarations) attract a separate retention obligation under the EU anti-money-laundering framework.
Third, the role split. Accountants are processors of their clients' data, not controllers. That makes Article 28 GDPR — the data processing agreement, the sub-processor disclosure, the documented chain of authorities — the operational backbone of the firm's relationship with every client. An unauthorised sub-processor, including a free ChatGPT account, is a contractual breach with every single one of those clients simultaneously.
Fourth, professional secrecy. Italy's Codice Penale art. 622 and Codice Civile art. 1175 / 1375, France's Code de commerce L820-5 and the OEC code de déontologie, Germany's StBerG §57 read together with §203 StGB, and Spain's RGL del ICEC all impose criminal or quasi-criminal professional secrecy. The interaction with GDPR is non-trivial: data minimisation under Art. 5 GDPR overlaps with professional secrecy, but the disclosure rules differ (GDPR has a right of access, professional secrecy has near-absolute confidentiality). Professional secrecy accountant obligations are typically stricter than GDPR access rights, and the firm must satisfy both.
Fifth, cross-border data movement is the default, not the exception. A typical mid-market accounting engagement involves data flows to a corresponding accountant abroad, to the client's foreign tax authorities, to bank correspondents for IBAN verification, and to the central business register of one or more Member States. Each flow carries its own Article 44 transfer assessment. Cross-border tax data routing through a US LLM is a single, easy-to-prove GDPR violation in any audit because the network logs alone are sufficient evidence.
2. The six document categories every accounting firm handles
Different document categories generate different redaction patterns. The six below cover ~98% of what flows through any accounting firm and they map cleanly onto the redaction architecture.
1. Payroll runs and pay slips. Multi-employee XLSX files with name, tax ID, IBAN, gross salary, deductions, and notes; PDF pay slips per employee; year-end payroll summaries. The redaction problem here is multi-modal: structured cell-level PII (tax ID column, IBAN column) plus unstructured notes (manager comments, sick-leave reasons). Payroll anonymization via a generic find-and-replace breaks the salary formulas; via a redaction tool that understands cell types, it preserves the spreadsheet's analytical value while masking the PII. Redact payroll workflows are also the highest-frequency redaction activity in any firm.
2. Tax filings and returns. Italian 730, F24, Modello Unico, IRAP; French liasse fiscale, déclaration de TVA, IS; German Einkommensteuererklärung, Umsatzsteuer-Voranmeldung, Bilanz; Spanish Modelo 100, Modelo 303, Modelo 200. Every tax filing contains both the taxpayer's PII and frequently dependants' or employees' PII. Tax filing redaction is needed whenever the filing or its working papers are shared with a third party (cross-correspondence, audit support, AI-assisted review). To anonymize tax return documents for AI analysis specifically, the redaction must preserve the calculation logic while masking identifiers — a step that requires structured detection rather than pattern matching alone.
3. KYC / AML onboarding documents. Identity documents (passports, ID cards), proof of address, ultimate beneficial owner declarations, source-of-funds documentation. These are governed by the EU AML stack: AMLD4 (2015), AMLD5 (2018), AMLD6 (2018), the AMLR (Regulation (EU) 2024/1624), and the AMLD (Directive (EU) 2024/1640). Accountants are obligated entities under all of them. KYC data redaction in this context is asymmetric: you cannot redact the underlying KYC dossier itself (it must be retained), but you must redact KYC-derived information whenever it travels into a downstream workflow (AI summarisation, internal training, client correspondence about a third party).
4. Audit working papers. For accounting firms with audit practices, working papers contain extracts from client systems, employee identifiers, vendor data, and management communications. ISA 230 requires retention for at least five years; ICAEW and IAASB guidance treat working papers as confidential. Audit working papers redaction is the path that allows partial sharing with co-audit teams, peer reviewers, and audit quality reviewers without breaching either GDPR or the audit confidentiality regime.
5. Contracts and client correspondence. Engagement letters, fee proposals, advisory memos, email exchanges. These contain client PII, often third-party PII (the client's counterparty), and frequently strategic information about a deal. Generic email AI assistants and document summarisation tools that operate on this category create the most insidious shadow AI exposure because the user perceives the activity as low-risk ("just summarising my inbox").
6. Bank and treasury data. IBAN lists, SWIFT statements, payment authorisations, bank reconciliations. The PII here is concentrated in IBANs and account holder names; the financial sensitivity is high; both PSD2 and SCT scheme rules add another layer to the GDPR baseline. Redact IBAN processing is a frequent micro-workflow that should run automatically before any AI step on financial documents.
The pattern across all six categories is the same: structured data needs structured redaction, free-text data needs ML detection, and the audit certificate is what makes the activity defensible to both the DPO and the Financial Intelligence Unit.
3. The national identifier landscape — and why pattern matching is not enough
Accountants work with national identifiers more than any other professional category. Each one has a structure, a check digit algorithm, and a set of false-positive risks. A generic redactor trained on US Social Security Numbers will silently miss most of them.
| Country | Identifier | Length | Notes |
|---|---|---|---|
| Italy | Codice Fiscale | 16 alphanumeric | Surname + name + DOB + sex + birthplace + check char. The structure leaks DOB and sex even after masking surrounding context. |
| Italy | Partita IVA | 11 numeric | VAT number; province encoded; check digit. Often confused with CF in free text. |
| France | NIR / INSEE | 15 numeric | Sex + year + month + département + commune + order + check. Identifies a person within their commune of birth uniquely. |
| France | SIRET / SIREN | 14 / 9 numeric | Establishment / company identifier. PII when self-employed. |
| Germany | Steuer-ID (IdNr) | 11 numeric | Personal tax ID, life-long, not derivable from DOB. Strictly regulated. |
| Germany | USt-IdNr | 9 numeric after DE | VAT number for cross-border transactions. |
| Spain | DNI / NIE | 8 digit + letter | DNI for nationals, NIE for foreign residents. Letter is a deterministic check. |
| Spain | CIF (legacy) / NIF | 9 chars | NIF for sole traders mirrors DNI; CIF for legal entities. |
| EU | EORI | varies | Customs identifier. Per-Member-State format; PII when self-employed importer. |
| EU | IBAN | 15-34 alpha-numeric | Country code + check + BBAN; structurally validatable. The most leak-prone single field in payroll. |
The risk pattern is consistent: each identifier is structurally regular enough that a regex catches the typical case and misses the unusual one. False positives are also common: a product code that looks like a tax ID, a customer ID that matches IBAN length, an invoice number that resembles a SIREN. A redaction tool used by accountants needs multi-national regex + multilingual NER + manual review to handle the corpus correctly. Redactic ships the cascade with the regex layer covering 17 country formats, the GLiNER multilingual NER catching person and organisation names that the regex misses, and the review console allowing the accountant to accept or reject each detected span before applying the redaction.
The masking decision is also identifier-specific. EORI and VAT numbers are typically not PII for incorporated entities and should not be masked when the workflow is purely B2B; the same numbers are PII for self-employed individuals and must be masked. The tool needs to understand the entity-type context to make the right choice.
4. The GDPR + AML stack — and how it differs for accountants
Three regimes apply to every accounting firm simultaneously: GDPR, the EU anti-money-laundering framework, and the national professional secrecy law. They are not aligned; in some places they conflict.
GDPR Article 28 — the processor backbone. An accountant is a processor for their clients. The engagement letter must include or reference the Art. 28(3) clauses. Sub-processors (the cloud accounting platform, the e-invoicing provider, the OCR vendor, the LLM) must be disclosed to the client with the right to object. Shadow AI use by a senior accountant breaches Art. 28 with every client whose data was in the session — typically dozens at once.
GDPR Article 32 — security of processing. The EDPB's 2024 guidelines on technical and organisational measures for processors put pseudonymisation explicitly in the recommended toolkit. For accountants this translates into: redact before AI use, encrypt at rest, log access, document the controls. A firm without a redaction layer cannot credibly claim it has met Art. 32 for AI workflows.
AMLD6 and the AMLR (2024). The Sixth Anti-Money-Laundering Directive (Directive (EU) 2018/1673) criminalised money laundering with predicate-offence harmonisation; the 2024 AMLR (Regulation (EU) 2024/1624) is the new single rulebook that will apply directly from July 2027 along with the new EU AML Authority (AMLA). Accountants are obligated entities under both. The KYC documents they collect must be retained for at least five years after the end of the business relationship. AML KYC data retention and GDPR storage-limitation create an apparent tension; the resolution is that the AML retention obligation is the lawful basis under Art. 6(1)(c) for retention, but downstream processing of the same data (AI summarisation, internal analytics) is a separate processing activity that needs its own basis. AMLD6 compliance and GDPR compliance are not in conflict per se; they require careful workflow design.
Professional secrecy at national level. Italy's Codice Penale art. 622 imposes criminal liability for disclosure by a professional secret-holder; France's professional secrecy attaches to the inscription au tableau de l'ordre; Germany's StBerG §57 with §203 StGB makes professional secrecy criminal; Spain's professional secrecy is statutory. In each case the secrecy is typically stricter than the GDPR right of access, meaning the firm must (a) refuse some access requests under professional secrecy even when GDPR would allow them, and (b) ensure that shadow AI does not constitute a disclosure to a third party (the LLM provider).
EU AI Act for accountants. The AI Act's high-risk classification under Annex III does not apply to most accounting AI uses (Annex III is HR and biometric-heavy). But Article 13 transparency, Article 26 deployer obligations for any high-risk system, and the Article 4 AI literacy obligation (effective February 2025) all reach accountants. A practical example: an AI tool used to triage suspicious activity reports (SARs) under the AML framework would likely be high-risk under Annex III(5)(d) "AI systems used for risk assessment in financial services". The accountant deploying it carries the deployer obligations.
The take-away: every AI use case in an accounting firm needs to pass simultaneously through GDPR (Art. 28 + Art. 32), AML (AMLR + AMLA where applicable), national professional secrecy, and — for some narrow categories — AI Act high-risk obligations. Accountant GDPR compliance is multi-regime by default, and the redaction layer is the single technical control that operates across all four.
A short worked example of how the four regimes interact in practice. An accountant uses an AI summarisation tool on a payroll schedule containing one employee whose name surfaced in a recent SAR. The action triggers GDPR Art. 28 (sub-processor question), GDPR Art. 32 (security of processing), Art. 5(1)(b) purpose limitation (the data was collected for payroll, not for SAR triage), the AML downstream-use boundary (you cannot use AML-derived information for unrelated purposes), professional secrecy (the disclosure to the LLM is a third-party disclosure), and potentially the AI Act if the AI tool's output influenced an AML risk decision. Without a redaction layer the breach surface is six-fold. With a redaction layer that masks all employee identifiers before the AI call, the same workflow is defensible across all six dimensions because the LLM never saw an identified data subject.
5. The shadow AI problem inside accounting firms
The shadow AI dynamic we covered in the HR cluster exists in accounting firms too, with different specific risk patterns.
The end-of-quarter shadow workflow. A senior associate working a Saturday before the tax filing deadline pastes a 2,000-row XLSX with employee names, Codice Fiscali, IBANs, and salaries into a personal ChatGPT account to "spot-check the totals". The model sees the entire client roster. The model's logs see it as a request. The session may train the next model version. The firm's Article 30 records see none of it. The client is unaware.
The translation shadow workflow. A practitioner working on a cross-border engagement uses a free translation tool to convert a German employee handbook into Italian. The handbook contains names, employment history, and Steuer-IDs in examples. The free tier of every major LLM-backed translator routes through US compute and retains for training by default.
The summarisation shadow workflow. A manager uses a consumer chatbot to summarise the partner's email thread on a client matter before responding. The thread contains the client's accountant-client privileged communications, third-party PII, and sometimes strategic AML/SAR considerations. This category is particularly insidious because the practitioner does not think of email summarisation as a regulated AI activity.
The professional development shadow workflow. An associate preparing for a CPE module pastes anonymised-but-not-really-anonymised case studies from real clients into a ChatGPT session for explanation. "Anonymised" in this context usually means the client's name has been removed; the tax structure, the geography, and the deal amounts are all intact, and the matter is reconstructible.
In each case the practitioner believes the activity is low-risk because the data is "just text", the action is "just summarising", or the model is "just helping me think". In each case the regulatory exposure is identical: undocumented sub-processor, undocumented international transfer, breach of professional secrecy, potential AML information leak. Accountant ChatGPT use also creates an evidence problem at the next inspection — there is no log to point to and no certificate to show.
The fix is the same architecture we described in the pillar and HR cluster: the official path must be faster than the shadow path, and the redaction layer must be in front of the model. For accountants specifically, the architecture must understand tax IDs, IBANs, and the entity-type distinction between B2B and self-employed. ChatGPT accountant use is not solvable by policy; it is solvable by architecture. To redact tax ID data, redact employee data, and anonymize payroll reliably across the firm's workflow, the architecture must run by default before any AI step, not as an opt-in. The same applies to US-style filings — for firms with US clients, redact 1099 SSN patterns and bank routing numbers are part of the same cascade.
Published numbers on how often professionals paste client data into AI tools come from surveys, vendor telemetry and consumer datasets, which measure different things, and a source-by-source review of shadow AI statistics sets them side by side.
6. The 5-step workflow tuned for accounting documents
The 5-step workflow from the pillar guide applies to accounting documents with three specific tunings.
- Upload (with format awareness). Accept native formats: XLSX (per-sheet structured), PDF digital and scanned (OCR for scans), DOCX (engagement letters, memos), CSV (data exports). Reject upload if the file would be cap-exceeded — typical caps are 100 pages per document and 50 MB per file; both should be configurable per client engagement.
- Detect (with accountant cascade). Dictionary lookup on the client roster the firm uploads (employees, suppliers, related parties), then national regex (CF, Partita IVA, NIR, SIRET, Steuer-ID, USt-IdNr, DNI/NIE, NIF, IBAN, SWIFT), then multilingual NER for names and organisations the regex missed, then OCR for scans. The order matters: dictionary first means the firm's own roster gets canonical-form replacements, regex next means structured identifiers are caught with high precision, NER last means residual names get caught.
- Review (with accountant categories). Show the detected spans grouped by category, not by document position. The reviewer typically wants to verify "all 80 Codice Fiscali → masked" rather than scan through the spreadsheet. The grouped view also makes audit certificate generation cleaner.
- Apply (reversible or irreversible). For AI workflows on tax filings and payroll, reversible is the right default (the accountant needs to read the AI output with the real values restored). For cross-border sharing to a foreign correspondent, irreversible blackout is the right default (the foreign correspondent must not be able to re-identify). The tool must support both from the same upload.
- Certify and route. Generate the SHA-256 certificate. For AI workflows, route the pseudonymised text to the EU LLM and restore locally. For sharing, package the redacted output with the certificate and route to the recipient via the firm's secure transfer channel. The certificate is the artefact you produce to the supervisory authority, to the financial intelligence unit, to the client when they ask "what did you do with my data?", and to your insurer.
A concrete example. The firm uploads a 12-sheet payroll XLSX for an Italian client, 80 employees, with columns for nome, CF, IBAN, retribuzione lorda, ritenute, and note. The dictionary contains the employee roster the firm has previously masked. The regex catches CF on column C (80/80) and IBAN on column D (80/80). The NER catches 14 names in the note column. The review shows 174 spans grouped by category. The reviewer accepts the canonical masks and rejects three false positives. The export is the same XLSX with placeholders on string cells, formulas intact, properties stripped of the producer's name. The certificate logs the input/output SHA-256, the counts per category (80 names, 80 CFs, 80 IBANs, 14 free-text names from the notes), the mode (reversible), and the timestamp. Total elapsed time: under 60 seconds for detection, under three minutes including review. The map is held in Redis for the LLM round-trip and destroyed automatically at TTL.
7. Choosing a redaction tool for an accounting practice
The 8-point checklist from the pillar guide applies; for accountants four points carry extra weight.
Weighted point A — multilingual national identifier coverage. The single most important capability. A tool that handles Codice Fiscale, Partita IVA, NIR, SIRET, Steuer-ID, USt-IdNr, DNI/NIE, NIF, EORI, and IBAN out of the box covers ~95% of the document types that the firm sees. Anything weaker forces you to write your own regex layer and maintain it.
Weighted point B — XLSX cell-aware processing. A redactor that treats XLSX as a bag of cells corrupts your spreadsheets the first time it touches a sheet with formulas. The right tool processes string cells via a structured library (openpyxl is the typical stack) and leaves numeric and formula cells untouched. This is what makes multi-employee XLSX redaction actually work for payroll runs.
Weighted point C — accountant-aware entity types. The tool must distinguish between Partita IVA on a corporate invoice (not PII when the client is incorporated) and Partita IVA on a sole-trader invoice (PII). Without this distinction the tool either over-redacts (destroys B2B workflows) or under-redacts (leaks self-employed PII).
Weighted point D — audit certificate format suitable for FIU. Financial Intelligence Units in Italy (UIF), France (Tracfin), Germany (FIU at the Zoll), and Spain (SEPBLAC) all want artefacts that demonstrate how a given AML-adjacent processing happened. A SHA-256 redaction certificate with hashes and counts but no content is the cleanest evidence to produce to a FIU because it does not create new disclosure obligations. Redactic's certificate format meets this requirement.
The other four checklist points — no-trace architecture, OCR for scans, reversible/irreversible modes, manual review — apply at the standard weight. Redaction software for accountants that gets all eight points right is rare; the build-vs-buy economics typically favour buy because the operational footprint (no-trace + audit + sub-processor management + national regex maintenance) is most of the cost. For workflows touching AI tax preparation GDPR obligations, the choice is further constrained because the tool also needs to expose an audit trail aligned to the tax authority's documentation expectations.
Practically, the firm-level discipline you are buying is accountant data minimization by default: every AI workflow, every shared document, every internal summarisation runs through the redaction layer first. That is the single discipline that satisfies Art. 5(1)(c) GDPR data minimisation, Art. 32 GDPR appropriate security, the AML downstream-use boundary, and the AI Act Art. 4 AI literacy obligation simultaneously. AI bookkeeping privacy for routine workflows (bank reconciliation summarisation, expense classification, invoice extraction) inherits the same architecture; the redaction layer is upstream of every model invocation.
Redactic was designed against this checklist from day one and includes the accountant-specific weighting: 17-country regex coverage including all the national identifiers above, XLSX per-sheet cell-aware processing using openpyxl, configurable entity-type rules for B2B vs self-employed Partita IVA / NIF / NIR, SHA-256 redaction certificate in a FIU-friendly format, GLiNER multilingual NER, Tesseract OCR with the 5-language pack, reversible and irreversible modes, manual review console. The DPA and sub-processor list are public on redactic.eu.
8. Frequently asked questions
As an accountant am I a controller or a processor of my client's payroll data?
You are typically a processor of the employee data and a controller of the client-firm data. The distinction matters because Article 28 obligations attach to the processor relationship: the engagement letter must reference the Art. 28(3) clauses, sub-processors must be disclosed, and you must process only on documented instructions. The Italian Garante and the French CNIL have both issued guidance treating accountants as processors of employee data; the German Datenschutzkonferenz aligns. If your engagement letter does not have an Art. 28 annex, fix it before the next client renewal.
Can I use a free ChatGPT account for "quick" calculations on a client's data?
No. The act creates undocumented sub-processing (Art. 28 breach), undocumented international transfer (Schrems II), and professional secrecy disclosure (Italian Codice Penale art. 622 or the equivalent in your jurisdiction). The fact that the task is "quick" does not change the legal characterisation.
Does AMLD6 require me to retain KYC data I would prefer to delete under GDPR?
Yes. The AML retention obligation (five years minimum from the end of the business relationship under the AMLR; longer under some national transpositions) overrides the GDPR storage-limitation principle for the retention itself. The lawful basis is Art. 6(1)(c) GDPR (legal obligation). What you can do is minimise downstream processing: if the retained KYC dossier is for AML proof, you should not use it for AI training, internal analytics, or client correspondence about a third party.
How does professional secrecy interact with shadow AI use?
Pasting client data into a consumer LLM is, in most EU jurisdictions, a disclosure to a third party (the LLM provider). Professional secrecy is typically a strict-liability offence: the practitioner cannot defend by arguing that "the LLM does not really see the data" because the legal characterisation tracks the disclosure act, not the subsequent use. Italian Codice Penale art. 622 in particular has been interpreted broadly. The safer assumption is that any sharing with an external service outside a signed processor relationship is a breach of professional secrecy.
Should I redact my own data or my client's data?
Your client's data, before sharing externally or feeding to AI. Your own data (firm staff CVs, internal performance reviews) follows the HR redaction rules covered in the HR cluster. The two workflows can use the same tool but the policy basis is different: client data is processor-side processing, own data is controller-side processing.
What is the difference between redacting a tax return and redacting a payroll spreadsheet?
A tax return is typically a single-taxpayer document with concentrated identifiers (the taxpayer's tax ID, dependants' tax IDs, IBANs, employer names). A payroll spreadsheet is a multi-employee document with structured PII columns. The redaction patterns differ: tax returns need single-document entity detection with calculation preservation; payroll needs cell-aware XLSX processing with column-level rules. A tool that handles both natively saves the firm from maintaining two pipelines.
Can I share a redacted client file with a foreign correspondent without a Schrems II assessment?
If the destination is in the EU, the question does not arise. If the destination is in a third country, the redacted file is still personal data if pseudonymised (Art. 4(5)) — only if the file is genuinely anonymised (Recital 26) does it leave GDPR scope. In practice you need either a Standard Contractual Clauses set with the correspondent, an adequacy decision (UK, Switzerland, Israel, etc.), or full anonymisation. A redaction certificate documenting irreversibility helps the anonymisation argument.
Does the EU AI Act apply to AI tools I use for AML triage?
If the tool is used to assess risk of money laundering for a specific client or transaction, it likely falls under Annex III(5)(d) "AI systems used for risk assessment in financial services". That makes it high-risk under the AI Act, with deployer obligations on the accountant: human oversight, monitoring, transparency, record-keeping, and in many cases a fundamental rights impact assessment. The vendor obligations (technical documentation, post-market monitoring, conformity assessment) sit with the provider.
What is the right retention period for the redaction certificate?
At least as long as the AML retention period for the underlying engagement (typically five years from end of relationship). Certificates contain no PII and no content, so retention does not raise its own privacy concerns. We recommend keeping them indefinitely as evidence — the marginal storage cost is trivial and the audit-proof value is high.
Where does Redactic store my client data?
Nowhere persistent. Input and output 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 has no database model for document content. The redaction certificate stores hashes and counts only. Compute and metadata storage are EU (Hetzner Helsinki + Cloudflare R2 EU jurisdiction). The sub-processor list and DPA are public on the trust pages. For accountants the same architecture applies; nothing about the accounting use case bypasses the no-trace guarantee.
One last operational note: the discipline of building a redaction layer in front of the firm's AI workflows also produces a positive side effect on quality. Models work better on cleanly pseudonymised text than on the raw documents because the input is shorter, the salient signal is concentrated, and the model is not distracted by entity-recognition. Tax-filing review agents that received pseudonymised inputs in our internal pilots produced fewer hallucinations on the analytical questions than agents that received raw documents — a small but reproducible quality gain that compounds across thousands of monthly runs. The redaction layer pays for itself once on compliance and a second time on output quality.
If your firm handles tax filings, payroll runs, KYC dossiers, or audit working papers — and it does — every single one of those documents is currently moving through email, drives, and consumer AI tools without a redaction layer in front of them. The cost of doing nothing is not just an abstract regulatory risk; it is a Garante or CNIL inspection waiting for the right trigger, an AMLA query when the framework activates in 2027, a professional secrecy criminal complaint from a disgruntled client, and the indemnity carrier rejecting a claim because the AI use was undocumented. The architecture exists, the regulatory clock is running, and the redaction layer pays for itself in the first audit. Start with the top 10 highest-volume clients this month.
For the foundational architecture see the pillar guide; for the HR-adjacent workflows that interact with payroll see the shadow AI in HR article. To see Redactic on a sample payroll spreadsheet, the redactic.eu landing includes a live demo.