PII Scrubber Reference

What Is PII?

When developers, compliance officers, and privacy advocates discuss protecting sensitive data, they center the conversation on PII, the category of information that makes a person identifiable, either directly or in combination with other fields.

What is personally identifiable information?

Direct versus indirect PII

Direct PII is a field that alone identifies an individual: an SSN, a passport number, or a biometric scan. Indirect PII requires combination: a date of birth plus a ZIP code plus a gender can identify a specific person in most US counties, even though none of the three fields alone is identifying. Consequently, data minimization under GDPR and CCPA applies to both categories, and limiting what indirect fields are shared is just as important as removing direct identifiers. The challenge is that indirect PII looks innocuous and often survives data cleaning processes designed only for obvious identifiers.

Research by Latanya Sweeney at Harvard demonstrated that 87% of the US population can be uniquely identified using only three data points: date of birth, gender, and five-digit ZIP code.² This finding fundamentally changed how regulators evaluate de-identification, because fields that appear harmless in isolation become powerful identifiers when combined. For teams building data pipelines or preparing datasets for AI training, this means that removing names and SSNs alone is insufficient if birth dates, locations, and demographic fields remain in the output.

PII in technical and business systems

Technical systems generate PII in forms that non-compliance teams often overlook: IP addresses confirmed as PII under GDPR, session tokens linked to specific authenticated users, email addresses used as database primary keys, and internal usernames embedded in log files. Building on this, business systems store PII in structured tables such as CRM and HRIS platforms, unstructured documents including contracts and emails, and semi-structured data like JSON API responses and CSV exports. Each system requires a different approach to PII discovery and removal, and the 22 pattern types that the scrubber detects cover the most common machine-readable formats across all these sources.

Log files deserve particular attention because they accumulate PII silently over time. A single day of web server access logs can contain thousands of IP addresses, authenticated user email addresses in session cookies, and internal hostnames that map to specific teams or services. When developers paste these logs into AI tools for debugging help, they transmit this accumulated PII in a single action. Treating log files as PII-bearing sources, rather than as inert technical data, is a shift that many engineering teams have not yet made.

PII in the context of AI tools

AI tools receive PII through prompts in two ways: intentionally when users paste customer data for analysis, and accidentally when developers include log files or config data that contain identifiable information without realizing it. Yet most AI providers are not GDPR-compliant data processors for PII, as their default terms of service do not constitute a data processing agreement. Removing PII before sending a prompt means the AI provider receives no personal data, sidesteps the regulatory relationship, and eliminates both the compliance obligation and the data breach risk from a potential provider-side incident.

The scale of accidental PII exposure through AI tools is larger than most organizations recognize. A 2026 analysis of enterprise AI usage found that more than 40% of prompts submitted to generative AI tools contained at least one PII element, with email addresses and internal hostnames being the most commonly exposed types.³ This means that on any given day, a mid-size company with an active AI-assisted workflow may be transmitting hundreds of personal data elements to external providers without any formal data processing agreement in place.

Intentional versus accidental PII exposure in AI prompt workflows

AI tools receive PII through two distinct pathways. Intentional exposure occurs when users deliberately include customer records, employee data, or personal information in a prompt for analysis. Accidental exposure occurs when users include PII embedded in files they paste for technical help: log files with customer IP addresses, config files with developer email addresses in comments, stack traces with connection strings containing credentials linked to named accounts.

The accidental pathway is harder to prevent with policy alone because the user often does not recognize the PII before pasting. A developer debugging a connection error may not think of the database password in the error message as PII, even though it is a credential linked to a named service account. Pattern-based detection at the point of paste catches the accidental pathway by scanning for known PII formats in whatever text is submitted, regardless of whether the user recognized it as sensitive.

Why policy alone does not prevent accidental PII exposure

Acceptable-use policies for AI tools require employees to recognize PII before submitting it. Recognition is the failure point: people are reliable at identifying names and obvious personal identifiers, but not at identifying indirect PII (IP addresses, session tokens, connection strings with embedded credentials). Supplementing policy with a technical control that runs before the paste closes the gap between policy intent and actual behavior. The scrubber serves as that technical control at zero deployment cost.

Cross-border PII transfers to third-country AI providers

GDPR Article 46 governs transfers of personal data to third countries outside the EU and EEA. Most major AI providers (OpenAI, Anthropic, Google, xAI, and Microsoft Azure OpenAI) process data on US-based infrastructure, making each prompt containing EU personal data a potential Article 46 transfer.⁴ Standard Contractual Clauses (SCCs) or an adequacy decision are the required legal mechanisms for these transfers; for teams using AI providers without a qualifying SCC in place, sending EU PII in prompts may constitute an unauthorized cross-border transfer.

Removing EU personal data before the prompt eliminates the Article 46 transfer question. If the prompt contains no personal data within GDPR's definition (no direct identifiers, no indirect identifiers that link to identified individuals), no cross-border transfer of personal data occurs, and Article 46 does not apply to that prompt. This approach addresses the transfer risk at the data level rather than requiring a legal mechanism with each AI provider you use.

UK GDPR and post-Brexit transfer considerations

UK GDPR, which applies to UK-established organizations processing data about UK data subjects, has equivalent transfer restrictions to EU GDPR Article 46. The UK Information Commissioner's Office has issued International Data Transfer Agreements (IDTAs) as the UK equivalent of SCCs.⁵ For organizations subject to both EU GDPR and UK GDPR, scrubbing before AI submission satisfies the transfer restriction for both frameworks simultaneously by ensuring no personal data under either definition reaches the AI provider.

Technical PII detection: patterns, coverage gaps, and false positives

Regex-based PII detection covers structured formats with high accuracy: email addresses, Social Security Numbers formatted with hyphens (123-45-6789), IBANs (GB29NWBK60161331926819), credit card numbers validated against the Luhn algorithm, and IPv4 addresses in dotted-decimal notation. These formats have low false-positive rates because the combination of format and checksum validation makes accidental matches rare.

Coverage gaps exist for unstructured PII that does not follow a detectable pattern. Personal names, physical addresses, birthdates in prose form, and narrative health information cannot be reliably detected by pattern matching because they share no distinguishing structural property. For text containing these types of PII, the scrubber removes the machine-detectable structured identifiers while manual review addresses the unstructured fields.

Reviewing the variables file to audit detection accuracy

The variables file produced after scrubbing lists every detected value alongside its token. Review this file after each scrubbing session to confirm that all expected PII types were caught and that no unexpected values were flagged as false positives. A legitimate 16-digit product SKU that passes the Luhn check may be detected as a credit card number⁶; note the false positive and verify it does not appear in the scrubbed output if restoration accuracy matters for your use case. This review step takes 30 to 60 seconds and provides a PII audit record for the text you shared.

That review record is itself a governance asset, because it documents exactly what was tokenized before any data left your control. CapyToolkit runs the scrubber locally in your browser, so the PII you paste is never transmitted to a server, and the variables file is the only artifact that links the tokens back to the original identifiers.

Try in the tool

What Is PHI?

In healthcare privacy law, not all patient data is equally protected. PHI (Protected Health Information) is the specific legal category that triggers HIPAA obligations, and understanding its boundaries determines when healthcare organizations need to de-identify before sharing data with AI tools.

What is protected health information?

The 18 HIPAA Safe Harbor identifiers

HIPAA's Safe Harbor de-identification method requires removing all 18 categories of identifiers to achieve de-identified status: names, geographic data smaller than a state, dates except year, phone numbers, fax numbers, email addresses, SSNs, medical record numbers, health plan beneficiary numbers, account numbers, certificate and license numbers, vehicle identifiers, device identifiers, URLs, IP addresses, biometric identifiers, full-face photographs, and any other unique identifying number or code.² Consequently, a patient record that removes 17 of the 18 is still identified under HIPAA, and all 18 must be removed.

The all-or-nothing nature of Safe Harbor is what makes it both rigorous and difficult to achieve in practice. A radiology report that removes the patient name, date of birth, and medical record number but retains the referring physician's name and the imaging facility identifier has not met the standard, because the physician name and facility can indirectly identify the patient when combined with external knowledge. This strictness is why many healthcare organizations prefer the expert determination method, which allows a qualified statistician to certify that re-identification risk is very small even when some quasi-identifiers remain.

ePHI and digital healthcare workflows

ePHI is PHI in electronic form, including text, images, databases, spreadsheets, and anything transmitted over a network.³ When a clinician copies patient notes into an AI chat interface, the copied text is ePHI if it contains any of the 18 identifiers and health information. Building on this, API calls from EHR systems that include patient identifiers are ePHI in transit, covered by HIPAA Requirement 4. Yet the most common ePHI exposure pathway in 2026 is not API calls; it is staff members manually copying patient data into AI productivity tools without pre-scrubbing.

The shift to cloud-based EHR platforms has amplified this risk significantly. When a healthcare organization runs Epic on Azure or Cerner on AWS, the EHR data already resides on a cloud provider's infrastructure with a BAA in place, but the moment a clinician copies a patient summary from the EHR and pastes it into a non-BAA AI tool, that data leaves the protected environment. The BAA with the cloud provider does not extend to the AI tool, creating a gap that the scrubber closes by removing identifiers before the data reaches the unprotected system.

PHI, BAAs, and AI tools

Any vendor that creates, receives, maintains, or transmits ePHI on behalf of a covered entity must sign a Business Associate Agreement (BAA). Most consumer and developer AI tools, including ChatGPT free tier, Gemini standard, and Claude.ai without an enterprise agreement, are not covered by a BAA. Conversely, Microsoft Azure OpenAI with a healthcare BAA and dedicated health AI platforms do offer BAAs.⁴ For teams without a BAA with their chosen AI tool, removing PHI before the prompt is the only HIPAA-compliant path to using that tool for healthcare-adjacent work.

The BAA landscape for AI tools is evolving rapidly. Microsoft offers BAAs for Azure OpenAI Service, which covers GPT-4 and other models accessed through the Azure platform, but not the same models accessed through the consumer chatGPT.com interface. Google provides BAAs for Google Cloud healthcare API and certain Workspace services, but not for the standard gemini.google.com consumer interface. Understanding which specific service tiers are covered by each provider's BAA is essential for healthcare organizations that want to use AI tools on PHI-containing workflows.

Electronic PHI and the digital transmission threshold

Electronic PHI (ePHI) is PHI in any electronic format: text files, spreadsheets, email, database records, audio transcriptions, and data transmitted over a network. The HITECH Act extended HIPAA's PHI protections explicitly to ePHI, adding breach notification requirements and increased penalties for electronic disclosures. When a clinician copies patient notes from an EHR into a chat AI interface, the copied text becomes ePHI in transit the moment it crosses a network connection to a third-party server.

Every AI prompt submission from a healthcare organization's device to an external AI provider is a network transmission. If the prompt contains any of the 18 HIPAA identifiers combined with health information, it qualifies as ePHI transmission under HITECH. The covered entity's HIPAA security rule obligations (access controls, audit controls, transmission security) apply to that ePHI in transit. Removing the identifiers before the prompt eliminates the ePHI classification of the transmitted content, taking the transmission out of HIPAA scope.

ePHI in image and audio inputs to multimodal AI tools

Multimodal AI tools that accept images and audio (including GPT-4o, Gemini 2.0, and Claude 3) can process photos of patient forms, audio recordings of clinical conversations, and screen captures of EHR interfaces. Each of these input types is ePHI in electronic form if it contains patient identifiers combined with health context. For image inputs, review and redact visible text labels before uploading; for audio inputs, transcribe and scrub the transcript before pasting for AI analysis.

The minimum necessary standard and AI prompt construction

HIPAA's minimum necessary standard (45 CFR §164.502(b)) requires that PHI use and disclosure be limited to the minimum amount necessary to accomplish the stated purpose.⁵ Pasting a complete patient record into an AI tool when only the medication list section is relevant to the AI task violates the minimum necessary standard: you have disclosed more PHI to the AI provider than the task required.

The scrubber operationalizes minimum necessary at the prompt level in two ways. First, scrubbing removes the structured identifiers (SSN, email, phone) that are almost never necessary for clinical AI tasks: an AI summarizing a discharge note does not need the patient's phone number to produce the summary. Second, the scrubbing step encourages you to consider what content is actually needed before pasting, rather than selecting the entire document out of convenience.

Applying minimum necessary to database queries for AI analysis

Healthcare revenue cycle teams use AI to analyze claim denial patterns, coding accuracy, and reimbursement trends. These analyses require claims data but not patient-level identifiers. Before passing claims data to an AI tool, exclude the patient identifier columns from the query and scrub any that remain in the result set. The AI can identify denial patterns from procedure codes, payor codes, and adjustment reason codes without ever receiving a member ID or patient email.

PHI in AI model training: OCR guidance and organizational exposure

The HHS Office for Civil Rights (OCR) issued guidance in 2024 clarifying that using PHI to train AI models without patient authorization constitutes a HIPAA violation.⁶ Healthcare organizations that use AI tools without BAAs, or that use AI tools with BAAs that permit training use, may inadvertently contribute patient data to AI model training. Standard consumer AI tools do not offer BAAs, and their terms of service typically permit using submitted content to improve models.

Reviewing AI provider data handling documentation before deploying any AI tool for healthcare workflows determines the training use status of submitted PHI. For providers where training use cannot be excluded, removing PHI from prompts before submission is the only available control. When PHI never reaches the AI provider's infrastructure, it cannot enter the training pipeline regardless of the provider's training use terms.

Audit trails for PHI-adjacent AI workflows

Healthcare organizations subject to HIPAA must maintain audit trails of PHI access and disclosure. For AI-assisted workflows where PHI is used to construct prompts, document which staff submitted which type of PHI content to which AI tool in your access log, along with the date and the purpose. This documentation supports HIPAA audit requirements and provides evidence of minimum necessary compliance if OCR reviews your AI usage patterns. Scrubbing before submission simplifies this audit trail: you log the scrubbed submission rather than the full PHI content, keeping the audit record's own storage requirements out of PHI scope.

Keeping the audit trail itself out of PHI scope reduces the storage and access controls your organization must apply to it. CapyToolkit runs the scrubber locally in your browser, so the patient identifiers are tokenized before any transmission reaches an external system, and the variables file is the only artifact that maps the tokens back to the real PHI for your own later audit if needed.

Try in the tool

PII vs PHI: Key Differences

Because GDPR, CCPA, and HIPAA use different terminology to describe sensitive personal data, compliance teams and developers frequently conflate PII and PHI, two overlapping but legally distinct categories that govern which data needs protection and under which framework.

What is PII vs PHI?

Scope: who is covered

PII frameworks under GDPR and CCPA apply broadly: any organization that processes EU personal data under GDPR or handles California consumer data under CCPA must comply regardless of industry. PHI under HIPAA has a narrower scope: it applies only to covered entities, which are healthcare providers, health plans, and healthcare clearinghouses, along with their business associates.¹ Consequently, a fintech company that processes medical payment data on behalf of a hospital is a business associate handling PHI, while the same company processing customer financial data has PII obligations but not PHI obligations.

This scope distinction has direct implications for AI tool governance. A software company that builds a patient portal for a hospital system is a business associate and must comply with HIPAA for the health data it touches. The same company building an e-commerce checkout flow handles PII under CCPA but has no HIPAA obligations. When employees at either company use AI tools, the scrubbing requirements differ: the healthcare-adjacent workflow needs PHI-level de-identification, while the e-commerce workflow needs PII-level protection.

Data fields: where they overlap

Email addresses, phone numbers, SSNs, and IP addresses are both PII (under GDPR and CCPA) and PHI (under HIPAA when associated with health information) depending on context. A patient email address stored in an EHR is PHI. The same email address stored in a marketing CRM without health context is PII but not PHI. Building on this, a blood type stored without any identifying information is health data but not PHI, since the identifier must accompany the health information for HIPAA to apply. The scrubber's detection is data-type-based, not context-based, so it removes email addresses and SSNs whether they are PII or PHI.

Regulatory consequences: what differs

GDPR fines can reach 4% of global annual revenue or €20 million.² CCPA fines reach $7,500 per intentional violation. HIPAA civil penalties range from $100 to $50,000 per violation category, with criminal penalties for intentional disclosure reaching $250,000 and imprisonment. Yet the operational consequence differs more than the penalty: a GDPR violation typically triggers a data subject rights response, while a HIPAA violation triggers OCR investigation and mandatory breach notification to patients. Conversely, both frameworks are aligned on the core prevention approach: minimize what you share and remove identifiers before sharing with external processors.

HIPAA's breach notification requirement is particularly burdensome for healthcare organizations. When a covered entity discovers that PHI has been disclosed to an unauthorized party, it must notify each affected individual within 60 days, issue a press release if more than 500 residents of a single state are affected, and report the breach to the HHS Secretary.³ For organizations using AI tools without BAAs, even a single prompt containing a patient's SSN and diagnosis could trigger this full notification and investigation workflow, making pre-submission scrubbing a far more attractive control than post-breach remediation.

State-level PII frameworks beyond GDPR and CCPA

US state privacy law has expanded rapidly since CCPA took effect in 2020. By 2026, more than 20 states have enacted comprehensive consumer data privacy laws. Virginia's Consumer Data Protection Act defines personal data as any information linked or reasonably linkable to an identified or identifiable natural person.⁴ Texas's Data Privacy and Security Act applies to businesses that process the data of more than 100,000 Texas residents annually or derive revenue from selling personal data. Colorado's Consumer Privacy Act and Connecticut's Data Privacy Act follow similar definitions, each with their own enforcement thresholds and exemptions.

These state laws share a common core definition of personal information that includes email addresses, phone numbers, IP addresses, government-issued identifiers, and account log-in credentials. The specific enforcement mechanisms, cure periods, and exemptions differ: Texas has no private right of action; Colorado requires a DPIA for high-risk processing activities; Connecticut's law has a broader definition of sensitive data that includes precise geolocation collected by non-healthcare entities.⁵ The scrubber's detection of the core identifier categories covers the most common personal data types across all of these frameworks simultaneously.

When multiple state frameworks apply to the same dataset

A US company processing employee data from offices in Texas, Virginia, and California simultaneously faces TDPSA, CDPA, and CCPA obligations for the same employee roster. Where frameworks differ, the most restrictive applicable rule governs the specific data operation. California's CPRA sensitive personal information category covers the widest range of field types, making CCPA the controlling framework for any multi-state dataset that includes California residents. Scrubbing the CPRA-defined sensitive categories (SSNs, account credentials, email addresses) satisfies the most demanding state framework, which typically satisfies the less demanding ones simultaneously for the same field types.

PHI created by non-healthcare companies

HIPAA's applicability to non-healthcare organizations depends on whether the organization is a covered entity or a business associate. A corporate wellness program administered by an employer using a third-party wellness platform creates ePHI if the employer self-funds the health plan and receives individually identifiable health information. A technology company that processes healthcare claims data for an insurance company is a business associate, making its handling of that data subject to HIPAA's Security and Privacy Rules even though the company itself is not a healthcare provider.

Fitness apps, sleep tracking applications, and meditation platforms that collect health data are not automatically HIPAA-covered entities. If the app does not interface with a healthcare provider, health plan, or healthcare clearinghouse, HIPAA does not apply to its health data collection. In these cases, state-level digital health data laws may apply: Washington's My Health MY Data Act (MHMDA), effective 2024, governs health data collected by non-HIPAA entities operating in Washington State.⁶ MHMDA's definition of consumer health data is broader than HIPAA's PHI definition, covering any personal information linked to an individual's physical or mental health condition regardless of whether a covered entity is involved.

Self-funded employer health plans and HIPAA applicability

Employers who self-fund their health insurance plans are covered entities under HIPAA for the health plan component of their operations. The HR department that receives individually identifiable health claims data for eligibility verification or cost analysis handles PHI in its role as plan administrator. AI tools used for benefits administration tasks that involve individual claims data therefore involve PHI, not just PII. HR teams at self-funded employers should apply the same pre-AI scrubbing discipline required for healthcare covered entities, removing detectable PHI identifiers before any claims data reaches an AI provider.

Applying the correct framework to your AI prompt

Identifying the correct framework for a specific AI prompt takes three questions. First: is the data from an EU resident? If yes, GDPR applies regardless of any other framework, because GDPR follows the data subject's location rather than the organization's establishment. Second: is the data about a California resident? If yes, CCPA applies for organizations meeting the volume or revenue thresholds. Third: does the data relate to an individual's health status and is it held by a covered entity or business associate? If yes, HIPAA applies.

For most operational AI prompts in a US business context, CCPA is the most commonly applicable framework. A customer support prompt mentioning a California customer's email, phone, and purchase history involves CCPA-covered personal information. A marketing team's campaign list with California contacts involves CCPA. An HR team at a self-funded health plan analyzing benefits claims involves both CCPA for California employee data and HIPAA for the health information itself. Applying the strictest applicable framework's requirements satisfies all others by definition, because the strictest framework imposes the most demanding removal obligations.

Documenting your framework determination for compliance records

Maintain a brief written record of which framework you identified as applicable for each category of AI-assisted task. A one-page document listing five to ten common task categories (customer support, HR administration, financial reporting, marketing, security incident analysis) with their applicable frameworks and the required scrubbing steps provides a reference employees use in the moment and that auditors can review during an investigation. Update this document when your organization begins new AI-assisted workflows or when new state privacy laws take effect in jurisdictions where your customers or employees reside.

Keeping this determination written down turns an ad-hoc choice into a repeatable procedure that auditors can review on request. Because CapyToolkit scrubs locally in your browser, the sensitive fields are tokenized before any prompt leaves your machine, and the variables file is the only record linking the tokens back to the real values under your own control.

Try in the tool

What Is Data Anonymization?

Among the techniques used to protect personal data, including anonymization, pseudonymization, redaction, and masking, anonymization is the only one that removes GDPR and CCPA obligations entirely, because anonymized data is no longer considered personal data under either framework.

What is data anonymization?

Anonymization versus pseudonymization

The critical distinction is reversibility. Pseudonymization replaces identifiers with codes like the tokens this scrubber creates but retains a key that allows re-identification. Consequently, pseudonymized data is still personal data under GDPR, as Article 4(5) explicitly defines pseudonymization as a category of personal data.² Anonymization is the complete and irreversible removal of the link between data and individual. Yet true anonymization is harder to achieve than it appears: a combination of age, ZIP code, and gender can re-identify the majority of individuals in a population, which means data you believe is anonymized may not meet the legal standard.

The practical consequence for data teams is that pseudonymization is almost always the safer operational choice. When you need to share data with an AI tool and later restore the original values in the response, pseudonymization via token replacement gives you both protection and reversibility. True anonymization, by contrast, is a one-way door: once the identifying fields are irreversibly transformed, no restoration is possible, which makes it unsuitable for interactive workflows where the output needs to map back to real records.

Anonymization techniques

Common anonymization techniques include data aggregation, which replaces individual values with group statistics so a salary becomes a range; data generalization, which replaces a precise value with a less specific one such as a birth year instead of a full date; data suppression, which removes identifying fields entirely; data noise addition, which alters values randomly so the original cannot be recovered; and synthetic data generation, which creates artificial data with the same statistical properties as the original. Building on this, k-anonymity and differential privacy are formal mathematical approaches that provide provable re-identification resistance and are used in research and analytics rather than operational data sharing.

Each technique carries a different utility trade-off. Aggregation and generalization reduce the granularity of the data, which means the output is less useful for individual-level analysis but still valid for population-level statistics. Synthetic data preserves statistical distributions without containing real records, making it ideal for model training, but the generation process requires expertise and validation to ensure the synthetic output does not inadvertently reproduce real individuals from the training set.

When to use anonymization versus other techniques

Anonymization is the right choice when you need to share data publicly, for research, or with parties you cannot bind by contract. If the data must eventually be linked back to individuals for customer service, compliance records, or audit trails, pseudonymization like the token-based scrubbing in this tool is more appropriate. Conversely, anonymization is inappropriate when the analytical use case requires tracking specific individuals across records. The scrubber performs pseudonymization, where tokens maintain reversibility via the variables file, which is the right approach for AI prompt workflows where you need to restore values in the AI's response.

A practical decision framework helps here. Ask whether the recipient needs to map results back to real individuals. If yes, use pseudonymization and keep the key file secure. If no, and the data will never need to be linked back, anonymization removes the ongoing obligation to protect the key. For AI prompt workflows, the answer is almost always pseudonymization, because the core workflow depends on restoring real values in the AI's tokenized output.

Re-identification risk: the regulatory standard in 2026

Regulatory guidance on anonymization has converged on a "relative approach" to re-identification risk: data is considered anonymized when re-identification is not reasonably likely given the means and information available to any party who might attempt it. The European Data Protection Board's 2025 guidance on anonymization criteria requires data controllers to assess re-identification risk against three attack scenarios: singling out (identifying an individual record from the dataset), linkability (linking two records that refer to the same person), and inference (deducing an attribute about an individual with high confidence).³

Failing the singling-out test is the most common reason a dataset believed to be anonymized retains personal data status. A dataset with age, gender, and ZIP code may appear generic, but research by Latanya Sweeney demonstrated that 87% of the US population can be uniquely identified with these three fields using census data. Any dataset allowing singling out an individual from a realistic auxiliary dataset fails the GDPR standard for anonymization, regardless of how many direct identifiers were removed. Data controllers who rely on field-level redaction without assessing re-identification risk expose themselves to DPA enforcement if the dataset is later shown to allow re-identification.

Testing a dataset for re-identification risk before public sharing

Before treating a dataset as anonymized for sharing or public release, apply a structured re-identification risk assessment. ARX Data Anonymization Tool, an open-source Java application, evaluates k-anonymity, l-diversity, and t-closeness for tabular datasets and is the most accessible tool for practitioners.⁴ For simpler assessments, evaluate whether a small combination of the dataset's quasi-identifiers (age, gender, location, occupation) uniquely identifies individuals when cross-referenced against a publicly available dataset such as a voter registration file. If any combination of three or fewer fields uniquely identifies a significant fraction of the dataset, the dataset does not meet the EDPB anonymization standard.

Differential privacy as a mathematical anonymization framework

Differential privacy provides a mathematical guarantee: the inclusion or exclusion of any single individual's record changes the output of a statistical query by at most a bounded amount, controlled by a privacy parameter called epsilon. A small epsilon (closer to 0) provides stronger privacy protection at the cost of reduced query accuracy. The formal definition ensures that an attacker observing the output of a differentially private mechanism cannot determine with high confidence whether any specific individual's data was in the input dataset.

Apple uses differential privacy in iOS and macOS for usage statistics collection: the QuickType keyboard dictionary, emoji frequency data, and Safari crash reports are all collected using local differential privacy mechanisms that add calibrated noise before data leaves the device.⁵ Google uses differential privacy in its Statistics API for advertising data. These implementations demonstrate that differential privacy is production-grade for aggregate analytics use cases, though individual-level data use cases (where you need to query a specific record rather than a statistical aggregate) require pseudonymization rather than differential privacy.

When differential privacy is appropriate versus simpler techniques

Differential privacy is appropriate for aggregate statistics release, machine learning model training, and federated learning scenarios where you need a formal, verifiable privacy guarantee that an adversary cannot circumvent regardless of auxiliary knowledge. Simpler techniques (field suppression, generalization, the scrubber's tokenization) are appropriate for operational data sharing: preparing a prompt for an AI tool, sharing a dataset with a specific trusted recipient, or sending a log to a vendor. The scrubber is a pseudonymization tool designed for the second use case; differential privacy is outside its scope and requires specialized implementation expertise.

Anonymization in machine learning training data pipelines

ML model training on personal data creates a distinct anonymization challenge: models can memorize specific training examples and reproduce them when prompted. A language model trained on customer support transcripts that include email addresses and phone numbers may generate responses containing those real values when prompted with similar context. This phenomenon, called training data memorization, was demonstrated in a 2021 paper on GPT-2 by Carlini et al., and subsequent work confirmed it affects large production models including GPT-3.⁶

Removing personal data from training sets before model training prevents memorization of individual records. Data pipelines that feed training data to ML models should apply an anonymization or pseudonymization step at the extract stage, before the data enters the training pipeline. For text-based training data, applying the scrubber's tokenization as a preprocessing step removes the identifiable values most likely to be memorized and reproduced. The model trains on the structural patterns in the text rather than the specific values in individual training examples.

Synthetic data generation as a training set anonymization strategy

Synthetic data generation creates artificial datasets that statistically resemble the original without sharing any actual records. Tools such as Gretel.ai, Mostly AI, and NVIDIA's NeMo Guardrails Synthetic Data Generator can produce synthetic tabular data (for customer records, transaction histories) and synthetic text (for customer support transcripts, HR notes) that preserves the statistical properties of the original. A model trained on synthetic data learns patterns equivalent to those in the real dataset, without any risk of memorizing or reproducing specific individuals from the original training population.

Synthetic data complements the scrubber's tokenization, because both remove the original records from the training path while preserving the patterns the model needs. CapyToolkit runs the scrubbing locally in your browser, so the real values are tokenized before any paste leaves your machine, and the variables file is the only artifact that maps the tokens back to the source data.

Try in the tool

What Is Data Pseudonymization?

While anonymization permanently removes the link between data and its subject, pseudonymization replaces identifying fields with codes or tokens that can be reversed with a key, a distinction that determines both the legal status of the data and whether you can still use it for operational purposes.

What is data pseudonymization?

How pseudonymization differs from anonymization

The difference is reversibility. Anonymization destroys the link between data and individual permanently, and no key or process can recover the original identity. Pseudonymization replaces identifiers with substitutes (tokens, codes, hash values) while the mapping from substitute to original exists separately. Consequently, pseudonymized data remains personal data under GDPR because re-identification is possible using the key.² Yet this reversibility is a feature, not a flaw, because pseudonymization allows organizations to maintain utility through restoring real values for authorized use while reducing the exposure of identifiers during processing.

Think of it this way: anonymization is a paper shredder, and pseudonymization is a lockbox. Shredded paper cannot be reassembled, which means the data is truly gone but also permanently unusable. A lockbox requires a key to open, which means the data remains protected during transmission and storage, but authorized parties with the key can restore the original content when they need it. For AI prompt workflows, the lockbox approach is what makes the scrub-and-restore pattern possible.

Pseudonymization techniques

Common pseudonymization approaches include token replacement, which replaces a value with a random code as this scrubber does; deterministic encryption, where the same input always maps to the same output allowing consistent pseudonyms across datasets; format-preserving encryption, which replaces a value with a structurally similar but different value such as a valid-format email that maps to the original; and hashing, a one-way cryptographic transformation that remains vulnerable to rainbow table attacks on low-entropy inputs like SSNs. Building on this, format-preserving encryption using the FF3-1 algorithm (standardized in NIST SP 800-38G Rev 1) produces ciphertexts that match the character set and length of the plaintext.³ Token-based pseudonymization, the approach used by this scrubber, is the most transparent because the mapping is stored in a separate file that the data controller retains under access control.

Deterministic encryption deserves special attention for teams that need consistent pseudonyms across multiple systems. When the same email address always produces the same encrypted output, you can join tables on the encrypted field without ever decrypting it, which enables analytics workflows where the data remains pseudonymized end to end. The trade-off is that deterministic output leaks equality: an observer can tell when two records share the same email address without knowing what that email address is.

GDPR incentives for pseudonymization

GDPR explicitly rewards pseudonymization. Recital 28 identifies it as a measure that reduces risk for data subjects and helps controllers meet their Article 25 privacy by design obligations. Article 89 allows pseudonymized data to be used for research and statistics purposes with looser safeguards than identified data. Conversely, pseudonymized data used for decisions about specific individuals still carries full GDPR obligations, because pseudonymization reduces risk but does not reduce the legal basis requirement for the processing. For the AI prompt use case, pseudonymizing before sending means the AI provider never receives personal data, so no legal basis for that provider's processing is required.

Article 32 of GDPR specifically names pseudonymization as a security measure that controllers should consider when implementing appropriate technical safeguards.⁴ This means that deploying pseudonymization is not just a good practice but a recognized compliance control that data protection authorities look for during audits. Organizations that can demonstrate a pseudonymization layer between their personal data and third-party processors, including AI providers, have a materially stronger position in any regulatory inquiry.

Pseudonymization in relational database architecture

Column-level pseudonymization in a production database replaces the stored value of identifying columns with pseudonymous substitutes, while a separate key table maps each substitute to its original value. A users table might store an email_token column (a UUID representing the email address) instead of email, with the email-to-UUID mapping stored in a separate, access-controlled key table. Application code that needs the real email for transactional purposes (sending a confirmation message) joins against the key table; code that processes aggregated user data (cohort analysis, ML training) works with the UUID and never sees the real email address.

Implementing column-level pseudonymization in PostgreSQL requires adding the pseudonym column, populating it with UUIDs or hashed values derived from the real value, and updating application queries to use the pseudonym column for non-transactional purposes. The pgcrypto extension provides gen_random_uuid() for UUID generation and crypt() for deterministic hashing with a salt.⁵ Deterministic pseudonymization (the same input always maps to the same output) allows consistent pseudonym-to-original mapping without a key table lookup, but requires a secret salt stored separately from the database to prevent rainbow table attacks on low-entropy inputs such as email addresses.

Column-level encryption as an alternative to pseudonymization

Column-level encryption using PostgreSQL's pgcrypto functions protects identifying column values at rest with cryptographic strength. Encryption differs from pseudonymization in that the encrypted value is not a consistent pseudonym: the same plaintext encrypted twice produces different ciphertexts using authenticated encryption modes (AES-GCM). For analytics use cases that require consistent pseudonyms for grouping and joining across tables, deterministic pseudonymization (UUID or HMAC-based) is more appropriate than encryption. For pure data-at-rest protection without an analytics use case, column-level encryption provides stronger security properties and is easier to key-manage.

Pseudonymization in data analytics pipelines

Analytics pipelines that process personal data benefit from a pseudonymization layer between the data source and the analytics environment. A common pattern uses an extract-transform-load (ETL) process that applies pseudonymization at the transform stage: raw personal data enters the ETL from the production database, pseudonyms replace the identifying fields, and the pseudonymized records load into the analytics data warehouse. Analysts in the warehouse environment work with pseudonyms and never have access to the key table mapping pseudonyms to real identities.

Consistent pseudonyms across multiple datasets in the analytics environment are critical for cross-table joins. If a customer email produces pseudonym A in the customers table and pseudonym B in the orders table (due to different pseudonymization keys or methods), the join key is broken and analysis cannot associate orders with customers. Using the same pseudonymization key and the same deterministic algorithm across all tables that share the email as a foreign key preserves referential integrity across the analytics schema and ensures that cross-table analysis remains valid after pseudonymization.

Format-preserving pseudonymization for analytics that require original data shape

Some analytics systems require that pseudonymous values maintain the structural format of the original: a pseudonymous email must still look like an email, a pseudonymous US phone number must still be a 10-digit sequence. Format-preserving encryption (FPE) using the FF3-1 algorithm (standardized in NIST SP 800-38G Rev 1) produces ciphertexts that match the character set and length of the plaintext. An FPE-pseudonymized email address looks like a valid email address but maps to a different mailbox. FPE is useful in analytics environments where query engines, validation rules, or downstream tools reject values that do not match the expected format of the original field.

Key management for pseudonymization systems

The security of a pseudonymization system depends entirely on the security of the pseudonymization key. A deterministic pseudonymization key used for HMAC-based token generation must be stored separately from the pseudonymized data and protected with the same controls as production credentials. Hardware Security Modules (HSMs) provide the strongest available key protection: the key material never leaves the HSM in plaintext, and all cryptographic operations (HMAC generation for new pseudonyms, lookup for restoration) execute within the tamper-resistant hardware boundary without exposing the key to the application layer.

For organizations without HSM infrastructure, cloud key management services provide an accessible equivalent. AWS Key Management Service (KMS), Google Cloud Key Management, and Azure Key Vault all provide FIPS 140-2 Level 3 hardware-backed key storage accessible via API.⁶ Using a KMS-managed key for HMAC pseudonymization means the key material is protected by the cloud provider's HSM while remaining accessible for cryptographic operations through the KMS API. Key usage is logged in CloudTrail (AWS), Cloud Audit Logs (GCP), or Azure Monitor, providing a record of every pseudonymization and re-identification operation for audit purposes.

Rotating pseudonymization keys without breaking existing data

Key rotation in a deterministic pseudonymization system requires a re-pseudonymization step: all existing pseudonyms generated with the old key must be re-generated using the new key, and the mapping table updated accordingly. The rotation process runs in sequence: generate new pseudonyms for each original value using the new key, update the mapping table with new pseudonyms, update all analytics tables to replace old pseudonyms with new ones, then retire the old key. Automating this process in a migration script prevents data inconsistency from leaving some tables with old pseudonyms and others with new ones. The re-pseudonymization window is the highest-risk period: both old and new keys must be active simultaneously until all tables are migrated.

Documenting each rotation in the migration script keeps the mapping consistent while both keys are briefly live. CapyToolkit applies the same reversible principle locally in your browser: the scrubber replaces values with session-scoped tokens and stores the mapping in the variables file, so the original is restorable without a persistent, network-exposed key vault.

Try in the tool

What Is Data Tokenization?

In payment security, tokenization replaces a credit card number with a randomly generated substitute that has no mathematical relationship to the original.¹ In data privacy, the same principle applies more broadly: tokenization replaces any sensitive data field with a non-sensitive placeholder, enabling downstream processing without exposing the original values.²

What is data tokenization?

Tokenization in payments versus data privacy

Payment tokenization, as defined by PCI DSS and implemented by Visa, Mastercard, and Apple Pay, replaces a PAN (primary account number) with a token that the merchant processes in place of the real card number.¹ The token has no value outside the issuer's vault, so a data breach at the merchant exposes tokens rather than actual card numbers. Data privacy tokenization applies the same concept to any field: email addresses, SSNs, IBANs, IP addresses, API keys, and other identifiers are all replaced with tokens. Consequently, a tokenized database export can be shared with analytics teams or AI tools without exposing any identifiable values.

The key architectural difference between payment tokenization and data privacy tokenization is the vault. In payment systems, the token vault is a centralized, highly secured system operated by the payment network or issuer, and merchants never have access to the mapping. In data privacy tokenization, the vault is often a simple mapping file or a local database table that the data controller manages directly. This makes data privacy tokenization more flexible but also places the security burden on the organization rather than on a specialized vault operator.

How the scrubber implements tokenization

When you paste text into the scrubber, the tool scans for 22 sensitive data patterns using regex. Each unique value that matches a pattern receives a unique numbered token: [EMAIL_1] for the first email, [EMAIL_2] for the second. The mapping between each token and its original value is stored in the variables file. Building on this, the same value always maps to the same token within a session, so if the same IP address appears three times, all three occurrences become [IP_1] and the restoration step correctly replaces all three. Closing the tab clears the mapping, because the token vault is session-scoped and lives only in browser memory.

This session-scoped design is a deliberate security choice. Enterprise tokenization systems maintain persistent vaults so that tokens remain consistent across transactions and over time, but this persistence creates an attack surface: a compromised vault exposes every token-to-value mapping the system has ever created. The scrubber's session-scoped approach means that each scrubbing operation produces a fresh, independent mapping that exists only for the duration of the browser tab, limiting the blast radius of any potential exposure to a single session's data.

Security properties of token-based pseudonymization

A token issued by the scrubber (e.g., [EMAIL_1]) has no mathematical relationship to the original value. An attacker who intercepts the scrubbed text cannot reverse the token without the variables file.³ The token format is standardized but the actual token-to-value mapping is unique to each scrubbing session. Yet the security of the tokenized output depends entirely on the security of the variables file: losing the file means the scrubbed text cannot be restored; sharing the file with the recipient means they can reconstruct the original. Treat the variables file as a secret with the same classification as the original data.

Why the variables file is the critical attack surface

In a tokenization system, the tokens themselves are worthless without the mapping. An attacker who obtains only the scrubbed text learns nothing about the original values, because [EMAIL_1] could be any email address. The real risk is the variables file: anyone who possesses both the scrubbed text and the variables file can reconstruct every original value instantly. This is why the variables file should be stored with the same access controls as the original sensitive data, transmitted over encrypted channels only, and deleted when the restoration workflow is complete.

Token vault architectures for enterprise-scale tokenization systems

An enterprise token vault stores the mapping between sensitive values and their tokens in a secured, access-controlled data store. The vault must satisfy three requirements: token generation is random (no mathematical relationship between token and original value), the vault is isolated from the systems that process the tokenized data, and all access to the vault for token issuance and lookup is logged and auditable. HashiCorp Vault's Transform Secrets Engine provides a built-in tokenization backend that satisfies all three requirements, using FF3-1 (AES-256) for format-preserving encryption of stored mappings and exposing a REST API for token issuance and detokenization that integrates with any application stack.⁴

AWS KMS can serve as the key management layer beneath a custom token vault implementation. A pattern common in financial services uses DynamoDB as the token mapping store, with DynamoDB encryption at rest using a KMS-managed key and AWS IAM policies restricting detokenization access to specific Lambda functions with documented business justification. This approach scales to more than six billion tokens with double-digit millisecond latency when vault and workload operate in the same AWS region.⁵ Azure Key Vault plus Azure Cosmos DB provides an equivalent architecture on Azure infrastructure, with Cosmos DB's strong consistency guarantees ensuring that a token lookup always returns the correct mapping.

Single-tenant versus multi-tenant token vaults

Single-tenant token vaults maintain a separate vault instance for each customer or business unit, ensuring that token mappings from one tenant cannot be accessed by another even in the event of an access control misconfiguration. Multi-tenant vaults share a single vault instance across multiple tenants, using row-level security and tenant-specific encryption keys to provide logical isolation. For PCI DSS-compliant tokenization, the PCI Security Standards Council requires adequate segmentation between tenants, whether vaults are single-tenant or multi-tenant.⁶ Multi-tenant vaults are permitted when they provide isolation equivalent to physical separation, including network, operating system, and application-layer controls, with segmentation tested at least semiannually. Single-tenant vaults reduce the scope of isolation controls by removing the multi-tenant attack surface entirely, but the Council's guidance is outcome-based rather than prescriptive about deployment model.

Tokenization in cloud data warehouses for analytics use cases

Cloud data warehouses (BigQuery, Redshift, Snowflake) hold tokenized personal data when the ETL pipeline applies tokenization before loading. BigQuery supports deterministic encryption using the AEAD.ENCRYPT function with a key reference stored in Google Cloud KMS, which effectively implements tokenization at the column level: the encrypted column value is deterministic for the same plaintext and key, enabling consistent pseudonyms across tables for join operations. Analysts who query the encrypted column receive the encrypted value; only users with KMS key decryption permission see the original.

Snowflake's Dynamic Data Masking feature applies a SQL-based masking policy at query time: analysts without the designated unmasking role see a tokenized representation of the column (such as the first three characters and asterisks), while authorized users see the real value. This approach handles tokenization at the access control layer rather than the storage layer, which means the real data is stored but only selectively revealed based on the role of the querying user. For use cases where the real value must never exist in the warehouse at all, apply tokenization at the ETL stage before loading, so the warehouse receives only tokens from the point of ingestion.

Reversible tokenization in real-time API response pipelines

APIs that return personal data to clients can apply reversible tokenization at the serialization layer: the API serializes the response with tokens instead of real values, the client stores and processes tokens, and the API provides a separate detokenization endpoint accessible only to clients with explicit detokenization permission. This pattern separates the common case (clients process business logic using tokens) from the rare case (display or communication that requires the real value), restricting real-value exposure to the minimum set of application actions that genuinely require it. The OAuth 2.0 token introspection pattern (RFC 7662) provides a model for how clients can look up token metadata via a secured endpoint without receiving the raw mapped value unless explicitly authorized by a scoped permission.

This pattern mirrors the scrubber's approach, where tokens travel in the response and the mapping stays under your control. CapyToolkit runs the tokenization locally in your browser, so the original values are replaced before any paste leaves your machine, and the variables file is the only artifact that can reverse the tokens back to the real data later.

Try in the tool