How Do You Strip Sensitive Data Out of a Document Before It Reaches a Cloud AI Model?

Detailed Explanation

If a business wants to use a cloud AI model on something that contains customer names, account numbers, health details or other sensitive fields, there are really only two honest options: don't send that data at all, or strip the sensitive parts out first and send only what the model actually needs to do its job. This page is about the second option — the mechanics of removing sensitive fields automatically, before a document or piece of text reaches a cloud model, rather than relying on someone remembering to do it by hand.

The distinction that matters here is between masking and tokenisation, and between a step that's optional and one that isn't.

Masking replaces a sensitive value with something generic — a name becomes [REDACTED], or every digit of an account number becomes X. It's simple, but it's a dead end: once the value is gone, there's no way to bring it back, which means the cloud model's response can't reference the original detail either.

Reversible tokenisation replaces a sensitive value with a placeholder that maps back to the original — a name becomes [PERSON_1], an account number becomes [ACCOUNT_REF_A] — and keeps that mapping in a lookup table that never leaves the business's own systems. The cloud model works entirely with placeholders, has no way to see the real values, and returns a result built around those same placeholders. A local step then swaps the placeholders back to real values before anyone reads the output. This is what makes it possible to get a genuinely useful result back — a drafted email that correctly addresses the customer by name, a summary that references the right account — without the cloud model ever having seen who that customer actually is.

Where This Sits in the Pipeline

The step has to run before the cloud API call, not as part of it, and it has to run every time, automatically. In practice this means:

1. Detection — an automated process scans the outgoing content and identifies sensitive fields. This typically uses a mix of pattern matching (account number formats, dates of birth, TFNs, phone numbers) and named-entity recognition (identifying that a particular word is a person's name or an organisation) rather than a fixed list of exact values, because sensitive content doesn't come in a predictable shape.
2. Replacement — each detected field is swapped for a placeholder token, and the mapping between placeholder and real value is stored locally, not sent anywhere.
3. The cloud call — only the tokenised version of the content goes to the AI model. The model performs its task — drafting, summarising, classifying, extracting structure — on data that no longer identifies anyone.
4. Re-identification — the model's response comes back referencing the placeholders, and a local step substitutes the real values back in before a person sees the result.

One open-source project that implements this kind of detection-and-anonymisation pipeline is Presidio, originally released by Microsoft and, during 2026, transferred to the community-governed Data Privacy Stack project. It's a useful reference point for what the detection layer actually has to do — recognising dozens of entity types across unstructured text — even for a business that ends up buying a packaged tool rather than running Presidio itself.

Why This Has to Be a Hard Dependency, Not Optional Middleware

The single most common way this fails in practice isn't a bad detection model — it's the step being skippable. If redaction runs as an optional add-on that a developer can bypass, a workflow can call, or a setting can disable, then sooner or later a version of the workflow goes live without it, and nobody notices until sensitive data has already left the business. Because there's usually no error message when redaction doesn't run — the AI call still succeeds, it just succeeds with more information than it should have had — this kind of failure is silent by default.

The practical fix is architectural, not procedural: build the pipeline so a cloud AI call cannot execute without first passing through the redaction step, the same way you'd build a payment flow so it can't skip the fraud check. A written policy telling staff to "always redact before uploading" doesn't survive contact with a busy Friday afternoon; a pipeline that makes the unredacted path unreachable does.

Things to Consider

• This is risk reduction, not anonymisation. Removing obvious identifiers doesn't always make data anonymous under the Privacy Act 1988 — if the remaining content is detailed enough, or a rare combination of surviving fields still points to one person, it can still be personal information. Redaction narrows what a cloud vendor sees; it doesn't automatically move a business outside its Australian Privacy Principles obligations for that data, including APP 8's rules on cross-border disclosure to an overseas AI vendor.
• This is a different mechanism from redacting a document before sharing it with a person. If the intent is a one-off document being sent to a human recipient — a lawyer, an auditor, a customer — see how do you automatically redact sensitive information from documents before sharing them. This page covers an automated, inline, usually-reversible step built into an AI pipeline itself, not a document prepared for a person to read.
• It complements, rather than replaces, the plan-and-vendor checks that already apply. Whether a cloud AI tool is appropriate for a given piece of data still depends on the vendor's plan, its terms of service, and its data processing agreement — see is it safe to put company data into AI tools for that broader assessment. Redaction reduces what's at stake if the answer to that question is "proceed with caution" rather than "don't."
• Processing location still matters for what's left. Even a tokenised, redacted payload is still content leaving the business, and where the cloud model processes and stores it remains a live question — see does it matter which country an AI tool stores your data in for why that's a separate check from redaction.
• A standing connection changes the calculation. If an AI assistant is connected to a business system via a feature like ChatGPT's connectors, Claude's connectors, or Copilot's Graph connectors, rather than being fed content manually, the same stripping logic needs to sit at the connector boundary — see what are AI assistant connectors, and is it safe to plug in your business apps for what to check before approving one.
• For a managed alternative to building this yourself: see how a Glivent Hybrid workflow keeps sensitive fields on the local system and sends a cloud model only what a defined task needs.

Common Mistakes

• Treating masking and tokenisation as the same thing. Masking is a dead end — once a value is replaced with [REDACTED], the workflow can never reference the real value again. Reversible tokenisation is what makes a genuinely useful AI response possible without exposing the underlying data.
• Building redaction as an optional step rather than a hard dependency. If a workflow, a developer, or a setting can bypass it, it eventually will be bypassed — usually without anyone noticing, since the AI call still returns a result either way.
• Relying on a fixed list of terms to redact. Sensitive fields — names, addresses, account numbers, case references — don't come from a fixed vocabulary. Pattern matching and named-entity recognition catch what a static keyword list misses, and even then, review the detection accuracy for your specific document types rather than assuming it catches everything.
• Assuming redaction alone satisfies privacy obligations. Stripping identifiers is a control, not a compliance certificate — the underlying Privacy Act obligations on the business, including for cross-border disclosure, still apply to whatever data is involved before it was tokenised.
• Skipping the re-identification step's own security. The lookup table mapping placeholders back to real values is itself sensitive data, and needs the same access controls as the source records — a redaction pipeline that leaves that mapping unsecured has just relocated the risk rather than removed it.