An employee AI acceptable-use policy should make a work decision possible. It should explain which tools and accounts people may use, what information they may enter, which tasks need approval, how outputs must be checked, and where to ask for help or report a mistake. Give the policy a named owner and keep its approved-use information current.
For an HR, IT or operations lead, the useful test is whether a colleague can apply those rules to a real task. “Use AI responsibly” offers little help to a procurement coordinator deciding whether to upload a supplier's quotation. The policy needs to resolve that question before the upload happens.
Specify what approval actually covers
A familiar logo is not enough. Your policy should point to a maintained list that identifies the approved service and account, the information it may process, the permitted purpose and any conditions. Explain how employees reach the correct workspace and whom they contact when it is unavailable.
The BC Public Service's generative AI policy illustrates why the account matters. It permits confidential information in tools covered by its Microsoft agreement and requires employees to use their government login, while prohibiting confidential information in publicly available tools. That permission belongs to BC's particular arrangement. It is not a guarantee about every account carrying the same product name.
Similarly, the US Department of Veterans Affairs guidance explicitly distinguishes being able to reach a website from having authorization to use sensitive data there. Translate that distinction into a rule employees can recognize: access does not establish approval for this input and task.
Include AI features inside existing software. Permission to use a document editor does not, by itself, answer whether an employee may enable a new feature that sends information elsewhere. Identify who assesses changed features and updates the approved-use list.
Cover the decisions employees actually make
Keep the policy connected to existing security, privacy, records, conduct and procurement rules. Give employees the practical answer and a link to the deeper requirement where needed. Avoid asking each person to interpret a vendor contract before every task.
| Policy area | What an employee needs to know |
|---|---|
Scope | Which people, work activities, devices and embedded AI features the rules cover. |
Tools and accounts | Where the approved list lives, how to sign in correctly and whether personal accounts are prohibited for work. |
Information | Which data categories are allowed in each approved service, with recognizable examples and an owner for uncertain classifications. |
Tasks and actions | What is permitted, prohibited or subject to further approval, including sending, publishing or changing records. |
Output review | Who checks facts, completeness, appropriateness and important omissions before anyone relies on the result. |
Disclosure and records | When colleagues or recipients need to know about AI involvement, and where required records belong. |
Help and incidents | Where to ask before proceeding and how to report suspected exposure or misuse promptly. |
Ownership and maintenance | Who approves exceptions, communicates changes and reviews whether the rules remain usable. |
Separate ordinary drafting from decisions that affect people's employment, access to services, money or safety. Name the specialist approval and established decision process that apply. A generic instruction to “review the output” does not establish that a high-consequence use is authorized.
Published organizational policies make different choices. UT Austin's guidance connects data classifications to authorized tools and contracts. The University of New England's policy assigns governance and procurement responsibilities and addresses output review and disclosure. Use these as examples of coverage, then have your own policy owners resolve the requirements for your workforce, contracts and jurisdiction.
Say what happens after drafting. In an August 2024 Reddit discussion, a Reddit user shared a policy that allowed drafting an email with AI but prohibited AI-created text in final work products. Their follow-up identified it as their organization's policy; the employer was not named. That distinction may be deliberate, but employees need an explanation of what they are expected to do between those two steps.
For your own policy, walk through the accepted result. Does an employee edit and verify an AI-assisted draft, or must they write the final text themselves? Who decides whether the result meets the rule? Resolve the answer rather than leaving contradictory interpretations for managers to enforce.
Test the rule on a supplier quotation
Suppose Jamie, a procurement coordinator, wants help comparing delivery terms from two suppliers. The approved tool list permits summarizing public product information in a work account. One document is a published specification; the other includes confidential negotiated pricing and a named contact.
The second document changes the decision. Jamie needs to know whether that information and purpose are approved, who can answer, and how to keep the comparison moving without uploading it while waiting. A sentence saying the tool is “approved” leaves those questions open.
Use synthetic documents to rehearse the decision without exposing real supplier information.
- Identify the input. Ask Jamie to distinguish the public specification from the confidential quotation and find the relevant handling rule.
- Find the permission. Check the approved account, data category and task together. If any is unclear, use the named policy-help route.
- Continue safely. Keep the existing manual comparison available while the question is resolved. Removing a name alone does not establish that negotiated pricing is permitted.
- Check the result. For an authorized AI-assisted comparison, the coordinator verifies delivery dates, exclusions and missing terms against the source documents before handing it to the buyer.
Then change one condition. The employee signs into a personal account, receives a customer restriction, or wants the tool to send the supplier an acceptance email. Ask whether the policy makes the changed decision clear. Drafting a comparison and committing the company to a purchase are different permissions.
The human-review guide explains how to make that final check specific to the work. Keep procurement's existing approval authority intact.
Keep the policy working after launch
A written boundary needs someone to maintain the arrangements behind it. In her September 2026 article, AI-governance practitioner Katharina Koerner argues that a prohibition becomes testable only when the enforcement mechanism, owner and evidence are specified. Her discussion also distinguishes approved work accounts from personal accounts. This is a practitioner argument, not a measured outcome from a company rollout.
Ask IT and security to confirm which restrictions are implemented and where gaps remain. Keep employee instructions consistent with that reality. Do not present a policy acknowledgement as proof that a technical restriction works.
Make maintenance concrete:
- Assign one accountable policy owner. Identify the teams that maintain tool approval, information classification, training and incident response.
- Give questions a route and an expectation. Tell employees where to submit the task and what they should do while waiting. Set a response target the responsible team can support.
- Explain reporting. Tell someone who suspects they uploaded restricted information to stop further sharing and use the established incident channel. The response team should direct containment and record handling.
- Revisit meaningful changes. Reassess new data, connected systems, actions, vendor terms or audiences, then communicate the decision to affected users.
The UK Department for Work and Pensions policy gives a concrete organizational example: a significant change to an approved use case requires further approval, and it names responsibility for policy maintenance and reporting. Your organization needs its own owners and routes, rather than a copied department name.
Before circulating the policy, ask colleagues from different departments to apply it to a permitted task, an uncertain input and a prohibited use. Record where they disagree or cannot find an answer. Fix those gaps and repeat the exercise. A clear policy gives employees a usable path forward as well as a boundary.
For the wider operating arrangement, return to the tools and workflows guide.
Questions about employee AI policies
Should employees be allowed to use personal AI accounts?
The policy should make that decision explicit. An approved work service does not automatically authorize a personal account with different terms, settings or administrative control. Tell employees which account to use and what to do when they cannot access it. Have the responsible IT and policy owners assess any exception before work information is entered.
Is removing names enough to make a document safe to upload?
No. A document may still contain confidential prices, identifying circumstances, proprietary material or information restricted by a contract. Removing names does not establish permission for the remaining content. Apply the organization's classification and approved-use rules to the actual input, and ask its information owner when uncertain. The supplier example shows why the task and data must be considered together.
Does every AI-assisted email need a disclosure?
A policy should specify when disclosure is required under the organization's rules, relevant contracts and applicable obligations. It should also explain when AI involvement or unresolved uncertainty matters to the recipient's interpretation. Do not assume one rule fits every email, client deliverable and consequential decision. Ask the policy owner to resolve unclear cases and give employees examples they can apply.
How can we tell whether the policy is usable?
Ask employees to find the approved account, classify a realistic input, identify the required reviewer and locate help using the policy itself. Include an exception and a change of purpose. If reasonable readers reach different decisions, revise the wording or underlying ownership and retest it. This exercise checks usability; technical control testing and compliance review remain separate responsibilities.
