Is It Safe to Put Client Data Into AI Tools?

Freelancers and agencies ask whether it is safe to put client data into AI tools as though the answer lived on the vendor's trust page. It does not. The vendor's security posture tells you how likely a breach is. Your contract with the client tells you whether you were allowed to send the data at all. Those are different questions, and the second one is the one that gets people into trouble.

A tool can be perfectly secure and still put you in breach of an agreement you signed.

When it is safe to put client data into AI

Work through it in this order.

One: does your contract name permitted subprocessors? Many client agreements, especially with anyone who has a compliance function, list the third parties you may pass data to, or require written approval before adding one. An AI vendor is a subprocessor. If the list exists and your tool is not on it, pasting the data is a breach regardless of how the tool handles it. The fix is administrative: ask for the addition in writing.

Two: what does the confidentiality clause actually restrict? Most say you will not disclose confidential information to third parties except as needed to perform the work, often with a requirement that recipients be bound by equivalent terms. Sending text to an API is a disclosure to a third party. Whether it is a permitted one depends on that "except" and on whether the vendor's terms bind them to equivalent confidentiality.

Three: is there personal data in it? If the material includes information about identifiable people, and most client material does, then data protection obligations attach on top of the contract. That typically means the client is the controller, you are a processor, and under rules such as Article 28 of the GDPR a processor may not engage another processor without the controller's authorisation. The question stops being about your judgment and becomes about the client's instructions.

If all three clear, you are in reasonable shape. If any of them is unresolved, the honest position is that you do not yet have permission.

What a no-training commitment does and does not cover

Business and enterprise tiers of the major assistants commonly commit not to train on your inputs by default. That commitment is real and worth having. It is also narrower than people read it as.

It does cover: your prompts and outputs not being used to improve the vendor's models.

It does not cover:

• Retention. Inputs are typically still stored for a period, often for abuse monitoring, and are readable by the vendor's staff under defined conditions. Zero training is not zero retention.

• Logging on your side. Your own tooling, browser extensions, IDE plugins, and chat history may retain the same content in places your client never agreed to.

• Sub-processors of the vendor. The model provider may use cloud infrastructure and moderation services of its own. Your client's chain of custody now includes those too.

• The free tier. Defaults differ between consumer and business plans, and the plan you personally use at home is often not the plan your agency pays for.

• Anything an agent pulls in. If you give a tool access to a shared drive or inbox, the scope of what gets sent is no longer what you pasted.

That last one is where most accidental disclosure now happens, and it is worth reading whether it is safe to give AI access to your data before wiring a tool into a client's systems.

The practical middle path

Refusing to use AI on client work is a competitive choice you are free to make, but it is rarely the only safe option. Three things that work:

Strip before you send. Names, addresses, account numbers, and identifiers usually contribute nothing to the task. A model does not need to know the customer is called Ana Beltran to rewrite the paragraph. We have a working method for this in prompting without leaking sensitive data.

Ask once, in writing, per client. A single email that names the tools you use and what you send them, answered with a yes, converts an ongoing risk into a documented permission. Clients say yes far more often than people expect, because they are usually using the same tools.

Put it in the agreement up front. A short clause naming AI tooling as permitted subprocessing, with a commitment to business-tier accounts and no training, is easier to get signed at the start of a relationship than mid-project. Our guide to writing an NDA for an AI project covers the wording side, and the general risk landscape sits in AI risks.

The one case that is simply not safe

If a client has told you no, or their contract forbids it, and you do it anyway because the tool is secure and nobody will know: that is not a security judgment, and the vendor's encryption is irrelevant to it. The exposure is contractual and it lands on you.

Frequently asked questions

Can I paste client documents into a chatbot?

Only if your contract permits disclosure to third-party services and no data protection obligation requires the client's instruction first. Check the subprocessor and confidentiality clauses before deciding.

Does a business plan make client data safe?

It improves it. Business tiers usually commit to no training on your inputs, which is meaningful. It does not remove retention, the vendor's own subprocessors, or your contractual duty to get permission.

Should I tell my client I use AI tools?

Yes, and ideally in writing before the work starts. It is the cheapest way to turn an open question into a documented approval, and most clients are using the same tools themselves.

Is anonymised data fine to send?

Stripping direct identifiers lowers the risk substantially and is good practice regardless. Be aware that combinations of details can still identify someone, so treat removal as risk reduction rather than a complete answer.