How to Write an AI Policy That People Actually Follow

How to Write an AI Policy That People Actually Follow

Your legal team wrote an AI policy. It's twenty pages. It covers governance, model development, data handling, ethical considerations, compliance. It's thorough. It's comprehensive. It's probably sitting in a folder that nobody reads. Your data scientists skim it once during onboarding. Your product managers ignore it. Your executives filed it away. A year later, someone asks your team about AI governance and they point to the policy document, confident that governance is happening. Inside, you know it's not. The policy exists. Behavior hasn't changed. The gap between policy and practice is where governance actually fails.

This pattern is so common it's become institutional. Legal writes a policy that's technically complete but practically useless. It lives in a handbook or on an intranet. It accumulates dust. When problems emerge, the policy is cited as evidence that governance existed, even though nobody was actually following it. The problem isn't that policy doesn't matter. It's that the wrong policy approach creates the wrong incentives. A policy written by legal for legal consumption creates distance between the policy and the people who actually need to follow it.

Effective AI policies are built differently. They're co-created with the people who'll actually implement them. They're written in language those people speak. They're tied directly to workflows and decisions people make every day. They're enforced through systems integration, not annual sign-offs. They're updated as capabilities and risks change. That's a policy that changes behavior.

Why Legal-First AI Policies Fail

There's a natural instinct to have legal write policies. Legal understands compliance. Legal understands risk. Legal understands what regulators are likely to ask for. But policies written by legal for legal consumption create a specific failure mode.

First, they're written for a regulator, not for practitioners. The language is formal. The structure is legal. The examples are hypothetical. A data scientist reading the policy is looking for guidance on how to validate a model. Instead they find language about "establishing robust governance frameworks for algorithmic decision-making in accordance with applicable law and industry standards." That's not actionable. That's theater.

Second, they create distance between policy and practice. The policy says one thing. The team knows what's actually needed to ship on schedule. The gap creates cynicism. People read the policy, nod during the compliance sign-off, and then ignore it when it conflicts with business priorities. They've learned that the policy doesn't describe how things actually work. Why follow it?

Third, they're often written without input from the people who'll implement them. Legal consulted with leadership. Nobody consulted with the data scientists, product managers, or operations team. The policy reflects what leadership thinks should happen, not what practitioners know is actually feasible. Feasibility gaps kill adoption. If a policy requires something that's technically impossible or operationally impractical, people won't follow it.

Fourth, they're typically enforced through annual sign-offs or compliance audits, not through integrated systems. You sign the policy once a year. Nobody asks about it again until audit time. The disconnect between policy and daily work remains vast. If the policy were integrated into your deployment workflow—if you couldn't ship a model without running the checks the policy requires—behavior would change. If the policy is just something you signed, behavior doesn't change.

Dr. Mark van Rijmenam, a world-leading futurist and AI expert, emphasizes that governance policies become effective only when they're embedded into the systems and workflows that teams actually use. Policies exist in documents. Governance exists in processes.

Co-Creating Policy With Practitioners

The first step in building a policy that people follow is involving the people who'll implement it from the start. This means co-creating policy with data scientists, product managers, operations teams, and security engineers. Not involving them in a token consultation. Actually involving them in designing what the policy should be.

Start with the practitioner's perspective: What decisions do you make every day? What information would help you make better decisions? What slows you down currently? What would make things faster without increasing risk? These conversations reveal the actual decision landscape. You're not trying to write policy in a vacuum. You're trying to understand how work actually happens, where guidance is needed, and what would be practical.

A concrete example: your policy includes "conduct fairness testing before model deployment." That's right in principle. But what does it mean operationally? The data science team is asking: Which fairness metrics? What's acceptable disparity? Do we test on historical data or require new data collection? How long does testing take? What if fairness testing surfaces problems—do we fix them or abandon the model? Do we need external fairness audit or can we do this internally? These aren't technical questions. They're governance questions. They require input from people who actually build and deploy models.

Co-creating policy means asking these practitioners to help shape the answers. What fairness testing is realistic? What can you do within current timelines? What would you need to support more rigorous testing? By the time you're done, you have a policy that practitioners actually contributed to and therefore understand more deeply. You also have buy-in. When you ask people to follow something they helped design, compliance is easier.

This co-creation process also surfaces infeasibility early. Your policy draft says every model will go through a six-week governance review. Your data science team says they deploy models weekly. The gap is real. Co-creation forces you to have the conversation: Do we need to slow down deployment? Do we need to parallelize review? Do we need to automate parts of it? The policy that emerges from this conversation is more realistic and more likely to be followed because the tension has been resolved, not buried.

Plain Language With Practical Scenarios

Once you've co-created the policy framework, write it in language people actually speak. Not legal language. Not academic language. Direct language. Short sentences. Concrete examples.

Instead of: "Establish robust pre-deployment validation protocols that assess model performance across representative demographic groups and document fairness metrics in accordance with organizational standards."

Write: "Before a model ships, test how it performs for different groups of people. Document what you found. If performance differs significantly, fix it or don't ship. Here's what 'significantly' means in your use case."

The second version is shorter, clearer, and actionable. A data scientist can read it and know what to do.

Structure the policy around scenarios people actually face. Not abstract principles. Scenarios. "Your team trained a model. What happens next?" That's a scenario. Walk through it. You need to validate accuracy. Here's how. You need to test fairness. Here's what that means for your use case. You need to document the model. Here's what to document. Here's the template. You need sign-off before deployment. Here's who gives it and what they're checking for.

Include concrete examples for your specific use cases. If you do lending, give examples of models that should go through governance and models that probably shouldn't. If you do hiring, give examples of fairness testing for a resume screening model. Examples make policy concrete. They prevent the false interpretation that happens when language is too abstract.

Include decision trees. "Your model is for loan decisions, involves protected characteristics, and goes to millions of customers. Here's the governance path." "Your model is for internal operations, doesn't touch protected characteristics, and affects fifty employees. Here's the lighter governance path." Decision trees help practitioners understand which parts of the policy apply to their situation and how much governance is appropriate.

Enforcement Through Workflow Integration

A policy is most effective when it's not something people sign and then forget. It's most effective when it's embedded into workflows so people encounter it as they work.

If deployment is your control point—that's where you decide what ships and what doesn't—integrate the policy into your deployment workflow. You can't submit a model for deployment without filling out the governance checklist. You can't approve deployment without reviewing governance documentation. The policy is now operationally enforced. People aren't following it voluntarily. They're following it because it's built into their workflow.

If approval is your control point—someone has to sign off that governance was done—make sure that person actually reviews governance documentation. Too often, approval becomes theater. Someone signs a checklist without actually looking at the work. Make approval real. Make people document what they reviewed. Make them articulate what they verified. If they skip any steps or are uncertain, they push back. When approval is real, policy enforcement is real.

If tooling is your control point—people use a specific system for model development—build policy enforcement into the tool. The tool guides people through the required steps. It prevents shortcuts. It documents what was done. When people are using the tool anyway for other reasons, enforcing policy through the tool has minimal friction.

If training is your control point—you're scaling knowledge—build policy into training. Don't have a separate policy training. Integrate policy into how you teach people to do their jobs. When you teach data scientists to validate models, teach them the specific fairness tests your policy requires. When you teach product managers to brief models, teach them the documentation your policy requires. When you teach operations teams to deploy, teach them the sign-off process your policy requires. Policy becomes part of how you onboard people, not a separate compliance requirement.

Updating Policy as AI Capabilities Evolve

A policy that's frozen doesn't serve you. AI capabilities evolve. Business use cases change. Regulations shift. Your policy needs to stay synchronized.

Create a quarterly policy review cycle. Bring together the co-creators from the original process. What's working? What's causing friction? What new capabilities are emerging that the policy doesn't address? What capabilities that the policy was trying to manage are now simpler or harder than expected? Use this quarterly input to update the policy.

When you update policy, communicate the changes clearly. Don't just quietly revise the document. Send a note to everyone: Here's what changed. Here's why. Here's what you need to know. This keeps the policy alive in people's minds. It signals that the policy isn't a fixed document but a living guide that evolves with the organization.

Track which policies are actually working and which ones are creating friction. Metrics help. How often is someone pushing back on a policy requirement? When they push back, do they have a good reason? If a policy requirement is universally considered too burdensome for the value it creates, it might be time to revise or remove it. A policy that exists but that everyone thinks is stupid is worse than no policy. It creates cynicism that extends to policies that matter.

Link policy updates to governance maturity. As your organization's AI capabilities mature, your policies can become more sophisticated. Early on, you might have simple policies: always validate, always test, always document. As you scale, you might have more nuanced policies: different governance paths for different risk levels, more automated validation, more sophisticated fairness testing. The policy evolves as your capability evolves.

Making Governance Operational

The difference between organizations with governance and organizations without is often not the existence of policy but the operationalization of it. Governance becomes real when it's built into the systems people use, integrated into workflows people follow, and updated as the organization evolves.

Organizations that build operational governance start with practitioners. They ask what guidance is needed and what would be practical. They write policy in direct language tied to actual scenarios. They embed the policy into workflows so people encounter it as they work, not as a compliance burden. They keep the policy alive by updating it as needs change. When you do all of this, policy stops being theater and becomes infrastructure.

Take the Intelligence Age Scorecard

Effective AI policy is a core governance capability. Dr. Mark van Rijmenam's Intelligence Age Scorecard assesses your maturity across eight capability areas, including governance processes and continuous improvement. A strong governance capability includes policies that are operationalized, practitioners who understand them, and systems that enforce them.

Take the Intelligence Age Scorecard at thedigitalspeaker.com/intelligence-age-scorecard/ to assess where your governance policy currently stands. Is it written but not followed? Is it integrated into workflows? Do practitioners understand what it requires? Is it staying current with how your AI capabilities are actually evolving? The Scorecard will show you exactly where your policy infrastructure is strong and where it needs to be rebuilt. Organizations that move the Intelligence Age Scorecard from diagnostic to operational use it to guide exactly this kind of governance work: making policy real instead of letting it remain a museum piece.