AI Acceptable Use Policy Template

§1Purpose and scope

Start by naming the business reason for the policy and everyone it covers. Include employees, contractors, temporary staff, and anyone using company information. Cover free accounts and browser extensions as well as software the company buys. That closes the familiar loophole of an employee claiming a consumer chatbot was outside the software policy.

Keep the purpose practical: enable useful experimentation while protecting confidential information, customers, colleagues, and the quality of the work. Do not promise that AI use will be risk-free. Your goal is controlled use with clear accountability.

Sample languageThis policy applies to all employees, contractors, and temporary workers who use an AI system for company work, whether the system is company-provided, free, personally purchased, or embedded in another product.

§2Definitions people can use

Define AI broadly enough to include generative chat, image and coding tools, transcription, automated scoring, and AI features added to familiar products. Then define a few terms your controls rely on: approved tool, confidential information, personal information, high-impact decision, and output.

Avoid a copied glossary full of technical distinctions. If a manager cannot use a definition to decide whether a meeting recorder is covered, the definition is not doing its job.

Sample languageAI system means software that generates, predicts, recommends, classifies, or makes decisions using machine-learning or similar techniques, including AI features within other software.

§3Approved tools and accounts

List approved tools in a separate register so the policy does not need a rewrite every month. For each tool, record its owner, approved uses, account type, data settings, and review date. Require company-managed accounts when they provide contractual privacy or administrative controls.

State what happens when somebody wants a new tool: a short request, an owner, and a review against consistent questions. A policy that only says “use approved tools” without an approval path encourages people to work around it.

Sample languageUse AI for company work only through tools recorded in the approved AI register and within the approved use cases shown there. Request review before creating an account for a new tool.

§4Prohibited data

Name the information that must not enter an AI system unless a documented exception permits it. Typical categories include client confidential material, credentials, payment information, health information, government identifiers, unpublished financial results, personnel records, source code under restriction, and legally privileged communications.

Tie the rule to contracts and the tool’s settings. Some enterprise services do not train on customer input; that may reduce one risk but does not erase confidentiality, retention, access, residency, or breach concerns.

Sample languageDo not enter restricted, confidential, personal, privileged, or client-provided information into an AI system unless the system and use case are specifically approved for that category of data.

§5Human review and accountability

Assign responsibility to the person using the output. Review must be proportionate: a brainstorm needs less scrutiny than tax guidance, production code, a clinical note, or a recommendation affecting a person. Require verification of factual claims, calculations, citations, permissions, bias, and fit for purpose where relevant.

“A human was in the loop” is not enough. The reviewer needs time, subject knowledge, authority to reject the answer, and access to the underlying evidence.

Sample languageThe person who uses or shares AI-assisted work remains responsible for it. Verify material facts, sources, calculations, rights, safety, and suitability before relying on the output.

§6Disclosure and records

Say when AI assistance must be disclosed. Internal drafting may not need a label; client deliverables might, especially when a contract or professional rule requires disclosure. Material that impersonates a real person or could mislead an audience needs particularly clear treatment.

Also decide what records matter. For consequential work, keep the prompt or input source, model or product, output, reviewer, date, and final decision. Do not retain sensitive prompts by default merely to prove that a process exists.

Sample languageDisclose material AI use when required by law, contract, professional duty, client instruction, or when a reasonable reader could otherwise be misled about how the work was produced.

§7Procurement and vendor review

Before approving a tool, identify what it receives, where that data goes, whether it trains a model, who can access it, how long it is retained, and how it can be deleted. Review security claims, subprocessors, incident notice, intellectual-property terms, administrative controls, and exit options.

Give reviewers a benchmark, not just questions. “We use encryption” is incomplete without scope. “We never train on your business data, contractually; administrators can set retention; and deletion propagates to backups within a stated period” is testable.

Sample languageThe policy owner must review an AI vendor’s data use, retention, security, subprocessors, model-training terms, intellectual-property terms, incident process, and deletion options before approval.

§8Security and access

Apply ordinary security controls: single sign-on where available, multifactor authentication, least privilege, approved sharing settings, and prompt incident reporting. Disable public link sharing unless there is a real need. Remove access when a person leaves or a pilot ends.

Treat AI agents and connectors as integrations, not clever chat features. A tool connected to email, files, source control, or customer records can expose much more than a pasted prompt.

Sample languageUse company authentication and approved access settings. Do not connect an AI system to company repositories, mailboxes, calendars, or customer systems without a documented access review.

§9Legal and contractual compliance

Make compliance a routing rule rather than a vague promise. Users must follow privacy, employment, consumer-protection, copyright, discrimination, sector, and professional obligations, plus client contracts. Identify who handles a doubtful use.

In the United States, obligations can come from state privacy and automated-decision laws, sector rules, and unfair-practices enforcement. In Canada, PIPEDA or provincial privacy laws govern many private-sector uses; Quebec’s Law 25 adds transparency and assessment duties in relevant cases. In the EU, deployers of certain high-risk systems have specific duties under the AI Act, alongside the GDPR. Applicability depends on the facts, so obtain local advice.

Sample languageDo not use AI in a way that violates applicable law, professional obligations, intellectual-property rights, employment rules, privacy requirements, or a customer or supplier contract.

§10High-impact and prohibited uses

Escalate uses that materially affect employment, credit, insurance, housing, education, healthcare, legal rights, or access to services. A small company may never operate a regulated high-risk system, but it can still buy one or rely on one without recognizing the consequence.

You may prohibit fully automated final decisions about people and require legal review before predictive scoring, emotion inference, biometric categorization, or similar sensitive uses.

Sample languageDo not allow an AI system to make the final decision on hiring, termination, promotion, eligibility, clinical care, credit, insurance, legal rights, or access to an essential service.

§11Violations and incident response

Use an amnesty-minded reporting path. You want early notice when somebody pasted the wrong file or discovered an unexpected data flow. Immediate reporting should not be treated as proof of bad intent.

Describe containment: stop use, preserve necessary facts, notify security or the policy owner, assess contractual and legal notification, and document remediation. Reserve discipline for reckless, repeated, or deliberate violations under existing processes.

Sample languageReport suspected disclosure, harmful output, unexpected system behavior, or policy breaches promptly. Good-faith reporting and cooperation will be considered in the response.

§12Ownership and review cadence

Name one policy owner and a backup. The owner maintains the tool register, handles exceptions, coordinates incidents, and reports material changes. Managers remain responsible for uses in their teams.

Review at least annually and sooner after a material incident, legal change, contract requirement, or major vendor change. A quarterly check of the tool register is often more useful than rewriting the full policy.

Sample languageThe policy owner will review this policy at least annually and the approved AI register quarterly, and after a material incident, legal change, or significant vendor change.

§13Turn the template into a working control

Adopt the policy with a short inventory first. Choose approved tools, close obvious data risks, publish a one-page employee summary, and give people somewhere to ask questions. Then review vendors and higher-risk uses in order of consequence.

Link the policy to the right-sized implementation guide in my AI policy for small business article, use the shadow AI audit to build your inventory, and use the RFP guide to describe the resulting controls to clients. The words matter. The operating evidence matters more.

§14Frequently asked questions