How to Write an AI Acceptable Use Policy (and the Inventory It Depends On)

Regulatory status current as of 3 September 2026.

An AI acceptable use policy works when it functions as a decision table rather than as a warning. Most of the ones we read are a page of caution telling staff not to put confidential information into AI tools, which is unenforceable, unmeasurable, and ignored within a month. A policy that actually operates names which categories of data may go into which approved tools, states what an AI system is never permitted to decide without a person, gives people a fast path to request something new, and rests on an inventory of what is already running. That last part is where most policies fail before they start. A policy drafted before the inventory governs an environment you imagined rather than the one you have. We recommend you spend the first week counting and the second week drafting, because the count nearly always changes the draft.

Overview

• A policy is a decision table, not a warning. Staff need to know which tool for which data, stated so plainly it needs no interpretation.
• The inventory comes first. Every rule you write references something, and you cannot reference tools you have not found.
• Name behaviors, not products. A policy listing brand names is obsolete the next time a vendor ships an AI feature into software you already approved.
• Consequential decisions need the hardest language. Employment, lending, housing, insurance, healthcare, and education are where legal exposure concentrates.
• A published exception path prevents more shadow AI than any prohibition. People route around slow approval, not around rules.

The 5 Why’s

This is written for IT directors, security leads, compliance officers, and operations executives at organizations between roughly one hundred and a few thousand employees where AI adoption has already happened and governance has not. The typical situation is a Microsoft 365 tenant with Copilot available, developers using coding assistants, two or three departments running their own tools, and no document anyone could point to if asked.

The trigger is almost always external. A customer questionnaire asks whether you have an AI use policy. An insurer’s renewal application asks the same. An auditor requests an inventory of AI systems touching regulated data. A board member asks what would stop an employee pasting a client file into a public tool. Occasionally the trigger is internal and less comfortable, when someone discovers a tool already connected to a production system.

Sector conditions change the stakes. Healthcare organizations face protected health information moving into tools whose data handling terms nobody read. Financial services firms carry third-party risk and model governance expectations. Legal and professional services firms hold client confidentiality duties that predate this technology entirely. Defense and aerospace suppliers face controlled unclassified information and export-controlled data moving into systems outside an assessed boundary, which converts a tool choice into a compliance boundary question.

The consequence of having no policy is not usually a dramatic breach. It is being unable to answer a straightforward question about what your organization uses and what those tools can reach.

Why Most AI Policies Fail Within a Month

The failures are consistent and they are all fixable at drafting time.

They are written as prohibition. A policy whose operative content is a list of things you may not do gives staff no way to accomplish the work they were trying to accomplish. People then use the tool anyway and stop telling anyone, which is a worse outcome than the one the policy was written to prevent.

They name products instead of behaviors. An approved-tools list is necessary, but the rules around it have to describe conduct. AI features now arrive inside software you already approved, shipped in a vendor release you did not evaluate, which means a policy built on brand names has gaps the day it publishes. Write rules about data categories and actions, then maintain the product list separately.

They are drafted before the inventory exists. This is the most common and the most expensive. A policy referencing approved tools, data classifications, and integration rules is meaningless if nobody has established what is running, what it touches, and what it can do. That inventory is the deliverable the policy depends on, and it is where we start during an IT assessment on AI governance.

Nobody owns them. A policy without a named owner and a review cadence describes the organization as it existed on the day it was written. Given how fast the tooling changes, that is a short shelf life.

They ignore the part that matters most. Nearly every policy we read addresses what people type into chatbots. Far fewer address what AI systems are permitted to do: which ones hold credentials, what they can read and write, and whether anything acts without a person approving it. That is the exposure covered in our post on AI security risks for business, and a policy that stops at data entry leaves it entirely unaddressed.

What Belongs in an AI Acceptable Use Policy?

Nine sections, and the order matters because each one references the ones before it.

Scope and definitions. State what counts as an AI system for this policy’s purposes: standalone assistants, coding assistants, AI features embedded in existing applications, meeting transcription and note-taking tools, and any agent or integration that acts on your systems. Transcription tools deserve explicit mention because they are widely adopted without review and they capture everything said in a meeting.

Approved tools with data classifications attached. The core of the document. A table mapping your data categories to the tools permitted to handle each. Not “do not enter confidential data,” which requires every employee to make a judgment call, but a matrix that answers the question for them.

Data handling rules in plain language. Name the categories that may never leave your environment in terms staff recognize, using your actual vocabulary rather than classification labels nobody remembers.

Prohibited uses. This section carries the legal weight, and it should be specific. AI output must not be the sole basis for a consequential decision about a person: hiring, promotion, termination, discipline, credit, insurance, housing, clinical care, or academic standing. Every state AI regime now in force or arriving converges on that category, so it is the one place worth being categorical rather than cautious.

Human accountability. The person who uses AI output owns it. That single sentence resolves most edge cases and is worth stating exactly that way.

Disclosure requirements. When AI involvement must be disclosed, covering client deliverables, external communications, and code contributions. Organizations with European market exposure should note the EU AI Act’s transparency obligations, which apply from August 2026 and include telling people when they are interacting with an AI system.

Agent and integration rules. Anything that acts rather than suggests requires review before deployment, scoped to least privilege, with logging attributable to an identity. No standing credentials, and human approval required for consequential actions such as sending external mail, moving money, changing permissions, or committing code.

Vendor terms requirements. What must be true of a tool’s contract before it can be approved: whether prompts and outputs are used for training, retention periods, subprocessors, and whether the agreement is an enterprise one with those commitments in writing rather than a consumer signup.

Exception process. How to request something not on the list, who decides, and how long it takes. Publish the turnaround time.

The weighting shifts by obligation. Organizations handling protected health information, controlled unclassified information, or export-controlled technical data should invert the default: denial unless approved, with the boundary defined before the tool list. In those environments the policy is a compliance control rather than a guidance document, and it needs to name which systems sit inside the assessed boundary. Organizations with no regulated data can run a permissive policy with a short prohibited list and get most of the value with far less friction.

What we recommend you do about it:

• Write the data-to-tool table first. It is the section people will actually read and the only one that answers their real question.
• Be categorical about consequential decisions. Every state regime targets them, and hedged language here is the expensive kind.
• Use one sentence for accountability. The person using the output owns it. Do not elaborate.
• Cover what AI systems can do, not only what people type. Read versus write, standing credentials, and approval for consequential actions.
• Publish the exception turnaround time. A week with an answer beats an indefinite wait, and it is what prevents workarounds.

How Do You Build the AI Inventory the Policy Depends On?

Cross-reference five sources. No single one is complete, and the overlap between them is what produces a list you can defend.

Identity provider logs and consent grants. Sign-in records show which applications people authenticated into with work accounts. Consent grants are more important and more overlooked, because they show what has standing access to your data rather than who logged in where.

Financial records. Accounts payable and corporate card statements surface paid subscriptions nobody disclosed, because somebody had to pay. Twelve months of records produces a longer list than most IT teams expect, in an afternoon.

Network egress and DNS data. Catches free tools that generated no invoice, which is where a substantial share of usage sits.

Vendor release notes for software you already approved. The step almost everyone skips. Your existing applications have shipped AI features, some enabled by default, and those are in scope whether or not you evaluated them. Review the tools already on your approved list before hunting for new ones.

The people who work there. Ask department by department, framed as inventory rather than enforcement. People conceal tools when disclosure sounds like an accusation.

Record the same fields for every entry or the inventory will not be usable: tool name, business owner, data categories it touches, whether it can read only or also write, whether it authenticates through single sign-on, whether it holds credentials or tokens into other systems, the vendor’s training and retention terms, whether it sits inside a compliance boundary, and a review date. Organizations with a cloud access security broker or SaaS management platform can automate most of the discovery and should shift their effort to maintaining these fields. Smaller teams get most of the value from a manual pass repeated annually against the budget cycle. Environments with heavy contractor or field workforces need a sixth source, since tools adopted by people outside your directory appear in neither your identity logs nor your accounts payable.

What we recommend you do about it:

• Start with accounts payable. Highest yield, lowest effort, and it usually reframes the whole project.
• Pull consent grants, not just sign-ins. Standing access matters more than login history.
• Audit the AI features in tools you already approved. This is the gap that makes most inventories wrong.
• Record what each system can do, not just what it is. Read versus write is the field that determines risk.
• Publish a partial inventory rather than waiting for a complete one. An incomplete list you maintain beats a perfect one you never finish.

Who Owns It, and How Does It Stay Current?

One named person, with the policy and the inventory attached to processes that already run. Split ownership between security, IT, and legal produces a document nobody updates, which is the state most organizations are in.

Ownership usually sits best with security or IT, with legal reviewing the prohibited-uses and disclosure sections and business leadership approving the tool list. What matters is that a single person is accountable for the inventory being current and the policy being accurate, and that this appears in their objectives rather than in a project plan that ends.

Staying current means attaching the work to existing cadences rather than inventing new ones. Procurement intake should trigger an AI review whenever a tool will hold company data, use company credentials, or connect to another system, and that trigger should be data-based rather than price-based, because most AI tooling costs less than the threshold that would otherwise catch it. Onboarding and offboarding should reference the inventory, since unmanaged tools are exactly the ones that survive a termination. Vendor risk review should cover AI subprocessors. Incident response should include a scenario where an agent takes an unauthorized action.

On the regulatory side, the practical approach is to align to one framework rather than tracking every jurisdiction. The state picture is a patchwork that changes quarterly, obligations attach to where your employees and customers are rather than where you are headquartered, and thousands of bills are in circulation. Building your program against the NIST AI Risk Management Framework gives you a defensible posture across most of it, and Texas explicitly offers an enforcement safe harbor for substantial compliance with that framework. Organizations making consequential decisions about people in Colorado, Illinois, California, or under New York City’s rules should have counsel confirm the current position, since several of these statutes have been amended, delayed, or replaced within the past year.

What we recommend you do about it:

• Name one owner and put it in their objectives. Not a committee, and not a project with an end date.
• Make the procurement trigger data-based, not price-based. AI tools are priced below the threshold that would catch them.
• Reference the inventory in onboarding and offboarding. Unmanaged tools are the ones that outlive an employee.
• Align to NIST AI RMF rather than tracking jurisdictions. One framework, defensible broadly, with safe harbor value in at least one state.
• Review quarterly, and on trigger. New tool, changed vendor terms, new compliance obligation, or an agent gaining write access.

Where to Start This Quarter

Two weeks of work produces something most organizations do not have. Spend the first counting and the second writing, in that order, because the count changes what you write.

Pull twelve months of software spend, your identity provider’s consent grants, and the release notes for the applications already on your approved list. That gives you a working inventory. Record what each tool touches and what it can do, since those two fields drive every decision that follows. Then draft the data-to-tool table, the prohibited uses covering consequential decisions, the one-sentence accountability rule, the agent and integration rules, and the exception process with a published turnaround.

Then name the owner, attach the review to a cadence that already exists, and add the procurement trigger. That is the whole program, and none of it requires new tooling or slowing adoption, which is the objection that stalls these projects before they start.

If you cannot currently produce a list of every AI system with access to your data, the policy is not the first deliverable. The list is. Contact Mindcore to request an AI inventory and governance review.