De-Identifying Data for AI and Analytics

You have years of useful data sitting in your systems. Service history, sales records, support tickets, project notes. Somebody on your team wants to run it through an AI tool to spot patterns, or hand a sample to a vendor evaluating a new analytics product. That is a reasonable thing to want. Your data is genuinely one of the more valuable assets you own.

The problem is that your data is also your customers’ data. Once a spreadsheet of real records leaves your control, you cannot pull it back. The usual answer is to strip out the names first and call it anonymous. That instinct is right. The execution is usually wrong, and the gap between the two is where businesses get into trouble.

Identifying Information Is More Than Names

The National Institute of Standards and Technology describes de-identification as any process that removes the association between a set of data and the person the data is about. In its guidance on the subject, NIST splits the problem into two categories, and the second is the one people miss.

Direct identifiers point at one person on their own. Name, email address, phone number, account number, Social Security number. Everybody knows to remove these.
Quasi-identifiers do not identify anyone by themselves, but they can be combined or matched against other information to pick a person out. ZIP code. Date of birth. Job title. Purchase date. The specific model of equipment you serviced.

How much does that second category matter? In its 2015 report on de-identification of personal information, the National Institute of Standards and Technology cites well known research finding that up to 87 percent of the United States population could be uniquely identified by just three things: five digit ZIP code, date of birth, and sex. None of those is a name. All three sit in ordinary business records.

Now apply that to a small business file. If your dataset covers customers in one county and includes the install date, the property type, and the invoice amount, you may have a handful of records that describe exactly one household. Deleting the name column did not fix that.

The Techniques, in Plain Terms

You do not need a data science degree to do this reasonably well. NIST describes a handful of approaches, and translated into normal language they are all things a competent person with a spreadsheet can do.

Remove the direct identifiers. Delete the columns holding names, emails, phone numbers, and account numbers. This is the floor, not the finish line.
Generalize the specifics. NIST describes this as reporting a value as part of a range or a group instead of an exact figure. Replace a birth date with a decade. Replace a full ZIP code with a region. Replace an exact invoice total with a band.
Aggregate instead of listing. Publish the summary rather than the records. If the question is which service line grows fastest in spring, the answer is a set of totals, not a list of customers.
Suppress the outliers. Drop the rows that stand alone. Your one enormous commercial account is identifiable no matter how you label it.
Replace real values with placeholders. NIST calls this pseudonymization: swapping identifying information for stand-in values. It is useful, with one catch worth remembering. If you keep the key that maps placeholders back to real people, the data is not anonymous. It is locked, and you are holding the key.
Use a sample instead of the whole file. A vendor evaluating a tool needs a few hundred representative rows, not your entire history. Smaller exposure, same answer.

The Honest Warning: This Is Harder Than It Looks

Here is the part most articles skip. De-identification is not a guarantee, and treating it like one is the actual risk.

NIST states the limitation directly, noting that approaches based on suppressing or generalizing fields in a database cannot provide absolute privacy guarantees, because there is always a chance the remaining data can be re-identified. The same report makes the tradeoff explicit: as long as any usefulness remains in data derived from personal information, some possibility remains that it could be linked back to real individuals. The more useful your dataset is, the more identifying it tends to be. Those two things pull against each other, always.

Regulators have made the same point about technical measures that look protective but are not. In a 2024 post from its Office of Technology, the Federal Trade Commission wrote that data is only anonymous when it can never be associated back to a person, and that companies should not act or claim as if hashing personal information renders it anonymized. Scrambling an email address into a code still leaves a unique marker that can follow a person around.

None of that means give up. It means describe your work accurately. “We removed identifiers and generalized the details, which substantially lowers the risk” is honest. “This data is anonymous” usually is not.

The Simplest Safe Pattern for Testing a New Tool

Most of the time, the request that starts this whole conversation is a trial. Somebody wants to see whether a new AI or analytics product is any good, and they want to test it on real data because sample data feels fake. Often they do it quietly, which is its own problem, and one we covered in our piece on shadow IT.

Use made up data instead. NIST describes synthetic data as data built to resemble the original but where the elements are generated and do not map to actual individuals. In practice, this is easy now: take your real file’s structure, describe it to an AI tool, and have it produce a few hundred rows of plausible fake records with the same columns, the same formats, and the same messy edge cases. No real customer is in it.

That answers almost every question a trial needs to answer. Does the tool handle our date format. Can it parse our notes field. Is the output useful. You only need real data once you have decided to buy, at which point the vendor contract and the security review carry the weight instead of the spreadsheet. This is the same discipline we describe in our guide to preparing your team for AI without the hype: decide what data a tool gets before anyone starts pasting.

One more reason to be careful about what you feed an AI system. NIST’s guidance on generative AI notes that models can memorize and later reveal sensitive information that was in their training data, and that they can sometimes infer personal details that were never provided directly. If your data becomes training material, you cannot take it back.

The Bottom Line

Your data is worth using. Use it. Just be clear eyed about what stripping the names actually accomplished, which is less than it feels like. Remove the direct identifiers, generalize the details that could combine into a fingerprint, drop the outliers, prefer summaries over records, and default to synthetic or scrubbed samples whenever you are just kicking the tires on a tool.

And be careful with the word anonymous. It is a strong claim, it is hard to earn, and your customers will hold you to it. Since the tools and their data terms change constantly, confirm what any given product does with your information before you send it anything real.

If your team is trying to get value out of company data without putting customer information where it does not belong, we can help you build a repeatable process for it, from what gets stripped to which tools are approved. That work is a normal part of what we do for businesses across Denton County. Contact us today.

Sources:

Artificial Intelligence Cybersecurity Data Privacy Explainers

Comments are closed