The Problem Isn’t That People Ignore Policies. It’s That the Policies Deserve to Be Ignored.
If your AI use policy is a twelve-page PDF sitting in a SharePoint folder nobody opens, you don’t have a governance document — you have liability theater. Employees are using ChatGPT, Copilot, Grammarly, and a dozen other AI-assisted tools right now, making judgment calls in real time with no practical guidance. A policy that lives in a folder doesn’t change that.
on Unsplash
The goal of an AI use policy isn’t to cover the company legally. It’s to give people a clear, fast answer to the question they’re actually asking in the moment: *Can I use this tool for this task?* If your policy can’t answer that in thirty seconds, it’s not doing its job.
Here’s how to write one that does.
Start With Scope, Not Philosophy
Most AI use policies open with a paragraph about the transformative nature of artificial intelligence. Skip it. Start with scope: what tools and use cases this policy actually covers.
Scope has two dimensions. The first is tool coverage — does this policy apply to standalone AI tools (ChatGPT, Claude, Gemini), AI features embedded in existing software (Copilot in Microsoft 365, AI suggestions in Salesforce), or both? The answer should almost always be both, because embedded AI is where most employees encounter it without realizing governance applies.
The second dimension is use-case coverage — what kinds of tasks are in scope? Drafting customer communications, summarizing contracts, generating code, analyzing internal data, creating marketing content. Be explicit. If you write a policy that covers “AI tools generally” but doesn’t name the tasks that matter to your business, you’ve written something that tells people nothing useful.
A scope section doesn’t need to be exhaustive. It needs to be clear enough that someone reading it can recognize whether their situation is covered. Two to three short paragraphs is enough.
Define Three Tiers of Use
The single most practical structure for an AI use policy is a tiered approval model. Instead of a binary allowed/prohibited split, divide AI use into three categories:
Approved use covers tools and tasks that are cleared for standard business activities with no additional review required. Think: drafting internal communications, summarizing meeting notes, generating first-draft marketing copy that goes through normal editorial review. Employees don’t need to ask permission for these.
Conditional use covers tools or tasks that are permitted only with specific controls in place — data type restrictions, output review requirements, or manager sign-off. This is where you put things like: using AI to analyze customer data (permitted only if the data is anonymized first), or using an external AI tool to draft a contract clause (permitted only if legal reviews the output before it goes to the client). The condition is part of the permission.
Prohibited use is the short list of things that are off the table entirely. Common examples: inputting personally identifiable information into a public AI tool that isn’t covered by a data processing agreement, using AI to generate content that will be attributed to a specific human expert without disclosure, or using AI tools to make or automate final decisions in regulated contexts like credit, employment, or benefits without human review.
This structure works because it matches how people actually think. When someone sits down to do a task, they want to know: is this fine, is this fine with conditions, or is this a no? Give them that answer directly.
Write the Conditional Use Rules With Enough Specificity to Be Actionable
This is where most policies fall apart. The conditional tier is only useful if the conditions are concrete. “Use AI responsibly with customer data” is not a condition. “Do not input customer names, account numbers, or contact information into any AI tool that does not have a signed Data Processing Agreement on file with IT” is a condition.
For each conditional use case, write out three things: what’s permitted, what’s required before or during that use, and who owns the decision if there’s ambiguity. That last one matters more than people realize. If an employee isn’t sure whether a specific data set qualifies as sensitive, they need to know who to call — and it shouldn’t require an IT ticket that takes three days to resolve.
You don’t need to cover every possible scenario. Cover the ten use cases that are already happening in your organization right now. If you don’t know what those are, that’s the first problem to solve — and a quick survey of department heads will surface them faster than you’d expect.
Keep the Document Under Two Pages
Two pages, or roughly 800 words, is the ceiling for a policy document that employees will actually read. If your AI use policy is longer than that, it’s probably because it’s trying to be a training manual, a vendor risk framework, and a legal disclaimer simultaneously. Those are separate documents.
The policy itself should cover: scope, the three-tier structure with examples, data classification rules (what can and can’t go into external tools), a disclosure or transparency requirement if applicable, and a clear statement of who owns enforcement. Everything else belongs in supporting materials that you can reference but don’t have to embed.
If your legal or HR team insists on additional language, put it in an appendix and keep the operational core clean. The two-page body is what employees interact with. The appendix is for auditors.
Embed It Into Workflows, Not Just Onboarding
A policy delivered once during onboarding is forgotten by week three. To make an AI use policy stick, it needs to appear at the moment of decision — which means embedding it into the tools and workflows where AI decisions actually happen.
In practice, this looks like a few things. Add a one-paragraph summary of the conditional use rules to your IT request process for new software tools, so anyone asking to add an AI tool gets the relevant section as part of the response. If you use a communication platform like Slack or Teams, pin a one-page quick reference in the channels where AI tools come up most often. If your company runs a monthly tech review or all-hands, include a standing two-minute segment on AI tool usage — not a lecture, just a reminder that the policy exists and a pointer to where to find it.
The goal is to make the policy impossible to claim you didn’t know about, and easy to find when you need it. Those are different problems that require different solutions, and you need to solve both.
Build in a Review Cycle
AI tools change faster than most governance documents. A policy written around the capabilities and risk profile of AI tools available eighteen months ago may not address the tools your employees are using today. Build an explicit review cycle into the document itself — quarterly for the prohibited and conditional use lists, annually for the full policy — and assign a named owner to that review.
This also signals to employees that the policy is a living document, not a set-it-and-forget-it compliance artifact. That matters for culture. People are more likely to follow guidance they perceive as current and maintained than guidance that looks like it was written once and abandoned.
The One Thing to Do This Week
Before you write a single word of policy, do this: spend one hour talking to three or four employees across different functions — sales, operations, marketing, finance — and ask them one question: *What AI tools are you using, and what are you using them for?*
You will almost certainly learn something that changes what you write. Most organizations find that AI tool adoption is broader and more varied than IT leadership knows. The policy you write without that information will have gaps that matter. The policy you write after it will be grounded in what’s actually happening.
Once you have that picture, scope your policy around the real use cases, not the theoretical ones. That’s the fastest path to a document that gets used.
A Note on the Regulatory Context
If your organization has EU exposure — customers, employees, or operations in Europe — your AI use policy needs to account for the EU AI Act, which introduces risk-based requirements for certain categories of AI systems. The EU AI Act classifies AI use cases by risk level, and some of what your employees are doing may fall into categories with specific documentation or human oversight requirements. That doesn’t mean your internal policy needs to reproduce the regulation, but it does mean the policy can’t be written as if the regulatory environment doesn’t exist.
Similarly, if you handle US health data, financial data, or employee records, existing sector regulations (HIPAA, GLBA, state privacy laws) impose requirements on how data gets processed — and feeding that data into an AI tool is processing. Your AI use policy and your data classification policy need to be aligned, not siloed.
Getting From Policy to Governance
A written AI use policy is the foundation, but it’s not the whole structure. Once you have a policy that people understand and follow, the next layer is tracking: knowing when something goes wrong, logging it, and learning from it. That’s where incident management comes in — and it’s a lot easier to manage AI incidents when you have a policy to measure against.
If you’re at the stage of building that tracking layer, that’s exactly what InfoDefenders is built to do — turn a policy document into a functioning governance program inside the platform, no dedicated compliance team required to run it. Start a free trial and see it in practice.
But start with the policy. Get it to two pages, tier it properly, and get it in front of employees where decisions happen. That’s more governance work done in a week than most organizations accomplish in a year.
