TL;DR. Most AI policies stall in draft while the workforce picks its own tools. The fix is a one-page policy that names approved tools, names off-limits data, names the owner, and ships in two weeks. Policy follows tools. Tools don’t follow policy.
There’s a pattern most companies land in. Somewhere in the organization, a forty-page AI governance framework sits in version 0.7. Legal owns it. IT was supposed to review it last quarter. Someone from risk has comments. The committee meets again next month.
Meanwhile, the highest-output people have already chosen their tools. Some are paying out of pocket. Some are using personal accounts on work laptops. Some are pasting customer records into a model whose data terms nobody in procurement has read. They’re not waiting for the policy. The work doesn’t pause for committees.
The gap between the draft policy and the actual behavior is where the real risk lives.
Why the forty-page version doesn’t work
The default move when an executive says “we need an AI policy” is to convene the committee. Legal, IT, security, HR, compliance, sometimes a line-of-business sponsor. Six months later there’s a document. It defines artificial intelligence. It cites the EU AI Act and the NIST AI Risk Management Framework. It enumerates seven categories of risk. It includes a sign-off form. Forty pages, written in the voice of an outside law firm, approved by everyone who will never use it.
Nobody reads it. Nobody can find it when they need it. The director who’s about to upload a contract to a chatbot isn’t going to scroll to PDF page nineteen to check whether she’s allowed to. She’s going to upload the contract.
The policy fails for three structural reasons.
It’s written by people who don’t use the tools, for people who do. The committee’s frame is risk classes. The user’s frame is “I have this document and this deadline.” The two never meet on the page.
It has no enforcement loop. Nobody’s monitoring whether the policy is being followed. There’s a signed acknowledgment in the LMS. That’s the entire compliance program. An acknowledgment isn’t a control.
It’s already obsolete. Vendor pricing changed last month. A new model launched yesterday. Data residency terms shifted. The forty-page policy can’t keep up because forty-page policies aren’t built to keep up. The cadence of the document is six months. The cadence of the market is two weeks.
The mechanism is straightforward. A long policy is a one-time artifact. The thing it’s trying to govern is continuous behavior. Static documents don’t govern continuous behavior. Available tools do.
The workforce already moved. The policy catches up.
While the forty-page version circulates for review, the workforce has moved. People found tools that help them do their jobs. They’re paying out of pocket or using personal accounts on work devices. Data is already flowing into models whose terms nobody in procurement has read. This isn’t a compliance failure. It’s a procurement gap, and the diagnosis is worth understanding in full.
The operational question isn’t how to stop them. It’s how to give them something approved before the next person pastes a client contract into a consumer-tier chatbot. That means the policy starts with a short list of tools you’ve actually procured under enterprise data terms, not a taxonomy of risk categories nobody will read at the moment it matters.
The right shape
A working AI policy has the shape of an internal operations memo, not a legal document. One page. Plain language. Updated on a fixed cadence. Owned by a named human, not a committee. Distributed where people work, not buried in a policy library.
The body of the policy is three lists.
Approved tools. The specific products, by name, your people are allowed to use for work. With links to where to request access and which plan tier they’re on. This list is short on purpose. Two or three is normal. One is fine. The list reflects what you’ve already procured under enterprise terms that protect your data. Anything not on the list isn’t approved, full stop. If a department head wants something added, there’s a one-paragraph request process. Approval or denial within two weeks. That cadence is the whole game.
Restricted data. The categories of information that don’t go into any AI tool, approved or not. Be specific to your business. Generic categories are useless. “Confidential information” isn’t a category. “Customer payment data, signed contracts, employee compensation, M&A working files, anything subject to a current NDA, anything covered by HIPAA, anything covered by attorney-client privilege” is a category. Five to eight specific lines. Not twenty. Twenty means nobody will remember any of them.
Logged and reviewed. What you actually monitor. For approved enterprise tools, this is admin-console usage data: who used what, how often, on what kind of prompt patterns where the vendor exposes them. For unapproved tools, this is whatever your endpoint or DLP stack catches. State the review cadence. Quarterly is the default. State who reviews it. Name the role, not the department.
That’s the policy. Three lists. The supporting metadata is four lines: owner (a named role), review cadence (quarterly is correct for now), the consequence for putting restricted data into any AI tool, and the date of the most recent update.
The whole document fits on one screen. A new hire reads it in two minutes. A manager forwards it without apology. A vendor sees it during procurement and recognizes a buyer who has thought about this.
The one-page policy, in full
Adapt the names and lists. Keep the shape.
[Company] AI Use Policy
Owner: [Head of IT or equivalent named role]. Last updated: [date]. Reviewed quarterly.
Approved tools. You may use the following AI tools for work. All other AI tools are not approved.
- [Tool A, plan tier, link to request a seat]
- [Tool B, plan tier, link to request a seat]
To request a new tool, email [owner] with the use case and the team. You will get an answer within two weeks.
Off-limits data. Do not put the following into any AI tool, approved or not.
- Customer personal or payment data
- Signed contracts or attorney-client communications
- Employee compensation, performance, or health information
- M&A, financing, or other material non-public information
- Anything covered by an active NDA
- Source code from [specific repos / acquired company codebases]
What we monitor. We review usage on approved tools quarterly: which seats are active, which are idle, which prompt patterns trigger data classifiers. We use endpoint controls to detect use of unapproved AI tools.
If you put off-limits data into an AI tool, tell [owner] within 24 hours. We will not punish a fast disclosure. We will treat a hidden one as a security incident.
That’s the entire policy. If yours is longer, try removing a sentence from the version above. You’ll find there’s nothing to cut.
Questions the policy forces you to answer
The forty-page version lets you defer the hard decisions by burying them. The one-pager surfaces them.
Which tools are on the approved list? This one can’t wait. If the answer is still “we’re evaluating,” that’s not a policy. It’s a backlog. Pick a primary chat tool with a real enterprise data agreement. Pick a coding tool if you have engineers. That’s enough to ship version one.
What’s the data agreement on each? Read it. Specifically: does the vendor train on your inputs by default, can you turn it off, where is the data stored, how long is it retained, what’s their notification policy on a breach. The reputable enterprise tiers from the major vendors all answer these acceptably as of this quarter. The free and consumer tiers don’t. That difference is the entire reason an approved list exists.
What’s the consequence for violating the off-limits list? “Up to and including termination” isn’t a useful answer because it’s the answer to every policy. Say the actual escalation. First instance with fast disclosure: documented, no penalty. First instance discovered later: written warning. Repeat: HR. Use of a personal account to circumvent a control: HR on first instance. The point isn’t to be punitive. The point is that a clear incentive structure exists and people can see it.
Who owns the policy? A person, not a department. The person who can update the approved-tools list when the market moves, run the quarterly review, and make the call when a manager asks for an exception. In most companies this is a head of IT or a CIO. In smaller companies it’s the COO or whoever is closest to the procurement seat. Not legal. Legal is an input. Owning the policy is an operational job.
Fourteen days is not aggressive. It matches the pace of the decisions.
The two-week timeline sounds fast until you map what actually happens. You’re not writing a document from scratch. You’re filling in a template with seven blanks, then getting three people to agree on the answers. Most of those answers already exist in someone’s head.
Week one: draft and review. Day one, open the template and fill in what you already know. You probably know the owner. You probably know the off-limits data categories — they’re the same categories you already restrict elsewhere, in your DLP rules, your NDA templates, your data classification scheme. The approved tools list is the only genuinely new decision, and you likely already know which tools your people are actually using. Pick the enterprise tiers of those. That’s the list.
Days two through five, send the draft to three people. Not a committee. Three named humans: the manager of your highest-output AI user, the head of IT, and someone from legal. You’re asking for line edits on a one-page document, not input on a governance framework. The framing determines the response. Frame it as a review of a finished draft and you get edits in three days. Frame it as a kickoff of a governance initiative and you get a meeting request for next month.
Week two: finalize and ship. Days six through eight, resolve whatever edits came back. Most will be wording on the off-limits list — legal will want a category or two added, and they’ll be right. Incorporate those. If someone proposes adding three pages of definitions, thank them and don’t. Days nine and ten, the owner signs off and the policy goes live. “Goes live” means it appears where people actually look: the company wiki, the Slack channel, pinned in the all-hands notes, linked from onboarding. Not uploaded to a policy library.
Days eleven through fourteen are buffer. You won’t need them all. Use whatever is left to set up the quarterly review calendar invite.
The kickoff message earns you speed or costs you a month
The message you send on day two determines whether this takes two weeks or twelve. Send it to the wrong people with the wrong framing and you’ll produce exactly the committee-driven process you’re trying to avoid.
Three recipients. Whoever runs IT, whoever represents legal’s view, and a line manager who sees AI usage on their team every day. The line manager is the one most companies skip. They’re the reality check on whether the off-limits list makes sense and whether the approved tools are the ones people actually want.
The message is short. It attaches the one-page draft. It says: this is going live in two weeks, here’s the current version, I want your edits by Friday. Not “your thoughts.” Not “your input on our AI governance approach.” Edits. On this document. By this date. The specificity is what makes it work. An open-ended request for input produces open-ended timelines. A request for line edits on a finished draft produces line edits on a finished draft.
If your organization requires broader sign-off, add one sentence: “I’ll circulate the final version to [executive sponsor] before it goes live.” That gives people confidence without turning the review into a consensus exercise.
Pushback is predictable. So are the answers.
Four objections come up in nearly every organization.
“Legal needs more time.” Ask: more time for what, specifically? If they need to verify data residency terms on the approved tools, that’s a concrete task and it fits inside two weeks. If they need to draft a comprehensive AI governance framework, that’s a different project. Let them do it. It doesn’t block this one. The one-page policy and the comprehensive framework aren’t the same deliverable. Ship the one-pager now. Let the framework take whatever time it takes.
“We need a committee.” You need decisions. A committee is one way to make them. A named owner with three reviewers is another. The committee will produce a better-debated result in six months. The owner will produce a good-enough result in two weeks. During those six months, the tools people are already using won’t have enterprise data terms.
“What about SOC 2 / ISO 27001 / [compliance framework]?” Those frameworks require that you have a policy. They don’t specify it be forty pages long. A one-page policy with named tools, named restrictions, a named owner, and a documented review cadence satisfies the control. Your auditor won’t object to a policy that’s clear, enforced, and current. They object to ones that are comprehensive, unenforced, and stale.
“The CTO wants to wait for the vendor evaluation.” Ship the policy with whatever tools you’ve procured under enterprise terms today. If that’s one tool, the approved list has one entry. The vendor evaluation changes the list, not the policy. When it concludes, the owner updates the approved-tools section in ten minutes. Waiting for a perfect list before shipping any list is how you end up with no list for six months.
The first quarterly review is where the policy becomes a program
Ninety days after shipping, the owner convenes the first review. Sixty minutes. Three to five people: the policy owner, someone from IT who can pull usage data, the same legal contact, and one or two department heads whose teams use AI the most.
Review three things. First, usage data from your approved tools — active seats, idle seats, spend, whether prompt-pattern monitoring flagged anything. Second, the approved-tools list: has the market moved, did any department request a new tool, is anything pending? Third, the off-limits list: any incidents, any near-misses, does it still reflect the categories that matter?
Three decisions come out of every quarterly review. Whether to add or remove a tool from the approved list. Whether to adjust the off-limits categories. Whether the current owner is still the right owner. Write the decisions down. Update the policy. Change the “last updated” date. Send the updated version to the same places you distributed the original.
That’s your governance program for the first year. One page. Quarterly updates. A named human. The forty-page framework can evolve in parallel if someone wants to write it. But the one-pager is the one that governs behavior, because it’s the one people read.
The heuristic
If you remember nothing else.
- One page or it doesn’t work. Length is the enemy of compliance.
- Three lists: Approved, Off-limits, Logged. That’s the policy.
- Tools precede policy. If you haven’t procured the approved tool, you don’t have a policy yet. You have a hope.
- Two-week SLA on requests. Faster than that is overkill. Slower than that creates shadow AI.
- Quarterly review by a named owner. Not annual. Not “as needed.” Quarterly, calendared.
- Off-limits data is specific to your business. Five to eight lines, named in your company’s vocabulary.
- Fast disclosure is rewarded. Concealment is the incident. This is the only sentence on culture you need.
Something to carry
Open a blank document. Write the seven lines that make up the one-page policy: owner, approved tools, off-limits data, what you monitor, the consequence, the review cadence, the last-updated date. Fill in what you can answer today. For the lines you can’t fill in, you’ve just produced the agenda for the next two weeks of work.
Send the draft to three people: the manager of your highest-leverage AI user, the head of IT, and the head of legal. Tell them you’re shipping a one-page policy in fourteen days and you want their edits, not their committee.