AI Anonymization vs Redaction: Enterprise Privacy Guide

Key Takeaways

• Redaction removes sensitive data permanently and irreversibly — it's the safest option on paper, but it also removes the context an AI model needs to complete complex tasks.
• Anonymization strips or generalizes identifiers with the goal of preventing re-linkage to a person; done correctly, it can take data outside the scope of regulations like GDPR.
• Pseudonymization (commonly implemented through tokenization) swaps identifiers for reversible placeholders, with the original values held in a separate, access-controlled mapping store.
• Semantic placeholders such as or preserve relationships between entities in a prompt — the model can tell that a person and an account are connected without ever seeing either value.
• Not every placeholder is designed to be reversible. Whether a token can be mapped back to the original value depends entirely on how the system that generated it was built.
• Large language models can sometimes infer identity or other sensitive attributes from context clues that survive traditional anonymization — location references, writing style, timing, and rare combinations of facts can all leak information a human reviewer wouldn't notice.
• Regulators, including the European Data Protection Board, have leaned toward treating pseudonymized data as personal data under GDPR when the party processing it could plausibly reverse it — so pseudonymization is not an automatic compliance shortcut.
• Protecting the data going into an AI model is only half the job. Outputs need inspection too, since a model can reconstruct or imply sensitive information even after its inputs were cleaned.
• A privacy-preserving AI architecture typically runs sensitive-data detection, classification, and protection before a prompt ever reaches a model, then inspects and controls what comes back out.
• The right technique depends on the workflow: permanent removal for one-off document review, semantic placeholders or tokenization when the AI needs to reason about specific entities, and carefully governed anonymization for analytics that shouldn't reference individuals at all.

Most enterprise AI privacy failures don't come from a lack of awareness — teams generally know PII shouldn't go into a prompt unprotected. They come from picking a protection method that doesn't match the workflow. A customer support team that redacts every account number out of a prompt ends up with an AI assistant that can't actually help with account-specific questions. A legal team that anonymizes a contract for AI review loses the ability to track which clause refers to which party. Getting this decision right — redaction, anonymization, or a reversible placeholder scheme — is as much an architecture decision as a privacy one, and it's usually made too late, after the AI workflow is already built around the wrong assumption.

What Is AI Data Anonymization?

AI data anonymization is the process of transforming personal or sensitive information so it can no longer be linked back to a specific individual, before that data is used in an AI system. Done properly, anonymized data has no direct identifiers (names, account numbers, emails) and has also been checked for indirect identifiers — combinations of details that could single someone out even without a name attached.

In practice, anonymization for AI workflows usually means one of two things. The first is generalization: turning "42-year-old radiologist in Cedar Rapids, Iowa" into "adult in a medical specialty, Midwest US," which reduces precision enough that the individual can't reasonably be picked out of a crowd. The second is suppression: removing rare or unusual data points entirely, since outliers are often the easiest records to re-identify. A dataset used to fine-tune a model or feed a RAG pipeline for research purposes is a common candidate for this kind of anonymization, because the goal is pattern-level insight, not individual reference.

The catch is that "anonymized" is a claim, not a guarantee. A dataset that looked sufficiently anonymized against a 2015 threat model — a human analyst with a spreadsheet — doesn't necessarily hold up against a large language model that's been trained on enormous amounts of text and is good at inference. That gap is discussed in more detail in the re-identification section below.

What Is AI Redaction?

AI redaction is the permanent removal of specific sensitive values from text or documents before that content is processed by an AI model, typically replaced with a generic marker like [REDACTED]. Unlike anonymization, redaction doesn't try to preserve any information about what was removed — it just takes it out.

Redaction is the right call when three conditions line up: the value doesn't need to come back later, the AI's output doesn't depend on knowing what the redacted value was, and the priority is maximum, unambiguous removal. A common example is preparing a legal filing for public release, where a Social Security number needs to be gone entirely rather than protected-but-reconstructable.

Where redaction runs into trouble is AI accuracy. Because [REDACTED] carries no information, a model reading "the transaction from account [REDACTED] for customer [REDACTED]" has lost the structural thread of the sentence. It can't tell you whether the same customer appears twice elsewhere in the document, and it can't reason about the relationship between the account and the customer, because both have become the same blank token. That trade-off — safety at the cost of coherence — is why redaction and placeholder-based tokenization tend to get used for different jobs inside the same organization.

What Is the Difference Between AI Anonymization and Redaction?

Redaction permanently deletes sensitive data before it reaches an AI model, which protects privacy but strips away the context the model needs to reason about the request. Anonymization also removes identifiers permanently, but it can do so in ways that preserve statistical patterns useful for analysis. Pseudonymization — often implemented as tokenization — replaces identifiers with placeholder values like or that can be reversed later by whoever holds the mapping key. The practical difference comes down to reversibility and context: redaction destroys both, anonymization destroys reversibility while sometimes keeping partial context, and pseudonymization keeps both intact behind a controlled boundary.

Enterprises get this wrong constantly, usually because "anonymization" gets used as a catch-all term in vendor decks and internal policy documents. The distinction matters because it changes two things at once: what the AI model is legally allowed to receive, and how well the AI can actually do its job once you've protected the data. Pick the wrong method and you either create regulatory exposure or you end up with an AI system that can't reference the account number it was asked to review.

What Is a Redaction Placeholder in AI?

A redaction placeholder is a marker inserted in place of a sensitive value that has been removed from text. The simplest version is [REDACTED], used generically regardless of what kind of data was removed. A more useful variant, sometimes called a semantic placeholder, is typed and numbered — [PERSON_1], [ACCOUNT_1], [EMAIL_1] — so the reader (human or AI) knows what category of data was there and can tell repeated references apart.

The difference matters more than it looks. [REDACTED] tells you something was removed and nothing else. [PERSON_1] tells you it was a person's name, and if [PERSON_1] shows up three times in the same document, you know all three references are the same individual, even without knowing who that individual is. That's enough structural information for an AI model to reason coherently about the text — summarizing it, answering questions about it, flagging inconsistencies — without ever seeing the underlying identity.

Semantic placeholders are not automatically reversible. Some systems generate them purely for display or redaction purposes with no mapping stored anywhere, in which case the original value is gone for good, just like [REDACTED]. Other systems generate placeholders as part of a tokenization scheme, storing the mapping in a separate, access-controlled location so an authorized process can restore the original value later. Whether a given [ACCOUNT_1] token can be reversed depends entirely on how the system that produced it was designed — it's not a property of the placeholder format itself.

What Does [ACCOUNT_1] Mean in AI?

[ACCOUNT_1] is a semantic placeholder representing an account identifier — typically a bank account, credit card, or customer account number — that has been removed from text and replaced with a typed, numbered token. The number distinguishes it from other account references in the same document ([ACCOUNT_1] and [ACCOUNT_2] would be two different accounts), and the label tells a reader or a model what category of data was there.

A typical example: the sentence "please review the transaction from account 4111-1111-1111-1111" becomes "please review the transaction from account [ACCOUNT_1]" before it's sent to an AI model. The model can still reason about "the transaction involving [ACCOUNT_1]," summarize it, or flag it — it just never sees the actual account number. If the system is built for reversible tokenization, an authorized process on the enterprise side can later swap [ACCOUNT_1] back for the real account number in the model's output, so the person reading the final response sees the correct information.

Whether [ACCOUNT_1] in a specific system is reversible or a dead end depends on that system's architecture — some tools use it purely as a redaction label with no mapping retained, others use it as a live token tied to a secured lookup table.

What Does [PRIVATE_PERSON] Mean in AI?

[PRIVATE_PERSON] (or the more common variant [PERSON_1]) is a semantic placeholder used to represent a person's name or personal identity within text that's being prepared for AI processing. It functions the same way [ACCOUNT_1] does for account numbers: it tells the reader that a person was referenced at that point in the text, without revealing who.

This label shows up most often in customer support transcripts, contract review, and case-management workflows, where an AI model needs to understand that a conversation or document involves a specific individual — possibly the same individual mentioned multiple times — without the underlying detection or generation pipeline ever exposing the name itself. As with account placeholders, whether [PRIVATE_PERSON] can be reversed back to the real name later depends on whether the system that generated it retained a mapping. Some implementations are strictly one-way redaction; others are part of a reversible tokenization pipeline.

What Is Tokenization in AI?

Tokenization in the AI privacy context is a technique that replaces sensitive values with placeholder tokens before they're sent to a model, while keeping the original values in a separate, access-controlled mapping store. It's a form of pseudonymization — the transformation is reversible, provided you hold the key.

The workflow looks like this: a name, account number, or other identifier gets replaced with something like [PERSON_1] or ACCOUNT_TOKEN_42, the mapping between the token and the real value is stored somewhere the AI model never has access to, the tokenized text goes to the model for processing, and if the output needs to reference the original value, an authorized restoration step swaps the token back before a human sees it.

The reason tokenization gets used over plain anonymization in live AI workflows is that it preserves both privacy and usefulness. The model gets enough structure to do its job — it can tell that [PERSON_1] is linked to [ACCOUNT_1] — while the enterprise retains the ability to show a human reviewer the real names and numbers once the AI's work is done. It's worth being precise here: tokenization doesn't automatically make data exempt from privacy regulation. Because the mapping key exists somewhere, tokenized data is generally still considered personal data under frameworks like GDPR, which shapes how it needs to be governed even after the token swap.

Anonymization vs. Pseudonymization

Anonymization and pseudonymization are often used interchangeably, and that's a mistake with real consequences. Anonymization is meant to be a one-way, permanent transformation — once done correctly, there's no key, no mapping, and no path back to the original identity. Pseudonymization is a reversible substitution: identifiers are replaced with alternate values, but the original data still exists somewhere, and someone with the right access can restore it.

The practical test is simple: if a mapping exists anywhere that could restore the original value, the data is pseudonymized, not anonymized, no matter how the tokens are labeled or how secure the mapping store is. This isn't a technicality — it changes what obligations apply. Truly anonymized data, where re-identification isn't reasonably possible by any party, can fall outside the scope of regulations like GDPR. Pseudonymized data generally does not get that exemption, because the possibility of reversal means the data still relates to an identifiable person in a legal sense.

It's worth being direct about what this doesn't mean. Pseudonymizing data doesn't automatically remove it from GDPR's scope, and anonymizing data doesn't automatically guarantee a legal exemption either — regulators assess this based on identifiability in context, including who else might hold information that could be combined to re-identify someone, and what means are "reasonably likely" to be used. A dataset that looks anonymized in isolation can still count as personal data if it's foreseeable that it could be re-linked using other information available to the processor or a third party. Any organization treating anonymization as an automatic compliance shortcut is making an assumption regulators haven't consistently agreed with.

The table collapses a distinction that's easy to lose in casual conversation: "placeholder" describes what the value looks like in the text, while "reversible" describes what's architecturally possible behind the scenes. A system can use identical-looking placeholders for two very different purposes — one where the mapping is thrown away after use, and one where it's retained under strict access control for later restoration.

Can AI Re-Identify Anonymized Data?

Yes, in some cases. Large language models can infer identity or other sensitive attributes from contextual details that traditional anonymization methods weren't designed to catch, because those methods were built against a different kind of adversary — a human analyst cross-referencing spreadsheets, not a model trained on a large fraction of the public internet.

Research from ETH Zurich, led by Staab and colleagues, demonstrated that LLMs can infer attributes like location, occupation, and sometimes identity from text where the obvious identifiers — names, emails, account numbers — had already been removed. The models pick up on things a human reviewer typically wouldn't flag: a mention of a regional slang term, a reference to a niche professional event, a writing style that's distinctive enough to narrow down a small pool of candidates, or a sequence of dates that only makes sense for one person's known schedule. None of these individually looks like personal data. Combined, they can be enough.

This is why re-identification risk in AI contexts is usually framed around combinations rather than single data points. A birth year alone identifies almost nobody. A birth year, a rare medical condition, and a small city narrows the field dramatically. A rare job title, a specific negotiation outcome, and a reference to "last quarter's board meeting" can be enough to identify a person inside a company even without a name attached. The practical implication for enterprises is that removing the obvious fields (name, email, SSN) is necessary but not automatically sufficient — the surrounding context needs the same scrutiny.

Does Redaction Reduce AI Accuracy?

Often, yes, and the effect is usually proportional to how much context the redacted text loses. Compare two versions of the same request:

Redacted: "Review the transaction involving [REDACTED]."

Semantic placeholder: "Review the transaction involving [ACCOUNT_1] and [PERSON_1]."

The redacted version gives a model almost nothing to work with — it can't tell what was removed, whether it was one entity or several, or whether the same entity is referenced elsewhere in the document. The placeholder version preserves the shape of the request: the model knows there's an account and a person, that they're connected by this transaction, and it can reason about that relationship, summarize it, or flag something unusual, all without ever seeing the real account number or name.

This doesn't mean tokenization always outperforms redaction — for tasks where the AI genuinely doesn't need to reason about the removed value (classifying a document's general topic, for instance), redaction and placeholder-based approaches can perform about the same, and redaction's simplicity and irreversibility make it the better choice. The accuracy gap shows up specifically on tasks that require the model to track relationships between entities, follow a value across multiple mentions, or produce a response that needs to reference the original information after restoration.

How Can Enterprises Prevent PII From Reaching AI Models?

The general approach follows a consistent pipeline, regardless of which specific vendor or tooling an organization uses:

User input → sensitive-data detection → entity classification → policy decision → redaction / anonymization / tokenization → AI model → output inspection → controlled restoration where authorized

Sensitive-data detection is the first checkpoint — typically a named entity recognition layer or similar classifier that scans the incoming prompt or document for known categories of sensitive data: names, account numbers, emails, IDs, health identifiers, and so on. Detection alone doesn't decide what happens next; it just flags what's there.

Entity classification tags each detected item by type, which matters because different categories often warrant different treatment — a customer's public first name might be handled differently from a Social Security number under most policies. Policy decision is where an organization's actual rules get applied: does this entity type get redacted, anonymized, or tokenized for this particular workflow? A healthcare triage assistant and an internal analytics job might apply completely different policies to the same underlying entity type.

The protection step itself — redaction, anonymization, or tokenization — executes the decision, producing the version of the text that actually reaches the AI model. The model then processes that protected version and generates a response. Output inspection checks what comes back: does the response contain anything that looks like it re-introduced sensitive information, whether through inference or an error in the pipeline? Only after that check does controlled restoration happen, where authorized processes swap placeholder tokens back for real values, if the workflow calls for it and the requester is entitled to see the restored version.

How Should Enterprises Protect Sensitive Data When Using AI?

Practically, this means building the pipeline above as infrastructure rather than a one-off filter, and matching the protection method to the workflow instead of applying one technique everywhere. A few patterns show up consistently across enterprises that have done this well.

Detection needs to happen before the prompt is assembled, not after — checking a prompt for PII after it's already been sent to a model is too late to matter. The mapping store for any reversible token needs to sit in infrastructure the AI vendor doesn't have access to, since the whole point of pseudonymization collapses if the party processing the data can also reverse it. Policies need to be entity-type-aware and workflow-aware rather than blanket rules, because a support agent triaging a ticket and a data science team building a training set have very different requirements from the same customer data. And logging matters as much as the protection step itself — for both internal audit purposes and for demonstrating, if asked, exactly what categories of data were detected and how they were handled, without having to log the sensitive values themselves.

None of this is a substitute for legal review of a specific processing activity. What it does is put the organization in a defensible position, with evidence of deliberate, consistent controls rather than ad hoc handling.

Why Protecting AI Inputs Is Not Enough

Input protection stops sensitive data from reaching a model in the first place, which is necessary but not the whole picture. A model can still produce sensitive information in its output even when its input was properly protected — through inference, hallucination, or simply retrieving something from its training data or a connected knowledge base that shouldn't have been surfaced in that context.

There are several failure modes worth naming specifically. Output Data leakage happens when a model's response contains sensitive information it inferred rather than was told directly — filling in a plausible name or number based on context, which can be just as damaging as a direct leak even though it's technically a guess. Unauthorized restoration is a pipeline failure mode where placeholder tokens get de-tokenized for a user or system that shouldn't have access to the restored values, often because the restoration step didn't check the requester's permissions. Downstream systems introduce risk when an AI's output — tokenized or not — flows into logging, analytics, or a second AI system without carrying the same protection policy with it. And without output inspection and auditability, an organization has no way to catch any of the above until something goes wrong externally.

A privacy architecture that stops at the input side is treating the model as a black box that can be trusted once its inputs are clean. In practice, the output side needs the same level of scrutiny — access controls on who can trigger restoration, inspection of generated responses before they're delivered, and audit logs that make it possible to reconstruct what happened if a problem is discovered later.

How Can Legal Teams Use AI on Confidential Contracts?

Contract review is one of the clearer cases for privacy-preserving preprocessing rather than either extreme — full redaction, which destroys the document's usefulness, or sending the contract unprotected, which risks exposing client names, account details, pricing, and negotiated terms to a third-party model.

A realistic example: a law firm wants an AI assistant to flag unusual indemnification language across a batch of vendor contracts. Before the documents reach the model, client names become [PERSON_1], [PERSON_2], and so on; specific contract values and pricing become [AMOUNT_1]; account or reference numbers become [ACCOUNT_1]; and any clause the firm has flagged as containing proprietary or confidential terms gets tagged separately. The model still sees the full structure of each contract — which party has which obligations, how indemnification clauses compare across documents, where language deviates from a standard template — without ever seeing who the parties actually are or what the deal was worth. If the review turns up something that needs a human's attention, the relevant section gets restored to its original form for the reviewing attorney, while the rest of the batch stays tokenized.

This kind of preprocessing reduces exposure meaningfully, but it doesn't by itself make an AI contract review workflow compliant with a firm's confidentiality obligations, client agreements, or applicable regulation — those depend on the specific engagement, jurisdiction, and what the firm has represented to its clients about how their information is handled. Privacy-preserving preprocessing is a control that supports a compliant workflow; it isn't a substitute for the legal analysis of whether that workflow is appropriate in the first place.

Enterprise Use Cases for AI Data Anonymization

Financial services. Sensitive data includes account numbers, transaction histories, and card details. AI workflows range from fraud detection to customer service automation. The privacy problem is that transaction narratives often contain enough embedded detail — merchant names, locations, amounts — to be identifying even after account numbers are removed. Tokenizing account and cardholder details while preserving transaction structure is a common protection strategy, since fraud models generally need to reason about patterns across linked entities rather than isolated numbers.

Healthcare. Sensitive data includes patient identifiers, diagnoses, and treatment histories. AI workflows include clinical documentation support and triage assistance. The privacy problem is that even after removing a patient's name, a rare diagnosis combined with an age and a small geographic area can narrow identification to one person. Protection strategies typically combine entity-level tokenization with generalization of rare or unusual data points before anything reaches a model.

Legal. Sensitive data includes client identities, case details, and negotiated terms, as covered in the contract review example above. AI workflows include document review and e-discovery. The core privacy problem is that legal documents are often uniquely identifying by nature — a contract's specific terms and parties are the whole point of the document. Entity-level tokenization that preserves document structure while removing party identities is the common approach.

BPO and customer support. Sensitive data includes names, account numbers, and payment details flowing through live chat and call transcripts. AI workflows include triage, summarization, and quality monitoring. The privacy problem is scale: thousands of interactions a day, each one a potential exposure point if a transcript with unprotected PII flows into a model or a logging system. Real-time tokenization at the point of intake, before any transcript is stored or processed, is the standard protection strategy here.

HR. Sensitive data includes employee records, compensation, and performance reviews. AI workflows include resume screening and internal analytics. The privacy problem is that employee-level data is both sensitive and, within a company, often re-identifiable even after obvious fields are removed, since job titles and team structures can narrow a dataset to a handful of people. Aggregation and generalization for analytics, combined with strict tokenization for any workflow touching individual records, is the typical approach.

Enterprise analytics. Sensitive data includes customer and operational data used to train models or generate reports. AI workflows include forecasting, segmentation, and reporting. The privacy problem is that analytics teams often want granular data for model quality, which pulls against the goal of minimizing identifiability. Anonymization designed for the specific analytical use case — not a generic one-size-fits-all transformation — is usually necessary to balance those two goals.

Privacy-Preserving AI Architecture

A privacy-preserving AI architecture puts a protection layer between an organization's sensitive data and any AI model that touches it, on both the way in and the way out:

Sensitive enterprise data → privacy/data protection layer → sensitive-data detection → redaction / anonymization / tokenization → policy enforcement → AI model → output inspection → controlled restoration where authorized

In practical terms, this means the protection layer sits in front of every path data takes toward a model — whether that's a live chat prompt, a batch document review job, or a RAG pipeline retrieving from an internal knowledge base. Detection and classification happen first, so the system knows what it's dealing with before any decision gets made. Policy enforcement applies the organization's actual rules — which entity types get which treatment, for which workflows, for which user roles — consistently, rather than leaving it to whichever engineer built a particular integration. The AI model only ever sees the output of that layer, never the raw sensitive data.

The output side mirrors the input side: inspection before delivery, and restoration only when the workflow requires it and the requester is authorized to see restored values. The mapping store, when reversible tokenization is used, needs to live somewhere the AI provider — especially a third-party, cloud-hosted model — cannot reach. That separation is what makes the difference between a privacy control that actually holds up and one that just adds a step without changing who has access to what.

Should You Use Redaction, Anonymization or Tokenization?

A practical way to think through the decision:

If permanent removal is required and nothing downstream needs the original value, redaction or anonymization is the right starting point — redaction for a specific value with no analytical purpose, anonymization when you want to keep some statistical usefulness for research or training data.

If the AI needs to understand relationships between entities to do its job — which account belongs to which customer, which clause applies to which party — semantic placeholders or tokenization are generally necessary, since redaction alone will degrade the quality of the model's output on that kind of task.

If authorized restoration is required — a human reviewer eventually needs to see the real name or account number — reversible tokenization or pseudonymization is the only option that supports that, since anonymization and redaction are designed specifically not to be reversible.

If the goal is analytics or reporting without any need to reference specific individuals, anonymization designed for that particular use case is usually the better fit than tokenization, since there's no need to retain a mapping key that then has to be secured and governed.

This is a starting framework, not universal guidance — the right choice in any specific case depends on the workflow, the applicable regulatory context, and what the organization has actually committed to in its own privacy policies and client agreements. A framework like this narrows the options; it doesn't replace legal or compliance review of a specific processing activity.

How Questa AI Supports Privacy-Preserving Enterprise AI

Questa AI's Blackbox architecture applies the detection-and-protection pattern described above as a layer that sits in front of outbound AI prompts. A named entity recognition step identifies sensitive entities before a prompt is assembled, replaces them with typed, numbered semantic placeholders, and keeps the mapping between those placeholders and the original values inside a local, access-controlled store rather than sending it anywhere near the AI model. The model itself only ever processes the tokenized version — structure and relationships between entities, no identity.

Where restoration is part of the workflow, Questa AI's approach re-personalizes the model's output locally, after the fact, rather than allowing sensitive values to pass through the model in either direction. That's the practical answer to the tension covered earlier in this article: an AI system that needs to reason about specific accounts, customers, or contract terms can still do so, without those values ever leaving the enterprise's own perimeter in a form a third-party model could see.

This is worth stating plainly: Questa AI's architecture is a control that reduces exposure and supports a more defensible privacy posture — it is not a guarantee of GDPR or EU AI Act compliance, and it doesn't replace an organization's existing security infrastructure, DLP tooling, identity and access management, or incident response process. Compliance depends on the specific processing activity, the applicable jurisdiction, and controls well beyond any single product. What a platform like this can do is sit inside a broader enterprise AI architecture as the layer responsible for keeping sensitive values away from models that don't need to see them, while preserving enough structure for those models to still be useful.

Enterprise AI Data Privacy Checklist

• Sensitive-data detection runs before a prompt is assembled, not after it's already been sent
• Policies are defined per entity type and per workflow, not applied as one blanket rule
• Reversible tokens have a mapping store that the AI provider cannot access
• Placeholder tokens are typed and numbered so the AI can reason about entity relationships
• Output responses are inspected before being delivered, not just sanitized on the way in
• Restoration of tokenized values requires authorization and is logged
• Audit logs capture what entity types were detected and handled, without logging the sensitive values themselves
• Anonymized datasets have been checked for indirect identifiers, not just direct ones
• Cross-border data flows account for where the mapping store and detection infrastructure are hosted
• Legal or compliance review has confirmed the chosen technique fits the specific processing activity and applicable regulation

FAQs

Is pseudonymized data still personal data?

Generally yes, under current guidance from bodies like the European Data Protection Board, because the existence of a mapping key means re-identification remains possible. This is context-dependent and shouldn't be treated as a fixed rule for every situation.

What should an enterprise AI privacy layer provide?

Detection and classification of sensitive entities, support for redaction, anonymization, and tokenization depending on the workflow, policy enforcement, output inspection, controlled and audited restoration, and deployment options that keep any mapping store outside the AI provider's access.

How does privacy-preserving AI work?

It works by inserting a protection layer between sensitive data and any AI model that processes it — detecting and transforming sensitive values on the way in, and inspecting and controlling what comes back out, so the model gets enough structure to be useful without ever seeing the raw identifying information.

What is the best approach for protecting sensitive data in LLM workflows?

There isn't a single best approach — the right technique depends on whether the workflow needs to reference specific entities (favoring tokenization), needs permanent removal with no downstream use (favoring redaction), or needs analytical value without individual reference (favoring anonymization).

Conclusion

The gap between redaction, anonymization, and pseudonymization isn't academic — it determines whether an AI system can actually do its job and what regulatory obligations follow the data it touches. Redaction is the bluntest and safest tool when nothing downstream needs the original value. Anonymization trades some context for permanence, useful for analytics and training data. Pseudonymization, usually implemented through tokenization and semantic placeholders, is the only option that lets an AI reason about specific entities while keeping a path back to the real values for authorized use.

None of these techniques is a compliance shortcut on its own. What determines whether a given implementation holds up — legally and practically — is the specific processing activity, who can access the mapping key, what's reasonably foreseeable in terms of re-identification, and how the output side of the AI system is governed, not just the input side. Getting the architecture right means building detection, protection, and output inspection as infrastructure the organization controls, matched deliberately to each workflow rather than applied as a single blanket policy across everything the company does with AI.