Writing an AI Acceptable-Use Policy: A Practical Walkthrough

The policy nobody asked for, until they needed it yesterday

Your team is already using AI. Someone pasted a client email into a chatbot to soften the tone. Someone else asked a model to summarise a contract. A developer is letting an assistant autocomplete code that touches your database. None of this is malicious, and most of it is genuinely useful. The problem is that it is happening with no rules, no record, and no one accountable for where the data goes.

An AI acceptable-use policy is how you turn that quiet free-for-all into something you can stand behind. It is not a ban, and it should not read like one. A good policy tells people what they can do confidently, what they must never do, and where to ask when they are unsure. Done well, it removes friction rather than adding it.

This walkthrough takes you from a blank page to a usable draft. It is written for Canadian organisations handling personal information, but the structure travels well across sectors and jurisdictions.

Start with scope: who and what the policy covers

Before you write a single rule, decide what you are governing. Vague scope is the most common reason these policies fail, because people genuinely cannot tell whether their use case is covered.

Define three things up front, in plain language:

• Who it applies to: employees, contractors, and anyone acting on the organisation's behalf. Contractors are often the gap, so name them explicitly.
• What counts as AI here: generative tools (ChatGPT, Claude, Gemini, Copilot), AI features embedded in software you already use, and any model your team builds or fine-tunes. Embedded AI inside everyday SaaS is the part people forget.
• What data is in play: distinguish public or already-published information from confidential business data, and from personal information or personal health information. The rules tighten as the data gets more sensitive.

Sort tools into approved, conditional, and prohibited

The heart of the policy is a simple tiering of tools. People do not read ten pages of nuance, but they will respect a clear list. Build three buckets and keep them current:

• Approved: tools the organisation has reviewed and licensed, ideally with a contract that prevents your inputs from being used to train the vendor's models. These are the default for day-to-day work.
• Conditional: tools allowed only for non-sensitive tasks, or only with sign-off. Free consumer tiers often land here, because their terms may permit training on your prompts.
• Prohibited: tools or uses that are off-limits entirely, such as feeding personal health information into an unvetted public chatbot, or using AI to make a final decision about someone's employment, credit, or care without human review.

Give the list a rationale, and a way to grow

Pair the tiers with a short explanation of why each tool sits where it does. When people understand that a free tier may train on their prompts, they stop treating the rule as arbitrary IT caution and start treating it as common sense.

Vetting matters, so give your team a method for assessing a new tool before it earns a place on the approved list, rather than approving on instinct. A short checklist (does the contract bar training on our data, where is data stored, what does the vendor retain) keeps decisions consistent.

Write the data rules people will actually remember

This is where most of your risk lives, so make the rules concrete. Abstract principles like "use AI responsibly" do nothing at the keyboard. Anchor the policy on a few hard lines:

• Never paste client personal information, health records, or confidential business data into a tool that is not on the approved list.
• Treat anything you type into a public AI tool as if it could become public. If that thought makes you uncomfortable, stop.
• Do not use AI to generate content you cannot verify, especially anything that goes to a client, a regulator, or the public. The human sending it owns the accuracy.
• Keep a human in the loop for any decision that materially affects a person. AI can draft, suggest, and summarise; it should not be the final authority on a person's rights or care.

Frame the rules against your Canadian obligations

If you operate in Canada, connect these rules to laws you already follow. PIPEDA and provincial regimes such as Quebec's Law 25 require you to control how personal information is collected, used, and disclosed, including when a third-party tool does the processing. Sending personal data to an AI vendor is a use and, in many cases, a disclosure, so it falls squarely within those obligations.

Health information raises the bar further. In Ontario, custodians under PHIPA face strict limits on disclosing personal health information to third parties, and similar rules apply under health privacy statutes in other provinces. An AI scribe or summariser that touches patient information deserves its own dedicated review, ideally with a privacy impact assessment, before it goes anywhere near live records.

Assign accountability and a way to ask questions

A policy with no owner drifts out of date within a quarter. Name a person or role responsible for maintaining the tool list, answering questions, and reviewing new use cases. In smaller organisations this often sits with a privacy officer or an external advisor; what matters is that the role exists and people know who it is.

Just as important, give people a low-friction way to ask "can I use this?" before they act. Most policy violations are not defiance; they are someone guessing in the absence of a quick answer. A shared channel or a named contact who responds within a day prevents the workaround culture that quietly undermines every rule you wrote.

Spell out what happens when something goes wrong, too. If confidential data was entered into the wrong tool, people need to know it should be reported, not hidden. Tie this into your incident response process so an AI misstep is handled like any other potential data exposure.

Make it stick: training, review, and version control

A signed policy that lives in a shared drive changes nothing. Three habits turn a document into actual governance:

• Onboard and refresh: walk new hires through the policy, and revisit it with the whole team when the tool list changes meaningfully. A fifteen-minute session beats a fifty-page manual nobody opens.
• Version and date it: AI tools and their terms change fast. Put a revision date on the policy and review it at least twice a year, or whenever a major tool or regulation shifts.
• Connect it to your wider program: an acceptable-use policy is one layer. As your AI use grows, it should sit inside a broader governance framework that covers risk assessment, vendor due diligence, and accountability, rather than standing alone.

From draft to living document

You do not need a perfect policy on day one. You need a clear, honest one that your team can follow this week, owned by someone who will keep it current. Start with scope, tier your tools, draw a few bright lines around sensitive data, name an owner, and build in review. That gets you most of the protection with very little bureaucracy.

The organisations that handle AI well are not the ones with the longest policies. They are the ones whose people know, without checking, what is safe to do. If you are weighing whether you even need this before your team keeps experimenting, or wondering how an acceptable-use policy fits into a fuller governance framework, the related reading below is a good next step, and we are happy to help you turn a draft into something you can rely on.

Related reading

• Do you need an AI policy before employees use chatgpt
• Does a small business need an AI governance framework