What actually counts as an AI policy?

Ask a roomful of Canadian municipal staff whether they have an AI policy and you will get four different answers from people who all, technically, have one. The word 'policy' is doing too much work.

One municipality has a five-page council-endorsed document titled 'Responsible Use of Artificial Intelligence.' Another has a single paragraph buried in its IT acceptable-use policy. A third has a governance framework with principles, a steering committee, and risk tiers — but nothing a frontline staff member can read in two minutes. A fourth has a one-pager their CAO emailed out the week ChatGPT trended on the news.

All four are real. All four show up in the registry. None of them are the same thing. This post is the working taxonomy we use to tag them — and the reason 'do you have an AI policy?' is almost always the wrong opening question.

Why the taxonomy matters

If you collapse every artifact into a single yes/no field, three bad things happen. You under-credit municipalities that have done meaningful embedded work. You over-credit municipalities that have shipped a glossy framework with no operational teeth. And you make peer comparison impossible — because two cities can both answer 'yes' while meaning completely different things.

The registry tags by artifact type for the same reason a librarian tags by format. A novel and a screenplay can tell the same story; they are not interchangeable when you are deciding what to read next.

"'Do you have an AI policy?' is a yes/no question pretending to be a research question."

Type 1: Standalone AI policy

A named document — usually council-endorsed or CAO-approved — whose explicit purpose is governing AI use across the organization. It typically covers scope, definitions, permitted and prohibited uses, approval workflows, data handling, vendor obligations, and review cadence.

What it looks like

• A titled policy document (PDF or web page) with a version, an effective date, and a named owner.
• Council or executive endorsement on the record — agenda item, motion, or signed directive.
• A defined review interval (often annual or biennial).
• Cross-references to procurement, privacy, records, and IT policies.

Canadian examples

A small but growing number of Canadian municipalities have published standalone AI policies or directives — typically larger cities or those that moved early after Quebec's Law 25 or Ontario's procurement guidance. The registry lists them by name with source links and the date a human last verified the link.

Type 2: Embedded clause

AI-specific rules tucked inside an existing policy — procurement, privacy, records management, IT acceptable use, code of conduct, or HR. No standalone document, but real, enforceable language in a policy that already has teeth.

What it looks like

• A clause requiring privacy impact assessment for AI-enabled procurement.
• An IT acceptable-use update prohibiting confidential data in public LLMs.
• A records policy clarifying that AI-generated outputs are records.
• A procurement standard requiring vendor disclosure of AI components.

Embedded clauses are often the highest-leverage starting point. They inherit the enforcement mechanism of the parent policy, they do not require a new council motion, and they put guardrails on the two places AI actually enters a municipality: through procurement and through staff laptops.

The downside: they are easy to miss. A resident searching the municipal website for 'AI policy' will find nothing. Auditors and journalists routinely under-count municipalities at this stage. The registry surfaces them explicitly so the work gets credit.

Type 3: Governance framework

A higher-altitude document — principles, values, oversight structures, risk tiers, decision rights — that sets direction without prescribing day-to-day behaviour. Often produced by a working group, sometimes adopted by council, sometimes published as a staff report.

What it looks like

• A statement of principles (transparency, accountability, human oversight, fairness).
• A risk-tiering model — low / medium / high — with approval workflow per tier.
• An oversight body: AI steering committee, ethics review, or expanded privacy committee.
• Alignment statements referencing federal directives, ISO standards, or NIST.

Frameworks are valuable because they make the operating posture legible. They are dangerous when they substitute for operational policy. A framework that says 'we will use AI responsibly' without telling a staff member what that means on Tuesday morning is not governance — it is a press release with footnotes.

"A framework without a clause is a poster. A clause without a framework is a rule with no story."

Type 4: Acceptable-use statement

Short, staff-facing guidance — often a one-pager, an intranet post, or an email from the CAO — telling employees what they can and cannot do with tools like ChatGPT, Copilot, Gemini, or Claude. Frequently the first artifact a municipality ships, sometimes the only one.

What it looks like

• 'Do not paste resident data, personnel information, or confidential records into public AI tools.'
• A list of approved tools (often the enterprise license the city already pays for).
• Guidance on disclosure: when staff should tell colleagues, council, or residents that AI was used.
• An escalation path: who to ask when something is unclear.

Acceptable-use statements are easy to ship and easy to underweight. They are also the artifact most likely to actually change behaviour — because they show up in onboarding, in IT prompts, and in manager conversations. The registry tracks them as a distinct type rather than dismissing them as 'just a memo.'

What doesn't count (yet)

Some artifacts get sent to us as 'AI policies' but do not, in our taxonomy, qualify on their own:

• A press release announcing that an AI policy is being developed.
• A vendor's product terms that mention AI ethics.
• A council motion directing staff to study AI governance without naming an artifact.
• An academic framework or template adopted by reference but never operationalized.

These often appear adjacent to real governance work — they are sometimes the first public signal that a municipality is moving — but on their own they fail the receipts test. The registry may note them as context; it will not list them as policy.

How the registry uses this taxonomy

Every entry in Got AI Policy is tagged by artifact type. That lets you compare artifacts of the same kind — a standalone policy against another standalone policy, an embedded clause against another embedded clause — rather than mixing formats that are not interchangeable.

Comparison becomes possible because we are no longer comparing a 47-page framework to a three-sentence email. We are comparing artifacts of the same type — and noting, transparently, where a municipality has one type and not another.

What this means for your municipality

If you are inside an organization and the question 'do we have an AI policy?' has landed on your desk, do not start by drafting a 30-page document. Start by inventorying what you already have under each of the four types.

• Standalone: probably no — and that is fine for now.
• Embedded: check procurement, IT acceptable use, privacy, and records. You likely have at least one clause already.
• Framework: check council reports and strategic plans. You may have principles you can point to.
• Acceptable-use: if nothing else exists, this is the cheapest first ship.

Then map the gap. The honest answer is rarely 'we have nothing.' It is usually 'we have two of four, and the missing two are the ones a journalist would ask about first.'

Browse the registry, filter by artifact type, and see how your municipality compares. If we have miscategorized something, tell us — every entry has a 'report an issue' path. The taxonomy is a working document, not a verdict.

Frequently asked questions

If we have an acceptable-use clause in our IT policy, does that count?

Yes — that is an embedded AI policy artifact. It is real, it is defensible, and it counts for the purpose of answering 'do we have an AI policy?' What it does not do is address procurement, risk classification, or human-oversight questions; those need to live somewhere else in your policy stack.

Does a council motion or board resolution count as a policy?

It counts as an authorization artifact — evidence that governance has spoken. On its own it is rarely enough to guide staff on Monday morning; pair it with a short standalone or embedded policy that says what to actually do.

Is it OK to publish a policy that only names principles, without procedures?

Yes, and many organizations do. A framework-style policy is a legitimate artifact — but be explicit that procedures follow. Publishing principles without procedures and pretending the work is done is what erodes trust.

Can we use a template we found online?

You can — /tracker exists so you don't have to guess whose template to trust. Read two or three peer policies at /grade before picking wording, and edit the sections that don't match your reality. A template that says 'we use a risk-tiering framework' when you don't is worse than saying nothing.

What is the fastest way to see what we already have?

Search four documents: IT acceptable use, privacy policy, procurement guidelines, and records/retention. Most organizations have at least one AI-relevant clause hiding in there. Map what exists, then decide what's missing — the honest answer is rarely 'we have nothing.'