Checklist September 22, 2026 9 min read

AI Policy Checklist: The Must-Have Sections Every Policy Needs

By the Shadow AI Policy team

Most AI policies fail not because they're wrong, but because they're incomplete — missing the sections that matter most when something actually goes wrong.

This post walks through the sections every AI acceptable use policy needs, organized into five functional areas: scope and applicability, data classification and input restrictions, tool tiers and approval, incident reporting and escalation, and training, enforcement, and review cadence. Whether you're writing your first policy or auditing an existing one, use this as your completeness check.

A policy that lists approved tools but doesn't define what data employees can feed into them is only half a policy. The most common gap we see in AI policies isn't the tool list — it's the absence of clear input rules tied to your existing data classification system. Fix that first.

Section 1: Scope and Applicability — Who and What Does This Cover?

The first mistake most AI policies make is being vague about who they apply to. "All employees" sounds comprehensive but misses contractors, temp workers, agency staff, and offshore vendors who may use AI tools on your behalf. Your scope section needs to name every worker category explicitly — employees, contractors, interns, consultants, and any third party accessing company systems or data.

Scope also means defining what AI tools are covered. Your policy should apply to any software with a generative AI or machine learning component, regardless of whether the company purchased it. That includes consumer tools employees use on personal devices for work purposes. If your policy only covers company-issued software, it leaves a large gap that's easy to exploit, usually without any bad intent — just convenience.

The scope section should answer three questions without ambiguity:

If your business operates in multiple states or countries, note that here too. Employees in the EU are subject to the EU AI Act's requirements for high-risk AI systems. California employees may have rights under CCPA related to automated decision-making. Scope is where you set the jurisdictional context before diving into rules.

Section 2: Data Classification and Input Restrictions

This is the section most policies either skip entirely or treat as an afterthought. It's the most operationally important section of the document. Without it, employees have no way to know whether it's acceptable to paste a client contract into ChatGPT or summarize HR performance notes with a free AI tool. The gap isn't malice — it's a missing decision rule.

Your policy needs a data classification tier system if you don't already have one, or a direct reference to your existing one if you do. A functional four-tier model looks like this:

Data Tier Examples AI Input Rule
Public Marketing copy, published blog posts, public job descriptions Approved for use in any approved AI tool
Internal Internal memos, meeting notes, project plans Approved for use in Tier 1 tools only (enterprise/BAA-covered)
Confidential Client contracts, financial projections, HR records, source code Approved for use only in specifically vetted Tier 1 tools; no consumer tools
Restricted PHI, PII, payment data, attorney-client privileged content, trade secrets No AI input without explicit written approval and a signed BAA or DPA

If your organization handles protected health information, the Restricted tier isn't optional — it's required. Under HIPAA Privacy Rule 45 CFR § 164.502(e), sharing PHI with a business associate (which an AI vendor can be) requires a signed Business Associate Agreement before any data transfer occurs. Most consumer AI tools, including free-tier versions of ChatGPT, Claude, and Google Gemini, do not offer BAAs. For a full comparison of which tools offer BAA coverage, see our HIPAA-compliant AI tools guide.

The input restrictions section should also explicitly call out what employees must never paste into any AI tool: Social Security numbers, credit card numbers, passwords, biometric data, and unpublished financial results. Make this a short, scannable list — not a paragraph buried in legal language.

Section 3: Tool Tier List and the Approval Process

Employees will use AI tools whether you approve them or not. The goal of a tool tier list isn't to stop that — it's to channel it toward tools that meet your security and compliance requirements. A good tier structure gives employees a clear answer to the question: "Can I use this tool for this task?"

Structure your tool tiers around organizational risk, not cost or brand recognition:

The approval process itself needs to be documented in the policy, not just implied. Who submits a tool for review? Who evaluates it? What's the turnaround time? A policy that says "employees must request approval for new AI tools" but doesn't describe how to do that will be ignored. Specify the submission form or email address, the evaluating team (typically IT + Legal), and a defined SLA — 10 business days is a workable standard for most SMBs.

A tool tier list without a clear submission process creates the illusion of governance without the reality of it. Employees don't bypass approval because they're careless — they bypass it because the approval path doesn't exist or takes too long.

For teams building a policy from scratch, our AI acceptable use policy template guide covers how to structure tool approval language in plain English.

Section 4: Incident Reporting and Escalation

When an employee realizes they've pasted confidential client data into an unapproved AI tool, what do they do? If your policy doesn't answer that question clearly, they'll do one of two things: panic and say nothing, or report it to the wrong person and lose days of response time. Both outcomes are bad. Shadow AI incidents — where unapproved tools receive sensitive data — are increasingly common. BlackFog's 2026 Shadow AI research found that shadow AI usage in enterprise environments has grown significantly, with many incidents going unreported due to lack of clear policy guidance.

Your incident section needs to define:

If your organization is subject to GDPR, note that Article 33 of the GDPR requires notification to a supervisory authority within 72 hours of discovering a personal data breach. An AI tool receiving personal data it shouldn't have received can constitute a reportable breach. Your incident policy should align with this timeline. Similarly, if you're subject to SEC or FINRA oversight, material incidents involving client financial data may carry their own disclosure obligations.

For teams that aren't sure what shadow AI exposure looks like in practice, the what is shadow AI explainer covers the most common patterns.

Section 5: Training, Enforcement, and Review Cadence

A policy no one has read is just a document. Training converts a document into practice. Your policy should specify when training is required (at onboarding and at least annually), what format it takes (live session, async module, or policy acknowledgment with quiz), and who is responsible for delivering it. Don't leave this to "department heads at their discretion" — give HR or L&D explicit ownership.

Training content doesn't need to be elaborate, but it must cover the minimum a reasonable employee needs to comply:

Enforcement is the part most policies omit because it's uncomfortable. Don't omit it. State clearly that violations of the AI policy are subject to your existing disciplinary process, up to and including termination for serious or repeated violations. This doesn't need to be punitive in tone — it needs to be clear. Employees should understand that the policy has teeth, not just that it exists. Equally important: enforce consistently. A policy applied selectively creates legal exposure under employment discrimination frameworks.

Finally, set a review cadence in the document itself. AI tools, regulations, and organizational risk profiles change faster than most other policy domains. A 12-month review cycle is the minimum. Build in a trigger clause that requires an out-of-cycle review when a major regulatory development occurs (such as new EU AI Act implementing rules) or when a significant incident happens. Assign the review owner by role, not by name — "the General Counsel and VP of HR" rather than a specific person who may not be in that role next year.

If you want to skip building the framework from scratch, you can generate a tailored policy kit that covers all five areas above, pre-mapped to your industry and headcount.

About Shadow AI Policy: We build AI acceptable use policy tools for HR and operations teams at 50–500 person companies. We publish guides on shadow AI, acceptable use policies, and AI governance, updated as regulations and AI tools change.

Common questions

What is the most important section to get right in an AI policy?

Data classification and input restrictions. Most AI-related incidents at small and midsize companies happen because employees didn't know what data they were and weren't allowed to enter into a given tool — not because they were careless or malicious. If your policy only lists approved tools but doesn't define what data can go into them, employees are still operating blind. Start with a clear four-tier data classification system and map each tier to specific input rules before worrying about anything else.

Do we need a separate AI policy, or can we add AI rules to our existing IT/acceptable use policy?

A standalone AI policy is strongly recommended, at least as a separate section with its own header and version history. Embedding AI rules inside a general IT policy buries the guidance and makes it harder to update quickly — and AI policy needs to change more frequently than general IT policy. If your organization has an existing acceptable use policy, cross-reference it in your AI policy but keep the AI-specific rules in a dedicated document that Legal and HR can revise independently.

How do we handle employees who use personal AI tools on personal devices for work tasks?

Your policy needs to explicitly cover this scenario — and the answer should be that the same input restrictions apply regardless of device ownership. If an employee uses a personal ChatGPT account on a personal laptop to summarize a confidential client contract, that's a policy violation. The controlling factor is the data classification of the content being processed, not who owns the hardware. Make this explicit in your scope section and reinforce it in training with a concrete example.

How often should we update our AI policy?

At minimum, review it every 12 months. Set a trigger clause requiring an out-of-cycle review whenever a major regulatory development occurs — the EU AI Act's implementing rules for high-risk systems, new FTC guidance on AI, or a significant change to a major tool's data retention practices all qualify. Also review it immediately after any internal incident involving unauthorized AI use. Assign the review to a named role (e.g., General Counsel + VP of HR), not a named individual, so the responsibility survives personnel changes.

Free tool: Check your policy for missing sections → Paste your AI policy and see which of the 9 essential sections it covers.

Generate your AI policy in 10 minutes

Tailored to your industry and the AI tools your team uses. Free preview, then $149/mo to keep it current as the rules and vendor terms change — or $79 for a one-time snapshot.

Generate my policy kit →

Writing policies for several clients? MSPs, IT consultancies and fractional CISOs keep a roster of client kits that refresh monthly, under their own branding. See partner plans →