AI Policy Template: A Practical Acceptable-Use Policy for Work

An effective AI policy tells employees what they may do today, what requires approval, what is prohibited, and who decides when the answer is unclear. The template below is an operational starting point, not legal advice. Adapt it to your contracts, jurisdictions, data classifications, employment practices, security program, and actual tools.

Research and disclosure: This template is informed by the NIST AI Risk Management Framework, the NIST Generative AI Profile, and OECD AI principles, reviewed September 4, 2026. It is original editorial material and must be reviewed by your legal, privacy, security, HR, and business owners.

Copy-and-adapt AI policy template

Title: Responsible AI Acceptable-Use Policy
Owner: [role or team]
Effective date: [date]
Review date: [date]

1. Purpose
This policy defines how workers may evaluate, purchase, build, and use AI
systems for [organization]. It applies to employees, contractors, and vendors
who use organizational data or act on the organization's behalf.

2. Approved uses
Workers may use tools on the approved-tool register for [listed low-risk uses].
They must follow the data, review, attribution, and recordkeeping rules below.

3. Uses requiring approval
Approval from [roles] is required before AI is used for decisions or outputs
that affect employment, eligibility, safety, legal rights, finances, customers,
public claims, regulated records, or production systems.

4. Prohibited uses
Do not use unapproved tools, bypass access controls, impersonate a person,
fabricate evidence, make a consequential final decision without an accountable
human, or submit data whose classification the tool is not approved to process.

5. Data handling
Follow the existing data-classification policy. Do not enter credentials,
restricted personal data, customer confidential data, source code, contracts,
or unpublished financial information unless the exact tool and use are approved.

6. Human review
The named owner must verify material facts, sources, calculations, rights,
bias risks, and required disclosures before the output is used or shared.

7. Transparency and attribution
Disclose material AI assistance when required by law, contract, platform rule,
professional standard, or organizational practice. Do not cite an AI response
as the source of a factual claim.

8. Procurement and development
Before adoption, document purpose, owner, data flows, vendors, retention,
training use, security controls, failure modes, evaluation, and exit plan.

9. Records and incidents
Preserve the records required for the use case. Report unexpected disclosure,
harmful output, policy bypass, material inaccuracy, or unauthorized action to
[incident channel] within [time]. Do not conceal or silently correct an incident.

10. Exceptions and enforcement
[role] may approve a time-limited written exception with scope, controls, owner,
and expiry. Violations are handled under existing security and conduct policies.

Add a risk-tier table

Risk depends on context, not the label on a tool. Summarizing a public article and screening job candidates can use similar technology while requiring very different controls.

Define the terms employees will use

A policy fails when ordinary work cannot be mapped to its vocabulary. Add short definitions for:

• AI system: software that generates, classifies, predicts, recommends, extracts, or takes action using machine-learning or generative models;
• approved tool: a named service, plan, configuration, and integration approved for stated uses and data classes;
• AI-assisted output: work materially drafted, transformed, analyzed, or recommended by an AI system;
• consequential decision: a decision affecting employment, access, eligibility, rights, safety, finances, customers, or another significant interest;
• accountable owner: the person who has authority and responsibility for the final use or action;
• restricted data: information whose policy, contractual, legal, or security classification limits processing;
• human review: an actual inspection against stated criteria, not a person clicking approve without access to evidence;
• incident: unexpected disclosure, harmful or discriminatory output, material inaccuracy, control bypass, unauthorized action, or other policy breach.

Align these definitions with existing company language. Do not create a separate meaning for confidential data or incident severity if security and privacy programs already define them.

Assign roles and decisions

Name a decision owner, not merely a group, for each approval path. A cross-functional committee can advise, but employees need to know who can say yes, no, or not yet.

Maintain an approved-tool register

Keep fast-changing product details outside the core policy in a controlled register:

Approval should attach to a configuration and use, not a brand name. A consumer account, enterprise account, API deployment, browser extension, and connected action feature can have different data handling and permissions.

Connect data classification to tool use

Adapt a matrix to the organization's existing classifications:

Include derived data. A prompt can reveal a customer relationship even when the attached document is removed. File names, summaries, embeddings, logs, tool arguments, and screenshots may inherit the source classification.

Add rules for actions and agents

Generative tools increasingly move from drafting to acting. Extend the policy beyond content:

An AI system may take an external or system-of-record action only when:
- the action is part of an approved use case;
- credentials are scoped to the minimum permissions;
- allowed targets, amounts, frequencies, and time windows are constrained;
- the system validates inputs and prevents duplicate execution;
- consequential actions require approval by the authorized role;
- the action and approval are logged;
- a tested stop, revocation, and recovery path exists.

Treat sending, publishing, purchasing, deleting, granting access, changing records, and contacting people as separate permissions. Permission to draft an email is not permission to send it.

Create a high-risk use assessment

Before a high-risk use is approved, require a short record:

Business purpose and expected benefit:
Affected people and decision:
Accountable owner:
AI role and human authority:
Inputs, outputs, data classes, and data flow:
Vendor, model, integrations, and versions:
Known limitations and foreseeable misuse:
Accuracy, fairness, accessibility, privacy, and security evaluations:
Notice, explanation, contest, and correction mechanisms:
Monitoring and incident thresholds:
Records and retention:
Rollback and alternative process:
Approvers, conditions, expiry, and next review:

Approval is not permanent. Scope it to the tested workflow, population, data, and configuration. Reassess material changes such as a new model, action capability, integration, population, or decision purpose.

Handle exceptions without creating loopholes

An exception should state the request, business reason, unavailable alternative, data, users, controls, owner, start, expiry, and approvers. Time-limit it and prevent silent renewal. Emergency access should receive retrospective review under an established process.

Do not approve an exception merely because work has already started or a vendor trial is ending. That rewards bypassing the policy. Track repeated requests: they may show that the approved-tool set is inadequate or that the rule is unclear.

Add an AI incident playbook

1. Stop or isolate the affected workflow when safe.
2. Preserve relevant inputs, outputs, versions, actions, and access records.
3. Notify the incident owner through the named channel.
4. Identify affected people, systems, records, and downstream recipients.
5. Contain access, revoke credentials, or withdraw output as appropriate.
6. Engage security, privacy, legal, HR, communications, or business owners.
7. Correct the record and notify affected parties when required.
8. Document cause, control gaps, and corrective action.
9. Add the failure to training, evaluation, or monitoring.
10. Reauthorize the workflow before restart when risk is material.

The AI policy should reference the existing incident program instead of inventing a competing severity scale. What changes is the evidence to preserve: model and prompt versions, source context, tool calls, approvals, and generated artifacts.

Implementation checklist

1. Inventory real AI use, including free browser tools and embedded features.
2. Align the policy with existing security, privacy, records, procurement, and conduct rules.
3. Publish an approved-tool register with permitted data classes and use cases.
4. Give workers a fast path for questions and new-tool requests.
5. Train with realistic allowed, approval-required, and prohibited examples.
6. Record exceptions with owners and expiry dates.
7. Review incidents, vendor changes, and high-risk use cases every quarter.

Do not rely on an annual acknowledgment alone. The policy becomes useful when it appears in procurement, onboarding, workflow design, and review checklists.

Train with decisions, not definitions

Give employees short scenarios:

• Can a salesperson paste a customer contract into a free assistant to summarize renewal dates?
• Can a marketer generate a product comparison from current official sources?
• Can a manager ask AI to rank employees for promotion?
• Can a developer submit a production error log that may contain credentials?
• Can an assistant draft a meeting summary and automatically assign tasks?

For each scenario, ask which tool, data, reviewer, action, and record are involved. Training is successful when employees choose the right path and know where to ask, not when they recall a definition.

Add policy reminders where decisions occur: procurement forms, browser access, data-classification labels, workflow templates, publishing checklists, code review, and incident intake.

Measure whether the policy works

Useful signals include:

• percentage of active AI tools recorded and owned;
• approval turnaround time by risk tier;
• percentage of high-risk uses with current assessments;
• unapproved-tool and restricted-data events;
• employee questions by unclear policy area;
• exceptions by reason, owner, and age;
• incidents, near misses, correction time, and repeated causes;
• evaluation and monitoring coverage for approved high-risk workflows;
• completion of scenario-based training.

Do not set a target of zero questions. Questions can indicate that people are pausing before risk. A healthier goal is fast, consistent resolution and fewer repeated ambiguities.

Policy maintenance calendar

Publish a change log. For material changes, identify which existing use cases must be reassessed rather than assuming the new rule applies cleanly without implementation work.

For concrete scenarios, see the AI usage policy examples. For technical threat boundaries, pair the policy with the AI agent security checklist.

FAQ

Can a small company use this AI policy template?

Yes, but keep ownership explicit. A short policy with one approved-tool list, clear data rules, and a reachable decision owner is better than a long policy nobody can apply.

Should the policy ban confidential data in every AI tool?

It should ban confidential data in unapproved tools. Approved enterprise systems may support specific data classes under contracts and controls, but those permissions should be documented by tool and use case.

Who should own the AI policy?

One accountable executive should own it, with legal, privacy, security, HR, procurement, and business input. A committee without a decision owner creates delay and ambiguity.

How often should an AI policy be updated?

Review it on a fixed schedule and whenever a material tool, law, contract, incident, or high-risk use changes. Keep the approved-tool register easier to update than the core policy.

Is this template legal advice?

No. It is an operating starting point. Qualified counsel and relevant specialists must adapt it to applicable laws, contracts, employment practices, regulated activities, and jurisdictions.

Should employees disclose every use of AI?

Disclosure should follow applicable law, contract, professional duty, platform rule, and organizational practice. The policy should define when internal records and external notices are required instead of using one vague universal rule.

Can a company approve an entire category of AI tools?

Broad category approval is risky because plans, configurations, integrations, retention, and action permissions differ. Approve named services and configurations for stated data and uses, with a review date.

Use Ottermind to turn the approved policy, tool register, and review rules into a reusable project context before teams start producing deliverables.