Before you write an AI policy, answer these five questions

Every CIO has the same document sitting in a shared drive right now: a half-finished AI policy, started with good intentions, stalled somewhere between “define acceptable use” and “figure out what Legal actually meant by that.”

Most AI policies are written backward. They start with rules before anyone has agreed on what problem the rules are solving. The result is a policy that reads well in a board deck and does almost nothing to change behavior on the ground, where employees are already pasting customer data into free chatbot tools and connecting AI assistants to file storage without asking anyone’s permission.

A policy built on assumptions instead of answers is a policy you’ll rewrite in six months, after the audit finding or the near miss that could have been avoided.

So before you draft another version of the policy, or hand the task to someone on your team with instructions to “make something like what Company X published,” sit with five questions. They’re not technical questions, but they’re the ones that determine whether your policy actually governs behavior or just documents intentions.

Question 1: What are we actually trying to govern?

This sounds obvious, but isn’t.

“AI” is not one thing inside your organization. It’s embedded across the tools your employees use every day, from the LLM embedded in your CRM, the browser extension an employee installed last week, or the agent with standing permissions to read email and draft responses. 

Treating all of that as a single governance category is how policies end up either too vague to enforce or too rigid to survive contact with how people actually work.

Before you write a word of policy, get specific about scope. Are you governing:

• Generative AI tools employees choose to use, like ChatGPT, Claude, or Gemini accessed directly
• AI features embedded in existing SaaS applications, often enabled by default and invisible to procurement
• Autonomous or semi-autonomous agents that can take action, not just generate text
• Data flows into and out of AI systems, regardless of which tool is doing the processing

Most organizations need to govern all four, but not with the same mechanisms or the same urgency. A policy that treats a marketing team’s use of an AI writing assistant the same way it treats an agent with access to your identity provider is a policy that will be ignored by one group and will slow the other down when speed actually matters.

Get precise about scope first. Everything else in the policy follows from this.

Question 2: Who owns the decision when a new AI tool shows up unannounced?

It will happen because it’s probably already happening.

An employee finds an AI tool that solves a real problem, signs up with a work email, and starts using it before anyone in IT or security knows it exists. It’s the newest version of shadow IT, also known as shadow AI. The difference is that shadow AI moves faster than the shadow IT of five years ago because the barrier to adoption is a single login, not a procurement cycle. 

A policy needs to name an owner for this moment because without one it is simply a wish. When ownership is unclear, the default owner becomes whoever notices first (usually security) reacting after the fact rather than governing in advance.

Before you write the policy, resolve:

• Who is accountable for evaluating a new AI tool request, and how fast can they turn around an answer
• What happens when the answer is “no” but the business need is real and urgent
• Whether there’s a fast-track path for low-risk tools versus a deeper review for tools touching sensitive data or critical systems
• How you’ll find the tools nobody asked permission to use in the first place

That last point matters more than most policies acknowledge. You can’t govern what you can’t see. Increasingly, CIOs are realizing visibility into SaaS and AI usage across the organization, not just the tools on an approved list, is the actual prerequisite for enforcement.

A policy without a discovery mechanism behind it is a policy that governs the tools you already knew about. 

Question 3: What happens to the data, specifically?

Every AI policy says something about protecting sensitive data. Almost none of them answer the question an employee actually has in the moment: can I paste this into the tool or not?

Vague data guidance produces one of two outcomes: either employees interpret it generously and put things at risk OR they interpret it conservatively and stop using AI tools altogether and quietly work around the policy to get their jobs done. Neither outcome is what you wanted.

Before you write the data section of your policy, work through it at the level of specificity your employees will need:

• What categories of data are off-limits for any AI tool, full stop (customer PII, financial data not yet public, source code, credentials)
• What categories require a specific enterprise agreement or data processing addendum before use
• Whether your existing AI tools retain, train on, or log the data submitted to them, and how you’d know if that changed
• How this applies differently to AI features embedded in tools you already trust, like AI-assisted search in your existing platforms, versus standalone AI products

This is also where a lot of CIOs discover a gap they didn’t expect: most organizations don’t have a current, accurate inventory of which SaaS applications have already turned on AI features, or what those features have access to. You can’t write precise data guidance for tools you can’t fully account for. Before the policy language gets finalized, it’s worth an honest look at what’s actually running in your environment and what those applications can already see.

Question 4: Where does human judgment stay in the loop, and where does it need to?

The instinct with AI governance is often to write rules about what the AI is allowed to do, but the more useful frame is to write rules about where a human is required to check the AI’s work before anything happens.

This distinction matters because AI capability is moving faster than any policy can track feature by feature. A policy that lists specific prohibited use cases will be outdated within a quarter. A policy that establishes clear human-in-the-loop checkpoints, tied to risk level rather than tool name, ages much better.

Think through this in tiers:

• Low-stakes, reversible actions (drafting an email, summarizing a document) can often run with light or no human review
• Medium-stakes actions (sending external communications, updating records) should have a human confirm before anything goes out
• High-stakes or hard-to-reverse actions (changing permissions, deleting data, modifying financial records) need explicit human approval, every time, with an audit trail

This is where the policy conversation starts to intersect directly with how AI agents are actually built into enterprise platforms today. The organizations getting this right aren’t relying on employee discipline alone. They’re choosing tools and platforms that build human-in-the-loop checkpoints and reversible actions into the workflow itself, so the safeguard exists in the system, not just in the policy document. If your policy assumes a level of manual oversight your tools don’t actually support, that’s a gap worth closing before enforcement, not after.

Question 5: How will you know if the policy is working?

Most AI policies are written as static documents. They get published, linked in an onboarding packet, and revisited when something goes wrong. 

A policy that’s actually working produces evidence, not just compliance sign-offs. Before you finalize anything, decide how you’ll measure whether the policy is doing its job:

• Can you see, in near real time, which AI tools are in use across the organization, sanctioned or not
• Do you know which of those tools have access to sensitive systems or data, and whether that access changed recently
• Is there a clear, low-friction path for employees to request a new tool, so the policy invites compliance instead of inviting workarounds
• Are you reviewing AI tool sprawl on a regular cadence, the same way you’d review any other access or security control

If the honest answer to most of these is “not yet,” that’s not a failure. It’s useful information. It tells you the policy needs an operational layer underneath it, some combination of visibility tooling, access management, and lifecycle processes, before the written rules can actually hold.

Why this matters more now than it did a year ago

A year ago, an imperfect AI policy was a manageable risk. Adoption was still early enough that the gap between what the policy said and what employees actually did was relatively small. That gap has widened fast.

AI features are now bundled into applications your teams already use, agent-based tools are gaining standing permissions rather than one-off access, and the pace of employee experimentation has outrun most procurement and security review cycles.

That shift changes what a policy needs to do. Just stating principles and trust that awareness will drive compliance isn’t enough. The organizations staying ahead of this are treating AI governance the way they’d treat any other fast moving access control problem: with ongoing visibility, clear ownership, and processes that can adapt as the tools themselves keep changing. A static policy written for a slower moment in AI adoption will feel outdated within a quarter.

This is also why the five questions above are worth answering honestly, even when the honest answer is uncomfortable. A CIO who can say “we don’t yet have visibility into every AI tool in use” is in a stronger position than one who assumes the policy alone will keep pace. The first is a solvable operational gap. The second is a false sense of security that tends to surface at the worst possible time, usually during an audit, a customer security questionnaire, or a data incident that traces back to a tool nobody remembers approving.

The real work happens before the document

None of these five questions have a universal right answer. The answer depends on your industry, your risk tolerance, your existing tech stack, and how mature your SaaS and identity governance already is. That’s exactly the point. A policy template pulled from another company’s website will never account for the specifics that make your environment different from theirs.

What every CIO can control is whether the policy gets built on a foundation of real answers or a foundation of assumptions. Organizations that get AI governance right tend to do the unglamorous work first: getting visibility into what’s actually running, understanding where data flows, and building operational processes that can enforce a decision, not just state one.

The policy document itself, once you get here, tends to write itself in a few pages. The five questions are where the real strategy lives.

If your team is still working through what visibility into AI and SaaS usage actually looks like in practice, that’s a conversation worth having before the policy goes to final draft, not after the first incident makes it urgent.

Turn your AI policy into enforceable governance with BetterCloud. Request a demo.