A company’s board asked to see its AI governance policy.
Legal produced a 47-page document covering risk assessment procedures, bias testing requirements, human oversight protocols, and incident response plans. It looked comprehensive. The board was satisfied.
Six months later, a discrimination lawsuit revealed the AI team had never followed any of it. No bias testing occurred before deployment. No human oversight existed for automated decisions. No incident response happened when problems were first reported internally.
The policy existed. Nobody operationalized it.
Why Policies Sit Unused
Most AI governance policies are written by legal and compliance teams disconnected from how AI actually gets built and deployed.
The policy describes an idealized process. Engineering and product teams continue working the way they always have, unaware the policy exists or what it requires. Nobody translated policy language into operational steps that fit into actual development workflows.
This happens because policies get written to satisfy board requests, audit requirements, or regulatory pressure rather than to genuinely govern how AI gets built. The deliverable is the document, not behavior change.
The Discovery Problem
Companies usually discover their policy isn’t followed during the worst possible moment – litigation, regulatory investigation, or a public AI failure.
When discrimination lawsuits happen, plaintiffs’ attorneys request the AI governance policy during discovery. The policy looks great until they ask for evidence it was followed. Then they request bias testing documentation, oversight records, and incident reports – none of which exist because the policy was never operationalized.
This creates worse liability than having no policy at all. A company with no written policy can argue they exercised reasonable care given AI’s novelty. A company with a detailed unfollowed policy demonstrates they knew exactly what should happen and chose not to do it.
What Makes Policies Actually Get Followed
Policies that work get built with the teams who’ll follow them, not handed down from legal without operational input.
Requirements need to be translated into specific steps within existing development workflows. Instead of “conduct bias testing,” the policy needs to specify which tool runs the test, who reviews results, what threshold triggers escalation, and where documentation gets stored.
Someone needs ownership for verifying compliance, not just writing the policy. Without a person checking whether bias testing actually happened before each deployment, it won’t happen consistently.
Policies need enforcement mechanisms tied to actual deployment processes. If AI can ship to production without passing through documented governance steps, the policy is optional in practice regardless of what it says on paper.
The Fix Isn’t More Documentation
Companies discovering their governance policy isn’t followed often respond by writing more detailed policies.
This doesn’t solve anything. The problem isn’t that the policy lacks detail. The problem is the policy isn’t connected to how work actually happens.
Real fixes require integrating governance steps into existing tools and workflows, assigning specific accountability for each requirement, and building in verification before AI deployment rather than after problems emerge.
The companies that survive AI litigation with minimal damage are the ones who can produce evidence their policy was followed – testing logs, review records, escalation documentation. The companies that get hurt are the ones with great policies and no evidence anyone followed them.
Brian Alexander
Founding Partner, VisionAI+ Consulting Group
Former General Counsel, AI Engineering Firm
Certified ISO 42001 Lead Auditor