Before You Adopt AI, Ask: Where Is Your Data Going?

In AI adoption discussions, data privacy is usually the question remembered last — typically when the system is nearly live and someone finally asks, "wait, is it okay to send customer data to the AI like this?" That order is backwards. Data flows should be thought through before model selection, because they directly eliminate certain options and reshape certain architectures. Fixing it afterward costs an order of magnitude more than planning it upfront.

We run a membership-based e-commerce business and a subscription AI product ourselves — we hold real customer data, and we genuinely use LLMs in daily operations. This article is a checklist written for decision-makers: no technical background required, but every question should have an answer before you sign.

Question one: where does the data actually go?

Draw the data path for your AI feature: data leaves your system, passes through which services, lands in data centers in which country, visible to whom. Three common blind spots:

• "Using AI" does not mean "your data trains the AI company's models": The enterprise API plans of the major model vendors do not use your data for training by default — but the free and personal-tier web tools may. An employee pasting a customer list into a free chat tool is the most common real-world leak path, far more dangerous than an API integration. Issuing an internal policy comes before building any system.
• Middle layers are flows too: If a SaaS tool you use has "built-in AI features," your data now passes through one more pair of hands. Ask exactly whose models sit behind it and how the contract is worded.
• Read the retention policy in the documents, not from the sales rep: How long API data is retained, when it's deleted, whether a zero-retention option exists — terms differ by vendor and they change over time. Archive the version of the terms you agreed to and put it on an annual review cycle.

Question two: which data should never be sent at all?

Before "where does it go" comes "should it go." Our principle is data minimization: the model receives only the minimum data set needed to complete the task. Three practical techniques:

1. De-identification: Before a support conversation enters the model, programmatically mask names, phone numbers, addresses, national ID numbers, and credit card numbers, replacing them with tokens. After the reply is generated, the system swaps them back — the model never sees real personal data at any point. This is a step that's easy engineering and enormous payoff.
2. Field allowlists: Don't dump a whole customer record into the model for convenience. List the fields the task genuinely needs and send nothing else. Analyzing purchase behavior doesn't require knowing where the customer lives.
3. Tiered handling: Classify data into three tiers — "may leave the country," "usable after de-identification," and "never leaves our own systems" — write it down, and have every AI project check against it before work begins.

The first principle of data privacy isn't "protect the data you send out" — it's "what you don't send out needs no protecting."

Question three: do your legal obligations and promises line up?

Taiwan's Personal Data Protection Act requires clear notice of how personal data will be used at the time of collection — does your existing privacy policy cover "providing data to AI services for processing"? Most companies' policies are versions from years ago, and this clause doesn't line up. What to do: update the privacy policy, confirm your notification obligations for cross-border transfers, and if your users include EU residents, sign a data processing agreement (DPA) under GDPR. These aren't engineering problems, they're paperwork problems — but the fines are real.

One more easily overlooked corner: AI-generated data is data too. Conversation logs, model outputs, embedding vector databases — where this derived data is stored, who can query it, and how long it's kept must also be governed. Many teams lock down the source data tightly while AI conversation logs full of customer information sit in unmanaged log files.

A one-page checklist for decision-makers

Before signing off on any AI project, confirm these five things have answers in writing: one, a data-flow diagram (which services it passes through, where it lands); two, the model vendor's training-use and retention terms, with version; three, how de-identification and field allowlists are implemented; four, whether the privacy policy covers this use; five, whether internal policy prohibits staff from pasting customer data into personal-tier AI tools. Answer all five and your AI project is ahead of most of the market on privacy.

These checks aren't meant to stop you from using AI — we use it heavily ourselves — they're meant to let you use it safely and for the long run. If you'd like help designing your data architecture and AI adoption right in one pass, see AI development services or just get in touch; for the overall adoption mindset, start with The first step in AI adoption.