Skip to content
AI Compliance Tool
Check my AI risk
PlatformSolutionsPricingRegulationsFree toolsGuides Partners Sign in

AI Governance Policy Examples

How to structure an AI acceptable-use policy and an AI governance policy, with annotated example clauses and the mistakes that make policies useless.

By AI Compliance Tool editorial team · Published 2026-10-14 · Reviewed 2026-10-14 · Reviewer: Pending independent review · 10 min read

Key takeaways

  • You need two documents: an acceptable-use policy that tells staff what they may do with AI tools, and a governance policy that tells the business how AI is approved, assessed, overseen and retired.
  • Good clauses name a person, a trigger and an evidence artefact. Clauses that only state values cannot be checked.
  • Tie the policy to the inventory lifecycle so approvals, suspensions and retirements are recorded decisions.
  • Quebec Law 25 and BC PIPA already require published governance policies for personal information; your AI policy should extend those, not duplicate them.
  • Do not write that the policy ensures compliance with any law or that alignment with NIST or ISO equals certification.

A policy is only useful if a specific person can be asked “did you do this?” and point to evidence. That principle shapes everything below: each example clause names who, when and what record exists.

This guide separates the two policies most small businesses need, walks through each structure, gives original annotated clauses you can adapt, and lists the mistakes that turn policies into wallpaper.

Two policies, two audiences

Acceptable-use policyGovernance policy
AudienceEvery person who uses an AI toolOwners, approvers, leadership
Length2 to 3 pages4 to 8 pages
AnswersWhat may I put into AI tools, and what must I check before I use the output?How do we decide which AI we use, how do we assess and oversee it, and who can stop it?
ChangesRarely; data rules are stableOn trigger events and annually
EvidenceAcknowledgement log, training recordsApproval records, risk assessments, inventory states, incident log

Both should reference the AI inventory as the single list of approved tools. Neither should list tools by name.

Structure of an acceptable-use policy

  1. Scope: who it covers (employees, contractors, anyone using company accounts or data).
  2. Approved tools: “only tools listed as Active in the AI inventory, on the account tier listed”.
  3. Data rules by category: what may and may not be entered.
  4. Output rules: verification, attribution, disclosure.
  5. Prohibited uses.
  6. Reporting: how to flag a mistake or a concern without blame.
  7. Acknowledgement.

Annotated example clauses

Approved tools.

Staff may use AI tools that appear in the AI inventory with status Active, using the account type recorded there. A tool not on the list may be requested through the operations lead and may not be used with company data until it is Active.

Why it works: it points to the inventory rather than naming products, and it gives a route for new requests so people do not go around the rule.

Data rules.

The following may not be entered into any AI tool unless the inventory entry for that tool explicitly permits the category: customer or employee personal information; health, financial or biometric details; credentials, keys or passwords; unreleased financial results; client documents marked confidential; and any content a contract says we may not share with third parties.

Why it works: the categories are concrete and the exception path is the inventory entry, so a business-tier tool with contractual protections can be permitted without rewriting the policy. In Canada, this clause supports PIPEDA Principle 4.7 safeguards and the limiting-use principle; in Quebec it supports the s. 3.2 governance duty.

Verification of output.

AI output is a draft. Before it is sent to a customer, published, filed or relied on for a decision, the person using it must check facts, figures, names, dates, citations and any legal, financial or medical statement against a source they can name. The person who sends or files the content is responsible for it.

Why it works: responsibility sits with a person, and “a source they can name” is testable.

Disclosure.

Where a customer, applicant or member of the public is interacting with an AI system rather than a person, the interaction must say so at the start. Where AI materially contributes to a decision about a person, the notice required for that jurisdiction (see governance policy section 6) must be given.

Why it works: it mirrors the EU AI Act Art. 50(1) transparency duty applying from 2 August 2026 and Utah’s disclose-when-asked rule, without pretending to restate either law.

Prohibited uses.

No one may use AI tools to infer emotions of staff or candidates, to score people on social behaviour, to generate content that imitates a real person without their written consent, or to make a decision with legal or significant effects on a person without a human reviewing and being able to change it.

Why it works: each item maps to a real prohibition or restriction (EU Art. 5 prohibitions on workplace emotion recognition and social scoring; GDPR Art. 22 and Quebec s. 12.1 on solely automated decisions) while staying in plain words.

Reporting.

If you think personal or confidential data was entered into a tool by mistake, or an AI output caused an error, tell the operations lead the same day. Reporting a mistake promptly will not be treated as misconduct.

Structure of a governance policy

  1. Purpose and principles (short; borrow from the OECD values-based principles if you want a reference point).
  2. Roles: governance owner, tool owners, approvers, who can suspend.
  3. Inventory and lifecycle: the six states and who moves entries between them.
  4. Risk assessment: when it is required and what it must contain.
  5. Vendor due diligence: minimum questions and contract terms.
  6. Transparency and notices: by jurisdiction and use.
  7. Human oversight and agents: autonomy levels and approval gates.
  8. Training (AI literacy): who, what, how often, records.
  9. Logging, incidents, suspension.
  10. Review cadence and version control.

Annotated example clauses

Roles and suspension.

The operations lead is the AI governance owner. Each inventory entry has a named tool owner. Any of the governance owner, the tool owner or a director may move an entry to Suspended at any time; a Suspended entry may only be reactivated by the governance owner after the reason is recorded as resolved.

Why it works: suspension is easy and reactivation is deliberate. This is the shape EU high-risk deployers will need from 2 December 2027 (Art. 26(5): suspend use where a system may present a risk), and it is sensible everywhere.

Risk assessment trigger.

A risk assessment is required before an entry moves to Approved if the tool processes personal information, interacts with the public, or recommends or makes decisions about individuals. The assessment records severity, likelihood and exposure for each identified harm, treats unknown data practices as a risk, and is signed by the tool owner and the governance owner. Where the business operates in Quebec, this assessment is combined with the privacy impact assessment required by s. 3.3 of the Act respecting the protection of personal information in the private sector.

Vendor terms.

Before customer or employee personal information is sent to a vendor’s AI service, the contract must state whether our data is used to train or improve the vendor’s models, how long inputs and outputs are retained, where data is stored and processed, the subprocessors used, the deletion process on termination, and the vendor’s incident-notification commitment. The vendor’s answers are attached to the inventory entry.

Why it works: PIPEDA Principle 4.1.3 and Alberta PIPA s. 5 keep the organisation responsible for information handled by service providers; this clause creates the record that shows you discharged that responsibility.

Notices by jurisdiction.

The governance owner maintains a notice register listing, for each Active entry that affects individuals, the notice required and where it is displayed. At minimum the register covers: Ontario publicly advertised job postings where AI screens applicants (Employment Standards Act, 2000 s. 8.4, employers with 25 or more employees); Quebec decisions based exclusively on automated processing (s. 12.1); EU interactions with AI systems (AI Act Art. 50); and, from 1 January 2027, Colorado consequential decisions using covered ADMT (SB 26-189).

Why it works: a register is checkable; a sentence saying “we comply with applicable disclosure laws” is not.

Agents and autonomy.

Each AI agent in the inventory is assigned an autonomy level: Suggest, Act with approval, Act and report, or Fully autonomous. Fully autonomous is permitted only for actions that are reversible, do not involve payments or external communications, and have been Approved with a documented override and logging method.

Training.

All staff who use AI tools complete the AI acceptable-use briefing on joining and annually; tool owners complete tool-specific training before an entry is Approved. Completion records are kept by the governance owner. This supports, but does not by itself satisfy, the AI literacy measures expected of EU deployers under Art. 4 of the AI Act.

Review.

This policy is reviewed annually and on any of the following: adoption of an AI agent, a new jurisdiction of operation, a material vendor change, an incident, or a regulatory application date. Each version records its approval date and approver.

Common mistakes

  1. Values without verbs. “We use AI responsibly and ethically” cannot be audited. Every clause should let someone ask “show me”.
  2. Listing products. Policies that name tools go stale within weeks and encourage the view that anything not named is fine.
  3. Claiming compliance. Do not write that the policy “ensures compliance with the EU AI Act” or “meets ISO 42001”. A policy supports compliance; alignment with a voluntary framework is not certification; only an accredited body issues an ISO certificate.
  4. Citing laws that do not exist. Canadian policies still appear that cite AIDA as a requirement. Bill C-27 died on 6 January 2025. Bill C-36, introduced 15 June 2026, is a proposed privacy bill. Neither creates obligations today.
  5. Treating consumer and business accounts the same. Data rules should distinguish account tiers, because contractual protections usually differ.
  6. No suspension route. If the only person who can switch a tool off is on holiday, the policy has a gap.
  7. No acknowledgement or training record. A policy nobody signed is hard to rely on in an employment or regulatory dispute.
  8. Forgetting contractors and agencies. Their AI use touches your customers’ data too.

Sources

Frequently asked

Can one document cover both acceptable use and governance?
It can for a very small team, but keep the two parts clearly separated. Staff need a two-page acceptable-use document they will actually read; the governance part is for owners and approvers and changes less often.
Should the policy name specific tools?
No. Name categories and point to the inventory for the approved list. Tools change monthly; the policy should not.
How often should we update the policy?
Review annually and on trigger events such as adopting agents, entering a new jurisdiction, or a regulatory date like 2 December 2027 for EU high-risk uses. Record every version and approval date.
Is a policy enough on its own?
No. A policy with no inventory, no training records and no evidence of approvals is a statement of intent. Regulators and customers look for the records the policy says you keep.

This guide is general information, not legal advice. Laws and dates are drawn from our verified regulatory dataset and link to official sources; check them for changes after the review date.