Ask five people in your organisation what "AI" means and you will get five answers. One thinks of the chatbot in a browser tab, another of the recommendation engine in a marketing tool, a third of a fraud model buried in a payment platform. When those interpretations all land inside a single document titled "AI Policy," the result is a text that everyone signs and no one can apply.
Definitions are not academic. In compliance, the word you choose sets the scope of every control, risk assessment and audit that follows. This article looks at how policy and regulation actually define AI, where the ambiguity bites, and why most companies are better served by starting with a deliberately narrow scope — one that mostly lives inside the policies they already have.
Why the definition decides everything
A policy applies to whatever its scope statement covers. If "AI" is defined loosely as "any system that automates decisions," you have quietly pulled spreadsheets, business rules and simple scripts into scope. If it is defined too narrowly, a genuinely high-risk model can slip through untouched.
Scope drives inventory, risk classification, vendor questionnaires, monitoring obligations and evidence collection. A definition that is vague or overbroad produces one of three failures:
Paralysis. Teams cannot tell what is in scope, so nothing gets assessed and the policy becomes shelfware.
Dilution. Everything is in scope, so limited governance effort is spread across hundreds of trivial systems while the few risky ones get the same shallow treatment.
Inconsistency. Different departments interpret the term differently, and your audit trail contradicts itself.
Before writing controls, you need a definition your own staff can apply without a debate.
How regulators and standards define it
You do not have to invent a definition. Several authoritative sources already offer one, and aligning with them saves argument later.
The EU AI Act defines an AI system as a machine-based system designed to operate with varying levels of autonomy, that may adapt after deployment, and that infers from input how to generate outputs such as predictions, content, recommendations or decisions. The emphasis on inference is the key distinction from ordinary deterministic software.
ISO/IEC 42001, the AI management system standard, leans on the definition in ISO/IEC 22989, the companion vocabulary standard, and is designed to sit alongside your existing management systems rather than replace them.
The NIST AI Risk Management Framework takes a function-oriented view: the AI lifecycle and the outcomes to be governed, mapped, measured and managed, rather than a single tight legal boundary.
These sources agree on a useful core idea: an AI system infers outputs from data rather than following only explicit, hand-written rules. That inference is what introduces uncertainty, drift and explainability challenges that traditional software does not carry in the same way.
The traps hiding in a broad scope
Many organisations, wanting to look thorough, write the widest possible definition. It feels safe. In practice it creates work that never ends and rarely reduces real risk.
Rule engines masquerading as AI. Deterministic if-then logic is auditable and predictable. Treating it as AI adds ceremony without addressing genuine model risk.
Shadow features inside SaaS. Vendors keep adding AI features to tools you already use. A broad definition puts every one of these in scope overnight, faster than you can assess them.
Generative tools used informally. Staff pasting text into a public assistant is a real risk, but it's a data-handling and acceptable-use problem first, not a reason to govern every automation in the company.
Model-driven analytics in finance and HR. These often carry the highest stakes yet get lost in the noise when the scope includes everything.
A broad scope does not make you more compliant. It makes your evidence thinner and your team more tired.
AI is not one policy — it's a claim on several you already have
There's a trap on the other side of "too broad" too: treating AI governance as a brand-new subject that needs its own document from page one. For most organisations, AI doesn't introduce a new risk category so much as it touches several they already govern — confidentiality, privacy, acceptable use, vendor diligence, IP and output ownership, logging and incident response.
Before drafting a new AI-specific rule, check whether an existing policy already covers it, and tighten that one instead. Not every AI-related rule belongs under an "AI Policy" banner; some belong in data classification, some in vendor due diligence, some in acceptable use. A short, standalone AI use policy still has a place as an interim measure for immediate guardrails — but it should sit alongside those refreshed policies, not replace them.
Why starting smaller works better
The most effective early AI governance programmes pick a small, high-value slice and do it properly. Starting smaller doesn't mean ignoring the rest — it means sequencing: govern the systems that carry regulatory exposure or material business impact first, then widen the net as your process matures.
Build an inventory before a policy. List where inference-based systems already exist, including inside third-party tools.
Tier by impact, not by hype. Rank each system by the consequence of a wrong or biased output: safety, legal rights, finances, reputation.
Adopt a definition and write it down. Reuse the EU AI Act or ISO/IEC 22989 wording, add two or three concrete examples of what is in and out of scope for your context — and check which existing policy already governs each case before writing a new rule.
Pilot controls on one or two systems. Test your risk assessment, documentation and monitoring on a real case before rolling out organisation-wide.
Expand in deliberate waves. Add categories of systems as capacity allows, updating the inventory and the definition examples each time.
This maps cleanly onto frameworks you may already use. Your existing ISO 27001 asset inventory and risk methodology give you a foundation, and NIST AI RMF or ISO 42001 provide the AI-specific structure on top.
A starting checklist
One definition, cited, with concrete in-scope and out-of-scope examples.
An inventory exists — a list of AI systems, including vendor-embedded features, that is owned and dated.
Impact tiers are set, with the highest tier assigned an owner.
Existing policies are checked first, before any new AI-specific rule is drafted.
Acceptable use is separate, handling informal use of generative tools rather than diluting the main policy.
A review cadence is fixed, since vendor features and regulation will keep moving.
The goal is not the longest AI policy in your sector, or even necessarily a standalone one. It's a set of rules your teams can apply on a Tuesday afternoon, backed by evidence you can show an auditor. Define the term precisely, scope it narrowly, put each rule where it already belongs, and grow the programme on proof rather than ambition.