Your AI Policy Is Compliance Theater

We have read a lot of corporate AI policies in the last twelve months. They tend to share a structure. There is a one-page introduction about innovation and responsibility. There is a list of approved tools. There is a list of prohibited tools. There is a paragraph forbidding the upload of customer data to public models. There is a generic statement about bias, transparency, and human oversight. The document is signed by a VP. It is filed.

It does almost nothing.

We are not against AI policies. We are against AI policies that exist to satisfy an auditor’s checkbox without changing what the engineering team actually does on Tuesday morning. The cost of that policy – the legal cost, the training cost, the political cost – buys you a piece of paper. The piece of paper does not stop the harm it claims to prevent. The piece of paper is theater.

Why the Standard Policy Fails

Most AI policies were drafted by people who do not write code, advised by lawyers who do not understand how agents are wired, and approved by executives whose primary interest is being able to say “we have a policy.” They are written in the language of HR handbooks. They use words like “appropriate,” “responsible,” and “as needed.” They forbid behavior they cannot detect, allow behavior they cannot define, and adjudicate violations they cannot identify.

The result is a document that the legal team is happy to point at and the engineering team has never read past page two.

Three specific failures are nearly universal.

They legislate tools, not behavior. A policy that says “use ChatGPT, do not use DeepSeek” is obsolete the day a new model ships. The actual question is what data is being sent where, what is coming back, who is reviewing it, and what happens if the output is wrong. None of those questions are answered by maintaining a list of vendor names.

They forbid the wrong things. A typical policy obsesses over confidential data leaving the org – a real concern, but a narrow one – and ignores the much larger surface area of confidential data being produced by AI systems and consumed downstream. The legal team is worried about the engineer pasting a customer record into a chat window. They should also be worried about the agent generating a contract clause that is subtly wrong and getting it past an inattentive reviewer.

They have no enforcement mechanism. A policy without monitoring is a wish. If you cannot tell, from the systems you actually operate, whether the policy is being followed, then you do not have a policy. You have a poster. Posters do not survive an incident review.

What an Operational Policy Looks Like

An AI policy that actually changes behavior has four characteristics.

It is written in terms of data and decisions, not tools. What data classes can be sent to which categories of model. What decisions can be made by an agent alone, which require human sign-off, and which are forbidden entirely. The policy survives the next model release because it is anchored in data and decisions rather than vendor names.

It is enforced by the systems, not by the document. If the policy says “PII cannot be sent to public models,” then the gateway in front of the public models has to reject PII. If the policy says “production database changes require human approval,” then the deployment system has to refuse to deploy database changes without a human signature. The document describes what the system enforces. The system is the policy. The document is documentation.

It assigns accountability by name. Every category of decision has a named owner. The owner is accountable when an incident occurs in their category. Not the “AI governance committee.” A specific human, with a specific title, who will be in the meeting when something goes wrong. Anonymous accountability is no accountability.

It is reviewed when the technology shifts, not on a calendar. Annual policy review made sense when technology moved annually. Today, your foundation models, agent frameworks, tooling, and threat surface change every quarter. The policy review is triggered by capability changes, not by the calendar. If your AI policy has not been updated in nine months and you have adopted three new platforms in that window, the policy is fiction.

What We Actually Recommend

A workable AI policy is short. Five to seven pages, in our experience. Most of the length goes into specifying the four to six data classes the organization handles – public, internal, confidential, regulated, customer-PII, and so on – and what categories of AI access are permitted for each. The rest specifies the decisions that require human approval, the owners of each category, and the technical controls that enforce them.

Almost everything else that ends up in a policy document either belongs in a training program, an incident response runbook, or a code-of-conduct addendum. Conflating them produces a document that is too long to be read, too vague to be enforced, and too generic to be useful.

We have also stopped writing the section that promises “we will use AI responsibly and ethically.” Every policy says this. None of them define it. The promise is the loudest part of the document and the most operationally useless. If your policy depends on the reader believing a vague pledge, your policy depends on belief, not on practice.

The Test

Here is the test we run with new clients. Take the AI policy off the shelf. Walk to the engineering floor. Ask three random engineers: which model can you use for code that touches customer data? Who has to sign off on a deployment that adds a new agent to a production workflow? What happens if you discover that an agent generated code that exposed a security vulnerability and it shipped two weeks ago?

If the engineers cannot answer those questions in plain language from memory, the policy does not exist in any operational sense. It exists only on the SharePoint where the legal team filed it.

If the engineers can answer them, and the answers match what the policy actually says, you have a policy.

If the answers do not match – if the policy says one thing and practice says another – you have a liability. You have a document that, in an incident review, will be used to demonstrate that the org “knew the right answer and chose not to follow it.” That is a worse posture than having no policy at all.

The Honest Statement

Compliance theater is comfortable. It looks like governance, costs less than governance, and feels like governance during a quarterly board update. It only fails on contact with an actual incident.

The policy that protects you is the policy that runs in the systems your engineers use every day, enforced by code, owned by named humans, and updated when the technology changes. The other policy – the one filed in SharePoint, signed by the VP, never read after onboarding – protects the people who signed it, briefly, until the incident.

Pick the policy that does the work.