PII Redaction Before the LLM: Guide for Banks and Insurers

Your bank cannot paste a loan file into an LLM and hope for the best. The Kenya Data Protection Act restricts personal data leaving the country, and once raw customer data reaches a model provider, no contract clause can pull it back. The workable pattern is to strip identifiers before anything leaves your infrastructure, send only the sanitized text, and restore the original values in the response. This post covers the legal basis, the detection pipeline, the tools, and the real costs.

What the Kenya Data Protection Act says about sending data out

Three provisions matter when a document is about to cross the border into an LLM API.

First, the processing principles in section 25 of the Data Protection Act state that personal data shall not be transferred outside Kenya unless there is proof of adequate data protection safeguards or the consent of the data subject. Second, section 48 sets the conditions for transfer: proof to the Data Commissioner of appropriate safeguards, including transfer to jurisdictions with commensurate data protection laws, or necessity grounds such as contract performance, public interest, or legal claims. Third, section 49 requires the safeguards to be in place before the transfer and proof of them to be produced to the Office of the Data Protection Commissioner on request. For sensitive personal data the bar is higher still: consent of the data subject plus confirmation of appropriate safeguards. Our companion guide covers the Kenya Data Protection Act and AI in banking and insurance more broadly.

The consequences are not theoretical:

Administrative fines up to KES 5 million, or for an undertaking up to 1% of annual turnover of the preceding financial year, whichever is lower (section 63).
Criminal exposure: failing to comply with an enforcement notice carries a fine up to KES 5 million or two years imprisonment (section 58), and the general penalty under section 73 reaches KES 3 million or ten years.
Private claims: under section 65, a data subject can claim compensation for damage, including non-financial loss such as distress.

The ODPC filled in the operational detail in 2026. A draft Guidance Note on Cross-Border Data Transfer went out for public consultation in April 2026, and the final guidance notes were published on September 8, 2026. The guidance names the recognised transfer mechanisms: adequacy decisions, appropriate safeguards using the ODPC's standard clauses for controller-to-controller and controller-to-processor transfers, binding corporate rules with an approval process, necessity, and consent. It also expects transfer agreements, a data protection impact assessment, and documented safeguards to be retained for inspection. Kenya and the European Union are meanwhile in an adequacy process, with the European Commission reporting a positive assessment in June 2026. The practical effect: transfer documentation is becoming an expected artefact, and redaction shrinks the number of flows that need it at all.

Now look at the provider side. Anthropic's privacy policy states that personal data may be transferred to and stored in the United States and other countries where subprocessors operate. The same policy explicitly does not apply to content processed on behalf of enterprise customers, which is governed by customer agreements instead. So a bank using the API under an enterprise agreement is on better contractual footing than an employee pasting data into a consumer chat window, but the Act's obligations still sit with you as the data controller. A cross-border transfer has happened either way. The question is whether what crossed the border was still personal data.

Why redaction works: anonymisation takes data out of scope

Section 2 of the Act defines anonymisation as the removal of personal identifiers from personal data such that the data subject is no longer identifiable. Properly anonymised text is no longer personal data, and the transfer restrictions stop applying to it. That definition is the legal engine of this entire pattern.

Two cautions keep this honest:

Pseudonymisation is not anonymisation. If you replace "Wanjiru Kamau" with "PERSON_1" and keep a mapping table, the mapped data is still personal data in your hands. That is fine, even desirable for many workflows, but the mapping table itself must stay inside your infrastructure and under the Act's protections.
Anonymisation must be real. A claim file with the name swapped but the national ID number, phone number, and exact dates intact is still identifiable. Partial redaction gives you the worst of both worlds: false comfort and full legal exposure.

The practical target for most bank and insurer workflows is pseudonymisation at the boundary: replace every identifier with a stable placeholder, send the placeholder text to the model, and restore values locally. The model never sees anything it could memorise or leak, which matters because research has shown that generative models can reproduce exact sensitive strings, including phone numbers and email addresses, from data they have processed.

The four-layer detection pipeline

No single detection method is reliable enough on its own. The strongest setup layers deterministic checks, statistical models, and custom rules, and the evidence for layering is direct. The PRvL study (arXiv 2508.05545) benchmarked PII redaction approaches and found that regex is fast and interpretable but does not generalise across domains or languages, while NER models work only in their training domain. The same study measured what happens when you ask a general-purpose LLM to redact its own input: a vanilla Llama 3.1 8B scored 0.431 ROUGE-1 on the redaction task versus 0.910 for an instruction-tuned variant, and GPT-4 scored 0.540 without support versus 0.928 with retrieval support. Asking the model to clean up after itself is the fragile option.

Build the pipeline in this order:

Layer 1: Regex and checksums for structured identifiers

Account numbers, card numbers, phone numbers, and ID numbers follow patterns. Deterministic matching catches them with near-perfect precision. Microsoft's Presidio, the open-source SDK most teams start with, ships recognizers that combine patterns with checksums: CREDIT_CARD validates with the Luhn algorithm, IBAN_CODE validates its checksum, EMAIL_ADDRESS follows RFC-822. Checksums kill the false positives that raw regex produces on lookalike numbers.

Layer 2: NER for free-text entities

Names, locations, and dates have no pattern. Named entity recognition catches "Wanjiru Kamau" or "Kisumu" in flowing prose. Presidio includes PERSON, LOCATION, and DATE_TIME recognizers across several languages.

Layer 3: Custom recognizers for Kenyan identifiers

This is where generic tooling stops and local work starts. Presidio's supported entities list has country-specific sets for the US, UK, Spain, Italy, and others, but nothing for Kenya. National ID numbers, KRA PINs, and NHIF or SHA numbers need custom recognizers. Presidio documents the process, and a recognizer is short:

from presidio_analyzer import Pattern, PatternRecognizer

kra_pin_recognizer = PatternRecognizer(
    supported_entity="KRA_PIN",
    patterns=[Pattern("kra_pin", r"\b[A-Z]\d{9}[A-Z]\b", 0.6)],
    context=["kra", "pin", "tax", "revenue"],
)

The context words raise the score when the surrounding text confirms the entity. Tune the patterns against your own documents with your data protection officer; treat the example above as a starting point, not an authoritative format definition.

Layer 4: A small local model for edge cases

For high-sensitivity flows, add a small language model running inside your network as a final reviewer. Lawrence Berkeley National Laboratory's PII guidance describes exactly this pattern with a privacy-filter model that emits placeholders such as [PRIVATE PERSON] and [PRIVATE EMAIL]. Reserve this layer for genuinely sensitive flows; it adds latency and operational burden that routine traffic does not need.

Rollout discipline

Run each new layer in warn-only mode before you let it block anything. The rollout guidance in MLflow's PII redaction article is the right sequence: deterministic detection first, then NER in observe mode against your real traffic long enough to see what it actually catches, then enforcement. Flipping a block on day one means operations teams spend week one routing around your gateway.

Reversible placeholders and the mapping vault

Detection is only half the design. What you substitute determines whether the workflow still functions.

Use stable, typed placeholders. "Wanjiru Kamau" becomes [PERSON_1] everywhere in the session, "0712 345 678" becomes [PHONE_1]. The model output stays coherent, and downstream logic can rely on consistent tokens.
Keep the mapping local. The table from placeholder to real value lives in memory or a secure store on your side, scoped to the session, and is never transmitted to the model. LBNL's guidance is blunt on this point: never transmit the mapping to the LLM.
Restore after the response. When the model returns "The claimant [PERSON_1] reported the incident on [DATE_1]", your gateway swaps the originals back before the result reaches a screen or document.
Log every substitution. A versioned audit log of what was redacted, by which recognizer, in which session, is what turns your pipeline from a hope into a control you can show the Data Commissioner or an internal audit committee.

Choose irreversible redaction when the workflow never needs the original values back, for example when producing training data or sharing documents with an external analytics vendor. Reversible placeholders earn their complexity when a human reads the final output and needs real names and figures.

Where redaction runs: the gateway pattern

Redaction belongs at the boundary, in a gateway or proxy that every LLM-bound request passes through. Two design points matter.

First, redact before send, not after receipt. Once raw PII reaches your server's memory or logs, the handling obligation is already incurred; cleaning it up later does not reduce your compliance scope. Second, treat your own logs as a leak path. If the gateway redacts the request to the model but your application logs the raw prompt first, you have built an expensive bypass around your own control. Redact upstream of logging, and audit what your observability stack captures.

If the underlying records sit in a database that feeds many flows, fix the source too: redaction at the boundary protects each request, but a database full of raw PII remains a liability for every future integration you build.

Tooling and real costs

Three realistic options, with current numbers:

Microsoft Presidio (self-hosted). Open source, no licence cost, runs as Python, Docker, or Kubernetes, and supports custom recognizers, multiple languages, and image redaction. Your cost is infrastructure: a modest VM handles substantial text volume because NER on CPU is fast for document-scale traffic. Presidio's own documentation warns that automated detection has no guarantee of finding all sensitive information, so budget for testing and additional protections.
AWS Bedrock Guardrails (managed). Per the Bedrock pricing page, sensitive information filters cost $0.10 per 1,000 text units, while regex-based sensitive information filters are free. A text unit is up to 1,000 characters, and the Guardrails documentation confirms the filters are ML-based, context-dependent, and can block or mask inputs and responses.
Google Cloud Sensitive Data Protection. A broader de-identification toolbox: replace, redact, mask, shift dates, or encrypt with format-preserving encryption, including surrogate info types that support re-identification later. Date shifting is the right answer when chronology matters, such as claims timelines, but exact dates would identify the claimant.

A worked example

Take an insurer summarising 100,000 claim pages a month through an LLM, averaging 3,000 characters each. That is 300 million characters, or 300,000 text units under the AWS definition. The cost breakdown:

Bedrock ML-based PII filter: 300,000 units at $0.10 per 1,000 units is $30 per month.
Regex layer: free on Bedrock, and free everywhere else.
Self-hosted Presidio: licence cost is zero; a single small VM covers this volume.
LLM tokens: the same on every path, since redacted text is roughly the same length as the original.

Detection is the cheap part of this architecture. The real investment is engineering time: writing Kenyan-format recognizers, tuning thresholds against real documents, and running the warn-only period properly.

When redaction is the wrong choice

Be honest about the limits:

Crown-jewel data. Medical records, full account ledgers, trading positions: if a miss would be catastrophic, do not redact-and-send at all. Keep everything in-country with a privately deployed open-weight model; our comparison of VPC, on-premise, and managed API deployment for banks walks through the trade-offs. Our guide to fine-tuning Llama on bank policy documents inside your own VPC covers that architecture.
Tasks that need the identities. Redaction works when the task is about content: summarising, classifying, extracting, drafting. If the task requires reasoning over the actual identities across records, placeholder text will not carry it.
Guaranteed recall requirements. Every automated detector misses things. Presidio says so in its own documentation. If your risk framework requires certainty, redaction is one control among several, not the control.
Very low volumes. A team sending twenty documents a month can review manually. The gateway pays off when volume or headcount makes manual review the bottleneck.

A step-by-step build procedure

Inventory the flows. List every place a document or prompt leaves your network for a model: API integrations, RAG pipelines, employee chat usage, vendor tools.
Define the entity list with your DPO. Statutory categories plus Kenyan identifiers: names, ID numbers, KRA PINs, phone numbers, account numbers, card numbers, emails, addresses, dates where identifying.
Stand up the gateway with the regex layer. Deterministic recognizers for structured identifiers, deployed as a proxy in front of all LLM calls.
Add NER in warn-only mode. Run two to four weeks against real traffic, review false negatives with actual document samples, tune thresholds.
Add custom recognizers for Kenyan formats. Build and test them against your own documents, not synthetic examples.
Turn on enforcement with the vault and audit log. Session-scoped mapping, substitution logs, alerting on detection-rate anomalies.
Red-team quarterly. Probe with adversarial inputs: homoglyph substitutions, leetspeak, split tokens, PII embedded in unusual contexts. Our guide on red-teaming an LLM before a bank or insurer deploys it has the testing framework.

Common mistakes

Regex only. Structured patterns miss every name in free text. The PRvL results show patterns fail to generalise; layer the methods.
Trusting the vendor policy as the whole control. "We do not train on your data" is a contractual promise, and Anthropic's consumer and enterprise terms genuinely differ. Contracts help, but architecture that never exposes the data is the stronger position.
Blocking before tuning. Enforcement on day one, before the warn-only period, produces alert fatigue and workarounds.
Leaking the vault. Storing the placeholder mapping next to the model client, or worse, logging it, defeats the design.
Over-redaction. Blanking every date destroys claims chronologies and credit timelines. Use date shifting or typed placeholders that preserve the information the task needs.
Redacting downstream of your own logs. If raw prompts hit application logs before the gateway, the gateway is theatre.

Frequently asked questions

Is anonymised data still covered by the Kenya Data Protection Act? No. Section 2 defines anonymisation as removing identifiers so the subject is no longer identifiable, and properly anonymised data falls outside the personal data regime. Pseudonymised data, where you hold a mapping, remains personal data and stays fully regulated.

Does Anthropic train models on my API data? Anthropic's consumer privacy policy allows inputs to be used for training with an opt-out, but that policy explicitly does not cover content processed for enterprise customers, which is governed by customer agreements. Redaction is still worth doing: it limits what any agreement has to protect and covers every provider at once.

Is regex enough for a bank? No. Regex catches structured identifiers reliably but misses names and free-text entities entirely, and research shows patterns do not generalise across domains. Combine regex with checksums, NER, and custom recognizers for Kenyan formats.

Can I just ask the LLM to redact the document for me? It is the fragile option. Benchmarks show vanilla models miss large amounts of PII, while specialised or supported configurations perform far better. Detection should happen in deterministic tooling before the model is involved, not inside the model itself.

What does PII redaction cost at scale? Managed filtering is cheap: AWS charges $0.10 per 1,000 text units for ML-based sensitive information filters, which works out to roughly $30 a month at 300 million characters, and regex filters are free. Self-hosted Presidio has no licence cost. Engineering time for tuning and testing is the real budget line.

Where to go from here

Redaction at the boundary is one layer of a defensible AI architecture for a regulated institution; the others are private deployment for the sensitive flows, evaluation, and governance documentation that survives an audit. We do this work for banks and insurers through our enterprise AI practice, and implement Anthropic's agents for fund administration, research, and advisory teams through Claude for financial services. If you are scoping a deployment, start with the flow inventory in step one; it tells you more about your risk than any vendor questionnaire will.

PII Redaction Before the LLM: A Guide for Banks and Insurers