Why Your AI Policy Needs Examples (Not Just Principles)

You know what happens when your organisation rolls out a new AI policy full of principles like “use responsibly” and “maintain ethical standards”? People interpret them differently. (If you’re lucky) they then ask their managers. Who interpret them differently again. And before you know it, you’ve got three departments doing completely different things, all claiming they’re following policy.

Vague guidelines don’t fail because people are stupid. They fail because interpretation is inevitable. That’s literally why we have contract lawyers.

The problem with principle-based policies

Most AI policies I’ve seen read like corporate values statements. “Use AI to enhance productivity whilst maintaining quality.” Right. But what does that actually mean when Sarah in Marketing wants to use ChatGPT to write customer emails? Or when one of your ops team writes a useful webapp and wants to feed the codebase into GitHub and roll it out to customers?

Change management principles teaches us that ambiguity kills adoption. People either freeze (afraid to do anything without explicit permission) or improvise (making it up as they go). Neither outcome serves your organisation.

What good examples actually do

Specific examples do three critical things:

They create shared understanding. When you write “Don’t use AI to generate final customer communications” versus “AI can draft responses, but humans must review and personalise before sending”, everyone knows where the line is. No interpretation is required.

They expose edge cases early. Writing examples forces you to think through scenarios. Can staff use AI for internal brainstorming using internal figures and information for context? What about meeting summaries? A/B versions of marketing images? Research? You’ll discover your grey areas whilst writing policy, not six months later when someone’s already crossed a line you didn’t know existed.

They make enforcement possible. How do you discipline someone for violating a principle? You can’t, because it’s open to interpretation. But you can absolutely address someone who submitted AI-generated content marked as their own work when your examples explicitly prohibited it.

What this looks like in practice

Instead of “Use AI transparently”, try:

Acceptable: Using AI to summarise research articles for your own understanding, then citing the original sources in your work.

Not acceptable: Using AI to write your conference presentation and claiming it as original thought without disclosure.

Grey area requiring judgement: Using AI to improve the grammar in text you’ve written. Flag this in internal drafts; judgement call for external materials depending on extent of changes.

See the difference? People can map their specific situation onto these examples. They can extrapolate. They understand the spirit of the rule through concrete application.

Why organisations resist this

I’ve watched companies shy away from specific examples for predictable reasons. They worry about looking controlling. They fear missing edge cases. They want “flexibility to adapt as AI evolves.”

This is risk-averse thinking masquerading as agility. What actually happens is you get neither control nor flexibility - you get chaos with a policy document attached.

The organisations doing this well aren’t trying to anticipate every possible scenario. They’re documenting the common ones, showing their reasoning, and creating a framework people can apply to novel situations. That’s not rigidity. That’s scaffolding.

The real-world gap

Here’s a scenario I see repeatedly: Company policy says “maintain data privacy when using AI tools.” Sounds sensible. But does that mean:

Don’t paste customer names into ChatGPT? (Probably yes)
Don’t use AI transcription tools for internal meetings? (Depends on the tool)
Don’t let AI grammar checkers see your draft board papers? (Actually unclear)
Don’t use AI for anonymised data analysis? (Probably fine, but is that commercially sensitive data regardless of anonymisation, who decides?)

Without examples, every employee becomes a policy interpreter. And most employees aren’t qualified (or given enough time and training) to make those judgement calls.

How to build your examples

Start with real scenarios from your team. Ask people: “What AI tasks are you doing or want to do?” You’ll get real-world cases immediately.

Then categorise them into three buckets: green (go ahead), red (absolutely not), and amber (needs human oversight). Be specific about why each falls where it does. The reasoning matters as much as the verdict.

Update regularly. AI capabilities change monthly. Your policy examples should evolve too. Review at least quarterly and adjust based on new tools, new use cases, and new risks.

And critically: involve your actual users in creating examples. The scenarios your legal team imagines are probably different from what your frontline staff encounter daily. This is also why your governance committee needs the people who do the work — practitioners bring the real-world scenarios that make examples credible.

The lawyer question

Someone will argue this approach creates rigid rules that can’t flex with changing circumstances. That principles give you adaptability whilst examples constrain you.

Rubbish.

Examples demonstrate application of principles. They don’t replace principles - they illuminate them. Your principle might be “maintain data privacy.” Your example shows what that means when someone wants to use an AI tool that stores prompts.

And yes, you’ll still need AI Steering (and lawyers) for genuinely novel situations. But you’ll need them far less often, because most scenarios aren’t genuinely novel. They’re variations on themes you can anticipate and document.

What happens if you don’t do this

Without examples, you get what every change manager dreads: inconsistent adoption driven by whoever shouts loudest or interprets most liberally. You get competitive advantage for the brave (or reckless) and paralysis for the cautious. You get a policy that exists on paper but not in practice.

You also get liability exposure, because when something goes wrong, you can’t prove anyone violated policy. They’ll argue their interpretation was reasonable. And without examples showing what reasonable looks like, they’re probably right.

Start somewhere

Don’t aim for comprehensive coverage immediately. Pick your top five AI use cases in your organisation. Write examples for those. See what questions emerge. Refine. Expand. Iterate.

The goal isn’t perfection. It’s clarity sufficient for people to act confidently and consistently. That’s achievable. But only if you’re willing to get specific.

What examples does your organisation need most? Start there.

Resourcing

If this isn’t a task for your emerging AI team, I don’t know what is. You do have an AI team, right?

This article is assisted by Claude, is my own opinion and does not represent Hachette corporate strategy or approach.