Hashed Customer IDs Are Not Anonymous AI Inputs

A support team wants an AI model to explain last month's complaints. It removes customer names and replaces phone numbers with SHA-256 hashes. The phone column is unreadable, but exact visit times, branches, complaint narratives and a stable customer reference remain. Is the upload now anonymous? That transformation alone cannot establish it.

This constructed scenario is for data engineers and owners of customer-facing AI workflows. The useful decision is not simply which stronger algorithm to select. It is which information and which relationships the task actually requires, and what the recipient can infer from the resulting package. This is an engineering guide, not legal clearance to share data or a certification of anonymity.

Start with the relationship the model needs

Classifying each complaint may require no customer identifier. Counting customers with repeated complaints requires linking some rows, but not knowing a phone number. Returning a recommendation to the right internal case requires an authorized lookup somewhere; it does not require giving that lookup capability to the model.

Write the task in those terms before transforming anything. “Analyze customers” is too broad. “Count recurring delivery complaints within this approved month's support export” defines a much smaller relationship. Decide whether the unit is a message, case, account or person. A phone number shared by a household is not a reliable substitute for that decision.

Pseudonymisation replaces direct identifiers while separating additional information used to attribute the records. Anonymity is a broader claim about identifiability in context. The UK's ICO guidance says data remain personal in the hands of someone holding that additional information; another recipient's position depends on identifiability. The page carried an under-review notice at our review date. Do not turn that UK guidance into a universal legal conclusion for Iran or an automatic authorization to use a foreign service.

An internal description such as “direct identifiers removed; links preserved within this batch; mapping held by the data team” is narrower and more testable than “anonymized.” Our privacy-enhancing technologies guide covers the wider toolkit. Here, the subject is the boundary around the replacement identifier.

A one-way function can still have guessable inputs

Consider a synthetic list of 100 addresses, from user01@example.invalid through user100@example.invalid. Hash each exact string with SHA-256. Someone holding the same candidate list can hash those candidates and compare the results. They do not need to invert the function.

In our local teaching fixture, all 100 values were matched against that deliberately complete list. This is not a benchmark of real phone-number recovery, attack speed or the probability of identifying an organization's customers. Its assumptions are explicit: the original is in the candidate set, and the input encoding and preparation are known. Only synthetic identifiers were used.

A phone number, short code or email present in another list can offer a much smaller guessing space than the digest's length suggests. Making the output look complicated does not create uncertainty about the input. ENISA's pseudonymisation report distinguishes dictionary search, exhaustive search and informed guessing. That is the relevant mechanism, not a claim that SHA-256 has been cryptographically broken.

A public salt is not a secret. A separate random salt per record can frustrate reuse of one precomputed lookup table, but a recipient who knows a record's salt can still test candidates for that record. It also disrupts straightforward equality matching across repeated identifiers. Evaluate that tradeoff deliberately; neither “salted” nor “one-way” answers the complete privacy question. Conduct defensive tests only on synthetic data or data explicitly authorized for the assessment.

Choose removal, scoped aliases or controlled keyed values

The first option should be omission when identity contributes nothing to the task. If the result needs to return to a message, an opaque temporary message reference may suffice. Do not automatically attach a permanent person identifier to every model interaction.

These are ZharfAI design recommendations, not a universal ranking of cryptographic techniques. “Random alias” needs clarification: a fresh value for every row destroys within-customer linkage; one random value per customer per batch preserves it. Both can be correct for different questions.

Use a suitable cryptographic random generator, sufficient output length and collision handling for random aliases. A sequential row number is not a secret. Conversely, a long random-looking identifier is not proof that the rest of the record is safe. For a one-off analysis, ask why the system should retain a reusable global identifier at all.

Make the permitted join visible in a four-row example

Suppose an approved September support batch contains two messages from customer A and one from customer B. A separate returns analysis contains another record from A. The support analysis needs recurrence within its batch. Its recipient is not meant to assemble one person's history across both analyses.

The short labels are for readability, not proposed production token lengths. The first two intentionally match; the last intentionally has a different alias. A single permanent global pseudonym would defeat this separation. Define scope using the tenant or organization, processing purpose and approved linkage period—not merely a filename that someone can rename.

For a keyed implementation, our proposed design encodes the version, scope, field type and authoritative internal identifier as an unambiguous structured input. Do not casually concatenate strings with a separator that may also occur inside a value. Specify the encoding and test that all components construct identical bytes for the same record.

Cryptography cannot repair a mistaken identity unit. Two people may share a phone number; one person may change numbers. Resolve the identity basis before generating a person-level pseudonym. The customer-record matching guide addresses the evidence needed for that separate decision. Tokenizing a bad merge simply preserves it more consistently.

Keep the key and the ability to use it outside the model

RFC 2104 defines HMAC as a construction using a secret key as well as the message. HMAC-SHA-256 with a protected random key is a candidate for this workflow. The historical document is cited for the keyed mechanism, not as advice to copy its old MD5 or SHA-1 examples. Use a maintained cryptographic library, not a home-made “secret plus string” function.

A recipient without the key or access to computations under it cannot perform the same public-hash comparison. But a tokenization endpoint that accepts arbitrary candidate inputs in the relevant scope can restore that comparison capability. Protect permission to use the service, not merely the key file. Rate limiting alone does not correct excessive authorization.

Give the model only the minimized representation. Keep keys, mappings and re-identification capability in a separate controlled internal service. They do not belong in a prompt, attachment, conversation history or diagnostic error. Authorize transformation and lookup by purpose, scope and role. Audit events should not recreate the raw dataset in broadly accessible logs.

Google Cloud's documentation distinguishes one-way keyed hashing from reversible encryption. Its product table supports context tweaks for AES-SIV and format-preserving encryption, not for the HMAC API option. Our explicit HMAC scope encoding is a separate architecture proposal, not a claim that this product exposes that setting. This is documentation evidence, not a purchasing or service-access recommendation.

Neither keyed hashes nor random aliases conceal repetition when deliberately reused. That leakage may be necessary for the analysis. Record it as an intended disclosure rather than describing the replacement as erasing every trace of identity.

Review the whole outgoing record, not just the ID column

A complaint saying “the only night-shift supervisor at the small branch collected the machine on opening day” may identify someone to a colleague without including a name. Exact times, rare occupations, journeys and combinations of otherwise ordinary attributes can act as indirect identifiers. Replacing the phone column does not change them.

NIST SP 800-188 treats direct identifiers, quasi-identifiers and the choice of data-sharing model as parts of de-identification. The practical implication is to inspect the complete release. If sufficient for the question, generalize time to a period, coarsen location or remove unnecessary free text. Then measure the loss of analytical usefulness instead of assuming every transformation is free.

Do not send the raw file to the model and ask it to anonymize the file for itself when the intended boundary forbids the raw data leaving the organization. Transformation must happen before that boundary. Automated personal-data detection is also not proof of completeness. Test permitted Persian examples, digit variants, quoted text and attachments separately.

Even distinct aliases across batches do not guarantee that the contents cannot be linked. Identical unusual narratives and precise timestamps may connect the records directly. The scope mechanism protects a particular identifier relationship; it does not certify unlinkability of the complete package. Revisit the release when a new recipient has additional background data.

Accept the export against specific tests

Before the first upload, the data owner should approve a small synthetic fixture and acceptance checks. The package must remain useful for the declared question while disclosing no more than the approved scope. A convincing model answer evaluates only usefulness, not confidentiality.

• Repeated events for one identity within an allowed scope link as intended; that identity does not receive a shared pseudonym in a forbidden scope.
• Different identities in the fixture are not merged. Production output length and collision handling have a documented design.
• Raw identifiers, keys and mappings are absent from the outgoing package, filenames, errors and recipient-accessible logs.
• An analyst role cannot submit arbitrary candidates to the transformation service or re-identify records. Authorized roles work only in their approved scope.
• Model results resolve only to references issued for that batch. Invented or out-of-scope references are rejected.

These tests support limited claims. A few successful comparisons do not estimate collision probability at scale. A text search finding no phone numbers does not establish anonymity. Track missed removals, incorrect joins, unauthorized lookups and loss of analytical quality separately; a single “privacy score” would obscure four different problems.

Our fixtures check deterministic hashing and expected within-scope equality and cross-scope differences using Node.js cryptographic functions. They do not validate a deployed service, a key-management implementation, a detector's recall or a customer's data release. Security review must examine those actual components and permissions.

Plan expiry and key changes before the upload

A task-specific alias should have a defined lifetime. Assign ownership of the mapping, retention period, backup handling and deletion process. If an appeal requires connecting a result back to a case, reconcile that need with limited retention and authorization from the start. Do not solve a later lookup problem by handing the model the key.

Key rotation changes derived pseudonyms and can break links to earlier outputs. Record key versions and scope-policy versions, and plan the transition. Deleting a key does not delete previously exported files, model outputs or indirect identifiers. Our guide to deletion across derived artifacts explains why removing one capability is not the same as removing every copy and consequence.

Reopen the sharing decision when the recipient, purpose, fields or re-identification capability changes. The closing question is concrete: which relationships did this analysis need, and which additional relationships did we disclose? A documented answer is more useful than a reassuring label that says only “hashed and safe.”

Source notes — reviewed September 27, 2026

The synthetic candidate-list fixture and scoped equality checks were executed locally. Tables, architecture and acceptance recommendations are ZharfAI analysis, not a customer result or a product-security certification. This guide does not replace specialist security review or applicable legal requirements.

• ICO, Pseudonymisation: rolling UK guidance without a fixed date on the page; under-review notice following legislative changes, accessed on the review date.
• ENISA, Pseudonymisation techniques and best practices: landing page published December 3, 2019; linked report dated November 2019. Technical attack and linkage models.
• NIST SP 800-188: final publication, September 2023. Government-dataset guidance, not certification of a commercial product.
• RFC 2104, HMAC: February 1997, Informational; cited for the keyed construction, not endorsement of its historical algorithm examples.
• Google Cloud, Pseudonymization: displayed update September 24, 2026. One-way hashing, reversible encryption and the product-specific scope of context tweaks.