← All articles

Reviewed

Writing an AI acceptable-use policy

An AI acceptable-use policy tells staff which tools they can use for work and what information they may enter. Start by listing the tools in use and the types of data your team handles. If that picture is incomplete, begin with an inventory of existing AI use. Write the policy around real tasks, not a general instruction to “use AI responsibly.”

The policy should answer five everyday questions: Which tool and account may I use? What information may I enter? What must I check? Who approves an exception? What should I do if something goes wrong? Keep the staff-facing instructions short enough to consult while working, with a separate register for detailed tool decisions.

Define what must stay out

List the information staff must not enter into AI tools, including secrets and credentials. Identify personal information, protected source code, and other confidential material that requires approval before use. Define who can approve that use and which tools and account settings are permitted. Check contractual and privacy restrictions before approving confidential data for use.

Give concrete examples without copying sensitive information into the policy. A public product description may be permitted in an approved drafting tool. A client support transcript may require a reviewed workflow and less identifying information. Passwords, API keys and authentication tokens must stay out of prompts and uploaded files. Do not assume that removing a name makes a document anonymous or that a paid account makes every data category acceptable.

The OPC's business guidance on AI and Canadian generative AI privacy principles help frame decisions about appropriate purposes, legal authority or consent, transparency and safeguards. Approval by a manager does not replace any consent, authority or contractual permission that the use actually requires.

Name the approved tools

List the approved tools, the account type required for each, and the person to contact with questions or requests for a new tool.

For each approval, state the allowed task, data categories, required settings, owner and review date. Distinguish a managed work account from a personal account. Include meeting assistants, coding extensions and AI features inside existing software, not just standalone chatbots. A tool approved for drafting public text is not automatically approved to record meetings or search client files.

Review connectors and agents separately when they add access or actions. For Microsoft 365 Copilot, Microsoft's privacy documentation describes product-specific protections and permission boundaries. Its statements about foundation-model training should not be rewritten as “nothing is stored,” or applied to unrelated services. Check retention, processing, access and provider terms for the actual product.

Check the results

Explain which outputs need review before use or sharing. For factual answers, check the cited source and confirm that it supports the answer. Assign a person to review work that could affect a client, an employee, or a business decision.

Make the review specific to the task. Check calculations against their inputs, code through the normal review and security process, and summaries against the original material. Do not publish invented citations or treat an assistant's confidence as evidence. Identify decisions that must remain with an authorized person, especially consequential decisions about individuals.

If an agent can send a message, change a record or call an external service, state which actions require human approval and who can give it. The approval should identify the recipient or target and the actual action, not provide blanket permission for whatever the agent decides next. Technical permissions should enforce the boundary; a policy paragraph alone does not.

Make questions and incidents easy to report

Name a contact or channel for new-tool requests, uncertain data and suspected disclosures. If staff enter restricted information or notice unexpected access, tell them to stop the affected use and report promptly through the incident process. Ask for the tool, account, time and data category through an appropriate channel, without copying the sensitive content into another ordinary message.

The incident owner should assess containment, evidence preservation, access revocation and any notification duties. Do not tell staff that deleting a chat necessarily deletes all provider-held copies. A useful policy makes early reporting practical rather than encouraging people to hide uncertainty.

Explain and review the policy

Keep the instructions concise and walk through them with your team. Name the person responsible for reviewing the policy, and revisit it when the tools, their terms, or your data-handling requirements change.

Walk through a permitted task, a task needing approval and a mistake worth reporting. Give staff an approved alternative where a tool or use is prohibited. For an exception, record the purpose, data, approver, safeguards and expiry date instead of leaving an informal permission open indefinitely.

Keep the dated policy, tool register, approval decisions and record of the staff briefing together. Review whether people can follow the instructions in their actual work. A signed policy is useful evidence of communication; it is not evidence that every use is controlled or that all legal obligations are met.

This is general readiness guidance, not legal advice; confirm obligations for your industry with a qualified professional.


Source: https://www.priv.gc.ca/en/privacy-topics/technology/artificial-intelligence/ai_business/. General readiness guidance — not legal advice.