An AI disclosure policy you can actually enforce
Most AI policies are aspirations nobody can check. A short policy backed by a record that already exists will hold up in a client conversation.
Most AI policies fail the same way. Someone writes four pages about responsible use, everyone signs it, and nine months later nobody can say whether a single clause was followed. The document was never wrong. It was just unenforceable, because none of it produced evidence.
If you want the short version as a document rather than an argument, the AI disclosure policy builder asks six questions and writes the one-page version, with each clause paired to the record that proves it was followed.
An enforceable policy is short, names the moments where a decision is made, and leans on a record the team is already keeping. If a clause cannot be checked against something that exists, it is a value statement rather than a policy, and it belongs somewhere else.
Attribution model
Five questions, one accountable owner
Turn the fields into a plain-language disclosure.
Build a statementWhy the long version fails
Length is the first problem. A policy nobody can recall at the moment of decision has no effect on the decision. If a designer has to remember four pages before pasting a client brief into a tool, the policy loses to the deadline every time.
Prohibition is the second. A policy that bans the tools people find genuinely useful does not stop the usage, it moves the usage somewhere you cannot see. You end up with less visibility than you had before you wrote anything down.
The third is that most clauses have no observable consequence. Use AI responsibly cannot be audited. Have a human review client-facing AI output can be, but only if review status is recorded somewhere. That difference is the whole design problem.
The five clauses that matter
| Clause | The decision it governs | How you check it |
|---|---|---|
| Approved tools | Which tools may touch client work | Tool list, with a named owner and a review date |
| Client data | What may be sent to a third-party model | Contract review, plus a default of no confidential material |
| Material involvement | When AI use has to be recorded | Recorded involvement level on the work entry |
| Human review | What must be reviewed before it ships | Review status against client-facing deliverables |
| Disclosure | What the client is told, and when | The disclosure statement attached to the deliverable |
Five clauses fit on one page and each produces something you can look at afterwards. That is the bar. If a sixth clause is worth adding, it has to clear the same bar.
Enforcement is a record, not a rule
The policy says client-facing AI-assisted work is reviewed by a senior person. Enforcement is being able to open last month's deliverables and see which ones carry a review, and by whom. Where the review is missing, you have a conversation about a specific piece of work rather than a general reminder about standards.
This is why the policy should be written after the record format, not before it. Write the clause to match a field you already capture, and compliance becomes a report. Write it first and you will spend the next quarter trying to instrument an aspiration.
Contracts that prohibit AI
Some client agreements still say no AI, and many were written before anyone had thought about the range of things that phrase now covers. Autocomplete in an editor and a model drafting client-facing copy are not the same activity, and an agreement written a while ago may not distinguish them.
The honest move is to raise it rather than interpret it quietly in your favour, and what an existing agreement actually permits is a question for your lawyer rather than one to settle internally. What you can bring to that conversation is the specific list: here is where we would use it, here is what would never leave your environment, here is who reviews the output, and here is the record you would receive. Most clients relax a blanket ban when the alternative is a specific, evidenced practice. The ones who do not have told you something useful about how to staff their work.
Freelancers and subcontractors
This is the clause most agency policies forget, and the one clients ask about first. Half the work on a given project may be produced by people who never read your internal policy, and a client who has been promised review coverage does not care about the employment relationship behind it.
The fix is small: hold them to the same five commitments, agreed before the work starts, and require the same involvement and review fields on what they deliver. If a freelancer's tooling cannot record that, the reviewing person on your side records it when they accept the work. Either way the deliverable carries the same evidence as anything produced in house.
Who owns it
A policy without a named owner decays quietly. Someone has to hold the tool list, answer the question when a new tool appears, and run the quarterly review. It is a small job and it does not belong to everyone.
In most firms the right owner is whoever already owns delivery quality, not legal and not IT. The clauses are about how work gets made and reviewed, and the person who cares most about that is the person accountable for what ships.
When someone breaks it
Assume the first breach is a process failure. Someone had a deadline, the approved tool did not do the thing, and the unapproved one did. Treating that as misconduct guarantees the next one goes unreported, and unreported use is the situation the policy exists to prevent.
Ask what made the shortcut worth taking. If the answer is that the approved tool is bad, the tool list is wrong. If the answer is that nobody knew the rule, the page is too long or nobody circulated it. If the answer is a genuine disregard for a client's data terms, that is a different conversation, and it should be a rare one.
A four-week rollout
- Week one: list what is actually being used. Ask, do not audit. You need an accurate picture more than a compliant one, and people will tell you if the question is not a trap.
- Week two: decide the tool list and the client-data rule. These two are the ones with legal and commercial consequences, so they get the most senior attention.
- Week three: add involvement and review to the work record, and check that both can be reported on. If a field cannot be reported on, it will not be maintained.
- Week four: write the page, circulate it, and set the first quarterly review date before anyone forgets.
Four weeks is enough because the policy is one page. Most of the work is in the record, which is the part that keeps paying off after the document is filed.
What to review each quarter
Three numbers are enough for the review: the share of client-facing deliverables with a recorded review, the share of work entries with an involvement level where you would expect one, and the tools in use that are not on the approved list.
None of these ranks individuals, and that is deliberate. A policy review that turns into a performance review teaches people to record less, and the record is the only thing making the policy real. Look at the shape of the practice, fix the process that produced the gap, and leave the individual scorecards out of it.