How to Write an AI Usage Policy for Clients

An AI usage policy for clients is a one-page document that states where AI is used in your work, what client material is allowed to reach a model, who reviews the output, and who owns the result. It is not a legal contract and it does not replace your terms of business. It exists so that the question "do you use AI on our account?" has one written answer instead of five improvised ones, and so a nervous procurement team has something to file. Freelancers and small agencies who publish one tend to get asked fewer questions, not more.

Why write one at all

Three things happen without a policy. A client discovers AI in your process from a stray artifact rather than from you, which reads as concealment even when nothing was concealed. Different people on your team give different answers to the same client question. And you end up agreeing, verbally and under pressure, to a blanket no-AI condition you cannot actually honour, because your IDE, your email client and your design tool all ship AI features you did not choose.

That last one is the trap worth naming early. A blanket prohibition is usually unenforceable now. A specific one, for example no client source code in third-party models without written approval, is enforceable and is usually what the client actually meant.

The six clauses that do the work

Keep it to one page. Longer policies do not get read, and every extra clause is another promise to keep.

1. Scope: what counts as AI here

Name the categories, not the products, because products change monthly. Something like: generative models used for drafting, code assistants integrated in the development environment, transcription and meeting summarisation, and automated translation. Explicitly say that spell-check, autocomplete and search ranking are out of scope, or you will be re-litigating the definition forever.

2. What client material may reach a model

This is the clause clients care about and the one most policies fumble. Use three tiers rather than a yes or no.

The distinction between commercial and consumer accounts is the practically important one, and it is checkable. Anthropic's commercial terms state that it will not use inputs or outputs from commercial products to train its models, and OpenAI states that data sent to the API is not used to train or improve its models unless you opt in. Consumer tiers of the same products follow different rules. If your policy says restricted material only goes to commercial tiers, you have made a claim you can actually substantiate.

3. Human review and accountability

State plainly that a named human reviews every AI-assisted deliverable before it reaches the client, and that you are accountable for the output exactly as if you had written every word. This is the clause that converts the policy from a disclosure into a reassurance, and it costs you nothing because it is already true of any work you would be willing to invoice for.

4. Disclosure level

Decide once how much detail you volunteer, then apply it consistently.

• Blanket disclosure: the policy exists, is public, and covers all engagements. Lowest friction, and the right default for most freelancers.

• Per-deliverable disclosure: you note AI assistance on specific artifacts. Appropriate for writing and design work where provenance matters to the client's own compliance.

• On-request disclosure: you answer honestly when asked but do not volunteer. Defensible, but it is the option most likely to read badly if the client finds out another way.

5. Ownership and third-party rights

Say who owns AI-assisted deliverables (in almost every case: the client, same as the rest of the work) and state that you do not knowingly deliver AI output that reproduces third-party material. If you write code, this is where you say something about license contamination, because that is the real exposure and a general ownership clause does not cover it.

6. What happens when the client says no

Write the opt-out before you need it. A good version: on written request, the engagement runs under restricted-tier rules only, with an agreed adjustment to timeline or rate where that changes the work. Naming the tradeoff in advance is far easier than negotiating it mid-project, and it also quietly signals that AI assistance was priced into the quote.

A worked example

Here is the restricted-material clause from a policy that has survived several procurement reviews, reproduced as a pattern rather than as legal text:

Client source code, internal documents and non-public data are entered only into AI tools operating under commercial or enterprise terms that exclude customer content from model training. Consumer or free-tier AI accounts are not used for client material at any time. Personal data and credentials are never entered into an AI tool.

It is short, it is specific, it names the thing that actually varies between tools, and every sentence is one you can prove you follow. Compare that to "we use AI responsibly and in line with industry best practice", which promises more and says nothing.

Four mistakes that make a policy backfire

The failure modes are consistent enough to list.

1. Naming products instead of categories. A policy that lists three specific tools is out of date the first time someone installs a fourth, and an out-of-date policy is evidence against you rather than for you.

2. Promising deletion you do not control. Saying client data is deleted from AI systems on request commits you to something your vendor decides, not you. Say what you control: what you send, and which tier you send it to.

3. Writing a confidentiality promise stronger than your vendor's. If your NDA says client material is never disclosed to third parties and your policy says you send it to a commercial model provider, those two documents disagree. The fix is usually a named-subprocessor clause, not softer wording in the policy.

4. Treating it as fixed. Tool tiers change, defaults change, and a policy written twelve months ago probably describes an account tier you no longer pay for. Put a review date on it, revisit it when you change tools, and keep the old versions so you can show what applied during a past engagement.

Getting it adopted internally

A policy nobody follows is worse than none, because now the gap is documented. Two mechanics carry most of the weight: a list of approved tools with the account tier written next to each, and an offboarding step so access leaves with the person. If your team has already drifted into unapproved AI tools nobody sanctioned, fix that before publishing the policy, not after, and make sure you can remove someone from AI tools when they leave.

Two adjacent documents are worth writing at the same time if they do not exist: how you bill clients for AI API usage when the cost is variable, and the privacy policy for any app you ship. They answer different questions, and clients routinely conflate all three.

FAQ

Do I legally need an AI usage policy?

In most jurisdictions no general law requires a freelancer to publish one. It is a commercial document, not a compliance artifact. Sector-specific rules and individual client contracts are what create actual obligations, so read the master services agreement before the policy.

Should I tell clients I used AI if they never ask?

Publishing a blanket policy answers the question before it is asked, which is the lowest-friction version of yes. The situation to avoid is a client learning it from somewhere other than you.

What if a client demands no AI at all?

Ask what they are actually worried about, which is usually their data reaching a training set or unreviewed output being delivered. Both are addressable with the restricted tier and the human review clause, without a blanket ban that neither of you can verify.

Does an AI usage policy make me look less skilled?

The opposite, in practice. Clients who ask are worried about diligence, not about tooling, and a written process reads as professional. It is closer in spirit to a well-structured proposal than to an apology.