AI usage policy: turning the document into operational controls

Your company shipped an AI usage policy. It names the approved tools, the data that can go in, and the moments a human must review the output. Six months later, half the team is using tools nobody reviewed, and no one can say which customer data touched which model. The policy exists. It just does not run.

A document cannot stop someone pasting customer data into an unvetted chatbot, and it cannot prove that a person reviewed an AI-drafted contract before it left the building. Enforcement does not live in a PDF. It lives in the workflow, where a step can require an input, hold for an approval, and record what happened.

Three control points carry most of the weight. Tool adoption: a request that goes through a risk review and an approval by role before any new AI tool is used. Data handling: a mandatory classification field before sensitive or customer data can enter an AI-assisted step. Human sign-off: any AI output that affects a customer, a contract, or a legal position needs a named reviewer before release.

The audit trail is the payoff. When a regulator, a customer, or your own board asks how you govern AI, the answer is a run history. Who requested which tool, who approved it, which outputs were human-reviewed, and when. That is a far stronger answer than a policy version number and a training completion rate.

“A policy you cannot prove ran is a policy you do not have.”

Do not try to govern every prompt. Map where AI already touches customer data or external-facing decisions, and put the first gate there. The risk is concentrated in the decisions that carry consequence, not in someone asking a model to summarize a meeting.

The failure mode is drift. The policy is owned by legal, the tools are adopted by teams, and the two never meet. Give the written policy and the enforcing workflow the same owner, so when one changes the other moves with it. That single alignment is what keeps governance from rotting back into a document.