AI Governance: Setting Internal Policies Before You Scale

A marketing coordinator pastes a client's unreleased campaign brief into a free AI tool to get a faster first draft. A developer feeds a chunk of proprietary code into a chatbot to debug it.

Neither one thinks of this as a policy violation, because there usually isn't a policy to violate. That's the actual starting point for most businesses' AI governance problem: not a rogue employee doing something reckless, but ordinary people trying to work faster, in the total absence of any rule telling them where the lines are.

Governance sounds like the kind of thing only a large enterprise with a compliance department needs to worry about. In practice, the businesses that get hurt worst by skipping it are the ones scaling AI usage fastest with the least structure, because that's exactly when the gap between what employees are doing and what leadership knows about widens the most. This article covers what's actually happening inside companies right now, what a workable AI policy needs to cover, and how to build one before the informal use that's already happening turns into a genuine liability.

The gap that already exists inside most companies

Ask most leadership teams whether employees are using AI tools, and the honest answer, if they're being honest, is "probably more than we know about." PagerDuty's 2026 Shadow AI Survey, covering 1,250 office professionals at companies with $500 million or more in annual revenue across Australia, Japan, the UK and the US, found that two-thirds of respondents had used AI tools at work despite believing those tools weren't permitted under existing company policy. The same survey found the majority had shared work-related information with public AI tools, including customer data and confidential documents, and separately found that more than half of employees don't act on the AI rules they already know about, even where a policy technically exists.

That last figure is worth sitting with. The problem isn't only that companies lack policies. It's that even where policies exist, they're frequently unclear, unenforced, or simply unknown to the people actually using the tools day to day. IBM's Cost of a Data Breach research has tracked shadow AI, AI adoption happening outside official visibility, as a rising factor in breach costs, with incidents involving unsanctioned AI tools now representing a meaningfully larger share of AI-related security breaches than the year before.

None of this means employees are acting maliciously. Most are trying to get their work done faster with tools that genuinely help, in an environment where nobody told them not to, or where the policy that exists doesn't match how the tools actually get used in practice. That's precisely why governance matters more before scaling than after. Once dozens of people have built AI into their daily workflow without any framework, retrofitting rules onto that behavior is a much harder problem than establishing the rules while usage is still forming.

What an internal AI policy actually needs to cover

A workable policy isn't a long legal document nobody reads. It's a small number of clear answers to the questions employees are already asking themselves, whether or not anyone's told them the answer.

Which tools are approved, and for what

The starting point is a specific, named list: which AI tools the company has vetted and approved, for which kinds of tasks, and under what conditions. This matters because the alternative, a vague instruction to "use approved AI tools" without naming any, forces employees back to whatever they already know, usually a free consumer chatbot they use in their personal life. Approval doesn't need to mean unlimited access to every tool; it can be scoped, a specific tool approved for drafting internal documents but not for anything touching customer data, for instance. The goal is giving people a real, usable option rather than leaving them to fill a vacuum on their own.

What data can and can't go into an AI tool

This is the single most consequential category, because it's where the actual financial and legal risk concentrates. A clear policy specifies, in plain language rather than legal abstraction, what categories of information are off-limits: customer personal data, financial records, unreleased product information, anything covered by a client confidentiality agreement, source code beyond a defined threshold. Vague guidance like "don't share sensitive information" leaves too much interpretation to someone in the middle of a task trying to move fast. Specific examples, "don't paste customer names, emails or account numbers into any AI tool that isn't on the approved list," give people something they can actually apply in the moment.

Who reviews AI-generated output before it goes external

Content, code or analysis produced with AI assistance still needs a clear line of human accountability before it reaches a customer, a regulator or the public. This isn't about distrust of the technology; it's about the well-documented tendency of language models to produce confident, plausible-sounding output that's sometimes wrong, and about making sure someone specific is responsible for catching that before it matters. A policy should state clearly whether AI-assisted customer emails need review, whether AI-generated code needs the same review as human-written code, and whether AI-assisted external communications require sign-off from someone other than the person who used the tool.

How employees escalate a tool they want to use that isn't on the list

Every AI policy needs a legitimate path for the situation the policy didn't anticipate, an employee finding a new tool that would genuinely help, with no existing guidance covering it. Without a defined, fast way to request evaluation, the practical result is that employees just use the tool anyway rather than wait for a slow, undefined approval process. A workable escalation path is deliberately lightweight: a specific person or small group who can evaluate and approve a new tool within days, not months, because the alternative to a fast approval process isn't caution, it's shadow use.

The regulatory backdrop, and why it's moving faster than most policies

Internal AI governance isn't happening in a vacuum. The EU AI Act became applicable across the EU on August 2, 2026, and its high-risk system obligations, covering AI used in areas like employment decisions, credit scoring and critical infrastructure, were originally set to take full effect on the same date. That timeline has since shifted: the EU's Digital Omnibus on AI, which entered into force in July 2026, pushed the deadline for high-risk obligations in sensitive areas out to December 2, 2027. Given how recently that change happened, it's worth treating any specific date as something to verify against current EU guidance rather than assume settled, particularly since the political negotiation around these deadlines has moved more than once already.

In the US, the NIST AI Risk Management Framework remains voluntary but has become the de facto reference point many enterprise customers and some state laws point to when assessing whether a company's AI governance is adequate, organized around four functions, govern, map, measure and manage, that map reasonably well onto the practical policy areas described above. ISO/IEC 42001 has emerged as the certifiable option for companies that need to formally demonstrate AI management maturity to clients or partners, though certification is a heavier commitment than most small and mid-sized businesses need at this stage.

The practical takeaway for a company that isn't itself building or selling high-risk AI systems is not to chase every regulatory framework simultaneously. It's to build an internal policy structured loosely around the same categories these frameworks converge on, who's accountable, what data is in scope, how risk gets assessed, so that whichever specific regulation eventually applies to your situation, you're extending an existing structure rather than starting from nothing under time pressure.

Building this before you scale, not after

The order matters more than most companies realize. It's tempting to let AI adoption happen organically across a growing team and address governance once it becomes a visible problem, but by the time it's visible, the informal habits are already established, and changing established habits is a much harder organizational task than setting expectations from the start.

Start with an honest inventory of what's already happening, rather than assuming you know. A brief, non-punitive survey asking employees which AI tools they currently use for work, even unofficially, will almost always surface more than leadership expects, and it gives you a realistic baseline rather than a policy built on guesses about behavior that's already three steps ahead of it.

Write the policy in the language people actually use, not in compliance-department phrasing that gets skimmed and forgotten. A policy employees can genuinely internalize is short enough to read in a few minutes and specific enough to apply without a lawyer's help, which is exactly why the PagerDuty finding about half of employees ignoring rules they already know is so telling: an unclear or overly abstract policy fails just as thoroughly as no policy at all.

Pair the policy with genuinely useful approved alternatives, not just restrictions. The Teramind and WalkMe research on shadow AI both point toward the same underlying dynamic: employees adopt unauthorized tools largely because the authorized options don't meet their actual needs, whether that's speed, capability or simple availability. A policy that only says no, without providing a workable yes, pushes usage further underground rather than reducing it.

Revisit the policy on a defined schedule, because the tools, the regulatory landscape and your own usage patterns are all moving quickly enough that a policy written a year ago is likely already out of step with reality. A quarterly review, checking what new tools have emerged, what's changed in relevant regulation, and what employees are actually asking for through the escalation path, keeps the policy functioning as a living document rather than one more file nobody's opened since it was written.

Where these policies most often fail

Writing the policy without involving the people who'll actually follow it is the most common mistake, since a policy built entirely by leadership or legal, with no input from the teams doing the day-to-day work, tends to miss the real friction points and gets treated as an obstacle to work around rather than a guide that reflects genuine operational reality.

Treating the policy as a one-time document rather than an ongoing program is closely related. AI tools and the risks around them change faster than most internal policies are built to accommodate, and a governance effort that stops at publishing the document, without a defined review cycle or an active escalation channel, quietly becomes outdated within months.

Focusing entirely on restriction, with no enablement, misreads why shadow AI happens in the first place. Every piece of research on this topic points the same direction: employees turn to unauthorized tools because the authorized path is too slow, too limited, or nonexistent, not out of any intent to create risk. A governance program that pairs clear boundaries with real, usable, approved tools addresses the actual cause rather than just the symptom.

Assuming a policy for one department covers the whole company overlooks how differently AI gets used across functions. What's appropriate governance for a marketing team drafting blog content looks very different from what's needed for an engineering team touching source code or a finance team handling sensitive figures, and a single generic policy applied uniformly across all of them tends to be too loose for the high-risk functions and too restrictive for the low-risk ones.

A sensible starting point

Rather than attempting a comprehensive governance program on day one, start with the inventory: find out honestly what AI tools are already in use across the company. From there, draft a short, specific policy covering approved tools, data boundaries, review requirements and an escalation path, built with input from a handful of people actually doing the work. Pair it with at least one genuinely useful, approved tool option so the policy has a real alternative to point to, not just a restriction. Set a review date before you finish writing it, because the landscape underneath this policy will have moved again by the time that date arrives.