Stop Writing an AI Policy. Start Running One.

The question I get more than almost any other right now is some version of: "How do we write an AI policy?" It's a reasonable question. It's also the wrong place to start — and starting there is how organizations end up with a beautifully worded PDF that changes nobody's behavior.

Here's the uncomfortable backdrop. While leadership debates the wording of a policy, the policy vacuum is already being filled. Roughly half of employees admit to using unsanctioned AI tools at work (CIO), and about two-thirds of workers who use AI say they've done it even when they believed it wasn't allowed (Aona). Meanwhile 90% of executives are confident they have visibility into AI use in their organization (The Register). Those two facts cannot both be true.

So the goal isn't a document. The goal is governance that's actually running — a standing body that makes decisions, and a cadence that keeps making them as the technology moves. The policy is just the artifact that body produces and maintains. Write it second.

A policy nobody operates is just decoration

The reason most AI policies fail isn't bad wording. It's that they're treated as a one-time deliverable: legal drafts it, it gets emailed around, everyone nods, and it goes stale the week a new model ships. AI is moving too fast for a static document. A rule you wrote about "generative AI tools" six months ago may not even describe what your team is using today.

And the instinct to just ban it backfires. When 63% of employees think using AI without IT approval is fine and 38% have already pasted sensitive company data into a tool without permission (Aona), a blanket prohibition doesn't stop the behavior — it drives it underground, where you have zero visibility and all of the risk. The organizations getting this right give people a sanctioned path that's easier than the shadow one, and a body that keeps that path current.

What the policy itself should actually say

Keep the document short enough that people read it — one or two pages, not twenty. It exists to answer the handful of questions an employee actually has on a Tuesday afternoon. Everything else belongs in the committee's operating procedures, not the policy everyone is supposed to internalize.

• Approved tools, and how to request new ones. A living list of what's sanctioned and a fast path to add to it — so the answer to "can I use X?" is findable, not a guess.
• Data boundaries. Plain-language rules about what may and may not go into AI tools — customer data, PII, source code, anything covered by a contract or regulation.
• Human accountability. AI can assist a decision, but a named person owns the outcome. No "the model did it."
• Disclosure. When AI-generated work has to be labeled — to customers, in code, in published content.
• Where to go with questions. The committee, and how to reach it. A policy with no owner is a policy with no enforcement.

Notice what's not here: a long taxonomy of every conceivable AI use case. You can't anticipate them all, and trying makes the document obsolete on arrival. The policy sets principles; the committee handles the cases.

The real engine: a cross-functional AI committee

This is the part most "how to write an AI policy" advice skips, and it's the part that actually matters. The durable unit of AI governance isn't a document — it's a standing, cross-functional committee with the authority to make decisions and the cadence to keep making them. International standards have converged on exactly this: ISO/IEC 42001, the first management-system standard for AI, is built around an ongoing governance function rather than a one-off policy (ISO).

Keep it small enough to actually meet — six to nine people — with clear seats rather than open invitations. The seats that matter for a mid-size company:

• An executive sponsor with budget and the authority to make decisions stick. Without this seat, the committee is a book club.
• Legal / privacy, for contracts, regulation, and data obligations.
• Security / IT, for the tool stack, access, and data flows.
• A data or engineering lead, for what's technically real versus vendor marketing.
• HR / People, because most AI policy questions are really questions about how people work.
• Two business practitioners from the teams actually using AI — the single best defense against governance that's theoretically sound and operationally useless.

Resist the urge to make it bigger. A 20-person committee doesn't decide anything; it holds meetings. You want the smallest group that covers legal, security, data, people, and the front line.

How to structure the committee's work

A committee with no operating model becomes either a rubber stamp or a bottleneck. To avoid both, give it a real process. The NIST AI Risk Management Framework offers a clean backbone — its four functions, Govern, Map, Measure, and Manage, describe what an ongoing AI governance function actually does (NIST). Translated into a cadence a mid-size company can run:

• Govern — set the rules and own the policy. The committee owns the policy document, the approved-tools list, and the decision rights. This is the standing work: revisit the policy quarterly, not annually.
• Map — run an intake process. Anyone proposing a new AI use case submits a short intake: what it does, what data it touches, who's affected. This is how you surface use cases before they go rogue, not after.
• Measure — tier the risk. Score each use case low / medium / high on data sensitivity and impact. This is the most important mechanism the committee has — more on it below.
• Manage — decide, document, and monitor. Approve, approve-with-conditions, or decline; record the decision in a use-case registry; and revisit high-risk uses on a schedule.

That registry is quietly the highest-leverage thing the committee maintains. A simple inventory of every approved AI use case — its owner, its risk tier, and its review date — turns governance from a vibe into something auditable.

Risk-tiering is what keeps the committee from becoming a bottleneck

Here's the mechanism that makes the whole thing work at speed. Most AI use cases are low-risk — summarizing public documents, drafting internal text, writing boilerplate code. If every one of those has to wait for a monthly committee meeting, people route around you, and you're back to shadow AI. So pre-authorize the low-risk tier: if a use case touches no sensitive data and has a human reviewing the output, it's approved by default under the policy, no meeting required.

Reserve the committee's actual deliberation for the medium and high tiers — anything touching customer data, regulated information, automated decisions about people, or external-facing output. That's where careful review earns its cost. Spend your scarce governance attention on the 20% of cases that carry 80% of the risk, and let the rest move at the speed of work.

A governance body that reviews everything reviews nothing carefully. Tier the risk, fast-track the boring 80%, and save your attention for the cases that can actually hurt you.

The two failure modes to design against

Every AI committee fails in one of two directions. The rubber stamp meets, nods, and approves whatever shows up — governance theater that adds latency and catches nothing. The bottleneck takes its mandate so seriously that nothing ships without weeks of review, so the organization quietly stops asking. Both end in the same place: people working around the committee.

The fix for both is the same discipline I'd apply to any rollout — clear ownership and a bias toward enabling work, not blocking it. The committee's job is to make the safe path the easy path. If using AI responsibly is more friction than using it in the shadows, you've designed the system backwards.

How to start in the first 90 days

You don't need all of this on day one. A pragmatic sequence:

• Days 1–30: Stand up the body. Name the sponsor and the seats, hold the first meeting, and agree on a one-page charter — what the committee decides and how. Do this before the policy.
• Days 31–60: Ship the short policy and the tiering rubric. Publish the approved-tools list, the data boundaries, and the low / medium / high definitions. Give people a sanctioned path immediately.
• Days 61–90: Run real intake. Start logging use cases into the registry, fast-track the low-risk ones, and work a couple of real high-risk cases end to end to pressure-test the process.

By the end of a quarter you have something far more valuable than a polished PDF: a functioning body, a current policy, and a registry that tells you what AI is actually doing in your company.

The takeaway

If you take one thing from this: don't start by writing the policy. Start by standing up the people who will own it. The document is the easy, visible part — and on its own it changes nothing while shadow AI fills the gap. Governance that works is a small cross-functional committee, a short policy it keeps current, a risk tier that fast-tracks the harmless majority, and a registry that makes the rest legible. Build the committee first, let it write the policy second, and you'll have something that's still true — and still followed — a year from now.

A quick disclosure: standing up this kind of governance — the committee, the short policy, the operating cadence — is the sort of work my firm, Prosigliere, does through fractional technology leadership. If you'd want experienced help building it, you can reach us at prosigliere.com.

Sources: CIO: roughly half of employees use unsanctioned AI tools · Aona: shadow AI statistics 2026 · The Register: executives overconfident on shadow AI visibility · NIST AI Risk Management Framework Core · ISO/IEC 42001 AI management systems