How to write an AI acceptable use policy for your small business

If you have already accepted that your employees are using AI at work – sanctioned or not – the next concrete artifact is an AI acceptable use policy. This is the document staff read, sign, and refer back to. It is what auditors, insurers, clients running security questionnaires, and regulators ask for when they want to know how your business governs AI use. Most small businesses do not have one yet. That is the gap this article helps close.

This is a practical guide, not a legal template. It explains what an AI acceptable use policy should cover, how to make it specific enough to be enforceable without making it long enough to be ignored, how to communicate it so staff actually follow it, how often to review it, and how it fits alongside the cybersecurity, IT, and BYOD policies you already have (or should). At the end there is a sample policy outline you can adapt – structured, not finished, so your business adapts it to your stack and your risk profile.

It is written for SMB owners, operations managers, HR directors, and the in-house IT generalists who get handed this. If you are also working through the broader picture, the shadow AI wake-up call and the parent cybersecurity policy sit upstream of this work.

Short answer

An AI acceptable use policy is a one-to-three-page document that names approved AI tools, prohibits specific use cases (regulated data in consumer AI, paste-the-customer-list-into-ChatGPT, AI-generated content presented as personally authored where it matters), classifies your data into tiers and maps each tier to an allowed AI handling rule, requires disclosure where AI was used in a way that affects clients or work product, defines consequences for violations, names an owner (usually IT or operations), and is reviewed at least twice a year because the AI landscape moves that fast. The fastest workable version is one page, written in plain language, communicated in a 20-minute staff conversation, and signed during onboarding. The mistake to avoid is writing a five-page document that no one reads. The second mistake is publishing the policy and never referring to it again.

AI acceptable use policy at a glance

Question	Short answer
Who needs one?	Every business with employees, contractors, or third parties using AI on company data or work product
How long should it be?	1-3 pages. Longer is not better. Specific and short beats vague and exhaustive.
Who owns it?	IT or operations as primary; HR co-owns communication and enforcement; legal reviews if regulated
Who signs it?	Every employee at hire, plus annually or when the policy materially changes
How often is it reviewed?	At least twice a year – quarterly if you are in a regulated vertical or AI-heavy industry
Does it need to be a legal document?	No. It needs to be enforceable, specific, and in plain language. Legal review helps but does not need to write it.
Where does it sit?	Alongside the cybersecurity policy, IT policy, and BYOD policy. Cross-reference, do not duplicate.
What is the most common mistake?	Publishing it once and never communicating, training, or updating it
How is it enforced?	Through manager conversations, technical controls where possible, audit log review, and a documented escalation path
How long to write the first version?	A working draft takes a few hours. Stakeholder review and staff communication add 1-2 weeks.

What an AI acceptable use policy actually has to do

The policy has four jobs. If it does these four things, it is doing its work. If it does anything beyond these, it is probably overweight.

Job 1: tell staff what is allowed. Approved tools, approved use cases, approved data categories. Most of the value of the policy is here. Employees are not trying to find loopholes; they are trying to do their jobs. A short list of approved AI tools paired with examples of approved use (“yes you can use Copilot to draft an email; yes you can use ChatGPT Team to summarize a public meeting transcript”) removes 80% of the shadow AI problem on day one.

Job 2: tell staff what is forbidden. Specific prohibited use cases, specific data categories that must never enter any AI tool, specific tools that are not approved. Vague prohibitions (“do not misuse AI”) accomplish nothing. Specific prohibitions (“do not paste customer payment information, employee SSNs, or PHI into any AI tool, sanctioned or not”) accomplish a lot.

Job 3: tell staff what to do when something goes wrong. If a staff member pastes something they should not have, they need a clear path to report it – without fear of immediate punishment. The policy that punishes mistake-reporting first is the policy that produces undisclosed incidents that show up much worse later. The reporting clause matters as much as the prohibition clause.

Job 4: tell staff what the consequences are. Vague consequences (may result in disciplinary action) are not deterrent enough. Specific consequences (“first offense: documented coaching conversation; repeat offense: written warning; egregious or repeated regulated-data leak: termination”) signal that the business takes this seriously and treats staff as adults.

A policy that does these four jobs in three pages or fewer is doing more than a policy that buries them under twenty pages of preamble.

The components every AI acceptable use policy should have

These are the sections to include. Use them as headings in your draft. The sample outline at the end of this article walks through them in order.

1. Scope and applicability

State who the policy covers (all employees, contractors, temporary workers, anyone with access to company data) and what activities (any use of AI tools that touches company data, company communication, client deliverables, or company systems – including AI features baked into approved SaaS tools, AI-powered browser extensions, and AI use on personal devices for work tasks). Explicitly include personal-device use; this is where most shadow AI lives.

2. Definitions

Short. Two or three lines per term. Define “AI tool” (any service that uses machine learning to generate or transform content, including but not limited to large language models, image generators, code assistants, and AI-enhanced features of existing software), define “company data” (anything created in the course of work for the business or its clients), and define “sensitive data” by reference to your data classification rule (next section). Do not get fancy. Lawyer-grade definitions belong in legal contracts, not in policies meant to be read by staff.

3. Data classification

This is the spine of the policy. If you have a data classification framework already, reference it. If you do not, the simplest workable version is three tiers:

• Public/General. Information that could be shared externally without harm – marketing copy already published, product documentation, public website content. Safe in any AI tool, including free consumer ones, subject to your prohibited-tools list.
• Internal. Information meant to stay within the business but not regulated or contractually restricted – internal process documents, non-sensitive operational data, draft material that has not been client- or regulator-facing. Safe in approved AI tools with enterprise data protection terms in place. Not safe in free consumer tools.
• Sensitive/Regulated. Information that is regulated (PHI, PII, payment data, regulated financial data) or contractually restricted (client data under NDA, source code, confidential strategy, M&A material). Safe only in AI tools with enterprise data protection terms AND a contract (BAA where required) that covers the specific data type. Never in free or unapproved tools.

Three tiers is the floor. Some businesses use four. More than four and staff stop being able to remember the rule, which means the rule does not work.

4. Approved AI tools list

Name the specific tools that are approved, with the specific tier of each tool where relevant. For a typical M365-based SMB, this might look like:

• Microsoft Copilot for Microsoft 365 (with appropriate licensing that includes enterprise data protection). Approved for internal and sensitive data. Approved use cases: drafting documents, summarizing meetings and emails, content generation, code assistance for staff with dev responsibilities. Tenant must be hardened first (see Microsoft 365 security hardening for small business).
• ChatGPT Team or Enterprise (paid, with the no-training-on-customer-data terms). Approved for internal and sensitive data. Approved use cases: drafting, summarization, research, analysis.
• Claude for Work (paid). Same scope as ChatGPT Team.
• GitHub Copilot Business (paid, with the no-code-retention terms). Approved for engineering use only.
• AI features in approved SaaS (specific list – Zoom AI Companion, Otter.ai Business, Notion AI, etc., named individually after security review of each). Approved per-tool basis.

For some businesses, free consumer AI tools may also be on an approved-for-public-data-only list – useful for staff to brainstorm, summarize a public news article, or learn something. Be explicit if they are, and explicit about what data they are not approved for. If you are not comfortable allowing free consumer AI at all, say that too.

5. Prohibited use cases

Specific, named, and explained briefly. Examples:

• Pasting any sensitive or regulated data into any AI tool that is not on the approved list.
• Pasting any sensitive or regulated data into any free consumer AI tool, regardless of vendor.
• Using AI to generate content that misrepresents human authorship in contexts where that matters (signing AI-generated text as personally authored in client communications, attesting that a deliverable is the unaided work of a specific person when AI assisted, attestations where a regulator or contract specifies human authorship).
• Using AI to make consequential decisions about people (hiring, firing, promotion, discipline, compensation) without human review and documented justification.
• Using AI to generate or transform content that could violate copyright, contractual confidentiality, or third-party data rights.
• Using AI to circumvent existing security controls (asking AI to write code that bypasses MFA, to summarize log data that an employee should not have direct access to, etc.).
• Installing AI-powered browser extensions or applications on company-managed devices without IT approval.
• Using AI on regulated data (PHI, payment card data, regulated financial data, EU resident personal data) without confirming that the tool has the required contractual protections in place (BAA for HIPAA, etc.).

6. Disclosure requirements

Where AI use should be disclosed, define it clearly. The basic principle: if a reasonable third party would expect a human to have produced the work, or if a contract or regulation requires human work, AI use should be disclosed or avoided. Specific cases to address:

• Client deliverables. If a client has not consented to AI use in their work, and the contract is silent, default to disclosure or to no AI use depending on the sensitivity.
• Code commits. Most engineering teams that allow AI code assistance also require it to be flagged in commits, code reviews, or PR descriptions.
• Internal performance documentation. Performance reviews and disciplinary documentation should disclose if AI drafted or assisted, because those documents may surface in legal disputes.
• Marketing and external content. Most businesses do not require disclosure here, but some industries (journalism, certain creative services) do. Match your industry norms.
• Communication. Emails, Slack messages, customer-facing chat – usually no disclosure required unless the content represents a personal statement that AI should not be authoring (condolences, personal apologies, sensitive HR communication).

7. Personal device and shadow AI

Address personal-device AI use explicitly. The policy should say that the same rules about data classification and prohibited use cases apply on personal devices – sensitive data still cannot go into a consumer AI tool even if the staff member is using their personal laptop on personal time. Cross-reference the BYOD policy for the broader personal-device framing.

8. Reporting and incident response

What to do if a staff member realizes they have shared sensitive data with an AI tool. The policy should:

• Provide a specific reporting channel (IT, a dedicated email, a manager).
• Specify a non-punitive default for mistake reporting. Punishing first offenses where a staff member proactively reports is the policy guaranteed to produce undisclosed incidents.
• Specify what happens after the report: data classification review, regulatory notification assessment (HIPAA, state breach laws), vendor-side data deletion request, technical containment if relevant.
• Specify the timeline. “Report within 24 hours of becoming aware” is a reasonable baseline for SMBs.

9. Consequences and enforcement

Specific consequence ladder. Use language staff can actually predict against:

• First offense, accidental, promptly reported, low-impact data: documented coaching conversation, no formal disciplinary action.
• First offense, accidental, promptly reported, regulated or high-impact data: documented coaching conversation, mandatory retraining, written record in personnel file.
• Repeat offense, or first offense involving deliberate violation: written warning, possible loss of AI tool access privileges, mandatory retraining.
• Egregious violation (deliberate exfiltration, repeated regulated-data leaks despite training): subject to termination and potential legal action.

This is not punishment for its own sake. It is predictability. Staff who know what the consequences are can make informed choices. Staff who do not know default to the assumption that consequences are arbitrary, which produces worse outcomes for everyone.

10. Ownership and review

Name an owner – usually IT or operations as primary, HR as co-owner. Specify a review cadence (at minimum twice per year, quarterly if regulated). Specify what triggers an off-cycle review (a major new AI tool launching in the staff’s daily stack, a vendor terms change, a regulatory development, a near-miss incident in the business). Include a version history at the end of the document so changes are visible.

11. Sign-off

Every employee signs at hire. Every employee re-signs when the policy materially changes. Track sign-offs the same way you track other onboarding paperwork.

What this policy is NOT

A short list of things to keep out of the AI acceptable use policy, because they belong elsewhere or do not belong anywhere.

• Legal disclaimers and indemnification language. That belongs in employment agreements, not in an acceptable use policy. Keep the policy plain-language.
• Detailed technical configuration. “Conditional access rule X is configured to do Y” is operational documentation, not policy. The policy says “AI tools must comply with our access control standards”; the technical doc explains how.
• Training content. The policy is the rule. The training is the explanation. Both are needed; do not collapse them into one document.
• Vendor-by-vendor risk assessment. That work happens once, and the output is the approved tools list. The risk assessment itself does not live in the policy.
• Punishment as the headline. A policy that opens with consequences instead of with what is allowed feels adversarial and produces shadow use. Open with what is allowed; consequences come later in the document.

How to communicate the policy so staff actually follow it

A policy is only as effective as the communication around it. The policy itself is the artifact; the communication is the deployment.

Lead with what is allowed, not what is banned. Staff who hear “we are providing Copilot for everyone” before they hear “do not paste customer data into ChatGPT” are far more likely to follow the rule. Staff who hear only the prohibition default to “this company does not want me to use AI, but I need to be productive” – which is exactly the situation that produced shadow AI in the first place.

Run a single short meeting. Twenty to thirty minutes. Walk through what the policy says, why it exists (use the shadow AI framing – this is not a “you misbehaved” conversation, it is an “AI is here and we want to use it well” conversation), what the approved tools are, what to do if something goes wrong. Take questions live. Do not rely on email alone.

Train on the gray areas. The black-and-white cases (paste customer SSNs into ChatGPT, do not do that) train themselves. The gray cases (can I use Copilot to summarize a Teams meeting where a client said something off the record? Can I ask ChatGPT Team to draft a response to a difficult HR situation that includes my own opinions?) are where staff actually need guidance. Spend most of the training time on the gray cases.

Pair the policy with the tools. Announcing approved AI tools at the same time as the policy makes the policy feel like enablement, not restriction. Announcing only the restriction makes the policy feel like a tax.

Onboard the policy. New hires read and sign during onboarding, the same week they get their laptop and their M365 account. Anchoring the policy at hire is far more effective than retrofitting it onto existing staff a year later.

Refer back to it. When someone asks “can I use AI for X?”, the answer should be “let me check the policy” – and the answer should be findable in the policy. If the question keeps coming up and the policy does not address it, that is a signal to update the policy.

Review cadence and what triggers an update

AI vendor terms change frequently. Models change. Pricing changes. Regulations change. State-level AI transparency laws are being passed quarterly. A policy reviewed once a year is stale within months.

Scheduled review. Twice a year is the baseline. Quarterly for regulated verticals (healthcare, financial services, defense contracting, legal services) and AI-heavy industries (creative services, marketing agencies, software development). Put the review on the calendar; do not rely on memory.

Triggered review. In addition to the scheduled review, certain events should trigger an immediate review:

• A major new AI tool launches that staff are very likely to start using (new Microsoft AI feature, new ChatGPT capability that obviously changes use patterns).
• An approved vendor changes its data protection or training terms.
• A regulator publishes guidance on AI use in your industry.
• A near-miss or actual incident inside your business.
• A cyber insurance renewal asks AI governance questions you cannot answer easily.
• A client security questionnaire surfaces an AI governance gap.

Version history. At the end of the policy, keep a version history. “Version 1.3 – 2026-04-15 – Added Claude for Work to approved tools list, clarified disclosure requirement for code commits. Reviewed by [name].” Makes it obvious when the policy was last touched and what changed. Auditors, insurers, and clients running questionnaires all look at this.

Sample AI acceptable use policy outline

The structure below is a working outline you can adapt to your business. It is not a finished policy. Fill in your specific tools, data definitions, reporting channels, and consequence ladder. Have legal review the final draft if you handle regulated data or want enforceability comfort. Plain language throughout; keep it under three pages if you can.

—

[Company Name] AI Acceptable Use Policy

Effective: [Date]

Version: [X.Y]

Owner: [Role]

Review cadence: [Twice yearly / Quarterly]

1. Purpose

This policy describes how employees and contractors at [Company] may use artificial intelligence (AI) tools in the course of work, what is prohibited, and how to report concerns.

2. Scope

This policy applies to all employees, contractors, and temporary workers who handle company data or work on behalf of the company. It applies to AI use on any device – company-issued or personal – that touches company data, company communication, or company work product.

3. Definitions

• AI tool: Any service or feature that uses machine learning to generate, transform, or analyze content. Includes large language models (ChatGPT, Claude, Copilot, Gemini), image generators, code assistants, AI features built into other SaaS, and AI-powered browser extensions.
• Company data: Any information created, received, or maintained in the course of work for [Company] or its clients.
• Sensitive data: Data classified as Sensitive/Regulated under our data classification framework (Section 4).

4. Data classification

Three tiers:

• Public/General. Already public or intended for public release.
• Internal. Internal to [Company], not regulated or contractually restricted.
• Sensitive/Regulated. Includes [list – e.g., PHI, PII, payment card data, regulated financial data, client data under NDA, source code, M&A material].

5. Approved AI tools

The following tools are approved for the data tiers indicated:

Tool	Public/General	Internal	Sensitive/Regulated
Microsoft Copilot for Microsoft 365 (licensed tier)	Yes	Yes	Yes
ChatGPT Team / Enterprise	Yes	Yes	Yes
Claude for Work	Yes	Yes	Yes
GitHub Copilot Business (engineering only)	Yes	Yes	Yes
AI features in [list of approved SaaS]	Yes	Yes	Per-tool basis
Free consumer AI (ChatGPT free, Gemini free, etc.)	Yes	No	No

Tools not on this list require IT approval before any use.

6. Prohibited use

The following are prohibited regardless of tool:

• Pasting Sensitive/Regulated data into any tool not approved for that tier.
• Using AI to make consequential decisions about people (hiring, firing, promotion, discipline) without human review and documented justification.
• Using AI in violation of copyright, contractual confidentiality, or third-party data rights.
• Using AI to circumvent existing security or compliance controls.
• Installing AI-powered browser extensions or applications on company-managed devices without IT approval.
• Using AI on regulated data without verifying that the contractual protections (BAA, DPA, etc.) required for that data are in place.

7. Disclosure

AI use must be disclosed in the following cases:

• Client deliverables where the contract or client expectation requires human authorship.
• Code commits and pull requests where AI assistance materially shaped the change.
• Performance reviews, disciplinary records, and other personnel documentation.
• Any other case where a reasonable third party would expect human-only work.

8. Personal devices

The data classification and prohibited use rules in this policy apply to AI use on personal devices when the use involves company data. See the BYOD policy for the broader personal-device framework.

9. Reporting

If you become aware that sensitive data may have been shared with an AI tool, report it to [reporting channel] within 24 hours. Reports made in good faith will be assessed on the facts; proactive reporting of mistakes will not result in disciplinary action for the act of reporting.

10. Consequences

Violations are addressed on a graduated basis:

• First offense, accidental, promptly reported, low-impact: Documented coaching conversation.
• First offense, accidental, promptly reported, high-impact or regulated data: Documented coaching, mandatory retraining, personnel file note.
• Repeat offense, or first offense involving deliberate violation: Written warning, possible loss of AI tool access.
• Egregious or repeated violation: Subject to termination and potential legal action.

11. Ownership and review

This policy is owned by [Role]. It is reviewed [twice yearly / quarterly] and may be reviewed off-cycle in response to vendor changes, regulatory developments, or incidents.

12. Acknowledgement

[Employee acknowledgement section – signed at hire and at material updates.]

Version history

• Version 1.0 – [Date] – Initial policy. [Reviewed by name.]

—

That outline is approximately what a workable two- to three-page AI acceptable use policy looks like. Some businesses will want to add an industry-specific section (HIPAA for healthcare, PCI for retail, defense FAR/DFARS clauses for federal contractors). Some will want a separate appendix listing approved use cases by department. Both are reasonable additions. Anything beyond that, and the policy starts losing the property that matters most: people read it.

How the AI acceptable use policy fits with everything else

The AI acceptable use policy does not stand alone. It sits inside a stack of policies that should all reference each other.

• Cybersecurity policy. The parent. Covers passwords, MFA, phishing, incident reporting, acceptable use of company systems generally. The AI policy is an expansion of the acceptable use section.
• IT policy for remote workers. Covers remote work specifics. AI tool installations on remote devices reference back to the AI policy.
• BYOD policy. Covers personal devices. AI use on personal devices references back to the AI policy.
• HR / employee handbook. The AI policy should be referenced in the employee handbook so new hires see it during onboarding.
• Data classification framework. If the company has one, the AI policy uses it. If not, the AI policy is often the first place a classification framework gets written down – that work then propagates outward.
• Contractual obligations. Client contracts, vendor agreements, and NDAs often contain confidentiality clauses that interact with the AI policy. Legal should confirm the AI policy is consistent with existing contractual commitments.

For regulated businesses, the AI policy also has to sit alongside the relevant compliance framework – HIPAA in healthcare (HIPAA cybersecurity requirements covers the baseline), GLBA Safeguards in financial services, CMMC in defense, SOC 2 if you sell into the enterprise. The AI policy does not replace the compliance framework; it is one input into the compliance framework’s evidence trail.

What this looks like to clients, insurers, and auditors

The AI acceptable use policy is increasingly a document that other parties ask to see. Knowing what each audience looks for helps shape the policy.

• Clients running security questionnaires. Want to see that there is a policy, that it covers the categories above, and that staff have signed it. Some clients will ask for the data classification rule, the approved tools list, and the reporting channel by name. Increasingly, client contracts include AI clauses that require the vendor to maintain an AI policy and disclose AI use in deliverables.
• Cyber insurers at renewal. Want to see that AI governance exists. AI-related questions are on most renewal questionnaires now. Answers like “we have an acceptable use policy reviewed twice yearly, an approved tools list, and a data classification rule” affect renewal terms. The cyber insurance for small business baseline already covers what insurers expect.
• Regulators (HIPAA OCR, state AG offices, FTC). Want to see documented governance over data flows. An AI policy that names which AI tools may handle PHI, with corresponding BAAs in place, is the kind of artifact that turns a regulator concern into a documented response.
• Auditors (SOC 2, ISO, internal audit). Want evidence: the policy itself, sign-off records, version history, training records, incident reports. The policy is the artifact; the audit trail around it is the evidence.

The thread running through all of these audiences: they want to know that AI governance is intentional, not accidental. The policy is the artifact that demonstrates intent.

Ten common AI acceptable use policy mistakes

1. Writing five pages when one would do. Length is not depth. Specificity is depth. Long policies do not get read.
2. Leading with prohibitions instead of approvals. A policy that opens with “AI is dangerous” produces shadow AI. A policy that opens with “here are the approved tools” produces compliance.
3. Punishing first-offense reporting. Guarantees that future mistakes go undisclosed. Reporting clauses should be explicitly non-punitive on good-faith reporting.
4. Skipping the data classification. Without a data classification rule, “approved for sensitive data” is meaningless. Staff cannot apply a tier rule they cannot read.
5. Approving tools without confirming the licensing tier. ChatGPT free and ChatGPT Team are different products under different terms. “ChatGPT is approved” without specifying the tier is an unenforceable rule.
6. Forgetting browser extensions and SaaS-embedded AI. Most policies focus on ChatGPT/Copilot/Gemini and miss the AI features in approved SaaS tools, AI-enhanced productivity apps, and AI-powered browser extensions. These are the long tail and they need to be in the policy.
7. Publishing the policy and never communicating. A policy in SharePoint that no one has heard about is worse than no policy – creates audit-trail liability without behavioral change.
8. No review cadence. AI vendor terms shift quarterly. A policy reviewed once a year is stale by the time staff need it. Schedule the review.
9. Treating it as HR’s problem. AI governance is data control, contracts, compliance, security, and culture. HR co-owns; IT or operations typically owns primary.
10. Trying to make it a legal document. A policy that reads like a contract gets ignored. A policy in plain language gets followed.

How long this takes from blank page to live policy

For a typical SMB starting from no AI policy at all, the realistic timeline is two weeks of calendar time with about 8-15 hours of total effort.

Phase	Activity	Duration
Discovery	Inventory AI tools in use, gather staff input on what they actually use	2-3 days
First draft	Write the policy using the sample outline	Half a day
Stakeholder review	Owner, HR, IT, legal (if regulated) review	3-5 days
Licensing alignment	Confirm approved tools have correct paid tiers in place	Parallel with review
Communication prep	Slide deck, FAQ, training plan	1-2 days
Staff rollout	20-30 minute meeting, distribute policy, collect signatures	1 day (plus follow-up)
Operate	Ongoing – sign-off tracking, twice-yearly review, incident handling	Permanent

For a regulated SMB, add another week to two weeks for the compliance overlay (HIPAA BAA review with approved vendors, GLBA mapping, etc.) and for legal review.

The first draft is the easy part. The hard part is communicating and operating it. Most policies fail at the communication and operation stages, not at the drafting stage.

What is next in this content series

This article is the policy template. Adjacent reads in the Cluster 8 series:

• Your employees are already using AI at work – the shadow AI wake-up call that motivates this policy
• Upcoming: what data is and is not safe to put into specific AI tools
• Upcoming: AI and HIPAA, including which AI vendors have signed BAAs and what that actually covers
• Upcoming: AI risk assessment – how to evaluate any new AI tool before approving it
• Upcoming: AI governance framework – the ongoing operating model that the policy is one input to

If your AI policy work is sitting inside a broader managed cybersecurity engagement, the relevant parent context is the managed cybersecurity services for small business overview.

How Sequentur can help

If you want help drafting an AI acceptable use policy that fits your business, your stack, and your regulatory exposure – or want a second pair of eyes on a draft you have already written – schedule a call.