Data Privacy for AI Tools: The Decisions to Make First

Most small businesses adopt AI tools without ever deciding what data is allowed to reach them, and then discover the answer retroactively when a client asks. This guide is the set of decisions to make first: what leaves your boundary, what the vendor may keep, and what you write down so the question has an answer before it is asked.

The symptom is a stack of tools nobody audited, a client questionnaire you cannot complete, and a vague sense that pasting a contract into a chat window was probably fine.

What you will end up with#

A written list of what may reach which tool, vendor terms you have actually read, a redaction layer where it matters, and a one-page answer for the next client who asks. Eleven lessons.

What this does not cover: legal advice, sector-specific regimes like HIPAA, or building a compliance programme. This is the practical layer a one-person or small business can actually run.

One framing worth carrying: nothing here is about trusting or distrusting AI vendors. It is about knowing what you have agreed to, which is a different and much more answerable question. Most of the discomfort people feel comes from not knowing, and the fix for not knowing is an afternoon.

Controls chosen before the inventory protect the wrong things and miss the logging path.

Lesson 1Inventory what already leaves#

Before deciding policy, find out what is happening today. This takes an afternoon and it is uncomfortable, which is why it is skipped and why it is first.

List every AI tool anyone in the business touches, including the ones nobody approved:

The method matters less than the honesty. Ask people what they actually do rather than what the process says, and ask about the last week rather than in general, because "in general" produces the sanitised version. "What did you paste into a chat window this week" gets a truthful answer; "do you follow our AI policy" does not.

1. The chat assistants people paste into, on personal accounts as well as company ones.
2. The APIs your automations call.
3. Anything embedded in a product you already pay for, where AI arrived in an update.
4. Browser extensions and IDE assistants, which see more than anyone remembers.

Do this without blame attached. The point of the inventory is an accurate picture, and an audit that people expect to be punished for produces an inaccurate one. Anyone who has been pasting client emails into a personal chat account needs to feel able to say so, because you cannot fix what nobody admits.

Row three is the one that surprises people: AI arrived in an update to a tool you approved years ago.

Item 3 is the one that surprises people. Features get added to existing tools, enabled by default, and nobody re-reads the terms because the tool was approved two years ago under different behaviour.

Give yourself a deadline on this, because an inventory that aims for completeness never finishes. An afternoon that captures the eight tools people actually use daily beats a month-long exercise that catalogues everything and gets abandoned at 60%. You can add the long tail later; the daily eight are where the exposure is.

Lesson 2Sort your data before you sort your tools#

Not all data needs the same treatment, and treating it uniformly means either blocking work that is fine or permitting work that is not.

Three tiers cover almost every small business:

A useful test for placing something: if this appeared in a screenshot on someone else's blog, would it be a problem? Public tier, no. Confidential tier, embarrassing. Personal tier, a notifiable incident. That question sorts most edge cases faster than a taxonomy does.

The top and bottom are obvious. The middle is where people improvise.

The middle tier is where the real decisions live. The top tier needs no policy and the bottom tier is obvious once someone says it out loud; the confidential-but-not-personal middle is where people improvise.

One thing to decide alongside the tiers: who is allowed to change them. In a small business the answer is usually one person, and naming that person prevents the slow drift where each new tool gets classified by whoever adopted it. A tier list everyone can edit is a tier list nobody follows.

1. Write the three tiers with YOUR examples, not generic ones.
2. Put the list somewhere people will see it, not in a policy document nobody opens.
3. Decide the middle tier deliberately, because that is the one that will be tested.

Lesson 3Read what the vendor actually promises#

Vendor privacy claims sit on a spectrum and the marketing page is not where the answer lives. Four questions settle it, and all four have answers in the terms if you look.

Do this once per vendor and record the answers with a date, in the same place as the tier list. The reason for the date is that these terms change on the vendor's schedule and they change quietly: a policy update lands in a release note, and the version you read eighteen months ago is not the version you are operating under. A dated note turns "I think we checked" into something you can stand behind.

1. Is my data used to train their models? Most business tiers now say no by default. Most consumer tiers do not.
2. How long is it retained? Zero-retention is offered by several providers, usually on request or on a specific tier, and it is a meaningfully different promise from "we delete after 30 days".
3. Who can see it? Human review for abuse monitoring is common and is often the detail that matters most to a client.
4. Where is it processed? Region matters for some contracts and for some regulations.

The gap within one product is usually larger than the gap between two vendors.

The gap between consumer and business tiers of the SAME product is usually larger than the gap between two different vendors. Someone using a personal account for work has a materially different privacy posture from the company plan, and that is invisible from the outside.

1. Check the tier, not just the vendor.
2. Get the answers in writing, in the terms or a data-processing agreement.
3. Note the date you checked, because these terms change.

Lesson 4Decide the middle tier deliberately#

For business-confidential data, the question is not whether to use AI tools. It is which ones, on what terms, and with what written down.

A workable default for a small business:

Public/trivial      -> any tool
Confidential        -> approved list only, business tier, terms on file
Personal/client     -> redact first, or keep it inside the boundary
Unsure              -> treat as the tier above until someone decides

Keep the approved list short enough that people can remember it. A list of three tools gets followed; a list of fifteen becomes a document nobody opens, and the practical effect of an unmemorable policy is that everyone falls back to whatever is open in another tab. Fewer approved tools, each properly checked, beats broad coverage nobody can recall.

That last line does more work than the others. Most breaches of your own policy are not defiance, they are someone hitting an unclassified case at 5pm and guessing. A default of "treat as more sensitive" makes the guess safe.

Lesson 5Redact before you send, not after#

Redaction is the highest-value control available to a small business, because it converts a policy problem into a technical one and technical ones can be enforced.

The pattern:

1. Detect identifiers before the prompt is assembled: names, emails, phone numbers, account and card numbers, addresses.
2. Replace them with stable placeholders, so the model can still reason about relationships.
3. Send the redacted version.
4. Re-insert the real values in the response, if the response needs them.

raw     : "Refund Sarah Chen (sarah@acme.com, order 40912) for GBP 240"
redacted: "Refund PERSON_1 (EMAIL_1, order ORDER_1) for GBP 240"
restored: mapping applied to the reply before it reaches anyone

One caveat worth knowing before you rely on it: detection is imperfect. Regex catches structured identifiers like emails and card numbers reliably, and names in free text much less so. Layer a model-based detector over the pattern matching if the data is sensitive enough to matter, and accept that the result is risk reduction rather than a guarantee.

Step 2 is what makes it usable. Stripping identifiers entirely destroys the meaning; replacing them consistently keeps the structure the model needs while sending nothing identifying.

Placement matters as much as detection. Redact at the point the prompt is assembled, not inside the model call, so everything downstream of assembly, including your logs and traces, sees the redacted version. Redacting inside the client library means the raw prompt was already logged by whatever wrapped it, which is precisely the failure lesson 6 is about.

The detection stack and where to place it in the pipeline are in PII Redaction in LLM Pipelines.

Lesson 6Find the paths you forgot#

The model is rarely the leak. The surrounding infrastructure is, because it was built for debugging rather than for privacy.

There is a reason this catches people who are otherwise careful. Every one of these paths was built deliberately, for a good reason, by someone solving a different problem: you wanted to debug a failure, so you logged the payload. None of them was a privacy decision, which is exactly why none of them got a privacy review.

Four places data escapes without anyone deciding it should:

The model is rarely the leak. The debugging infrastructure usually is.

The first row is the one that catches careful teams. The model provider had zero retention, the prompts went to a logging service on a different continent, and both facts were true at once.

One more path that belongs on the list and rarely makes it: anything a person copies out. A support ticket quoting the failing prompt, a screenshot in a Slack thread, a bug report pasted into a vendor's portal. Those leave your boundary through a human rather than a system, and no configuration change prevents them. Only telling people does.

Draw the data-flow diagram and follow one real prompt through every hop. It takes twenty minutes and it is the only reliable way to find these.

Lesson 7Keep data inside the boundary when the reason is real#

Sometimes the answer is that the data genuinely cannot leave, and no vendor promise substitutes for that. When it applies, it applies, and the setup follows from it rather than the other way round.

The cases where it is a real requirement rather than a preference:

It is worth separating a genuine requirement from an inherited assumption, because the cost difference is large. "Our clients are sensitive about data" is a real business concern and is not the same as a clause you can quote. If the requirement turns out to be assumed rather than written, you have the option of satisfying it with terms and redaction instead of infrastructure, which is usually what people actually wanted.

1. A contract says so explicitly, in words you can point at.
2. A regulation applies to your sector and your jurisdiction.
3. A client asked and you agreed, which makes it contractual whether or not it is written well.

Be honest about the operational cost before choosing it, because the requirement being real does not make the setup free. Running your own model means owning uptime, updates, evaluation and a fallback path, indefinitely, and that work lands on whoever already has other work. A real requirement justifies the cost; it does not remove it.

If none of those hold, a business-tier vendor with zero retention plus the redaction from lesson 5 usually achieves what people actually want, at a fraction of the operational cost of running your own model.

There is a middle option people skip past. A hosted model with zero retention, in a region you chose, under a signed data-processing agreement, with identifiers redacted before they are sent, is a genuinely strong posture. It satisfies most client questions and nearly every contract that is not sector-specific, without anyone owning a GPU.

The trade-offs and the cost of the local route are in Local LLMs for Business.

Lesson 8Write the retention rule down#

Retention is where two separate policies collide: what the vendor keeps, and what you keep. Most small businesses have thought about neither, and the second is the one entirely within your control.

Retention is the control with the best ratio of effort to risk reduction in this entire guide. Setting a log TTL is a configuration change measured in minutes, and it converts an indefinitely-growing liability into a bounded one. Nothing else here is that cheap.

Retention interacts with the delete question in a way that catches people. If a client asks you to delete their data, your obligation covers your logs, caches and backups, not just the vendor. A 30-day log policy makes that request answerable; an indefinite one makes it a project.

The vendor is one hop. The other three are yours, and backups outlive retention policies.

The second row is the sharp one. An indefinite log of every prompt your business ever sent is a liability you created yourself, and it is the one a client questionnaire will eventually ask about.

Lesson 9Know which regulation actually touches you#

Most small businesses are subject to less than they fear and more than they check. The honest version is short.

One thing worth saying plainly before the list: this is the area where a small business is most likely to either over-worry or under-check, and the two often coexist. People fret about regulations that do not apply to them while never reading the data clause in the contract they signed last month. Read your own agreements first.

1. Data protection law where your customers live applies whether or not AI is involved. AI does not create a new obligation so much as create new ways to breach an existing one.
2. The EU AI Act has obligations that scale with risk, and most small-business uses sit at the transparency end rather than the high-risk end.
3. Sector rules are the ones that actually bite: health, finance, legal, education. If you are in one, it outranks everything here.
4. Your contracts are frequently stricter than any regulation, and are the thing you will be held to first.

One practical note on transparency, which is the obligation most likely to touch a small business: if customers interact with something automated, say so. It is cheap, it is usually required at the transparency tier, and it prevents the much worse conversation that follows someone discovering it themselves.

A useful sanity check on scope: ask whether the AI tool changed anything about your obligations, or only about the number of places the data now sits. Most of the time it is the second, which means the answer is not a new compliance programme but the same obligations applied to a longer list of systems. That reframing makes the work finite.

Point 4 is worth internalising. The clause a client put in a services agreement is enforceable against you next quarter; the regulation is a slower, more distant risk. Read your own contracts before you read the legislation.

The builder-level read on the AI Act is in The EU AI Act Reaches Agents.

Lesson 10Write the one-page answer before you are asked#

Every client questionnaire asks the same handful of questions. Writing the answers once turns a two-hour scramble into a two-minute reply, and the act of writing them is what surfaces the gaps.

Write it for a reader who is not technical, because the person sending you the questionnaire usually is not. They are trying to close a procurement item, and a clear page that answers all five questions gets signed off, while a technically precise one full of terms they do not recognise generates a follow-up call.

One page, five headings:

1. Which AI tools we use, and on what tier
2. What categories of data reach them, and what never does
3. Whether our data is used for training (and the term proving it)
4. How long anything is retained, on their side and ours
5. What we do if you ask us to stop or delete

Keep it in plain language and keep it honest. A questionnaire answer that overstates your posture is worse than one that says "we use business-tier terms with zero retention, we redact identifiers before sending, and our own logs are kept 30 days". That is specific, modest, and checkable. Specific and modest reads as true, because it usually is.

Writing the last item is what exposes whether you could actually delete on request.

Writing item 5 is the one that changes behaviour, because it forces you to check whether you actually could. If the answer is "delete from the vendor, our logs, our caches, and our backups" and you have never tried, you have found the gap.

Lesson 11Review it when something changes#

This is not a quarterly ritual. It is a short list of triggers, because the things that invalidate a privacy posture are events rather than dates.

1. A vendor changes its terms, which they announce and nobody reads.
2. A tool adds an AI feature in an update, silently enabled.
3. You sign a client contract with a data clause.
4. Someone joins, or starts using a tool on a personal account.

Attach the review to those triggers rather than to a calendar, because a quarterly reminder for something that changes on external events will either fire when nothing has happened or miss the month something did. The exception is the vendor-terms check, which benefits from an annual sweep simply because "they announce it" is not the same as "you noticed".

Trigger 2 is the most common and the least visible. A tool you audited last year is not the tool you are running today, and the change arrived in a release note.

What I would do differently#

Audit the logging, not just the model providers. A provider with zero retention and an application writing every prompt to a hosted log with an indefinite policy are both true at once, and only one of them is usually in anyone's head. The second one was set up deliberately, for debugging, by someone solving a different problem.

That combination is worse than it looks, because it makes an honest answer wrong. A questionnaire response citing the provider's retention policy is true about the provider and incomplete about the system, and nothing surfaces the gap.

Follow one real prompt through every hop, on paper, before claiming anything about where data goes. Twenty minutes, and it is the only method that reliably finds this.

There is a subtler version worth naming. The providers chosen deliberately tend to be fine, precisely because they were chosen deliberately. The exposure sits in the ones that arrived by default inside tools already being paid for, where nobody re-read anything because the tool was approved years ago under different behaviour.

The second thing is treating privacy as a yes or no per tool rather than as tiers of data. A blanket rule that blocks pasting a marketing headline into a chat window is a rule that teaches people the rules are wrong, and they will apply that lesson to the rules that matter. Tiering the data is what makes the policy survivable.

Keep it to three tiers and resist a fourth. Every extra tier feels more precise and makes the list harder to hold in your head, which is the only property that determines whether anyone uses it.

Third: write the one-page client answer before anyone asks. It takes an hour when nobody is waiting, and item 5 in particular exposes whether deletion on request is actually possible. Written under time pressure, it gets written badly.

One note on sequencing. Inventory, tier, then control. Privacy efforts that start with controls, buying a tool or writing a policy before anyone knows what data is moving, tend to protect the wrong things while missing the logging path entirely.

What I am still unsure about is personal accounts. Company-tier terms are meaningfully better, and telling people not to use their own accounts is a rule with no enforcement behind it in a small business. Ask, explain why, and assume some of it happens anyway. I do not have a good answer.

One last thing about sequencing. Inventory, tier, then control. Almost every privacy effort I have seen start with controls, buying a tool or writing a policy before anyone knew what data was moving, and controls chosen before the inventory tend to protect the wrong things while missing the logging path entirely.

Where to go next#

If none of this is written down, lesson 1 is the whole thing compressed: an afternoon listing what already leaves, including the tools nobody approved.

If the answer is redaction, PII Redaction in LLM Pipelines is the layer that does most of the work. If the answer is genuinely keeping data in-house, Local LLMs for Business has the honest cost of that. For agent permissions specifically, AI Agent Guardrails in n8n, and for the regulation, The EU AI Act Reaches Agents.