Building Your AI Use Policy: A 6-Section Framework for CIOs and General Counsels

Your employees are already using AI.

Not the AI tools you've approved. The ones you haven't reviewed yet. The free ChatGPT accounts someone set up last year. The Copilot subscription a department head added to the team budget. The browser extension three engineers installed that "reads your screen to help you write faster."

Every one of these tools is in active use. Every paste of a customer record, internal financial projection, or draft contract into these tools is a potential data exposure. And every company that doesn't have an AI use policy has implicitly approved all of it by saying nothing. The EU AI Act requires organizations deploying AI in high-risk contexts to have documented governance in place: the EUR-Lex summary of AI governance obligations makes clear that informal practices don't satisfy compliance requirements.

A policy doesn't slow AI adoption. It makes adoption survivable. It gives your employees clear guidance on what's safe, what requires approval, and what's off-limits. They can move quickly within known boundaries instead of either avoiding AI entirely or using it recklessly.

This article gives you the complete 6-section structure, the key decisions to make in each section, and real-world vendor policy references you can use as anchors for your own language.

Why you need it now, not after scaling

Key Facts: The Cost of No AI Policy

• 78% of knowledge workers use personal AI tools at work without explicit employer approval; most organizations have no visibility into which tools are in use across their workforce (Microsoft Work Trend Index, 2024)
• Companies without AI governance policies face data breach costs averaging $4.88M per incident under GDPR, compared to a median governance program cost of $50,000-100,000 for mid-market companies (IBM Cost of Data Breach Report 2024)
• The EU AI Act, now in effect, requires organizations deploying AI in high-risk contexts to have documented governance in place; informal practices do not satisfy compliance requirements (EU AI Act, effective 2025-2026)

The governance gap at Stage 1 is the most common source of AI incidents. But many organizations tell themselves they'll address policy "once AI becomes more established in the company." That logic has it backwards.

The time to write the policy is before incidents happen, not after. And incidents are happening right now, invisibly.

A lawyer at a mid-size firm pastes a draft merger agreement into ChatGPT to clean up the language. A sales rep uploads a spreadsheet of customer contact data to an AI tool to auto-generate personalized emails. An engineer asks Copilot to review code that contains an internal API key in the comments.

None of these employees were acting maliciously. None of them had policy guidance telling them not to. None of their companies know it happened.

The policy you write this quarter is the policy that prevents those incidents from becoming bigger problems. It's also Stage 2's entry ticket: the AI maturity model requires a written policy before you can run a governed pilot. You can't build a compliant AI program on a no-policy foundation.

The good news: you don't need a perfect policy to start. You need one that exists and is shared. Iteration beats absence.

"The policy you write this quarter is the policy that prevents incidents from becoming front-page problems. The governance program that would have prevented a major data breach costs $50,000-100,000. The legal fees, regulatory response, and customer communication after the breach average $4.88M. The math on AI governance investment is straightforward." (Rework, based on IBM Cost of Data Breach 2024)

The 6-Section AI Policy Template

A structured framework for building an enterprise AI use policy that covers the minimum requirements for governance compliance, employee clarity, and legal protection. The six sections are: (1) Acceptable Use (approved tools, permitted purposes, role-based access), (2) Data Classification Rules (which data tiers can go into which tool categories), (3) Approval Process for New Tools (intake, review, registry), (4) Prohibited Tools and Actions (hard compliance and security lines), (5) Incident Reporting (reporting channel, response SLA, protection for reporters), (6) Training Requirements (baseline for all employees, elevated for high-access roles). A working draft covering all six sections is more valuable than a perfect document in development. Iteration beats absence.

The 6 required sections

Section 1: Acceptable Use

This section answers: which AI tools are approved, for what purposes, and for which employee roles.

Key decisions to make:

List the approved tools by name. Don't say "approved AI tools" generically. Name them: ChatGPT Enterprise, Microsoft Copilot for Microsoft 365, Anthropic Claude for Teams, GitHub Copilot. Each named tool has an approval status: Approved, Conditionally Approved (with restrictions), or Under Review.

For each approved tool, state the permitted use cases. "ChatGPT Enterprise: approved for drafting internal communications, summarizing meeting notes, and generating first-draft content. Not approved for processing customer data or generating compliance documentation without human review."

Define which roles have access to which tools. Not every employee needs every tool. Your finance team may have access to AI tools your warehouse team doesn't. This is a governance choice, not a technical limitation.

Vendor reference: Microsoft 365 Copilot is enterprise-grade with Microsoft's Compliance Center integration, meaning it inherits your existing Microsoft 365 data handling, data loss prevention (DLP) policies, and audit logging. If your company is already on Microsoft 365, Copilot has the lowest governance friction because it operates within your existing compliance envelope.

Section 2: Data Classification Rules

This section answers: what data can employees put into AI tools?

This is the single most important section in the policy. Most AI governance incidents happen here. An employee uses an approved AI tool for an approved purpose, but pastes the wrong data.

Key decisions to make:

Define your data tiers and which tiers are permitted in which tool categories. A working framework:

The detail required here is covered in full in Data Classification for AI Access Rules, which should be read alongside this policy section.

Vendor reference: OpenAI Enterprise does not use your data to train models, operates under a data processing agreement (DPA), and holds SOC 2 Type II certification. That makes it an appropriate home for Internal-tier data. Anthropic Claude for Business similarly offers no-training commitments and data residency options. The key point: verify these commitments in the actual enterprise agreement before treating them as policy-cleared.

A common gap: Policies that say "don't use AI with sensitive data" without defining what sensitive means. Employees interpret "sensitive" to mean extreme cases (medical records, SSNs) and don't realize that customer email addresses, contract terms, or internal revenue numbers are also sensitive by most companies' standards.

Section 3: Approval Process for New Tools

This section answers: how does an employee get a new AI tool evaluated and approved before use?

Without an approval process, you have three outcomes: employees use unapproved tools anyway (shadow AI), employees don't use AI at all (adoption blocked), or IT approves everything reactively when someone gets an invoice. None of these are governance.

Key decisions to make:

Define the intake process. A simple form works: tool name, vendor, intended use case, data types to be processed, cost, who requested it. This should take the requestor five minutes to complete.

Name the reviewer. One person, not a committee. For most companies, this is the chief information officer (CIO), chief information security officer (CISO), or their delegate. The reviewer checks the tool's data handling terms, DPA availability, SOC 2 status, and alignment with your data classification rules.

Set a turnaround standard. Five business days for standard requests. Ten days if legal review is needed. This signals that the approval process is responsive, not a veto mechanism.

Build a tool registry. A simple spreadsheet or intranet page listing all approved tools, their conditions, and the date of last review. When the registry is visible to employees, they can self-serve rather than submitting redundant requests.

Note on NIST alignment: The NIST AI Risk Management Framework (AI RMF) includes a GOVERN function that establishes the structures, processes, and teams organizations need before AI risk management can function. Its MAP function specifically covers identifying organizational AI uses and their risk profiles. An approval process with a tool registry is the practical implementation of both recommendations.

Section 4: Prohibited Uses

This section answers: what are the hard lines?

Prohibited uses fall into two categories: prohibited tools and prohibited actions.

Prohibited tools (examples):

• Free consumer-tier AI tools for any business-purpose work (no DPA, unknown data handling)
• AI tools from vendors with no enterprise agreement pathway available
• Browser extensions that access or modify content in your business applications without IT review

Prohibited actions (examples):

• Using AI to make final decisions on hiring, promotion, or performance without human review and documentation
• Using AI to generate legal advice, compliance determinations, or regulatory filings without attorney review
• Inputting customer PII into any external AI tool without an active DPA
• Using AI to generate communications that claim to be from a human when they are not, in any regulated context
• Inputting M&A materials, board materials, or other material non-public information into external AI tools

The prohibited actions list is where your legal and compliance teams will have the most input. Pay attention to your industry-specific regulatory requirements. Healthcare organizations have HIPAA constraints. Financial services firms have FINRA and SEC considerations. Law firms have professional conduct rules around client data. These regulatory floors belong in prohibited actions, not just as informal guidance.

A common gap: Policies that list no prohibited uses at all ("use your judgment") or policies that list prohibited uses so comprehensively that nearly all practical AI use is blocked, driving adoption underground. The goal is specificity about the real risks, not exhaustive restriction.

Section 5: Incident Reporting

This section answers: what happens when something goes wrong?

AI incidents are more diverse than traditional security incidents. They include: an AI tool sending incorrect information to a customer, a data exposure via an approved tool's unexpected behavior, discriminatory outputs from an AI system, and incorrect AI-generated content reaching an external audience.

Key decisions to make:

Define what constitutes an AI incident. Give examples. "If an AI tool sends a customer communication you didn't review. If an AI tool appears to have accessed or retained data you didn't intend to share. If an AI output causes a customer complaint or reputational concern. If an AI tool produces output that could be discriminatory or harmful."

Name the reporting channel. One contact: the CIO, CISO, or a dedicated AI governance address. Employees should be able to report in 30 seconds, not wade through a complex system.

Set the response SLA. What's the acknowledgment time? Who investigates? Who decides whether external disclosure (customer notification, regulatory notice) is required? For data exposure incidents, your existing breach response procedures apply. AI incidents that may constitute data breaches under GDPR (General Data Protection Regulation) or CCPA (California Consumer Privacy Act) need to follow those timelines.

Clarify that reporting is encouraged, not penalized. If employees fear reporting AI incidents, incidents accumulate invisibly. The policy should explicitly state that good-faith reporting is protected.

A common gap: No incident reporting section at all. Many AI policies cover acceptable use and data restrictions but leave incident response undefined. This is the gap that turns minor incidents into major ones. Employees don't report problems they're unsure how to escalate, and small exposures compound.

Section 6: Training Requirements

This section answers: who needs to complete AI literacy training before using approved tools?

AI tools produce poor or risky outputs when used without context about their limitations. An employee who understands that AI can confidently produce incorrect information will review AI outputs differently than one who treats them as reliable facts. Training is risk mitigation, not compliance box-checking.

Key decisions to make:

Define training requirements by role and tool. Not everyone needs the same training. A marketing coordinator using Copilot for first-draft emails needs different training than a data analyst using AI for SQL generation.

Set a minimum baseline for all employees: what AI is (and isn't), what the company's data classification rules mean in practice, how to recognize an AI incident, and how to report it. This baseline training should take under two hours and can be delivered asynchronously.

For employees with elevated AI access (engineers building AI workflows, team leads managing AI tools, any role using Execute-capable AI), require deeper training on the specific tool's behavior, limitations, and failure modes.

Define renewal cadence. AI tools change faster than annual training cycles can track. Require acknowledgment of any material policy updates (new approved tools, new prohibited uses) when the policy is revised.

Vendor policy references as anchors

When negotiating enterprise AI agreements, these three reference points establish the baseline your organization should negotiate from.

OpenAI Enterprise: Provides a formal DPA, commits to not using your data for model training, maintains SOC 2 Type II certification, and offers a dedicated security review process. The enterprise agreement gives your legal team a starting point for data processing terms. See OpenAI Enterprise for the current security and privacy documentation.

Anthropic Claude for Business: Offers no-training commitments on business data, data residency options, and enterprise-grade data isolation. Anthropic's Acceptable Use Policy defines the categories of content their models will and won't produce, which should inform your own prohibited uses list. The current policy documentation is at anthropic.com/legal.

Microsoft Copilot for Microsoft 365: Operates within the Microsoft 365 compliance boundary, meaning existing DLP policies, retention labels, and audit logging apply to Copilot interactions. For organizations already in the Microsoft 365 compliance ecosystem, this is the lowest-friction path to an enterprise AI tool with auditable data handling. See Microsoft 365 Copilot for current compliance documentation.

These references give you defensible negotiating positions. "We require SOC 2 Type II and a DPA with no-training commitment" is a standard ask that all three vendors above can satisfy. Vendors who can't satisfy these should default to your Confidential tier restrictions.

Policy gaps that create the most risk

Based on the governance section of the AI maturity model, these are the gaps that produce the most incidents.

No data classification in the policy. The most common and the most dangerous. Without explicit guidance on what data can go where, employees default to their intuition, which varies widely. Data classification is the single most impactful section to get right.

No incident reporting mechanism. Incidents accumulate silently. Small data exposures that could have been addressed early become larger problems. Every AI policy needs a named contact and a defined reporting path.

No approval process for new tools. Shadow AI expands at the pace of vendor marketing. Without an approval process, every new tool that gets a positive review at a conference becomes a potential liability.

Prohibited uses list that blocks all practical AI use. Policies written by teams that are primarily worried about risk, with no input from teams that need to use AI to work. The result drives adoption underground, which is worse than the risk the policy was trying to prevent.

No review cadence. A policy written in 2024 that hasn't been updated since doesn't address the tools employees are using today. Quarterly review of the approved tool list is the minimum. Annual full policy review should be a calendar event.

Rework Analysis: Based on the governance failure patterns across the 5 AI Transformation Failure Modes framework, the data classification section (Section 2 of the 6-Section AI Policy Template) is the most consequential single policy element. Organizations that define data tiers and tool-tier mappings explicitly reduce AI-related data exposure incidents by eliminating the ambiguity that causes most violations. Most incidents are not caused by malicious employees. They're caused by employees who didn't know the rule applied to their specific situation. Explicit data classification removes the ambiguity.

How to enforce without creating friction

Heavy-handed enforcement creates the same outcome as no policy: shadow AI. The enforcement approach that works combines lightweight processes with visible accountability.

A tool registry that's actually accessible. Employees can check whether a tool is approved without submitting a request. A shared spreadsheet with tool name, status, permitted uses, and last review date, updated quarterly, reduces friction substantially.

Fast approval turnarounds. A five-day turnaround for new tool requests means employees don't route around the process out of impatience.

Spot checks rather than comprehensive monitoring. Quarterly review of AI tool invoices and expense reports to catch unapproved tools in use. Not surveillance; accountability.

Manager accountability. Department heads know which AI tools their teams are using. Making the approved tool list visible and sending a quarterly update ensures they're equipped to enforce it without micromanagement.

The policy review cadence

AI technology changes faster than traditional IT. A policy written in January may be materially out of date by July: new tools released, vendor terms changed, regulatory guidance issued. Build the review cadence into the policy itself.

Quarterly: Review the approved tool list. Add newly reviewed tools. Remove or restrict tools whose vendor terms have changed. Log any incidents from the previous quarter and assess whether policy updates are needed.

Annually: Full policy review. Assess whether the data classification tiers still reflect current business data types. Update prohibited use examples. Revise training requirements based on what's changed.

Trigger-based: Any material AI incident, any significant change in vendor data handling terms, any new regulatory guidance that affects your industry. Don't wait for the quarterly cycle when a trigger event requires immediate response.

The policy structure, in summary

An AI use policy that does its job has these six sections:

1. Acceptable Use: Approved tools, permitted purposes, role-based access
2. Data Classification Rules: What data can go into which tool categories
3. Approval Process: How new tools get evaluated and registered
4. Prohibited Tools and Actions: Hard lines for compliance and risk
5. Incident Reporting: How to report, who responds, what's protected
6. Training Requirements: Baseline for all employees, elevated for high-access roles

Print this list. Share it with your legal counsel and CISO. Block a half-day to draft the first version. A working draft published internally today is more valuable than a perfect policy delivered in six months.

The harder question isn't how to write the policy. It's what happens when the first incident occurs and you find out whether the policy actually worked.

What to read next

Read: Data Classification for AI Access Rules for the full 4-tier framework that Section 2 of this policy requires.

Read: AI Approval Gates and Vendor Review for the complete vendor evaluation checklist referenced in Section 3.

Read: AI Incident Response Playbook for the runbook that Section 5 depends on.

Read: Stage 1 to 2: From Ad-Hoc to Pilot to see how the policy fits into the Stage 2 requirements and why it's the entry ticket to governed piloting.

See also:

• Audit Trails for AI Execute Actions: the logging requirements that flow directly from your policy's incident reporting section
• The Generate vs. Execute Boundary: Why Guardrails Matter: the distinction your prohibited uses list needs to encode
• Why Most AI Transformations Fail: how no-governance is one of the five root causes