Writing an AI policy for client work before a client asks for one
Your team already uses AI tools. The only open question is whether the rules are written down or improvised per project. Sooner or later a client asks what you feed into these tools, and “nothing sensitive, I think” is a bad answer to give a client's legal team.
1. Classify inputs before you classify tools
Most policies fail by listing approved products, which goes stale in a month. Classify the data instead, and the rule survives every new tool.
| Data | Rule |
|---|---|
| Public material, your own marketing, generic questions | Fine in any reputable tool |
| Internal drafts with no client or personal data | Fine in approved business accounts |
| Client-identifiable material, briefs, unreleased work | Only where the contract and the tool's terms both permit it |
| Personal data about identifiable people | Only with a lawful basis and explicit client agreement |
| Credentials, keys, contracts, financial or health records | Never |
Anchor this to one clear line staff can remember: if pasting it into a public forum would be a problem, pasting it into a chat interface is a problem.
2. Use business accounts, and read the retention terms
Consumer tiers and business tiers of the same product often differ on whether inputs may be used to improve models, how long data is retained, and who inside the vendor can access it. Check for each approved tool, write down the answer, and re-check when the vendor changes terms. Personal accounts with company data is the specific pattern to prohibit, because it puts client material somewhere you cannot audit or revoke.
3. Human review, scaled to consequence
Not everything needs the same scrutiny, and pretending otherwise means the rule gets ignored entirely.
- Low stakes — internal notes, brainstorms, first drafts nobody sends: a glance is enough.
- Medium — client-facing copy, documentation, code that goes into review: a named person edits and signs off. Every factual claim gets verified against a source.
- High — anything published under a client's name, legal or financial or medical content, security-relevant code, or a claim about a person: subject-matter review, sources cited, and a record of who approved it.
Two failure modes to name explicitly: fabricated facts stated confidently, and code that runs but is subtly wrong. Both look finished, which is precisely the danger.
4. Decide the disclosure position, then be consistent
There is no universal right answer, and consistency matters more than which line you pick. The workable middle: disclose the categories of work where AI assists, do not annotate every sentence, and never claim a human did something a tool did if asked directly. Get this into the contract or scope so the client agrees in advance rather than discovering it.
Two hard rules regardless of position: no fabricated testimonials, case studies, credentials, or research, and no synthetic media of a real person without their written consent. These are not style choices.
5. Ownership and rights need saying out loud
- Confirm that the tool's terms grant you rights to the output for commercial use, and that you can transfer those rights to the client.
- Never present AI-generated imagery, code, or text as covered by a licence you have not verified. Check licences on generated code the same way you would on a library.
- Do not ask a tool to imitate a named living artist's style for client deliverables. It is a legal and reputational risk with no upside.
- Keep the prompt and the source material for high-stakes deliverables, so you can show your working if the origin of something is questioned later.
6. Tasks to keep humans on
Not because tools cannot attempt them, but because the cost of being wrong is carried by someone else:
- Final client communication about money, deadlines, or bad news.
- Anything that becomes a legal, tax, medical, or safety representation.
- Decisions about people: hiring, performance, termination.
- Security-sensitive code review and access decisions.
- Statements of fact about a competitor or an identifiable individual.
What the one page contains
- The data classification table, unedited.
- The list of approved tools and accounts, with an owner who maintains it.
- Review requirements by stake level.
- The disclosure position, in the words you would use with a client.
- Prohibited uses, stated flatly.
- Who to ask when a case is unclear, and the instruction to ask rather than guess.
- A review date, because tools and terms change quarterly.
Why bother before anyone asks
Three reasons, in order of how likely they are to arrive. Client procurement questionnaires increasingly ask about AI use, and having an answer wins work from firms that do not. It prevents the incident where a junior pastes a client's unreleased material into a personal account. And it settles internal arguments about disclosure once, in calm conditions, rather than during a dispute with a client who feels misled.
An afternoon, one page, reviewed quarterly. That is the whole investment.
No company paid for placement in this article. Verify current prices and terms with each provider before buying.