Where Did the Customer's Data Go?

Deleting the original is not a map of where its copies went.

I would rather ask a business to trace one record than begin with a sweeping promise about its data. An AI workflow can involve an intake system, extracted text, a service request, a saved draft and operational records. Which of those actually retains information depends on the implementation. The first job is to find out.

The FTC's business guidance starts with taking stock: know what information you hold, how it moves and who can access it. It also recommends keeping only what the business needs. I am turning that inventory habit into a small workflow exercise.¹

Follow the record, not the product name

Start with five zones. They are questions to inspect, not a claim that every system stores data in all five places. A service may avoid retaining request content; a business may still save the resulting document elsewhere. “Not used for training” and “not retained” are different questions, so ask both without assuming the answers.

NIST's January 2020 Privacy Framework edition provides a useful foundation: inventory data processing, identify owners and locations, and map flows. It also treats deletion, destruction, minimized audit records and backups as explicit management concerns. I am citing that identified edition, not claiming it is the newest framework.²

Rehearse with a record that is not a customer

Here is a synthetic example. A repair shop drafts a service summary from an intake form. A workflow extracts the problem description, sends selected text to an AI service, and saves a draft for the owner to review. The shop later deletes the intake entry.

The remaining questions are concrete. Was the extracted text written to a temporary file? Did request logging include it? Where was the draft saved? Was an email copy created? Does a backup contain the earlier entry? These are possibilities to verify, not assertions about a particular vendor.

Use an unmistakably fictional test record containing no personal information. With appropriate authorization, follow its marker through the approved workflow. Record the places where you can observe it, then ask the system owner about places you cannot inspect. Absence from a visible screen does not settle what is retained elsewhere.

Make one Copy Card

For each discovered location, write a short card. My version has five entries:

• Contents: the fields or metadata present, not just the file name.
• Responsibility: the person or service owner who can explain and control that copy.
• Purpose: why it is needed and who may access it.
• Lifecycle: retention, deletion, backup expiry and any applicable hold.
• Evidence: the setting, contract, documented policy or authorized test supporting the answer.

Write “unknown” when the answer is unknown. That is a useful finding. A vague assurance should not become a precise retention promise just because the workflow diagram looks tidy.

Then choose one practical move: remove an unnecessary field, disable an unnecessary content log, or clarify an unresolved retention policy with the responsible owner. Follow the organization's authorization and change process; some records must be retained, and backups may have separate expiry behavior.

What this map does not prove

This exercise is not a legal opinion, a security audit, proof of immediate deletion from backups or certification of a provider. It does not establish that a tool trains on your records, nor that it never does. Those answers require evidence for the specific service, account, deployment and jurisdiction.

It gives you a smaller, answerable question: where can this one record go, and what can we verify about each copy? Try it on one approved workflow. If the team cannot name the owner of a copy, you have found a good place to begin the conversation.