A salesperson uses an AI assistant to rewrite a follow-up email. A developer asks it to explain an error. Someone in finance uploads a supplier invoice to summarize it. A manager pastes employee notes into a chatbot to draft a performance review. All four people may believe they are doing the same thing: using AI to save time. The data, consequences, and business risk are completely different.
A blanket ban rarely answers the real questions, and an informal use your judgment rule leaves every employee to invent a security and privacy policy at the prompt box. The practical middle ground is an AI acceptable-use policy: a short operating document that names approved tools, permitted data, review requirements, prohibited activities, ownership, and a safe way to ask for an exception.
For a Toronto professional-services firm, an Ontario manufacturer, or another Canadian small business, the policy should be proportionate. A company using AI to brainstorm social posts does not need the same control system as one connecting an agent to customer records and payment workflows. Both need clear boundaries, accountable owners, and employees who understand that model output can be convincing without being correct.
An acceptable-use policy is one part of AI governance
The employee-facing policy explains everyday behaviour. Broader AI governance decides who approves tools, how vendors are assessed, how systems are inventoried, which risks are measured, how privacy and security reviews work, how incidents are handled, and who remains accountable for customer or employee impact. A two-page policy cannot replace those decisions.
NIST's Generative AI Profile explicitly recommends acceptable-use policies for generative AI interfaces and human-AI configurations. Canada's current guidance also points toward governance rather than unstructured experimentation. The Canadian Centre for Cyber Security published its Top 10 AI Security Actions on May 29, 2026, organized around secure design, development, deployment, and operation. The Office of the Privacy Commissioner and its provincial counterparts advise organizations using generative AI to apply privacy principles across the system lifecycle.
Use the starter language below as a working draft, not legal advice or a universal compliance document. Adapt it to the organization, sector, province, employment context, contracts, professional duties, insurance, and the actual tools being used. Involve appropriate privacy, legal, HR, security, records, and business owners for higher-risk uses.
Inventory real AI use before writing rules
Ask teams where AI is already used. Include public chatbots, paid business assistants, Microsoft 365 or Google Workspace features, meeting transcription, CRM suggestions, design tools, code assistants, accounting features, customer-service bots, document extraction, browser extensions, mobile apps, and AI embedded inside existing software. Shadow AI often appears as a feature rather than a product employees think to report.
- Tool and vendor, including plan or licence level.
- Business owner and technical administrator.
- Users, departments, and connected systems.
- Data entered, retrieved, generated, stored, or used for model improvement.
- Business purpose and decisions influenced by output.
- Human review, logging, retention, deletion, and incident process.
- Contract, privacy, security, residency, intellectual-property, and exit considerations.
Do not promise anonymity for policy questions and then punish the first employee who discloses an unapproved tool in good faith. The first inventory should find risk and useful experiments. It should not become a trap that drives future use further underground.
Use three risk levels employees can remember
| Level | Meaning | Examples | Required action |
|---|---|---|---|
| Green: approved routine use | Low consequence, approved tool, non-sensitive information | Brainstorm generic ideas, improve wording, summarize approved public material | User reviews the result and follows normal work procedures |
| Yellow: review required | Sensitive context, meaningful decision, external output, code, or system access | Draft client advice, analyze internal data, generate code, create public content | Named owner approves the use, data, output, and control plan |
| Red: prohibited unless formally redesigned and approved | Unacceptable data exposure or delegated high-impact authority | Paste credentials, make final hiring decisions, approve payments, impersonate people | Do not proceed; report or submit a formal use-case request |
Risk depends on context, not the tool's brand. Rewriting a public event description and ranking job applicants may happen in the same assistant, but the second use affects people and may involve personal information, bias, employment obligations, and a need to explain the decision. The policy should classify what the business is doing, not declare a whole product safe.
AI acceptable-use policy starter template
The following sections can be adapted into an internal policy. Replace bracketed ideas with organization-specific roles, tools, contacts, data categories, and approval steps. Keep the employee version short enough to use, with detailed standards and vendor reviews linked separately.
1. Purpose and principles
State the positive objective before the restrictions. Employees should understand that the company wants useful, responsible adoption. The principles might include relevance, necessity, privacy, security, fairness, transparency, human accountability, accuracy, accessibility, and proportional control.
2. Who and what the policy covers
Include personal devices and free accounts when they are used for company work. Otherwise, an employee can reasonably believe the policy applies only to corporate software. Align contractor obligations with agreements and onboarding rather than assuming an employee handbook automatically binds every external worker.
3. Approved tools, accounts, and integrations
A product name alone is not enough. Consumer and enterprise plans may have different contracts, administration, retention, and model-improvement settings. Record the approved plan, identity method, configuration owner, permitted groups, data conditions, renewal, and review date. Disable unmanaged account creation where the platform and business needs allow it.
4. Data that may and may not be entered
Give employees recognizable examples from their work. Personal information may include names, contact details, recordings, account identifiers, applicant records, performance notes, customer history, location, and combinations that identify someone. Confidential information may include pricing, contracts, credentials, incidents, financial forecasts, source code, designs, and client material protected by agreement.
The Canadian Cyber Centre warns that users may unknowingly disclose sensitive corporate or personally identifiable information through prompts. The policy should not rely on employees reading every provider's changing terms. The company must configure approved tools and translate vendor conditions into clear internal rules.
5. Permitted and prohibited uses
Tailor the list to actual authority. An AI tool may help organize interview notes without scoring candidates; draft a payment reminder without changing bank details; summarize a contract for navigation without providing final legal interpretation; or suggest code without receiving production credentials or deploying itself.
6. Human review and decision authority
Human in the loop is meaningful only when the reviewer has time, authority, competence, source material, and the ability to reject the output. Clicking approve on hundreds of opaque recommendations is not strong oversight. Identify decisions that AI may support, decisions it may not influence, and evidence the reviewer must examine.
7. Accuracy, sources, and professional judgment
Define what authoritative means in the business: the signed contract rather than a model summary, the accounting system rather than a generated table, official product documentation rather than a plausible answer, and the approved policy rather than a chatbot's interpretation. For code, require normal review, tests, scanning, dependency checks, and deployment controls.
8. Intellectual property and confidential material
Do not tell employees that AI output is automatically original or automatically owned by the company. Vendor terms, source material, employment agreements, client contracts, and applicable law may matter. Route material commercial, publishing, software, and brand uses through the same intellectual-property review the business would apply without AI.
9. Privacy, fairness, and people
Canadian privacy regulators' generative AI principles emphasize legal authority, appropriate purposes, necessity, proportionality, openness, access, accuracy, safeguards, and accountability. A May 6, 2026 joint Canadian privacy investigation into OpenAI also examined consent, appropriate purpose, accuracy, transparency, access, safeguards, retention, and disposal. A small business policy should direct sensitive use cases to qualified review rather than summarize complex law in one sentence.
10. Security, access, and AI agents
Agentic systems need stronger rules because they can act, not only generate. The Canadian Cyber Centre's May 1, 2026 joint guidance recommends layered defence and strict access controls. Limit tools, data, duration, transaction value, recipients, and environments. Use read-only access first, require confirmation for consequential steps, preserve logs, and provide a reliable way to pause or revoke the agent.
11. Transparency and communication
A label on every spell-checked sentence is not useful transparency. Focus on material involvement: an AI-generated customer recommendation, automated screening, synthetic spokesperson, chatbot, decision support, or generated report used as evidence. Provide a human contact or alternative channel where the use affects customers or employees.
12. Records, incidents, exceptions, and review
Create a reporting path that employees can use quickly. A worker who pastes the wrong document should know whether to close the session, preserve details, contact security, inform privacy, reset credentials, or notify a client. The response team—not the employee improvising alone—should determine containment, provider contact, legal obligations, and communication.
Turn policy language into scenario examples
| Scenario | Classification | Safer path |
|---|---|---|
| Rewrite a generic meeting agenda | Green if no sensitive details and an approved account is used | Remove names and internal issues; review before sending |
| Summarize a customer contract | Yellow because it is confidential and may influence obligations | Use an approved protected tool, authorized data path, and legal or contract-owner review |
| Rank applicants from resumes | Red unless a formal employment, privacy, fairness, and legal process approves a redesigned use | Keep people accountable and use established hiring criteria and review |
| Generate a software function | Yellow because code can create security, licence, and reliability risk | Exclude secrets; require peer review, tests, scanning, and normal deployment approval |
| Draft a public article | Yellow because it represents the business | Verify sources, originality, rights, claims, tone, privacy, and final human ownership |
| Agent reads invoices and releases payments | Red for autonomous payment authority | Separate extraction from vendor verification, invoice approval, and independent payment authorization |
A practical 30-day rollout
| Week | Action | Evidence |
|---|---|---|
| 1 | Inventory tools, data, accounts, integrations, owners, and existing use cases | AI register and immediate-risk list |
| 2 | Approve initial tools, define green/yellow/red uses, and adapt the policy | Named owners, configured accounts, and policy draft |
| 3 | Train with real scenarios and open a simple use-case and incident channel | Attendance, knowledge check, FAQs, and escalation path |
| 4 | Pilot two low-risk uses, test controls, collect feedback, and approve the first revision | Pilot evidence, issues, metrics, and dated policy |
Measure adoption and control together. Useful indicators include approved-tool usage, time saved on selected tasks, output correction rate, policy questions, exception requests, unapproved tools discovered, sensitive-data events, customer complaints, and completion of reviews. A policy is working when employees can use approved AI confidently and know when to stop—not when nobody reports anything.
Questions to answer before approving an AI tool
- What exact business purpose and users are approved?
- Which plan, contract, data-processing terms, and administrative controls apply?
- Is prompt, file, output, feedback, telemetry, or account data used to improve models?
- Where is information processed and stored, who can access it, and which subprocessors are involved?
- How are retention, deletion, export, access requests, and contract termination handled?
- Which identity, MFA, role, logging, data-loss prevention, and integration controls are available?
- What accuracy, bias, security, privacy, accessibility, and abuse testing has been performed?
- How can the business monitor, restrict, suspend, and investigate use?
- What happens when the model, terms, price, features, or provider change?
- Can the business complete the workflow safely if the AI service is unavailable?
The goal is not to eliminate uncertainty. It is to understand which uncertainty the business is accepting, which controls reduce it, who owns the remaining risk, and what evidence will trigger a change. Start with bounded work and expand only after the organization can demonstrate safe, useful operation.