How to Write an AI Policy: Free Workplace Template

An AI policy earns its keep when an employee can use it to make a decision. Which tools are allowed? What data may go into them? Which outputs need review? Who approves a new use case, and what happens when something goes wrong? A statement about using AI "responsibly" fails if nobody can apply it on Monday morning.

This guide shows how to write a workplace AI acceptable-use and governance policy, then provides a template you can copy. It is designed for organizations that buy or use AI tools, including generative assistants, embedded AI features, APIs, and agents. It is a starting point, not legal advice. Adapt it to your jurisdictions, sector rules, contracts, labor arrangements, security program, and data classifications before adoption.

Policy in one sentence: people may use approved AI for approved purposes, with permitted data and controls proportionate to the consequence of an error.

Start with decisions, not abstract principles

The policy should connect to existing security, privacy, procurement, records, employment, and professional rules. Managers and specialists remain accountable for work they approve.

The NIST AI Risk Management Framework organizes the work as Govern, Map, Measure, and Manage. It is voluntary, sector-neutral guidance, not a compliance certificate, and NIST notes that version 1.0 is being revised. The durable lesson is to define ownership, understand the context of use, test relevant risks, and manage the system throughout its life.

Keep two documents separate. The policy contains stable rules and accountability. An approved-tool register contains products, models, permitted features, data classes, owners, and expiry dates. That register can change without rewriting the whole policy.

How to write the policy in seven steps

1. Inventory real use, including shadow AI

Ask teams which AI features they use, the task, input data, output destination, and reviewer. Include AI embedded in office suites, design tools, customer systems, code editors, browsers, and meeting tools. Procurement records will miss free accounts and new features.

Record a use case, not just a product name. One product may be acceptable for public brainstorming but unsuitable for customer records. If the tool list is already messy, first audit the AI and SaaS stack, then map each tool to an owner and purpose.

2. Classify uses by consequence

Create internal tiers that determine the approval and evidence required. State clearly that these are company categories, not legal classifications.

Context determines risk. Summarizing a public report is not equivalent to ranking applicants with the same model. Reassess after a material change in purpose, data, integration, affected group, or autonomy.

3. Assign owners and approval authority

Name one policy owner and one business owner for each approved use case. Define who approves tools, exceptions, high-impact uses, and deployment. Give security, privacy, legal, HR, procurement, records, and accessibility specialists authority in their domains. An AI committee needs defined membership, authority, records, and escalation.

4. Write rules employees can apply

Use examples and decision tests. "Do not paste restricted data into an unapproved tool" is actionable. "Protect privacy" is not. Define sensitive data by reference to the organization's classification standard and include credentials, customer information, personal data, health or financial information, confidential contracts, source code, unreleased strategy, and privileged material where relevant.

The reviewer must be competent, see enough context, check authoritative sources, have time to review, and have authority to reject or stop the result. A ceremonial click is not oversight.

5. Put vendors and integrations through a gate

The NIST Generative AI Profile recommends provider lists, acquisition diligence, contract controls, monitoring, and incident plans. Review submitted-data use, training, retention, hosting, subprocessors, access, logs, security evidence, model changes, intellectual property terms, incident notice, continuity, and exit.

Recheck material integrations and agent permissions. An assistant that only drafts text presents a different risk from an agent that can send email, change records, run code, or spend money. Give tools the least access required and require confirmation before consequential external actions.

6. Define records, incidents, and exceptions

For controlled and high-impact uses, retain enough evidence to reconstruct the decision: owner, purpose, system version when available, data class, approvals, tests, reviewer, exceptions, and incidents. Follow the records schedule and avoid duplicating sensitive prompts.

Define an AI incident broadly enough to catch confidential data exposure, a discriminatory recommendation, a materially false public output, an unsafe action, a compromised credential, an intellectual property complaint, a vendor breach, or an unexpected autonomous action. Give staff one reporting channel and permission to stop a workflow without retaliation. Security, privacy, legal, HR, or another authorized team should decide any external notification required by applicable law or contract.

7. Train, test, and review

Train people on data classification, approved accounts, verification, bias, accessibility, disclosure, incidents, and approval triggers. Include in-scope contractors. Test realistic scenarios, not attendance.

Review the policy on a stated cadence and after a trigger such as a new law, serious incident, major vendor change, new high-impact use, merger, or material change in data processing. Review the tool register more often than the policy because product terms and features move faster.

Set the legal boundary correctly

No template ensures compliance everywhere. Duties can arise from privacy, employment, consumer, intellectual property, sector, contract, and collective bargaining rules.

• European Union: Article 4 of the EU AI Act requires providers and deployers to take measures for sufficient AI literacy, considering people's knowledge, experience, training, and the context of use. The European Commission's current implementation timeline says that obligation has applied since February 2, 2025. The timeline has exceptions and ongoing adjustments, so confirm the current legal position for each system and role.
• Personal data: the UK Information Commissioner's AI and data protection guidance organizes the work around accountability, transparency, lawfulness, accuracy, fairness, security, data minimization, and individual rights. Other jurisdictions have their own tests and authorities.
• Employment: the US Equal Employment Opportunity Commission warns that AI can discriminate and provides guidance on applying federal equal employment opportunity law to employment technologies. Review the EEOC AI resource page and relevant state or local rules before using AI in hiring or workforce decisions.
• Copyright: rights in inputs, outputs, brands, likenesses, and training material can differ by country and facts. The US Copyright Office AI study is one official source on copyrightability, digital replicas, and generative AI training. A policy should never assume that generated material is automatically original, non-infringing, licensed, or protectable.

For a high-impact or regulated use, obtain qualified legal and domain review before launch. Human review is a control, but it does not cure an unlawful purpose, defective data, discrimination, inadequate notice, or a vendor contract that does not permit the planned use.

Copyable workplace AI policy template

Replace every bracketed field, remove inapplicable examples, attach the referenced registers and procedures, and obtain authorized approval.

Document control

Policy owner: [role or team]
Executive sponsor: [role]
Effective date: [date]
Version: [number]
Next scheduled review: [date]
Questions and incidents: [channel]

1. Purpose and scope

This policy governs the acquisition, development, configuration, and use of artificial intelligence on behalf of [Organization]. It applies to [employees, contractors, temporary workers, and other in-scope people] using organization-managed or personal devices and accounts for organization work. It covers standalone AI tools, AI features embedded in other products, models, APIs, automated decision systems, and AI agents.

This policy supplements our security, privacy, acceptable-use, records, intellectual property, procurement, employment, and disciplinary policies. Where requirements conflict, stop and contact [policy owner or legal contact].

2. Definitions and internal risk tiers

AI system means a machine-based system that produces predictions, recommendations, decisions, content, or other outputs from inputs. Generative AI creates content such as text, images, audio, video, or code. High-impact use is our internal label for a use that may materially affect a person's rights, safety, livelihood, or access to an important service. It is not a substitute for any legal classification.

Use cases are classified as [low, controlled, high-impact, or prohibited]. [Policy owner] maintains the criteria and may raise a classification when risk or uncertainty warrants it.

3. Approved tools and accounts

People may use AI for organization work only through tools, features, accounts, purposes, and data classes listed in the approved-tool register. Personal accounts, unapproved browser extensions, unapproved plugins, and hidden AI features must not be used for organization data. Approval for one purpose does not authorize every feature or integration.

4. Acceptable use

Permitted use must support a legitimate business purpose, stay within the approved use case, use the minimum necessary data, and receive review proportionate to the consequence of error. Examples may include [brainstorming with public information, summarizing approved documents, drafting non-final text, or assisting with code in an isolated environment]. The person submitting or approving work remains accountable for the result.

5. Prohibited use and sensitive data

Do not use AI to violate a law or contract, discriminate unlawfully, deceive people, impersonate a person without authorization, create non-consensual intimate content, bypass security, conceal misconduct, or make a final high-impact decision without approved controls. Do not enter passwords, access tokens, restricted data, privileged material, trade secrets, or [other prohibited classes] into an AI system unless the specific use and environment have written approval.

Do not rely on generated citations, calculations, code, or factual claims without verification appropriate to the use.

6. Human review and high-impact decisions

High-impact uses require a documented impact assessment, legal and domain review, representative testing, an accountable business owner, monitoring, an incident route, and an appeal or reconsideration process where appropriate. The human reviewer must be trained, understand system limits, access relevant evidence, detect automation bias, and have authority to override or stop the output. AI must not be the sole basis for an adverse employment, credit, housing, education, health, safety, or legal decision unless [authorized body] has confirmed that the use and safeguards are lawful and approved.

7. Security

Use organization authentication, multi-factor authentication, least privilege, approved devices, and approved storage. Do not place secrets in prompts or generated code. Treat external content and tool instructions as untrusted. Test code and automated actions in an appropriate isolated environment. Agents with write access or external actions must have scoped permissions, logs, spending or action limits where relevant, and human confirmation for consequential steps.

8. Privacy and personal data

Personal data may be processed only for an approved purpose with a documented lawful basis or other applicable authority, appropriate notice, data minimization, retention and deletion rules, access controls, and support for individual rights. Complete [privacy impact assessment or equivalent] before uses that may create high risk to people. Do not infer sensitive traits or reuse personal data for a new purpose without approval.

9. Intellectual property and licensing

Use only inputs the organization has the right and authority to use. Follow licenses, attribution duties, confidentiality terms, brand rules, and restrictions on third-party content. Review vendor terms for input, output, and training rights. Generated output must be checked for copied or confusingly similar material and edited by a responsible person. Record sources and licenses when the work requires provenance. Escalate ownership, infringement, likeness, or trademark uncertainty to [legal or IP contact].

10. Transparency and disclosure

Disclose material AI use when required by law, contract, professional duty, customer commitment, platform rule, or when omission could mislead a reasonable person. Clearly label synthetic media and automated interactions where required. Customer-facing systems must provide [notice, explanation, human contact, and challenge route] appropriate to the use. Do not claim that a person created, reviewed, or approved work when that is untrue.

11. Records and monitoring

For controlled and high-impact uses, keep [use-case owner, purpose, tool and version when available, data class, approvals, assessment, test results, reviewer, material output or decision record, exceptions, and incidents] for [retention period or records schedule]. Monitor agreed quality, safety, fairness, security, privacy, accessibility, and reliability measures. Logging must not collect more sensitive data than necessary.

12. Incident reporting

Immediately stop or contain unsafe use when feasible and report suspected confidential data exposure, harmful or discriminatory output, false public content, unauthorized action, credential compromise, intellectual property complaint, vendor breach, or control failure through [channel]. Preserve relevant evidence without copying sensitive data into new locations. [Response owner] will coordinate triage, remediation, required notification, and lessons learned.

13. Vendor assessment

Before approval, [procurement or risk owner] will review the intended use, data flows, training and retention terms, subprocessors, hosting, access controls, logs, security evidence, model changes, intellectual property terms, output restrictions, accessibility, incident notice, service continuity, audit rights, and exit plan. Material changes require reassessment. Critical uses require an alternative process if the service fails or changes unexpectedly.

14. Exceptions

Exceptions require a written request stating the business need, duration, data involved, risks, compensating controls, owner, and exit plan. [Approver roles] may approve, reject, limit, or revoke an exception. Exceptions expire on [date or maximum period] and do not create a precedent.

15. Ownership, training, and enforcement

[Policy owner] maintains this policy and the use-case inventory. [Security, privacy, legal, HR, procurement, records, and business owners] perform reviews within their authority. Managers ensure their teams complete role-based training and use approved systems. Everyone in scope must report incidents and cooperate with reviews. Violations are handled under [existing disciplinary or contract process], considering intent, impact, and applicable worker rights.

16. Review and change control

[Policy owner] reviews this policy at least [annually or chosen cadence] and after material legal, technical, vendor, organizational, or incident changes. The approved-tool register is reviewed [monthly or quarterly] and each high-impact use is reassessed [cadence] and before a material change. Changes require approval from [roles] and are communicated through [channel].

Implement the policy in 30 days

1. Week 1: appoint the owner, open one reporting channel, inventory tools and use cases, and pause clearly prohibited activity.
2. Week 2: classify uses, publish a temporary approved-tool register, and send high-impact or sensitive-data cases for specialist review.
3. Week 3: run vendor checks, test representative workflows, write examples, and train managers plus frequent users.
4. Week 4: approve the policy, communicate it, collect acknowledgements if appropriate, set review dates, and start an exception and incident log.

Track controls in operation: known tools with current owners and reviews, role-based training, overdue assessments, expired exceptions, incident type and containment time, and high-impact uses with current tests and named reviewers. Fewer incidents are not success if reporting also falls.

Final check before approval

• Can an employee tell whether a tool, feature, account, purpose, and data class are approved?
• Are prohibited uses and high-impact approval gates explicit?
• Does human review include competence, evidence, time, and authority?
• Are security, privacy, intellectual property, transparency, records, vendors, incidents, and exceptions covered?
• Does every decision have a named owner and escalation route?
• Are training, monitoring, review dates, and change triggers assigned?
• Has qualified counsel checked the jurisdictions and regulated uses that apply?

The finished policy should be short enough to use and specific enough to enforce. Put detailed tool approvals and procedures in maintained attachments, then test the rules against real scenarios. If people cannot decide what to do with a customer file, an AI-generated citation, or an agent asking for write access, the policy still needs work.