Most AI use policies I see from mid-market companies share the same flaw: they look complete on paper but fall apart the moment someone asks a specific question. “Can we use this AI tool to process customer data?” “Who do we tell if the model outputs something wrong?” “Is this vendor even vetted?” The policy either doesn’t answer the question or answers it so vaguely that every employee gets to make their own call.
on Unsplash
If you’re working from a generic AI use policy template you found online, or one that was assembled quickly to check a compliance box, there’s a good chance it’s missing at least one of the five things below. None of these are exotic governance theory. They’re the gaps that create actual liability.
1. Data Classification Requirements
An AI use policy that says “don’t input sensitive data” is not a policy. It’s a wish. The employees who read it don’t know what counts as sensitive, and the ones who skipped it definitely don’t.
A functional policy maps your existing data classification tiers directly to permitted AI tool categories. If your company classifies data as Public, Internal, Confidential, and Restricted, the policy needs to say explicitly: Internal-classified data may be processed by approved AI tools with a business associate agreement or equivalent data processing addendum in place. Confidential data requires documented security review before use in any external AI system. Restricted data — which might include protected health information, payment card data, or employee records — may not be submitted to third-party AI tools under any circumstances.
Without that mapping, “sensitive data” means whatever the individual employee decides it means. That’s not a governance program; that’s a coin flip.
If your organization doesn’t have formal data classification yet, an AI use policy is actually a forcing function to build one. The two documents need each other.
2. Vendor Vetting Criteria
Most AI policies have some version of an “approved tools” list. Fewer of them explain how a tool gets on that list — or how it gets removed.
Vendor vetting for AI tools isn’t the same as standard SaaS procurement. The questions you need answered go beyond the usual SOC 2 checkbox. Does the vendor use your inputs to train or improve its models? If so, is there a way to opt out, and have you exercised it? Where is inference happening — on the vendor’s infrastructure, a third-party cloud, or on-premise? Who has access to your prompts and outputs? What is the vendor’s process when the model produces a materially wrong output?
The EU AI Act, which is now progressively coming into force for systems used by or affecting EU residents, introduces tiered obligations that flow through the supply chain. If you’re using a high-risk AI system as defined under that regulation — even as an end-user deploying a third-party tool — you have due diligence obligations that require documented vendor assessment. Under the Act’s framework, even downstream deployers bear responsibility for ensuring the systems they use meet applicable requirements. That’s not a future concern for companies with any EU customer, partner, or employee exposure.
Your policy should define a minimum vetting checklist and state who owns the vendor assessment process. It should also define a review trigger — if the vendor materially changes its data handling practices, model infrastructure, or terms of service, the approval status gets revisited, not assumed to carry forward.
3. Prohibited Use Cases
Permission-by-default is a pattern I see in a lot of AI policies: here’s the approved tool list, here are some general guidelines, go use it. The problem is that employees are creative and the tools are capable, and the gap between “general guidelines” and actual misuse is enormous.
A useful policy names prohibited use cases specifically. Not an exhaustive list — you’ll never catch everything — but a clear enumeration of the high-stakes categories. Generating or editing communications that misrepresent human authorship in a regulated or legal context. Using AI to make or significantly inform employment-related decisions, including screening, scheduling, or performance evaluation, without documented human review. Submitting customer data, patient information, or financial records to any AI tool not specifically cleared for that data type. Using AI-generated outputs in external-facing materials without a defined review and approval step.
The reason to name these explicitly is not to be exhaustive — it’s to signal that the organization has thought about these scenarios and treats them seriously. “We prohibit using AI in ways that create legal, reputational, or ethical risk” is the same as prohibiting nothing. Named prohibitions create accountability. They also make policy violations actionable rather than debatable.
For companies with consumer-facing AI features or tools, the Federal Trade Commission has been vocal about deceptive AI practices and consumer harm. The FTC’s guidance on AI is worth reading even if you’re not in a heavily regulated industry, because it signals where enforcement attention is moving.
4. Incident Reporting Obligations
Ask yourself: if an AI tool your company uses today produced a significantly wrong output — a contract with incorrect terms, a customer communication with fabricated information, a compliance report with flawed analysis — would your employees know to report it? Would they know who to tell? Would anything be logged?
For most mid-market companies, the honest answer is no. AI incidents fall into a dead zone between IT helpdesk tickets and formal security incidents. They don’t fit the existing process, so they don’t get reported, which means they don’t get tracked, which means you have no visibility into how frequently AI outputs are causing problems.
Your AI use policy needs to define what constitutes a reportable AI incident and establish a clear reporting path. A reportable incident isn’t just a system outage or a data breach involving an AI tool. It includes consequential errors: outputs that were acted upon and caused a business, legal, or customer harm; outputs that were nearly acted upon before a human caught the problem; situations where the model behaved in a way that was materially inconsistent with vendor representations.
The reporting path matters as much as the definition. Employees need to know exactly who receives an AI incident report and what happens next. A vague “contact IT or your manager” instruction produces inconsistent behavior. A named owner, a defined intake channel, and a documented response process produces a record you can actually use.
This is also where the practical value of structured logging starts to show. A simple, consistent AI incident log — even a spreadsheet to start — gives you pattern visibility that informal reporting never will. Over time that log becomes evidence of a functioning governance program, not just a policy document sitting in SharePoint.
5. Policy Review Cadence
AI tools are evolving faster than any other technology category most IT managers have dealt with. A policy written eighteen months ago may be completely misaligned with the tools your teams are actually using today, let alone the risk landscape those tools create.
And yet the majority of AI policies I’ve seen have no stated review schedule. They were written once, approved once, and posted. That’s not a living governance document — it’s an artifact.
A functional AI use policy states an explicit review cadence. Annual review is the floor, not the ceiling, and annual review is only adequate if you have a defined trigger process for out-of-cycle reviews. Triggers should include: material changes to any approved vendor’s data handling practices, a significant AI incident affecting the organization, the adoption of a new category of AI tool not covered by the existing policy, or a material regulatory development in a jurisdiction where you operate.
The person responsible for initiating the review needs to be named in the policy — a title, not just “the IT team” — and the review should produce a documented revision log so there’s a clear record of what changed and why. This matters if you ever need to demonstrate to a regulator, an auditor, or a client that your governance program is active rather than decorative.
Pairing the review cadence with a version number and effective date on the policy document itself is a small thing that makes a real difference in how seriously employees take it. A document stamped “Version 1.0, effective two years ago” reads as a relic. A document that shows it’s been reviewed and revised sends a different signal.
Do This Week
Pull your current AI use policy and mark every place it uses vague language like “sensitive data,” “approved use cases,” or “as appropriate.” For each one, write one sentence that converts the vague language into a concrete, answerable criterion. If you can’t write the sentence because you don’t have the underlying policy decision made, that’s the gap — and now you know exactly where to start.
You don’t need to fix everything at once. But every piece of vague language in a policy is a place where governance breaks down in practice, and finding them takes less than an hour.
—
If you want a structured starting point rather than a blank document, the AI Governance Manager handles these five areas inside the platform instead of a framework you’re assembling from scratch. Try it free — no card required for the trial — and see what a policy looks like when it’s built to hold up, not just look complete until someone asks a hard question.
