An AI policy template for employees

How should you use this template?

Copy the clauses below into your own document, replace every bracketed placeholder, and discuss each one with the person responsible for that workflow. Do not adopt it as company policy without checking the actual tools, information and obligations involved. It deliberately avoids inventing a universal permission to upload business data.

Use a familiar task to test whether an employee can apply the finished document. For example, can they tell which account is approved for drafting an email from public facts, and which person to ask before sharing a client report? If the answer is unclear, improve the policy before asking staff to acknowledge it.

This template is general information, not legal advice. Data protection, employment and sector rules vary by country, and a qualified adviser should review the version you adopt.

What goes in the purpose, scope and ownership clauses?

The first three clauses say why the policy exists, whom it covers and who decides when it is unclear. Keep them short; their job is orientation, not legal effect.

Clause 1, purpose: "[Company] uses AI tools to help staff draft, summarise, research and analyse. This policy explains which tools are approved, what information may be used with them, how outputs are checked and whom to ask. It supports, and does not replace, our [information security / data protection / confidentiality] policies."

Clause 2, scope: "This policy applies to all employees, contractors and [freelancers / interns] doing work for [Company], on any device, including AI features built into software we already use, such as [office suite, design tool, CRM]."

Clause 3, ownership: "[Name, role] owns this policy and the approved-tool register. [Backup name] covers when they are unavailable. Questions go to [email or channel]. [Name, role] approves any workflow involving personal information."

How do you fill in the tools and information clauses?

Clauses 4 and 5 carry most of the risk, so they need the most specific answers. Clause 4 names exact accounts; clause 5 says which classes of information may go into each one.

Clause 4, approved tools: "Use only the tools listed in the approved-tool register, signed in with your [Company] account. Personal accounts, free tiers and browser plug-ins not in the register must not be used for [Company] or client work. To request a new tool, email [owner] with the tool, the plan, the task and the information it would involve."

Clause 5, information: "You may use public information and [internal information] in approved tools. You must not enter [client confidential material / pricing / unreleased financials / source code / credentials] unless the register approves that tool for that task. Do not enter personal information about staff, candidates or customers unless [name] has approved the specific workflow. Removing names does not by itself make information safe to share."

Each approval in the register needs the service and plan, the permitted task, the information allowed, the reviewer and a review date. Ask vendors separately about training on your data, retention, administrator access and deletion, and record what their current terms say with the date you checked. A no-training statement is not the same as no storage.

What should the output review and people-decision clauses say?

Clause 6 makes the person who uses an output responsible for checking it; clause 7 keeps decisions about people with people. Both should match approvals you already have, not replace them.

Clause 6, output review: "You are responsible for any AI-assisted work you use or send. Before use, check facts, figures, quotes and citations against the source material or a named source. Remove any statistic, result, endorsement or citation you cannot trace. Work that would normally be reviewed by [legal / finance / a manager] is still reviewed by them."

Clause 7, decisions about people: "AI tools must not be used as the basis for decisions about hiring, pay, performance, discipline, credit or a customer complaint. They may help draft or organise material, but a named person must review the underlying information and make the decision."

If your team does high-volume work such as support replies, add a sentence on spot checks: who samples AI-assisted replies, how often, and what happens when a pattern of errors appears.

How do the disclosure, reporting and review clauses work?

The last three clauses say when to tell others AI was used, what to do when something goes wrong and how the policy stays current.

Clause 8, disclosure: "Tell your reviewer when a draft was substantially produced with AI. Follow client contracts and any platform or publication rules about AI-generated content. [Optional: Customer-facing images or text generated by AI are labelled as [wording].]"

Clause 9, reporting: "If restricted information may have gone into an unapproved tool, or an AI-assisted output caused or nearly caused a problem, tell [owner] the same day with the tool, the account and what was shared. Follow [existing incident procedure] where it applies. Prompt reporting will not be treated as misconduct."

Clause 10, review: "[Owner] reviews this policy and the register at least every [six / twelve] months, and whenever a tool, plan, contract or workflow changes. Version [number], approved by [name] on [date]."

Which placeholders need real decisions?

Every bracket is an unresolved decision, not a safe default, so mark unknown items for review rather than fill them with a plausible-sounding rule. The company must supply its policy owner, approved services and plans, permitted tasks, restricted information, review responsibilities, reporting route and review date.

Record why a tool is approved for a particular task. Model-training settings, retention, access controls and contractual permission are separate questions. A tool can have one acceptable use and another use that needs extra approval. Keep that distinction visible in the register.

A worked case: a fictional 18-person bookkeeping practice filled clause 5 first and found it could not answer it, because its client engagement letters said nothing about AI. Rather than guessing, the owner marked client material as not allowed pending review, approved public and internal use straight away, and booked a conversation with its adviser about updating the engagement letters.

What should a reviewer inspect?

A reviewer should check that the policy matches existing information-security, privacy, employment and publication processes and does not quietly override them. A short AI document should not loosen a rule that already controls confidential data or consequential decisions. The right reviewers depend on the organisation, workflow and jurisdiction.

The NIST AI RMF Playbook's Govern material discusses roles, responsibilities, training and third-party risk; this template is our practical adaptation for small teams. The ICO's guidance on AI and data protection is an official UK resource for personal-data questions, and its pages currently say it is under review after the Data (Use and Access) Act, so check the live version. The template is not a compliance certificate or a statement that your company has implemented the controls.

How do you introduce the policy to the team?

Introduce it with examples from your own work, not a reading assignment. Walk through one allowed example, one restricted example and one uncertain case. Ask people to explain the difference and find the escalation route. Give them time to ask about the tools and accounts they actually use. An acknowledgement alone does not show that someone can apply a boundary.

Return to the policy after the first practice session. Add the examples that made a decision clearer and correct any instruction that did not match the workflow. Keep a version number and an owner so staff know where to find the current rules.

If you want structured practice, Tosheo.ai is being built to give each role short lessons that end in a hands-on task in a real AI tool, graded against a visible rubric. It does not write or approve your policy.

When is a generic template the wrong starting point?

A generic template is the wrong starting point if you build AI into a product you sell, process special-category personal data, operate in a regulated profession, or have contracts that already set AI terms. Start from those obligations with a qualified adviser and use this structure only as a checklist of topics.

It is also wrong if nobody will own it. A template filled in once and never reviewed becomes a list of rules about tools the team no longer uses. Name the owner before you fill in clause 4.

Sources and scope

NIST AI RMF Playbook: Govern, checked 16 October 2026 ↗

ICO, Guidance on AI and data protection (under review), checked 16 October 2026 ↗

ICO, AI and data protection risk toolkit (under review), checked 16 October 2026 ↗