An AI acceptable-use policy people will actually follow

The typical AI policy is a PDF approved by legal, announced once, and forgotten by the following week. It names three tools that were popular when it was drafted, forbids sharing confidential information without saying what counts, and offers no way to ask for something new. People respond rationally: they keep using whatever helps them do their job and hope nobody asks.

Three design failures cause most of this. The policy is keyed to products, which change monthly, rather than to data and use, which change slowly. It prohibits without offering an approved alternative, which turns a policy into a reason to hide. And its clauses cannot be checked, so the only enforcement mechanism is an incident. The fixes are structural, and none of them require a longer document.

Write it in three lanes, keyed to data and use

Every AI use falls into one of three lanes. Approved means sanctioned tools, used with company accounts, where internal data is allowed and use is logged but needs no case-by-case review. Allowed with conditions means permitted only within stated limits, such as public data only or a human review before anything is sent, with a named owner for each use. Prohibited means not allowed under any account or tool without a formal exception. The lane is decided by two things: the class of data involved and what the AI is being asked to do.

Use the data classification you already have. If you do not have one, four classes are enough to start: public, internal, confidential and restricted, where restricted covers customer personal data, credentials, regulated data and anything under a contractual confidentiality duty. Then add one dimension that older policies never needed: whether the AI only produces text for a person to use, or takes actions on its own.

Name products only in an appendix or on an internal page that the owner updates. The policy should say “the sanctioned assistant listed on the AI tools page” so that adding a new tool is a page edit rather than a policy revision.

Sample clause language: short, plain, checkable

Each clause should be one or two sentences, say who it applies to, and describe something that can be observed. If a clause cannot be checked by any control, either rewrite it or label it plainly as guidance.

• Use the sanctioned AI assistant, listed on the AI tools page, for work that involves internal or confidential data. Sign in with your company account.
• You may use other AI tools with public information only. Do not paste customer data, source code, credentials or unreleased financial information into them.
• Never use a personal AI account for company work that involves customer personal data.
• Review AI output before it leaves the company. You are accountable for what you send, whoever or whatever drafted it.
• AI agents may not send external messages, move money or change access without a person approving the action, unless an approved exception covers it.
• Every AI agent has a named human owner, recorded in the agent inventory, who is accountable for its access and behavior.
• To use a tool or data source that is not approved, submit a request on the AI tools page. Requests are answered within five business days.
• If you think you shared data you should not have, report it within one business day. Reporting is not a disciplinary matter; hiding it may be.

The five-day and one-day windows are examples; pick numbers you can meet. The request clause matters more than any prohibition. A policy that answers requests quickly gets requests. One that answers slowly gets shadow use.

Name one owner and make every exception expire

The policy needs one named person who decides lane changes, answers requests, approves exceptions and runs the quarterly review. A committee can advise, but it cannot own. The NIST AI RMF's GOVERN function calls for documented roles, responsibilities and lines of communication for AI risk, and for executive leadership to take responsibility for decisions about AI risk [1]. The owner is how that shows up in practice.

Exceptions are where most policies quietly fail. A team gets permission to use a tool for one project, and two years later that permission is still in effect for everyone. Treat each exception as a record with a requester, a named scope (which people or agents, which data, which tool), a reason, an approver and an expiry. Default to seven days and cap at ninety. Renewal requires a fresh reason and evidence that the conditions held.

An exception renewed twice is a signal, not a nuisance. Either the use belongs in the conditional lane with defined limits, or the underlying need should be met by an approved tool. Bring those to the quarterly review.

Map every clause to a control and to evidence

A policy becomes enforceable when each clause has a control that applies it and evidence that shows the control ran. ISO/IEC 42001 frames AI governance as a management system to be established, implemented, maintained and continually improved [2]; the clause-to-evidence chain is what makes that cycle auditable rather than aspirational. It also forces honesty: a clause with no control is training content, and you should say so.

Keep the last row. Some clauses depend on human judgment, and pretending otherwise produces controls that block legitimate work or generate evidence nobody believes. GOVERN also calls for an inventory of AI systems, resourced by risk priority [1]; the owner row above is the cheapest way to start one.

Roll it out in four weeks

Consider Fernhill Insurance, a fictional regional insurer of about 1,200 people. Suppose its old policy banned all generative AI except one assistant, and a first discovery pass finds eleven AI tools in active use. Here is a four-week rollout that would work for a company like that.

1. Week 1: establish a baseline. Run discovery across identity-provider app grants, network and browser traffic, code repositories and AI provider accounts. Do not act on individuals; you are measuring the starting point.
2. Week 2: publish the approved lane first. Make sure the sanctioned assistant works with company sign-in and covers the most common uses the baseline revealed. People need a yes before they will respect a no.
3. Week 3: publish the full policy with a short training session built around the three lanes and the request process. Record completion.
4. Week 4: switch the controls for the prohibited lane from monitoring to enforcement, starting with restricted data. Announce the date in advance and keep the request queue staffed that week.

If you operate in or sell into the EU, the training step also serves an existing obligation. Article 4 of the AI Act requires providers and deployers of AI systems to take measures to support the AI literacy of their staff and others operating AI on their behalf, taking into account context and the people affected [3]. The Commission says the obligation has applied since 2 February 2025, that no certificate is required, that internal records of training are sufficient, and that it covers staff using general-purpose tools such as chat assistants at work [4].

What goes wrong in practice

At Fernhill, the baseline would likely show claims adjusters pasting claim notes, which contain policyholder names and medical details, into a free chatbot to draft summaries. Blocking the chatbot on day one would only move the work to phones. The better sequence is to give adjusters an approved summarization path for restricted data first, then block the prohibited use with a message that links to it.

• Enforcement arrives before the approved alternative works, so the first experience of the policy is a block with nowhere to go.
• The policy forbids confidential data without defining it, and every team interprets the word differently.
• Exceptions are granted by email and never recorded, so nobody can tell which are still in effect.
• Agents are treated as tools rather than as actors, so nothing in the policy covers an agent that sends mail or moves money on its own.

Measure adherence without surveillance theater

Measure the system, not the people. Adherence is visible in metadata: which paths AI traffic takes, which data classes trigger redaction, how many exceptions exist and how old they are. None of that requires reading anyone's prompts. Content review should happen only when a control has already detected a likely violation, by a small named group, with the access itself logged.

• Share of AI use that goes through sanctioned paths, tracked monthly. This is the headline number.
• Count of unsanctioned AI tools with active use, and how many were closed by approving an alternative rather than by blocking.
• Redaction events per thousand requests, by data class. A rising rate in restricted data points to a workflow that needs an approved tool.
• Open exceptions, their median age, and how many expired without renewal. Expired is healthy.
• Median time to answer a tool request. If this climbs, shadow use will follow.
• Self-reported accidental disclosures. A rising count early on usually means trust is working, not that behavior got worse.

Avoid leaderboards of offenders and per-person dashboards shared with managers. They encourage people to move work to devices and accounts you cannot see, which leaves you with less information and more risk.

Revise it every quarter, on a fixed agenda

The NIST AI RMF calls for ongoing monitoring and periodic review of the risk management process, with clear roles [1]. A quarterly review with a fixed agenda keeps that from becoming open-ended. Review the request queue and decide which repeated requests should become approved or conditional uses. Review exceptions renewed more than once. Review incidents and near misses, the metrics above, vendor contract changes and new legal obligations. Publish a short change log with a version number, and tell people what got easier, not just what got stricter.

Where enforcement can live

Several controls in the map can be held by a runtime gateway for AI traffic you route through it. Intertrace detects and redacts PII and secrets in requests, responses and tool-call arguments under an organization data policy that agents can only tighten. It requires a person to approve outbound messages, payments and admin changes, and records exceptions as named, agent-scoped and expiring (seven days by default, ninety at most). Read-only discovery of identity-provider AI-app grants, repositories and provider keys supplies the baseline and the unsanctioned-tool count. Every decision is a structured event you can export to your SIEM as evidence; clauses that depend on human review still need the training and management practices described above.

What to do this quarter

1. Name the policy owner and publish the name. Give that person the request queue and the exception log.
2. Rewrite your current policy into the three lanes using your existing data classification, and move product names to an internal tools page.
3. Build the clause-to-evidence table. Mark every clause with no control as guidance, and choose the two most important to enforce first.
4. Run a discovery baseline before announcing anything, so you can measure change.
5. Convert every open exception into a record with scope, approver and expiry; anything without an owner expires in seven days.
6. Ship the approved lane, then the training, then enforcement of the prohibited lane, in that order.
7. Put the first quarterly review on the calendar with the agenda above, and commit to publishing the change log.