AI Acceptable Use Policy: How to Write One That Works

2026-10-18 · Tommaso Maria Ricci

An AI acceptable use policy is the cheapest control most companies still do not have. In ISACA's 2025 AI Pulse Poll of 3,029 digital trust professionals, 81% said employees in their organization use AI whether it is permitted or not, while only 28% said their organization has a formal, comprehensive AI policy. Read those two numbers together and the picture is simple: in roughly two out of three companies, people are already making the rules up as they go.

This guide is about closing that gap with a document people will actually follow. Not a 40 page legal artifact that lives on the intranet, but a short, operational AI acceptable use policy that tells every employee which tools they can use, what data can go into them, what needs a human check, and who to call when something goes wrong.

I will walk through the sections a working policy needs, the data rules that matter most, a self-assessment scorecard, sample clauses you can adapt, and a 30/60/90 day rollout plan. The perspective is that of a founder who has run AI projects inside real operating companies, not that of a compliance office writing for itself.

Why an AI acceptable use policy matters now

For two years most companies treated generative AI like a curiosity. Some banned it, most ignored it, a few bought licenses and hoped for the best. That phase is over, for three reasons that show up clearly in the data.

First, the usage is already there. Netskope's Cloud and Threat Report 2026, based on enterprise traffic telemetry rather than a survey, found that 47% of people using generative AI at work still do it through personal or unmanaged accounts. That is down from 78% the year before, and company managed access rose from 25% to 62%. Progress, yes. But nearly half of the usage still happens where the company cannot see it.

Second, the data leaks are measurable. The same Netskope report counts an average of 223 generative AI data policy violations per organization per month, and regulated data (personal, financial, health) accounts for 54% of them. Source code, intellectual property and credentials appear too. This is not hypothetical risk. It is what monitoring tools already flag.

Third, the cost of ungoverned use now has a price tag. IBM's Cost of a Data Breach Report 2025, run by the Ponemon Institute across 600 breached organizations, found that about one in five breaches involved shadow AI, and that organizations with high levels of shadow AI paid roughly $670,000 more per breach than those with low or no shadow AI. In the same study, 63% of breached organizations had no AI governance policy or were still developing one.

The incidents that made policy a board topic

Two cases are worth knowing because they illustrate two different failure modes.

1. Data going out. In spring 2023 Samsung restricted the use of generative AI tools on company devices and networks after engineers uploaded internal source code to ChatGPT, according to an internal memo reported by Bloomberg. Nobody acted maliciously. They were trying to work faster with the tool in front of them.
2. Answers coming in. In Moffatt v. Air Canada (2024), a British Columbia tribunal held the airline liable for negligent misrepresentation after its website chatbot gave a customer wrong information about bereavement fares. The tribunal rejected the idea that the chatbot was a separate entity responsible for its own statements. The company owns what its AI says.

An AI acceptable use policy addresses both directions: what goes into AI tools, and what comes out of them and reaches customers, regulators or decisions.

Why bans do not work

The instinctive response to these stories is a ban. It rarely holds. The ISACA data says it plainly: employees use AI whether it is permitted or not. A ban pushes usage onto personal phones and personal accounts, which is exactly the blind spot the Netskope numbers describe.

There is also a productivity argument. The NBER working paper by Brynjolfsson, Li and Raymond on 5,179 customer support agents found that access to a generative AI assistant raised issues resolved per hour by 14% on average, and by 34% for novice and low skilled workers. A company that bans AI gives up that gain and still carries the risk. The goal of the policy is to channel use, not to stop it.

What an AI acceptable use policy is (and what it is not)

Confusion about scope is the most common reason these documents fail. Teams try to write one policy that covers model development, vendor risk, ethics principles, data science standards and employee behavior all at once. The result is long, abstract and ignored.

An AI acceptable use policy has a narrow job: it governs how employees and contractors use AI tools in their daily work. It answers practical questions a salesperson, a recruiter or an accountant has on a Tuesday afternoon.

How it fits with your other documents

The acceptable use policy should reference the others rather than repeat them. If you already have a data classification scheme, your AI policy says "Confidential data as defined in the Data Classification Policy may only be used in tools marked Approved for Confidential in the AI Tools Register." One sentence, linked, done.

If you do not yet have a governance layer above the policy, start there in parallel. I covered the structure in AI governance for business, and the risk side of unsanctioned tools in Shadow AI: the risk hiding in your company.

What it is not

• It is not an ethics manifesto. Principles like fairness and transparency belong in the governance framework. The acceptable use policy turns them into concrete do and do not rules.
• It is not a tool review. It names approved tools but does not compare vendors.
• It is not permanent. Tools, contracts and regulation change every quarter. A policy that is not reviewed on a schedule is outdated within six months.

How to write an AI acceptable use policy: the ten sections

After drafting and reviewing these policies across different kinds of companies, I have found that ten sections cover what matters. A good first version fits in four to six pages. Anything longer will not be read.

1. Purpose and scope

State in two or three sentences why the policy exists and who it covers. Include employees, contractors, interns and anyone acting on behalf of the company. Cover all AI tools, including features embedded in software you already use, such as AI assistants inside email, CRM, office suites and design tools. Those embedded features are where most unnoticed usage happens.

2. Definitions

Keep it to five or six terms: generative AI tool, approved tool, personal account, confidential data, personal data, AI output. Plain language. If an employee needs a lawyer to understand the definitions, rewrite them.

3. The AI Tools Register

This is the heart of the policy. A living list, maintained by a named owner, of every AI tool the company allows, with its status and the highest data class it can receive. The policy itself only says that the register exists, where to find it, and that anything not on it is not approved. The register can then change weekly without rewriting the policy.

4. Data rules

Which categories of data can go into which tools. I recommend a traffic light system, described in detail in the next section, because people remember colors under time pressure better than paragraphs.

5. Permitted, restricted and prohibited uses

Three short lists. Permitted uses need no approval (drafting, summarizing public material, brainstorming). Restricted uses require approval or a specific tool (anything touching personal data, customer communications, code going to production). Prohibited uses are off limits for everyone (for example, using AI to make final decisions about hiring, firing or credit without human review, or entering credentials into any AI tool).

6. Human review and accountability

The rule that saves you from the Air Canada problem: the person who uses the output owns the output. AI generated content that reaches a customer, a regulator, a contract, a financial statement or a decision about a person must be reviewed by a human who is accountable for it. Spell out what review means for each high impact category.

7. Transparency and disclosure

When must employees disclose that content or interactions are AI generated? At minimum: customer facing chatbots, synthetic images or audio, and any situation where a customer might reasonably believe they are dealing with a human. In the EU, the transparency obligations of Article 50 of the AI Act apply from 2 August 2026, so this section is not optional for companies with European exposure.

8. New tools and exceptions

A fast, simple route to request a new tool. This is the section most policies get wrong. If approval takes two months, people use personal accounts. Set a service level: for example, a decision within ten working days for low risk tools, with a short form covering purpose, data involved and vendor terms.

9. Training

Who must complete what, and when. A short required module for everyone at onboarding and once a year, plus deeper sessions for roles with higher risk such as HR, finance, legal, engineering and customer service. I cover program design in AI training for employees.

10. Incidents, enforcement and review

How to report a mistake (for example, confidential data pasted into the wrong tool), with a clear statement that early self reporting is treated differently from concealment. Consequences for deliberate violations, aligned with existing disciplinary procedures. And a review cadence: at least every six months, plus any time a major tool or regulation changes.

The data traffic light: the rule people remember

If employees remember only one thing from your AI acceptable use policy, it should be what data they can put where. The traffic light makes that decision fast.

Rules that make the traffic light work

• Company accounts only. Even for green data, use company provisioned accounts. Personal accounts mean no audit trail, no contract, and no control over retention.
• When in doubt, treat it as red. This single sentence prevents most incidents.
• Anonymization must be real. Removing a name while leaving an email address, a contract number or a unique job title is not anonymization.
• Credentials are always red. No API keys, passwords or tokens in any AI tool, for any reason, including debugging.
• Outputs inherit the color of inputs. A summary of a red document is a red document.

Why contracts matter more than features

The difference between a safe and an unsafe tool is often not technical. It is contractual. Enterprise tiers of most major AI services offer terms that exclude your inputs from model training, define retention periods and include a data processing agreement. Consumer tiers of the same product often do not. Your register should record which tier and which contract you are on, not just the product name.

Building the AI Tools Register

A register turns an abstract policy into a reference people check before they act. Here is a structure that works in practice.

Three practical tips

1. Include embedded AI. List the AI features inside your CRM, help desk, office suite and HR system, with their own status. These are often switched on by default with an update.
2. Publish the "Not approved" list too. People are more likely to comply when they can see that a tool was evaluated and rejected, with a one line reason.
3. Keep it where people work. A pinned page in the company chat beats a PDF on a shared drive.

Rules by function: where the risk actually sits

A single set of rules for the whole company is a good start, but risk is not evenly distributed. The highest value AI uses are often in the same places as the highest exposure, because both depend on customer and operational data.

When a sports distribution company I worked with grew sales 30% through AI driven marketing, the gain came from customer and sales data. When a hotel went from 9 to 10 million in revenue, or a medical center added 20% of capacity, the leverage came from operational data that nobody would want in a personal chatbot account. That is the point: the policy has to make the valuable uses possible, safely, not block them.

Sales and marketing

• Green: drafting campaign copy, generating ideas, summarizing public market information.
• Amber: analyzing pipeline exports or campaign results in an approved tool.
• Red: uploading customer lists with contact details into any tool not approved for personal data.
• Specific rule: AI generated claims about products, prices or competitors must be checked before publication. Synthetic images and voices must follow disclosure rules.

Human resources

HR is the highest risk area in most policies, because decisions about people carry legal consequences. In New York City, Local Law 144 already requires bias audits and candidate notices for automated employment decision tools. In the EU, AI systems used for recruitment and for decisions affecting employment fall under the high risk category of Annex III of the AI Act, with those obligations applying from 2 December 2027 after the changes introduced by Regulation (EU) 2026/1744.

• Permitted: drafting job descriptions, summarizing anonymized engagement survey themes.
• Restricted: any tool that screens, ranks or scores candidates or employees requires prior approval from HR leadership and legal.
• Prohibited: final hiring, promotion or termination decisions made by AI without documented human review.

For a broader view of where AI fits in people processes, see AI for HR professionals.

Finance and accounting

• Amber: using approved tools to draft commentary, reconcile non sensitive data, or explain variances.
• Red: unreleased results, bank details, payroll data, anything subject to insider rules.
• Specific rule: no AI output enters a financial statement, a tax filing or an audit response without review by an accountable person, and the review is recorded.

Engineering and IT

• Approved coding assistants only, on company accounts, with settings that exclude code from training where the contract allows it.
• No secrets, keys or customer data in prompts.
• AI generated code follows the same review, testing and security scanning as human written code. Licensing and provenance checks apply to large generated blocks.

Customer service

This is where the Air Canada lesson applies most directly.

• Customer facing AI must be configured from approved, current knowledge sources.
• Customers must be told when they are talking to an AI system.
• Answers involving refunds, legal terms, health, safety or money must have a clear escalation path to a human, and the company stands behind what its AI says.

Legal and contracts

• Red by default: contracts under NDA, litigation material, privileged communications.
• Use only tools approved for that class, with confirmed confidentiality terms.
• AI may assist with first drafts and clause comparison; a qualified person signs off.

Self-assessment: is your AI acceptable use policy ready?

Score each statement: 2 points if fully true, 1 if partially true, 0 if not true.

How to read your score

• 20 to 24 points: operational. Your focus is measurement and continuous improvement. Track usage on approved tools versus estimates of unmanaged use.
• 12 to 19 points: partial. You likely have a document but not the machinery around it: register, training, request process. Fix those before rewriting the text.
• 0 to 11 points: exposed. Use the 30/60/90 plan below. Start with the data traffic light and the register, because they reduce the most risk fastest.

If you want an outside view on where you stand, the AI readiness assessment covers the wider organizational picture, and you can also request a consultation through the site to review your draft policy line by line.

Sample clauses you can adapt

These are starting points written in plain language. Adapt them to your structure and have them reviewed by counsel in your jurisdiction.

Scope

"This policy applies to all employees, contractors, interns and third parties acting on behalf of the Company when they use any artificial intelligence tool for Company work, including AI features embedded in software provided by the Company."

Approved tools

"Only tools listed as Approved or Restricted in the AI Tools Register may be used for Company work, and only on Company provisioned accounts. Any tool not listed is not approved. To request a new tool, submit the AI Tool Request form; you will receive a decision within ten working days."

Data

"You may enter data into an AI tool only if the tool is approved for that data class in the AI Tools Register. Never enter passwords, API keys, access tokens or other credentials into any AI tool. If you are unsure of the data class, treat the data as Red."

Human review

"You are responsible for any AI output you use. Before AI generated content is sent to a customer, published, included in a contract or financial record, or used in a decision about a person, it must be reviewed by an accountable employee who confirms it is accurate, appropriate and compliant."

Prohibited uses

"You must not use AI tools to: make final decisions about hiring, promotion, discipline or termination without documented human review; impersonate a real person; generate content designed to deceive customers or regulators; bypass security controls; or process data in breach of contractual or legal obligations."

Disclosure

"Customers must be informed when they interact with an AI system. Synthetic images, audio or video depicting real people or events must be labeled as AI generated, in line with applicable law."

Incidents

"If you believe Company data has been entered into an unapproved tool, or an AI output has caused or may cause harm, report it immediately to the AI policy owner. Prompt self reporting will be taken into account positively. Concealment will not."

Review

"The AI policy owner reviews this policy at least every six months and whenever a significant change in tools, contracts or regulation occurs."

30/60/90 day rollout roadmap

A policy is only as good as its rollout. This is the sequence I use, sized for a company between 50 and 1,000 people.

Days 1 to 30: discover and draft

1. Appoint an owner. One person accountable for the policy and the register, usually from IT, risk or operations, with a sponsor on the leadership team.
2. Measure real usage. Pull data from your network or security tools on AI domains, and run a short anonymous survey asking which tools people actually use and for what. Expect surprises.
3. Build the first register. Classify the tools you found as Approved, Restricted, Pilot or Not approved. Check contracts and tiers for each.
4. Draft the policy using the ten sections above. Target four to six pages.
5. Review with legal, HR, IT and two or three heavy users. The users will tell you which rules are unworkable.

Days 31 to 60: enable and launch

1. Close the gap between demand and supply. If people use a personal assistant because there is no approved alternative, provide one on a company account before you enforce anything. Otherwise the policy simply drives usage underground.
2. Publish the policy and the register where people work.
3. Run training. A 30 to 45 minute module for everyone, focused on the traffic light, the register and the review rule. Role based sessions for HR, finance, legal, engineering and customer service.
4. Open the request channel with a published service level.
5. Collect acknowledgments as part of training, not as a separate signature campaign.

Days 61 to 90: monitor and adjust

1. Compare usage before and after. The share of AI traffic going to approved tools is your leading indicator.
2. Review incidents and near misses in a short monthly meeting. Look for patterns, not culprits.
3. Update the register based on requests received.
4. Fix the rules that do not work. If an amber rule is broken every day, the rule or the tooling is wrong.
5. Report to leadership with three numbers: adoption on approved tools, incidents, and time to approve new tools.

For the people side of this rollout, the stages in AI change management apply directly.

Enforcement without killing adoption

The best AI acceptable use policies I have seen share a counterintuitive trait: they are permissive in the green zone and strict in the red zone. Most failed policies do the opposite, or treat everything the same.

Seven mistakes to avoid

1. Writing for lawyers instead of users. If the policy cannot be summarized on one slide, it will not be followed.
2. Banning without providing. A prohibition without an approved alternative moves usage to personal accounts.
3. Ignoring embedded AI. The AI inside existing software is often the largest unmanaged surface.
4. Slow approvals. A two month review cycle is a de facto ban.
5. No owner. A policy without a named owner stops being updated after the launch email.
6. Punishing honesty. If reporting a mistake gets someone disciplined, mistakes stop being reported.
7. Confusing training with a signature. Clicking "I agree" is not training. People need examples from their own work.

Monitoring that respects people

Some monitoring is necessary: you need to know which AI services are being used and whether red data is leaving. Keep monitoring proportionate, transparent and documented. Tell employees what is monitored and why. In many jurisdictions, including much of Europe, employee monitoring is subject to specific rules on information and proportionality, so involve HR and legal before switching on content inspection.

Regulatory anchors to reference

You do not need to turn your acceptable use policy into a legal treatise, but it should be consistent with the main frameworks your company is exposed to.

EU AI Act

The EU AI Act entered into force on 1 August 2024. Article 4 on AI literacy has applied since 2 February 2025 and, after the amendments introduced by Regulation (EU) 2026/1744 in force since 27 July 2026, asks providers and deployers to take measures to support the development of AI literacy of their staff, without imposing a specific level for any individual. Training on your acceptable use policy is one of the most practical and documentable of those measures. The current text is on the AI Act Service Desk page for Article 4. Transparency obligations under Article 50 apply from 2 August 2026, while high risk obligations apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I systems.

United States

There is no single federal AI law for private employers, but several anchors matter:

• NIST AI Risk Management Framework. Voluntary, widely used, and a good reference structure for governance. The NIST AI RMF also has a generative AI profile.
• Sector and local rules. NYC Local Law 144 on automated employment decision tools is the best known example. Financial services, healthcare and other regulated sectors have existing rules that apply to AI outputs just as they apply to any other.
• Existing liability. As Moffatt v. Air Canada showed in Canada, ordinary principles like misrepresentation apply to AI generated statements. Courts do not need an AI law to hold a company responsible.

Standards

ISO/IEC 42001, published in December 2023, defines requirements for an AI management system. You do not need certification to benefit from its structure, and an acceptable use policy is one of the controls an auditor would expect to see.

What good looks like after six months

When an AI acceptable use policy works, you see it in behavior rather than in documents.

• Most AI usage runs through approved, company managed tools, and the share keeps growing.
• People ask before they experiment because asking is fast.
• Incidents get reported early, while they are still small.
• The register changes regularly, a sign that the company is adopting new tools deliberately instead of resisting them.
• Leadership can answer three questions in a minute: which AI tools do we use, what data goes into them, and who is accountable for the outputs.

That last point matters more than it seems. When a customer, an auditor, an investor or a regulator asks how you use AI, a company with a working policy answers in one page. A company without one starts an investigation.

If you are building this from scratch, or your current document is long and unread, it is usually faster to rebuild around the ten sections and the traffic light than to patch the old text. And if you want help pressure testing your draft against how your teams really work, a short consultation request through the site is the quickest way to start. For the broader adoption picture this policy sits inside, see the enterprise AI adoption framework.

FAQ

How do I write an AI acceptable use policy for my company?

Start by measuring which AI tools employees already use, then draft a short document of four to six pages with ten sections: purpose and scope, definitions, an AI Tools Register, data rules, permitted and prohibited uses, human review, disclosure, a request process for new tools, training, and incident handling with a review schedule. Use a traffic light system for data so people can decide quickly. Review the draft with legal, HR, IT and a few heavy users, then launch it together with approved tools and training.

What should an AI acceptable use policy include?

At minimum it should include the scope of people and tools covered, a list of approved AI tools with the highest data class each can receive, clear rules on personal and confidential data, the uses that are permitted, restricted or prohibited, a requirement for human review of high impact outputs, disclosure rules for AI generated content and AI customer interactions, a fast route to request new tools, training requirements, incident reporting and a regular review cycle.

Should companies ban ChatGPT and other generative AI tools?

Blanket bans rarely work. ISACA's 2025 research found that 81% of respondents believe employees use AI whether it is permitted or not, so a ban tends to push usage onto personal accounts where the company has no visibility or contractual protection. A better approach is to provide approved tools on company accounts, restrict sensitive data to tools with the right contractual terms, and prohibit only specific high risk uses.

How long should an AI acceptable use policy be?

A working first version usually fits in four to six pages. The policy should state the rules and point to a separate AI Tools Register, which holds the detailed and frequently changing list of tools, statuses and data permissions. Keeping the policy short and the register separate means you can update tools weekly without rewriting the policy, and employees are far more likely to read and remember it.

How often should an AI acceptable use policy be reviewed?

Review it at least every six months and whenever there is a significant change in tools, vendor contracts or regulation. AI products add features constantly, often switching on AI capabilities inside software you already use, and regulatory timelines such as those of the EU AI Act keep evolving. The AI Tools Register should be updated continuously as new requests are approved or rejected.

Does the EU AI Act require an AI acceptable use policy?

The EU AI Act does not require a document with that specific name. Article 4, as amended by Regulation (EU) 2026/1744, asks providers and deployers of AI systems to take measures to support the AI literacy of their staff. A clear acceptable use policy combined with documented training is one of the most practical ways to show such measures. Other obligations, such as transparency under Article 50 from 2 August 2026, also translate naturally into policy rules.

Who should own the AI acceptable use policy?

Ownership works best with one accountable person, often from IT, risk, security or operations, supported by an executive sponsor and a small group with legal, HR and business representatives. The owner maintains the AI Tools Register, runs the request process, tracks incidents and leads the periodic review. Without a named owner, policies stop being updated shortly after launch.