AI Data Privacy: Where Does Your Company Data Actually Go?

Published 2026-09-22 · Updated 2026-09-22 · 7 min read · ShooWork (FreeCo Co., Ltd.)

Before you pick an AI vendor, map where your data goes. Five questions on data flow, minimization, policy and logs to answer before you sign anything.

If you want to know where your company data ends up once you switch on an AI feature, the honest answer is: wherever your architecture sends it — and almost nobody draws that map before the project ships. In most rollouts the privacy question arrives last. A week before launch, someone in a meeting says "hang on, are we allowed to send customer records to this thing?" That ordering is backwards. Data flow belongs before model selection, because the answer deletes options and changes architecture. Retrofitting privacy costs roughly ten times what designing it in would have cost.

The good part: none of this requires a security engineering background. It requires five written answers, in plain language, that a non-technical decision maker can read and sign. If your team can produce those five answers, you are already ahead of most companies shipping AI features right now. If they cannot, the project is not ready, no matter how good the demo looked.

We run a membership commerce business alongside our own subscription AI platform — ShooWork Clip for video editing, ShooWork Write for SEO articles, ShooWork Ads for campaign management — so we hold real customer data and we push LLMs through daily operations. This checklist is what we actually use before signing off on an AI project, written for the person doing the signing rather than the person doing the wiring.

Question one: where does the data actually go?

Draw the path. Data leaves your system, passes through some list of services, lands on hardware in some country, and some set of humans could theoretically read it. Put that on one page. If nobody on your team can draw it without guessing, that is your finding for the week. Three blind spots show up almost every time:

• "Using AI" is not the same as "handing your data over for training." Enterprise API tiers from the major model providers generally do not train on your inputs by default. Free and personal web tiers are a different contract entirely. Read which one you are on, and read it in the terms document rather than in a sales deck.
• Your biggest leak is an employee, not an API. Someone pasting a customer list into a free chatbot to "clean it up quickly" is the most common real-world data exit we see — far riskier than a properly configured integration, because it leaves no audit trail and nobody reports it. Publish an internal rule about this before you build any system. It costs one email and prevents more exposure than most technical controls.
• Middle layers count as data flow. If a SaaS tool you already use has "AI features built in," your data now passes through one more party on its way to a model. Ask who sits behind that feature and what the contract says. Vendors are usually happy to tell you; the problem is that nobody asks.

One more habit worth building: retention terms change. How long does the provider hold API data, when is it deleted, is there a zero-retention option? Save a dated copy of the current terms and put a review in the calendar once a year. "We checked that in 2024" is not an answer.

Question two: which data should never leave at all?

Before "where does it go," ask "does it need to go anywhere?" Our operating principle is data minimization: the model receives the smallest dataset that still completes the task. Three tactics do most of the work.

1. De-identify before the call. Strip names, phone numbers, addresses, national ID numbers and card numbers out of support conversations programmatically and replace them with tokens. Generate the reply, then swap the real values back in on your side. The model never sees a real person. This is a modest amount of engineering for an enormous reduction in blast radius, and it is the single highest-leverage thing on this page.
2. Whitelist fields, do not dump records. It is tempting to pass the whole customer object because it is one line of code. List the fields the task genuinely needs and send only those. Analyzing purchase patterns does not require knowing where somebody lives.
3. Grade your data once, reuse it forever. Sort everything into three buckets: can cross borders, usable only after de-identification, never leaves our systems. Write it down. Every future AI project starts by checking its inputs against that document instead of re-litigating the question from scratch.

The first principle of data privacy is not "protect the data you send out." It is "data you never send out needs no protection."

If you are building something that needs lots of internal context — a support assistant, an internal search tool — the grading exercise pays for itself immediately, because it tells you which documents can go into the index. We walk through that build in detail in our guide to an AI knowledge base.

Question three: do your promises still cover this?

Most privacy regimes require you to tell people how their data will be used when you collect it. So look at your own privacy policy — the one written three or four years ago by someone who has since left — and check whether it covers "we may send this information to third-party AI services for processing." For most companies, it does not. That is a documentation gap, not an engineering gap, but the fines are real.

Three concrete items: update the privacy policy to name AI processing as a use; confirm your disclosure obligations for cross-border transfers, since your model provider's servers are probably not in your country; and if you serve EU users, sign a data processing agreement with each provider in the chain. None of this is glamorous and all of it is cheap compared to explaining the omission to a regulator later. Our broader AI security checklist covers the access-control side of the same review.

Data your AI generates is still data

This is the corner teams miss most often. Conversation transcripts, model outputs, prompt logs, embedding vectors sitting in a database — all of that is derived data, and much of it contains the customer information you were careful about on the way in. Where is it stored? Who can query it? How long does it live? Does it get deleted when the customer asks to be forgotten?

We have seen companies lock down their production database beautifully and then leave six months of AI chat logs — full of names, order numbers and complaint details — sitting in a log bucket that half the engineering team can read and nobody has ever audited. Debug logging is the usual culprit: someone logs the full prompt during development to diagnose a formatting bug, and it never gets turned off. Add log redaction to the same pipeline that does your de-identification, and put retention limits on the log store the same way you would on a customer table.

Vector databases deserve a specific mention. An embedding is not human-readable, which makes people treat it as anonymous. It is not — it is a lossy encoding of the source text, and the source text is usually sitting right next to it as metadata so you can display citations. Grade it like the original document.

The one-page checklist before you sign

Before approving any AI project, confirm that all five of these have written answers — not verbal reassurance in a meeting:

1. A data flow diagram: which services the data passes through and which country it lands in.
2. The provider's training and retention terms, with the version and date you read them.
3. The de-identification and field-whitelist implementation, described in enough detail that someone could verify it.
4. Confirmation that your privacy policy covers this use, updated if it does not.
5. An internal rule prohibiting staff from pasting customer data into personal-tier AI tools, plus a sanctioned alternative so the rule is followable.

Answer all five and your AI project clears the privacy bar more convincingly than most of the market. Notice that only one of the five is an engineering task. The rest are decisions and documents, which means they can be done this week rather than next quarter — and that item five, the cheapest one on the list, prevents more real exposure than the other four combined.

None of this exists to stop you using AI. We use it hard, every day, across our own products — you can read our unvarnished account of that in how we actually use AI at work. The point of the checklist is to let you keep using it in two years without a cleanup project, a regulator letter, or an awkward email to your customers. If you want to see how we handle these constraints inside our own tools, the plan details are on the pricing page — check there for current numbers rather than trusting any figure quoted in an article.

FAQ

Q: Does using an AI API mean the provider trains on my company data?
Usually not, on business and enterprise API tiers — the major providers state that API inputs are not used for training by default. Free and consumer web tiers often have different terms. The only reliable method is to open the current terms for the exact plan you are on, save a dated copy, and re-check annually, because these documents get revised.

Q: Is it really that bad if someone pastes customer data into a free chatbot?
It is the most common data exit we see. Beyond the vendor's terms, you get no audit trail, no retention control, no deletion path, and no way to tell a regulator or a customer what was exposed. Ban it explicitly and give people an approved tool instead, because a rule with no alternative just gets ignored quietly.

Q: Do I have to update my privacy policy before launching an AI feature?
If your policy does not mention sending data to third-party processors for AI-based processing, then yes, update it before launch. Also check your cross-border transfer disclosures, since model providers rarely host in your country, and sign a data processing agreement with each provider if you serve EU users.

Q: What is the single cheapest way to cut AI privacy risk?
De-identification at the boundary. Mask names, contact details and identifiers with tokens before the API call and restore them in your own system afterwards. It is a contained piece of engineering, it works across every current and future model vendor, and it means a provider breach never touches your customers' actual identities.

Q: Are embeddings in a vector database anonymous?
No. An embedding is a lossy encoding of the source text, not an anonymization technique, and in most implementations the original chunk is stored alongside it as metadata so you can show citations. Classify a vector store with the same sensitivity grade as the documents you loaded into it, and apply the same retention and access rules.

← AI Knowledge Base · 中文版