- Generic AI policy templates fail because they're written before anyone maps how AI is actually being used.
- Start with discovery: audit what tools are in use, who's using them, and why, before writing any policy language.
- The same AI tool carries different risk depending on the department and the data it touches.
- A policy built this way earns real buy-in and needs a periodic review, not a one-time sign-off.
Most AI policies fail before anyone reads them, because most companies write the policy first and figure out how AI is actually being used second. A template gets pulled off the internet, a few paragraphs get swapped for the company name, and the document gets filed away. It covers risks the business doesn't have and misses the ones it does.
A policy that actually works starts somewhere else entirely: with a clear picture of how AI is already being used inside the business, who is using it, and why. Everything else, the approved tools, the data rules, the approval process, follows from those answers. Skip that step and the policy is a guess.
Start With Discovery, Not a Template
Before drafting a single rule, three questions need real answers, not assumptions:
- How is AI already being used across the company, sanctioned or not?
- Who is using it, and in which roles or departments?
- Why are they using it, and what business problem is it actually solving?
These three questions determine everything that follows. A policy built without them tends to either lock down tools nobody uses while ignoring the ones everyone already relies on, or apply the same restrictions to every department regardless of what they actually do.
Find Out What's Actually Happening (the How)
Most companies underestimate how much AI is already in use. Employees are drafting emails in ChatGPT, summarizing meetings with Copilot, cleaning up copy in Grammarly, or running reports through a chatbot, often without telling anyone. This is normal. It also means the starting inventory can't come from what leadership assumes is happening. It has to come from what's actually happening.
A short, anonymous survey works well here: what tools do you use day to day, and what do you use them for? Pairing that with a look at approved and unapproved software already connecting to company systems fills in the gaps people forget to mention. A few informal conversations with department managers round it out. The goal isn't to catch anyone doing something wrong. It's to end up with a complete, honest list of what's actually in use, not the shorter, tidier list a template would assume.
Map It by Who
The same tool carries different risk depending on who's using it and what they have access to. A marketing team drafting blog copy with AI is a very different situation than a finance team running numbers through a chatbot, or HR screening resumes with one. Same category of tool, entirely different exposure.
For each department or role, the useful questions are:
- What tasks are they actually using AI to help with?
- What systems and data do they have access to in their day-to-day work?
- What would happen if that data ended up somewhere it shouldn't?
This is what determines where a policy needs firm guardrails and where it can be more permissive. A blanket rule applied evenly across every department almost always ends up either too loose where it matters most, or too restrictive where the risk was never real to begin with.
Map It by Why
The purpose behind a given use of AI is what actually determines how much risk it carries, more than the tool itself. Using AI to brainstorm blog topics or clean up internal notes is low risk. Using it to summarize a client contract, draft financial analysis, or make a hiring decision is a different category entirely, even if it's the exact same tool.
For every use case that surfaces in the discovery phase, it's worth asking: what business problem is this actually solving, and is there a lower-risk way to solve it? Sometimes the answer is that the current approach is fine. Sometimes it points to a need for a specific, sanctioned tool instead of an ad hoc one. Either way, this is the step that turns a list of tools into an actual risk picture.
Only Then, Write the Policy
With the how, who, and why mapped out, the policy itself becomes much more straightforward to write, and far more likely to hold up in practice:
- An approved tools list built from what's actually in use, not from a template's guesses
- Data handling rules tied to the specific data that actually flows through those specific tools
- Role-based guidance instead of one blanket rule for the whole company
- A lightweight approval process for new tools, sized to fit a team this size rather than borrowed from a much larger organization
- Training that addresses the real tools and real gaps the discovery process surfaced, not generic AI awareness content
This is also where the policy earns buy-in. Employees are far more likely to follow rules that clearly reflect how they actually work, rather than a document that reads like it was written for a different company.
A Few Common Mistakes
- Drafting from a template instead of starting with the audit
- Banning AI outright, which mostly just pushes usage underground and out of sight
- Writing one policy for the whole company regardless of role or data exposure
- Treating the policy as a one-time document instead of something reviewed as tools and usage change
A Living Document, Not a One-Time Project
AI tools and the ways employees use them will keep changing, which means the policy needs a review point built in, not a one-time sign-off and a drawer to sit in. A short check-in every few months, tied to whatever new tools have shown up since the last review, keeps the policy accurate instead of stale.
This is the kind of governance work Jump Start already does with clients as part of ongoing strategic technology leadership: not handing over a generic document, but working through the specifics of how a business actually operates and building a policy around that reality.
Common Questions About Building an AI Policy
How do I customize an AI policy for my business?
Start by mapping how AI is actually being used across your company: which tools, which departments, and for what purpose. That audit determines what belongs in the policy, rather than starting from a generic template.
Who should be involved in writing an AI policy?
Department leads who know what their teams are actually using day to day, plus whoever owns data security and compliance. A policy written in isolation from real usage rarely holds up.
What should an AI usage policy include?
An approved tools list based on actual usage, data handling rules tied to the specific data each tool touches, role-based guidance, an approval process for new tools, and a set review cadence.
How often should an AI policy be updated?
Every few months, or whenever a new tool shows up in the business. AI usage changes quickly, and a policy that isn't reviewed regularly goes stale fast.
You don't need another template sitting in a drawer. You need fifteen minutes to map out how AI is actually being used in your business, and what a policy built around that reality would actually look like.
Book a 15-Minute Strategy Call
