A workplace AI policy that only says “be careful” will not survive contact with an actual incident. Here are the six questions Canadian law and guidance say a real one has to answer, in plain language.
Key takeaways
This is the item every other item depends on. Canada’s Cyber Centre names it as the leading generative-AI risk in plain language: “users may unknowingly provide sensitive corporate data or personally identifiable information (PII) in their AI queries and prompts.” (Canadian Centre for Cyber Security, ITSAP.00.041) A policy needs a specific list, not a general instruction — client files, unreleased financials, health information, anything under an NDA — and it needs to name which tool, if any, is approved for that kind of work instead of a personal consumer account.
PIPEDA’s accountability principle is specific about what an organization has to do, not just believe: “the identity of the individual(s) designated by the organization to oversee the organization’s compliance with the principles shall be made known upon request”, and the organization “shall implement policies and practices to give effect to the principles, including… training staff and communicating to staff information about the organization’s policies and practices” and “establishing procedures to receive and respond to complaints and inquiries.” (PIPEDA, Schedule 1, clauses 4.1.1–4.1.4) A policy that never names a person accountable for AI-related privacy questions, or never says how staff are trained, is missing content the statute itself expects an organization to have in place — not just a good idea.
Canada’s privacy commissioners state the principle plainly: organizations should “ensure that system outputs that could have a significant impact on an individual or group are meaningfully identified as being created by a generative AI tool.” (OPC, Principles for responsible, trustworthy and privacy-protective generative AI) Separately, the federal Voluntary Code of Conduct puts a specific obligation on whoever manages a customer-facing system: “ensure that systems that could be mistaken for humans are clearly and prominently identified as AI systems.” (ISED, Voluntary Code of Conduct) Neither is a binding law outside its own scope — the Code binds only its 46 signatories — but both describe the disclosure norm a policy should adopt anyway: say when AI touched something a customer or employee is looking at, especially where the stakes are real.
The same regulators expect a live path back to a person, not a settings toggle: organizations should “ensure that impacted individuals are provided with an effective challenge mechanism for any administrative or otherwise significant decision made about them… and allowing them the opportunity to request human review and/or re-consideration of the decision.” (same OPC principles) A workplace policy should name, concretely, which categories of AI-assisted work go out without further review (a first-draft internal email) and which require a named person’s sign-off before anything leaves the building (anything affecting a customer’s account, an employee’s status, or a public statement).
The Voluntary Code’s own measures table separates what a developer or manager owes before launch from what they owe after. Before deployment, it recommends the developer “employ adversarial testing (i.e., red-teaming) to identify vulnerabilities”; after deployment, the manager should “monitor the operation of the system for harmful uses or impacts after it is made available, including through the use of third-party feedback channels” and “maintain a database of reported incidents after deployment.” (ISED, Voluntary Code of Conduct) A policy should say, concretely, who does this testing, on what schedule, and where an incident actually gets logged — not merely that the system will be “monitored.”
A policy is only as useful as its own enforceability. Ontario courts, per treadstonelaw’s review of employment contract drafting, treat broad language letting an employer change terms “at its sole discretion” with real skepticism, particularly where the change “purports to reach fundamental terms” — a genuinely fundamental change “usually still requires the employee’s agreement (often supported by fresh consideration) to be enforceable.” (Treadstone Law, Unenforceable Employment Contract Clauses in Ontario) An AI policy rolled out with a signed acknowledgment and a real training session behind it stands on much firmer ground than one emailed out as an update to the handbook nobody reopens.
If the AI tool being adopted also monitors employees — tracking keystrokes, screen activity, or message content, for example — a separate Ontario duty attaches on top of everything above. Employers with 25 or more employees on January 1 of any year must have a written electronic-monitoring policy in place by March 1, describing how and when monitoring happens and what the information gathered is used for, and must give every employee a copy within 30 days. (Employment Standards Act, 2000, s.41.1.1) An AI feature that quietly adds monitoring to a tool bought for something else can trigger this duty before anyone has consciously decided to start monitoring staff.
A useful check before publishing a policy: hand it to an employee who has never seen it and ask four questions cold. What can I paste into a public AI tool, and what can’t I? Who do I ask if I’m not sure? What has to be checked by a person before it goes to a customer? What happens if I break the rule by accident versus on purpose? If the document does not answer all four in under a minute of reading, it is a statement of values, not a policy.
Two failure modes show up repeatedly in practice, and both are avoidable at the drafting stage. The first is a policy copied from a generic online template that never mentions the specific tools staff actually use, so nobody recognizes their own daily workflow in it. The second is a policy so broad it bans “AI tools” outright, which staff quietly route around because it does not distinguish between pasting a client file into a public chatbot and using an approved internal tool — a workable policy narrows the ban to what actually creates risk, not to the technology as a category.
Not necessarily, but it has to be specific enough to answer concrete questions — what data is off-limits, who signs off, and who is accountable — rather than a general statement folded into an existing acceptable-use section.
No. It is voluntary and binds only the organizations that signed it. It is still useful as the closest thing Canadian federal policy has to a description of what responsible AI governance looks like.
PIPEDA’s accountability principle requires that the identity of the individual overseeing compliance be made known on request — a policy should name that person or role directly rather than leaving it to “the company.”
Related: training staff to work alongside AI, can staff be disciplined for using AI, and operating an AI workflow once the policy is live.
A short call is enough to check a draft policy against the six items above before it goes out to staff.
