Organisations using AI
Stanford HAI's 2025 AI Index reported that 78% of organisations used AI in 2024, up from 55% the previous year. Adoption is already inside the organisation; policy has to meet people where they work.
Most AI policies are written as if the main audience is a regulator, a board committee, or a future litigation file. Those audiences matter. But if the policy does not help a project manager, analyst, assistant, lawyer, consultant, clinician, or operations lead make a decision on Monday morning, it will not govern real behaviour.
A useful AI policy is not a wall of prohibitions. It is an operating tool. It tells people which uses are encouraged, which are restricted, which are prohibited, and what to do when a use case does not fit neatly into the categories.
The policy problem is not awareness. It is translation.
Most professional teams now know that AI creates risk. They have heard about hallucinations, data leakage, copyright disputes, bias, the EU AI Act, GDPR, and reputational exposure. The gap is more practical: people do not know how those concerns translate into everyday work.
Can I summarize a client call? Can I paste a contract clause? Can I use an AI meeting assistant? Can I ask a model to rewrite a board memo? Can I use a public tool if I remove names? Can I use the output in a deliverable if I reviewed it?
If the policy does not answer these questions, teams will make their own rules. That is how governance becomes informal, inconsistent, and hard to defend.
Five sections every usable AI policy needs
1. A simple use-case map
The policy should start with the work people actually do. Group uses into practical categories:
- low-risk productivity support, such as grammar, formatting, brainstorming, and public information summaries;
- internal knowledge work, such as drafting, analysis, meeting notes, and decision support;
- client, patient, employee, or customer-facing work;
- high-impact decisions, such as hiring, credit, health, legal, education, safety, or access to services;
- prohibited or paused uses.
This structure is easier to apply than a purely legal taxonomy. Legal classification still matters, but teams need a front door they understand.
2. Data rules people can remember
A usable policy should distinguish between public, internal, confidential, personal, sensitive, and regulated data. It should explain what may be entered into which type of tool.
The rule should be concrete. For example: public AI tools may be used for non-confidential drafting and brainstorming, but not for client-identifying, patient-identifying, employee, trade-secret, unpublished financial, or sensitive personal data unless an approved enterprise configuration and review path exists.
3. A review standard
AI-assisted work should have a human review rule. The rule cannot simply say "review output". It should explain what review means:
- verify factual claims;
- check citations and references;
- compare output against source documents;
- test assumptions;
- identify missing context;
- document material AI contribution where needed;
- escalate when the output affects rights, obligations, safety, money, health, or reputation.
4. An approval path for new tools
People should know where to go before connecting a new AI tool to organisational data. The path should cover vendor review, data processing, security, model training terms, retention, access controls, human oversight, and business owner accountability.
5. Examples, not just rules
Teams learn faster from examples than abstract principles. A policy should include sample scenarios: allowed, allowed with conditions, not allowed, and needs review.
The governance test
A good AI policy should pass three tests:
- Can a non-specialist understand it? If not, it will not shape behaviour.
- Can a manager enforce it? If not, it is only a statement of intent.
- Can the organisation show evidence? If not, it will be difficult to defend later.
NIST's AI Risk Management Framework is useful here because it separates governance from measurement and management. ISO/IEC 42001 adds the management-system lens: policies, objectives, processes, responsibilities, review, and continuous improvement.
What to do next
Start with a one-page working policy before building a full governance manual. Define approved tools, data rules, review standards, escalation paths, and examples. Then test the policy with three real workflows. If people cannot apply it without a meeting, it is not ready.