How to Keep Client Data Separate When Using AI

If you work for several clients, the way to keep client data separate when using AI is a separate container per client, not separate habits. A workspace, project or account boundary that the tool enforces will hold when you are tired. A rule you follow by hand will not. The distinction matters because the common failure is not a vendor breach, it is Client B's proposal quietly picking up a detail from Client A's contract because both lived in the same assistant.

What follows is the boundary model, the four leak paths worth knowing, and a setup you can finish in an afternoon.

Boundaries that hold, and ones that do not

The top two rows are the ones to build on. Everything below them is hygiene that helps but cannot be audited, and an audit is exactly what a client asks for when something goes wrong.

The four ways client data actually crosses over

1. Memory that spans conversations

Assistants that remember across sessions are the most common cause of cross-client bleed, because the feature is designed to work invisibly. A detail you mentioned in March about one client's pricing can surface in October while you draft something for a different one. Check whether memory is on, whether it is scoped per project or per account, and turn it off in any container where you handle client material. Our explainer on what happens to your prompts after you send them covers the storage side of this.

2. Files that stay attached to the container

Uploading a client's spreadsheet to a project usually attaches it to that project, not to the single message. Every later conversation in that project can read it. That is useful when the project is one client, and a confidentiality problem when the project is "work".

3. Connected tools with wider reach than the chat

A connected drive, inbox or repository does not respect the boundary you drew in your head. If the assistant can search your whole drive, it can pull Client A's folder into an answer about Client B. Scope connectors to the narrowest folder that makes the work possible, and prefer a connector you can point at one client's directory over one pointed at everything.

4. You, moving text between windows

The least technical path and the most frequent. Pasting a real contract to "show the model the format" puts a counterparty's terms into a system you may not have cleared for it. Redacting before pasting is a reliable habit, and our guide to prompting without leaking sensitive data goes through what to strip.

A setup that survives a busy week

1. One container per client. A project, workspace or account, whichever your tool enforces. Name it after the client and nothing else, so putting work in the wrong place requires actively choosing the wrong name.

2. Memory off, or scoped to the container. If the setting is account-wide and cannot be scoped, that is a reason to use separate accounts for your most sensitive client rather than separate projects.

3. A separate key per client for anything you build. It costs nothing and means a single revocation does not take down every other client's integration.

4. Connectors scoped to that client's folder only. Re-check after any tool update, because permission scopes are a common thing for vendors to widen quietly.

5. Retention set deliberately. Find the retention or training setting once and record what it says. Our checklist for finding out whether a tool trains on your data covers where these settings hide.

6. A one-page record of the above. Which tool, which container, what retention, who has access. This is the document that answers a client's question in five minutes instead of five days.

When someone else touches the work

Subcontractors are where a tidy setup usually comes apart, because the simplest thing is to share your login. Shared logins destroy the separation you just built and make the audit trail meaningless, since every action belongs to one identity. Give a named seat inside the right client's container instead, and remove it when the engagement ends. We cover the mechanics in giving a contractor access to your AI tools, and keeping a usable record of who did what in how to keep an audit trail of AI use.

What to do if it has already happened

Assume something has crossed over at some point, because for most people it has. The useful response is narrow and quick:

• Work out what moved and into which container, rather than how embarrassing it is.

• Delete the stored artefact at the source: the file in the project, the memory entry, the conversation.

• Check whether the output went anywhere external, since a document already sent to Client B is a different problem from a draft on your screen.

• Check your contracts for a notification clause before deciding whether to tell anyone. Many confidentiality agreements require it regardless of harm.

• Fix the container, not the habit. If it happened once with care applied, care is not the control.

For the wider picture of where AI tools create exposure beyond this one problem, see our overview of AI risks for people building and running businesses.

Frequently asked questions

Is one paid account with separate projects enough?

Usually yes, provided memory is scoped to the project rather than the account and files attach per project. If memory is account-wide with no scoping, separate accounts are the only real boundary.

Does starting a new chat keep clients separate?

Not on its own. A new chat clears the visible conversation, but account-level memory, project files and connected tools can still carry information across.

Do I need to tell clients which AI tools I use?

Check the agreement you signed. Many confidentiality and data-processing clauses require disclosure of subprocessors, which an AI vendor may well be, and some clients prohibit specific tools outright.

Is a local model a way around all of this?

It removes the vendor from the picture but not the separation problem. A local model with access to a shared folder mixes clients just as readily. The container discipline still applies.