The typical AI policy is a PDF approved by legal, announced once and forgotten 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.
None of that is fixed by a longer document. It is fixed by structure, and the structure is blocked by six beliefs that sound prudent and are wrong. Each section below takes one, says what is true instead, and gives the piece of the policy that follows from it.
Myth: a good policy names the approved tools
Products change monthly; data and use change slowly. Key the policy to the slow things. 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 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. Two things decide the lane: the class of data involved and what the AI is being asked to do.
Approved means the sanctioned assistant, internal data allowed, logged with no review; allowed with conditions means public data only, review before sending and a named owner per use; prohibited covers customer PII in personal accounts, autonomous payments and unvetted plugins or MCP servers. Most of the policy's value is in making the first lane easy.
Use the data classification you already have. If you have none, four classes are enough: public, internal, confidential and restricted, where restricted covers customer personal data, credentials, regulated data and anything under a contractual confidentiality duty. Then add the dimension older policies never needed: whether the AI only produces text for a person to use, or takes actions on its own.
| Data class or use | Approved | Allowed with conditions | Prohibited |
|---|---|---|---|
| Public | Any sanctioned tool | Unsanctioned tools, without signing in with company credentials | None |
| Internal | Sanctioned assistant under a company account | Sanctioned coding assistant in approved repositories | Personal accounts on any AI tool |
| Confidential | Sanctioned assistant with a no-training contract | Summaries for internal audiences, reviewed before sharing | Any tool without a contract that covers retention and training |
| Restricted (customer PII, credentials, regulated data) | Approved AI systems designed for that data, through the gateway | Redacted or tokenized extracts, with the data owner's approval | Personal accounts, unapproved tools, unvetted plugins or MCP servers, and pasting credentials anywhere |
| Agent actions inside the company | Reads and reversible changes by approved agents | Irreversible changes with a person approving in production | Agents without a named owner |
| Agent actions outside the company | None by default | Outbound messages a person approves | Autonomous payments and access changes |
Products go on an internal page the owner updates. The policy says “the sanctioned assistant listed on the AI tools page”, so adding a tool is a page edit, not a policy revision.
Myth: a prohibition reduces risk on the day it is announced
A prohibition with no approved alternative does not stop the work. It moves it somewhere you cannot see. Picture a fictional regional accounting firm of about 1,200 people whose old policy banned all generative AI except one assistant. A first discovery pass would likely find eleven AI tools in use, and staff pasting client workpapers, full of client names and financial details, into a free chatbot to draft summaries. Blocking the chatbot on day one would move that work to phones; giving staff an approved summarization path first, then blocking with a message that links to it, would not.
So sequence the rollout around the yes. Four weeks is enough for a company of that size.
- 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.
- Week 2: publish the approved lane. 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.
- Week 3: publish the full policy with a short training session built around the three lanes and the request process. Record completion.
- Week 4: switch the prohibited lane's controls from monitoring to enforcement, starting with restricted data. Announce the date in advance and staff the request queue that week.
If you operate in or sell into the EU, the training step also meets 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].
The most important clause in the policy is the one that answers requests. “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.” Pick a number you can meet. A policy that answers quickly gets requests; one that answers slowly gets shadow use.
Myth: careful legal wording makes a clause enforceable
A clause is enforceable when something checks it. Write each one in one or two sentences, say who it applies to, and describe something observable. If no control can check a clause, 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.
- 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.
- 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.
Then map every clause to the control that applies it and the 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.
Each clause points to a control that applies it and to the evidence that control produces. If you cannot fill in the right-hand column, the clause is not yet enforced.
| Policy clause | Control | Evidence | Reviewed by |
|---|---|---|---|
| No customer data in unapproved AI tools | Gateway DLP on sanctioned paths, plus discovery of unsanctioned AI apps and grants | Redaction events by data class; discovery findings and their resolution | Policy owner, monthly |
| People approve outbound messages sent by agents | Approval rule on outbound tools | Approval records with approver, time and the exact message approved | Agent owners, weekly sample |
| Exceptions expire | Named exception with a 7-day default and 90-day cap | Exception log showing scope, approver, expiry and renewals | Policy owner, quarterly |
| Every agent has a named owner | Agent inventory with a required owner field | Inventory export; agents without an owner flagged as findings | Security engineering, monthly |
| Use company accounts for approved tools | Single sign-on enforced on sanctioned tools | Identity provider sign-in logs and AI-app grant reports | IT, quarterly |
| Review AI output before it leaves the company | None technical; training and manager review | Training completion records | People managers |
Keep the last row. Some clauses depend on human judgment, and pretending otherwise produces controls that block legitimate work or evidence nobody believes. The owner row matters for another reason: GOVERN in the NIST AI RMF calls for an inventory of AI systems, resourced by risk priority [1], and a required owner field is the cheapest way to start one.
Myth: a committee can own it, and exceptions are one-offs
A committee can advise. It cannot own. The policy needs one named person who decides lane changes, answers requests, approves exceptions and runs the review. 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 policies quietly fail. A team gets permission to use a tool for one project, and two years later it is still in effect for everyone, granted by an email nobody can find. 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: either the use belongs in the conditional lane with defined limits, or an approved tool should meet the need.
Myth: measuring adherence means reading what people type
Measure the system, not the people. Adherence shows in metadata: which paths AI traffic takes, which data classes trigger redaction, how many exceptions exist and how old they are. Content review should happen only after a control has detected a likely violation, by a small named group, with that access itself logged.
- Share of AI use that goes through sanctioned paths, tracked monthly. This is the headline number.
- 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 follows.
- Self-reported accidental disclosures. A rising count early on usually means trust is working, not that behavior got worse.
Skip leaderboards of offenders and per-person dashboards shared with managers. They push work onto devices and accounts you cannot see, which leaves you with less information and more risk.
Myth: the policy is finished when legal signs it
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: repeated requests that should become approved or conditional uses, exceptions renewed more than once, 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 only what got stricter.
Clauses a gateway can hold for you
For AI traffic routed through it, Intertrace detects and redacts PII and secrets in requests, responses and tool-call arguments under an organization data policy agents can only tighten. It makes outbound messages, payments and admin changes ask a person, and records exceptions as named, agent-scoped and expiring (seven days by default, ninety at most). Read-only discovery of AI-app grants, repositories and provider keys supplies the baseline. Every decision is a structured event you can export to your SIEM as evidence.
None of this starts without one decision, and it belongs to whoever sponsors the policy: name the owner, publish the name, and give that person the request queue and the exception log this week. Everything else in this guide is work that person can schedule. Without them, it is a PDF again.
