AI Governance: How to Build an AI Policy That Actually Gets Followed

An AI policy that works is a set of technical controls with a document attached, not a document with hope attached. The distinction explains most of the gap between what organizations publish and what their employees do. Survey evidence keeps finding the same shape: a large majority of enterprises now have a written AI policy, while half or more of employees who use AI at work report using tools their employer never approved, frequently pasting company information into them. Those two facts coexist comfortably because a PDF cannot see a paste event. The organizations whose policies are actually followed did not write better prose; they moved the policy into the request path, where the allowed thing is easy, the risky thing is logged, and the forbidden thing does not work. This guide covers what AI governance has to govern, why the document-first approach fails, how to right-size the machinery to your actual risk instead of copying a bank's framework, who should own it, what regulators genuinely require, and how to tell whether any of it is working.

Key Takeaways

• AI governance has six jobs: approving models and vendors, defining data boundaries, scoping agent permissions, fixing human-override points, preparing incident response, and keeping an audit trail. A policy that does not assign each of these to a control and an owner is a values statement, not governance.
• Policy-as-document fails for a structural reason: it puts the enforcement burden on the busiest, least-informed point in the system, the individual employee at the moment of use. Policy-as-controls moves enforcement to the gateway, where allowlists, data filters, spend caps, and logging apply by default and compliance is the path of least resistance.
• Governance should be tiered to risk, not copied from the most regulated company in the room. A workable pattern is three tiers: a light baseline for everyday internal use, elevated review for anything customer-facing, and full review for agentic systems and regulated decisions. One-size-fits-all governance is how review boards become the reason shadow AI exists.
• Ownership fails at both extremes. Legal-only ownership produces prohibitions nobody can implement; IT-only ownership produces controls nobody connected to legal exposure. The pattern that works is a small cross-functional group with a single accountable executive, real veto power, and a service-level obligation to answer requests fast.
• The EU AI Act is the binding reference point, with obligations phased from 2025 through 2027 by risk class, and most corporate use lands in the lightly regulated tiers. The practical exposure for most enterprises is data protection, sector rules, and vendor terms, not the headline prohibitions; governance scoped to actual obligations is smaller and firmer than governance scoped to vendor fear-marketing.

What AI Governance Actually Has to Govern

Strip away the framework diagrams and AI governance has six concrete jobs. Each one is a question that will get answered somewhere in the organization; governance is deciding to answer it deliberately.

Model and vendor approval. Which models, tools, and vendors may be used, for what, and who decides. The approval decision has real content: where the vendor processes data, whether prompts are retained or trained on, what the terms permit, and what happens contractually when the model misbehaves. A structured way to run that evaluation is covered in the AI vendor evaluation framework.

Data boundaries. Which classes of data may reach which classes of tool. This is the control employees violate most, almost never maliciously: the deadline is real and the chatbot is helpful. A boundary that exists only in a training deck is a boundary that loses to every deadline.

Agent permissions. The newest and fastest-growing job: what AI systems may do, not just say. An assistant that drafts text and an agent that executes refunds differ in kind, and permissions, scopes, and spending authority for agentic systems need explicit grants, the same way service accounts do. Whether the organization is even ready to operate agents is a maturity question, mapped in the AI agent readiness maturity model.

Human-override points. For each consequential use, where a person can inspect, veto, or reverse the system's action, and who that person is. "Human in the loop" degrades into ritual unless the override point is named, staffed, and fast enough to matter.

Incident response. What counts as an AI incident (a harmful output that shipped, a data leak through a prompt, an agent action outside its scope, a discrimination complaint about an automated decision), who gets paged, and what gets preserved. Teams with mature runtime enforcement treat this as an extension of the safety layer, covered in LLM guardrails in production.

Audit trail. The record that lets the organization answer, months later, what model made this decision, with what prompt and version, on whose approval. Regulated firms already know this discipline; AI merely adds new objects to log.

Why Policy-as-Document Fails and Policy-as-Controls Works

The standard corporate AI policy fails for the same reason the standard security-awareness poster fails: it locates enforcement in individual memory at the moment of maximum time pressure. The employee pasting a contract into a consumer chatbot at 6 p.m. is not consulting section 4.2. The policy document is not useless, it sets expectations and creates the basis for consequences, but as an enforcement mechanism it is a suggestion.

Policy-as-controls relocates enforcement to infrastructure. The organization routes AI traffic through a gateway; the gateway enforces an allowlist of approved models; data-loss-prevention filters screen what leaves; spend is capped per team and per application; every request is logged by default; guardrails run in the request path rather than in a training deck. Under this design the approved tool is one click, the unapproved tool is blocked or visibly logged, and the policy document shrinks to something an employee can actually retain: use the tools in the portal, do not move data across these boundaries, here is who to ask.

The honest caveat: controls have edges. Personal devices, personal accounts, and browser-based consumer tools leak around gateways, which is why the control layer is paired with the one incentive that reliably shrinks shadow usage: making the sanctioned path genuinely better, faster models, preloaded context, no login friction, than the unsanctioned one. Detection of what still leaks around the edges is a security discipline of its own, covered in the CISO's guide to shadow AI. Prohibition without provision is how organizations convert their most motivated employees into their largest unmonitored risk surface.

Right-Sizing: The Three-Tier Model

The second-most-common governance failure, after the unenforced PDF, is the over-engineered gate: a committee designed for a bank's model-risk function applied to a marketing team's copywriting assistant. The cost is not just delay; it is that a review board that takes six weeks to approve a low-risk tool teaches the organization to stop asking. Governance should price review effort to risk, and a three-tier structure does this without a taxonomy project.

Two rules keep the tiers honest. Escalation is by use, not by tool: the same model API is tier 1 in a coding assistant and tier 3 in a credit workflow. And tier boundaries are published, so a product team knows before building which tier it is building for, rather than discovering the gate at launch.

Who Owns It

Both single-owner patterns fail in characteristic ways. Legal-only ownership optimizes for the absence of liability and produces prohibitions detached from how work happens; the organization nods and routes around it. IT-only ownership produces gateways and allowlists tuned to technical risk while missing the exposures a lawyer would catch in the vendor terms or a compliance officer would catch in a sector rule. Committee-of-everyone ownership fails differently: it converts every approval into a calendar problem and accountability into fog.

The pattern with the best track record is small and specific: a cross-functional group, typically security, legal, data, and a business or product representative, chaired by one accountable executive (a CTO, CISO, or chief data or AI officer depending on where the organization's center of gravity sits), with three properties that matter more than its org-chart location. It has real authority, meaning its allowlist is the one the gateway enforces. It is bound by a service level, answering tier 1 questions in hours and tier 2 requests in days, because a slow yes functions as a no and breeds shadow usage. And it owns the metrics, reporting to the executive team on the numbers below rather than on activity ("we published guidance") that measures effort instead of adoption.

What Regulators Actually Require Versus What Vendors Claim

The compliance conversation around AI is fogged by vendors whose product is fear. The binding obligations are narrower, more specific, and mostly land on a minority of use cases.

The EU AI Act is the reference regime, in force since August 2024 with obligations phasing in: prohibitions on a short list of unacceptable practices (social scoring, certain biometric uses, manipulative techniques) since February 2025, transparency and governance duties for general-purpose model providers from August 2025, and the heavy high-risk regime, conformity assessment, risk management, human oversight, logging, phasing in through 2026 and 2027. The critical reading for an enterprise: the high-risk category is defined by use case, credit scoring, employment screening, essential services, biometric identification, not by "uses AI." A company using a chatbot for internal drafting is not running a high-risk system, and most corporate AI portfolios are dominated by limited-risk and minimal-risk uses whose obligations are transparency-shaped, telling people they are interacting with AI, labeling synthetic content, not conformity-assessment-shaped.

Sector rules already apply and always did. Fair-lending law binds a credit model regardless of what the AI Act says; US regulators have confirmed that adverse-action notice requirements apply to algorithmic denials, and model-risk-management guidance in banking covers machine-learning models. Privacy regimes, GDPR and its cousins, govern the personal data in prompts and training sets today, no new AI law required. Health, insurance, and employment carry their own overlays. For most enterprises, the real, immediate legal exposure of everyday AI use runs through data protection and confidentiality, not through AI-specific statute.

What this means for scoping: governance built to actual obligations puts its heavy machinery on tier 3 uses, credit, employment, safety, biometrics, and keeps everything else on controls and transparency. Governance built to vendor marketing puts a conformity assessment in front of a summarization tool, and then wonders why the organization treats the whole program as theater.

The Metrics That Show a Policy Is Working

Governance without measurement converges on the same equilibrium as the unenforced PDF, just with more meetings. Three metrics, none of which can be gamed by publishing another document, tell the truth.

Exception rate. How often people formally ask to go outside the allowlist, and what happens next. A healthy program has a nonzero, stable exception rate with fast dispositions: people are asking, which means they believe asking works. A zero exception rate does not mean compliance; it means the request path is unknown or not worth using.

Shadow-AI discovery rate. What network and endpoint monitoring finds outside the sanctioned path, trended over time. The goal is not zero discoveries, it is a falling trend after the sanctioned path improves, because that trend is the direct measure of whether the easy path and the allowed path are the same path.

Time-to-approve. Median days from request to disposition, per tier. This is the metric that predicts all the others: when tier 2 approval takes two days, people ask; when it takes six weeks, they stop asking and the other two metrics quietly rot.

A governance program that reports these three numbers to the executive team quarterly, alongside usage and spend from the gateway logs, is accountable in the only sense that matters: it can tell whether the policy is being followed without asking anyone to fill in a survey. That, more than any framework diagram, is the difference between an AI policy that gets followed and a PDF with a version number.

FAQ

What should a corporate AI policy include?

Six things, each tied to a control and an owner: which models and vendors are approved and how new ones get approved; which data classes may reach which tools; what permissions agentic systems may hold; where humans can override consequential outputs; how AI incidents are reported and handled; and what gets logged for audit. A policy that answers these six operationally can be short; length is usually a substitute for enforceability, not a form of it.

Why do employees ignore AI policies?

Because the policy asks the employee to enforce it at the moment of maximum time pressure, and the unapproved tool is often better or faster than the approved path. Survey data consistently shows half or more of AI-using employees relying on unapproved tools even where policies exist. The fix is structural, not rhetorical: enforce the allowlist at a gateway, log by default, and make the sanctioned tools good enough that compliance is the convenient option.

What is the difference between AI governance and an AI acceptable-use policy?

An acceptable-use policy is one artifact: the rules for individual employees using AI tools. AI governance is the full system: vendor and model approval, data boundaries, agent permissions, oversight points, incident response, audit, and the controls that enforce all of it. Organizations that publish an acceptable-use policy and stop have governed the least risky layer, individual drafting, while leaving customer-facing and agentic uses, where the real exposure lives, unmanaged.

Does the EU AI Act apply to ordinary company use of AI?

Mostly lightly. The Act's heavy obligations attach to high-risk use cases defined by function, such as credit scoring, employment screening, biometric identification, and essential services, with duties phasing in through 2027. Everyday internal uses like drafting, coding assistance, and summarization fall into minimal or limited-risk tiers, where obligations are largely transparency: disclosing AI interaction and labeling synthetic content. The immediate legal exposure for typical corporate use runs through existing data-protection and sector rules rather than the Act's headline provisions.

Who should own AI governance in a company?

A small cross-functional group, typically security, legal, data, and a business representative, chaired by one accountable executive with authority over the enforced allowlist. Legal-only ownership produces unimplementable prohibitions; IT-only ownership misses contractual and regulatory exposure; large committees convert approval into delay. The ownership test is operational: can the group answer a tier 1 question in hours and a customer-facing review in days, and does its decision actually change what the gateway allows.

Related reading on FinTekCafe

• The AI Agent Readiness Framework: A Maturity Model
• LLM Guardrails: AI Safety in Production
• Shadow AI: The Security Problem CISOs Cannot See
• The AI Vendor Evaluation Framework