Which Customer Data Can Go Into AI? The Building Test for Marketing Engineers

Is it safe to put customer data into AI? Sort it first

A marketer exports 4,000 support tickets on a Thursday afternoon. She wants an AI assistant to find the top five complaints. Easy job, right?

Ticket 312 holds a card number. Ticket 1,880 mentions a divorce.

Nobody planned to send either one. Both now sit on someone else's computer.

So, is it safe to put customer data into AI? For most of it, yes, once you sort it. The real work is deciding which fields leave the building, before the upload.

Leaving the building means any copy that lands on a computer you do not control. An AI vendor's server counts. So does a browser add-on that sends text to its maker.

Judge the data before you judge the vendor

Most teams ask the wrong question first. They ask whether the AI tool is safe.

A vendor's promise matters. It is the second check, not the first.

Chip Huyen says it plainly in AI Engineering: once data goes to an outside model, no method stops every slip. Guardrails only lower the odds.

Promises also move. Her book recalls a video-call company that quietly changed its terms to train AI on user data, and the backlash that followed.

Then there is your own promise. Your privacy policy told customers what you would do with their data. Sending it somewhere new can break that promise, even if the vendor is perfect.

The famous case is the phone maker that restricted AI tools after staff pasted internal code into a public chatbot. That is a habits problem, and our shadow AI guide covers it. This guide covers the rows.

How to hand your customer list to a stranger in four easy steps:

1. Export the whole CRM, because filtering takes ten whole minutes.

2. Paste it into whatever AI tab is open.

3. Read the vendor's privacy page after the upload, if ever.

4. Call it a pilot.

That is not a pilot. It is a data transfer with a nicer name.

The Building Test asks four questions about every field

The Building Test is our four-question check for customer data before any of it reaches an outside AI. Run it per field, not per company. A field is one kind of detail: an email, a ticket body, a price quoted.

Who gets hurt if this field goes public? Think money, health, legal trouble, private words and social standing. The Trustworthy Online Controlled Experiments authors ask experimenters nearly the same thing about their data.

Can it point to one person? A name does. So do many fields that look harmless, as the next section shows.

What did we promise? Laws, client contracts, confidentiality agreements and your own privacy policy all count. If any of them says no, the answer is no.

Is it our edge? Some data hurts no customer but helps every competitor. Price tests, win and loss notes, margin by client.

Four questions. About a minute per field. The answers pick a lane.

Can a file with no names still point to one person?

Often, yes. Removing names is the start of the job, not the end.

The same experiment book splits data into three kinds. Identified data carries names, ID numbers or phone numbers. Pseudonymous data swaps those for a random ID, like a cookie.

Anonymized data is different again. Someone has checked it and shown that tracing a row back to a person is very unlikely.

Their warning matters most. Calling data anonymous does not make it anonymous. People can still be traced back.

Picture a ticket with no name. A dentist in a small town asks for a refund on a given date. Three plain facts, one person.

Our reading: AI raises this risk. A model is very good at joining small clues into one answer. It is Sherlock Holmes with no day off.

So we treat any field that could narrow a row to one person as identified. It stays that way until a real check says otherwise.

Route every field into one of four lanes

Every field ends up in one of four lanes. Pick the loosest lane that passes all four questions.

Send. Public or harmless fields go to an approved AI as they are. Published reviews, ad copy, product names.

Mask. The field travels with its personal parts swapped for placeholders, like [PHONE NUMBER]. The key that swaps them back never leaves your systems; our AI governance framework shows the full pattern.

Summary only. The raw file stays home. A model you run yourself reads it and writes a short, fixed set of fields, and only those leave.

Stay home. The field never reaches an outside AI in any form. Card numbers, passwords, health details, anything a contract forbids.

Where do you strip? At the very first step the data touches.

Andy Grove made this a rule in High Output Management: catch a defect at its lowest-value stage. Reject the bad egg at delivery, not on the customer's plate.

Data works the same way, in our reading. A name removed in the export costs nothing. A name found on a vendor's server costs a lot.

Grove also set one hard exception. When a defect could cause total failure, like a bad part in a pacemaker, you never let it pass to save money. We hold health and money fields at the gate the same way.

Price the grey cases with chance times cost

Most fields sort themselves. A few sit on the line, and arguing about them burns a week.

Price them instead. Douglas Hubbard and Richard Seiersen teach the move in How to Measure Anything in Cybersecurity Risk: expected loss is the chance of an event times its cost.

Then compare lanes by their return on control. That is the loss a control removes, divided by what the control costs, minus one.

Here is a worked example with made-up inputs. Say raw sales call notes sent as they are carry a 5 percent yearly chance of a costly exposure, at about $200,000. Expected loss: $10,000 a year.

Masking cuts the chance to 1 percent for $2,000 a year. It removes $8,000 of expected loss, a 300 percent return.

A local setup that keeps the notes fully in-house removes about $10,000. But it costs $12,000 a year to run and maintain. That is a return of minus 17 percent.

In this example, masking wins. Change the inputs and the answer can flip. That is the point.

Two limits. The math settles grey cases, never a legal no. For the company-wide risk list, use the ten-row method in the governance framework above.

Keep your edge at home, even when no law asks

Privacy is half the test. The other half is advantage.

Gary Lilien and Arvind Rangaswamy coined marketing engineering for decisions made with data, models and judgment together. Their textbook adds a point most privacy guides skip. Models built on a firm's own knowledge are hard for rivals to see, so they are hard to copy.

That is where the edge lives. Today's marketing engineer also builds the systems those models run in. So the same person decides where that knowledge travels.

Our list of edge data is short. Win and loss notes, price tests and their results, margin by client, next quarter's offer. None of it hurts a customer, and all of it helps a rival.

Trust is also per vendor, not per category. Huyen notes that some strict companies send data to the biggest cloud providers but not to startups.

Write your approved list by name. Keep edge data off it unless you would show the contract to your board.

Let a local clerk read the raw file and a cloud strategist read the summary

The summary-only lane needs a model you run yourself. We call it the local clerk.

It reads the raw recording or ticket on a machine you control. Then it fills a fixed set of fields: objection, product area, price mentioned, next step, and a summary with the names removed.

Only those fields go to the cloud strategist, the strongest outside model you have. It reads 200 clean summaries and writes the positioning memo.

Why not do it all locally? Because a model you run yourself is usually weaker at judgment.

Bloomberg once trained its own 50-billion-parameter model for finance, partly so sensitive work could stay in-house. Research Huyen cites found a general model, released the same month, beat it on finance tests. Millions in compute, beaten the same month.

So keep the raw data local. Send the thinking out. Running the clerk yourself also means far less filtering, because nothing raw is sent at all.

One rule keeps the split honest. The field list is the contract. If a field is not on it, it does not leave the machine.

This is how a customer truth system can run on sensitive sales calls without the calls going anywhere.

Treat what the AI writes back as customer data too

Outputs can be more sensitive than inputs. An AI that reads purchases can guess a pregnancy, an illness or a money problem.

The Hacking Growth authors retell the classic warning. Target's coupons for baby clothes reached a teenager before her father knew she was pregnant.

Nobody typed the word pregnant. The system inferred it.

Our rule: any tag an AI creates about a person goes back through the Building Test. It passes before it is stored, sent or used in an ad.

Some privacy laws count these guesses as personal information in their own right. The dated box below has the current wording.

A guess about a person is still about a person.

Check the boundary with samples, not trust

A boundary you never check is a guess. But checking every file by hand kills the job.

Grove's answer was variable inspection. Check more often when problems show up, and less often after weeks without one.

In his monitoring example, three failed samples in a row stop the line. We borrow that number.

Our check plan for the mask and summary lanes has four rules. Start at 20 hand-checked outputs per batch, field by field. After four clean weeks, drop to 10.

Any miss sends you back to 20, plus a fix to the rule that missed. Three misses in a row stop the job until someone finds the cause.

Who checks? Someone who did not build the job. Nobody should grade their own homework.

The full method is in how to evaluate AI agents.

What do privacy laws and vendor terms change?

They change the answer to question three. The method stays the same.

Laws differ by country and by state, and they keep changing. Health data, money data and data about people in Europe usually carry the strictest rules.

The current legal wording, the vendor terms worth reading, and the local tools we use all sit in the dated box below. If your data is regulated, take your draft boundary to counsel; our healthcare and med spa work starts there.

Write your data boundary with AI

Paste the prompt below into your preferred AI. Describe your data, never paste it.

It asks for field names and made-up examples, one question at a time. Then it runs the Building Test on every field and returns a one-page boundary with lanes, reasons, owners and a check plan.

Do three things this week

1. List the three data sets your team most wants to give an AI. Write each field on its own line.

2. Run the prompt and print the boundary. Read every Stay home line aloud to the person who owns that data.

3. Fix the first step. Mask or strip in the export itself, so the raw file never reaches an AI tab.

Remember ticket 312, the one with the card number? Under this boundary it gets masked in the export. The AI never sees it.

Next, decide where the clean data lives and what may read it, with the marketing engineering stack. Customer data also leaves through the events you send to ad platforms, which server-side conversion tracking covers.

Before you buy hardware to save money, check the bill with AI cost controls. Most teams find it smaller than they feared.

The safest lock in the building is the one on the export button.