AI governance is the set of decisions about who is accountable for AI, which uses are acceptable, and how much risk an organization is prepared to carry. AI controls are the technical mechanisms that enforce those decisions. The gap between the two is real: 63% of breached organizations in IBM’s 2025 research had no AI governance policies in place.1
I raise this because of what I keep seeing in the market.
Every few weeks, another product launches under the AI governance label. That momentum reflects real demand. Gartner projects spending on AI governance platforms to reach $492 million in 2026 and pass $1 billion by 2030.2 Organizations are taking AI risk seriously, and builders are responding.
When I look closely at many of these products, a pattern shows up. You describe what you want the controls to do. Some tools let you upload your existing AI policy so it can be translated into rules. The tool then monitors, flags, blocks, or logs activity against those rules.
That capability is useful, and I want to be clear about that. This is not a critique of any vendor or product. It is an observation about language. What many of these tools deliver is AI controls, and controls are not the same thing as governance.
Governance sets strategic direction, defines policy, and assigns accountability. Controls enforce and operationalize those decisions inside systems.7 One answers who, why, and what. The other answers how.
| Governance | Controls | |
|---|---|---|
| Core question | Who decides, why, and what is acceptable | How those decisions are enforced |
| Primary goal | Align AI risk with business objectives | Protect systems and data, and prevent misuse |
| Owned by | Board, executives, and cross-functional leaders | IT, security, and technical teams |
| Nature | Strategic, directional, evolving | Operational, technical, responsive |
| Typical outputs | Risk appetite, use-case approvals, roles, exception decisions | Access restrictions, data loss prevention, logging, monitoring |
Neither column replaces the other. Governance without controls is a document on a shelf. Controls without governance run without business context, which tends to produce either access so restrictive that people work around it, or a growing pile of exceptions nobody can explain later.7
This is the part I think buyers should understand. When a tool asks you to write in what you want the controls to do, or to upload your AI policy, it assumes the governance work has already happened. It assumes:
If those foundations exist, a controls tool can accelerate a program in a meaningful way. If they do not, the tool enforces whatever it is given. A controls tool can faithfully enforce the wrong decisions.
The analysts tracking this category make a similar point. Gartner advises organizations adopting AI governance platforms to reassess their governance and compliance processes, identify gaps, and clarify roles and responsibilities along the way.2
IBM’s 2025 Cost of a Data Breach research found that 97% of organizations reporting an AI-related breach lacked proper AI access controls, and 63% of breached organizations had no AI governance policies.1 Those are two different findings. One is a controls gap. The other is a governance gap. Closing one does not close the other.
High levels of shadow AI added an estimated $670,000 to the average breach cost in the same study.1 Shadow AI is, at its root, a governance question: which tools are permitted, who approves them, and what happens when someone goes around the process.
Deloitte’s 2025 global survey of board members and executives found that 31% say AI is not on the board agenda, and 66% say their boards have limited to no knowledge or experience with AI.3 A controls dashboard does not answer the questions a board needs answered: what the organization is trying to achieve with AI, what it is prepared to risk, and who is accountable.
The EU AI Act timeline shifted this year. The Digital Omnibus, enacted as Regulation (EU) 2026/1744, moved obligations for stand-alone high-risk systems to December 2027.4 The obligations were deferred, not removed. The Act’s high-risk requirements include classifying systems by risk and assigning human oversight to people with the competence and authority to act. Those are governance decisions before they are technical ones.
The NIST AI Risk Management Framework organizes AI risk work into four functions: Govern, Map, Measure, and Manage.5 Govern is the cross-cutting function. It establishes the policies, accountability structures, and culture the other three depend on. A few of its categories make the difference from controls concrete:
Many AI controls tools do strong work in Measure and Manage: monitoring, testing, tracking, and responding. That work matters. It also depends on Govern being done first, by people.
ISO/IEC 42001 takes a similar view. It sets requirements for an AI management system that begins with leadership commitment, defined roles, and objectives before it reaches operational controls.6
Classification connects the two. When governance defines how data and AI use cases are tiered by sensitivity and risk, controls can map directly to those tiers.7 A high-risk use case gets tighter oversight. A low-risk one moves faster. The strategic decision flows cleanly into a technical action.
These are not a test a vendor has to pass. They are a way to know which job you are hiring the tool to do.
AI governance is the set of decisions about accountability, acceptable use, and risk appetite for AI. AI controls are the technical mechanisms that enforce those decisions, such as access restrictions, data loss prevention, logging, and monitoring. Governance decides. Controls enforce.
No. A platform can inventory AI systems, automate policy enforcement, and collect evidence. It cannot set your risk appetite or hold accountability. Those decisions belong to people with the authority to make them.
Ownership typically sits with executive leadership, with oversight from the board and participation from legal, security, privacy, compliance, data, and business leaders. The NIST AI RMF treats accountability structures as a core part of its Govern function.5
Only if the policy reflects real, current decisions and has a named owner. A tool enforces what it is given. If the policy is outdated or incomplete, enforcement carries those gaps forward.
Start with decisions, not tooling. Inventory where AI is in use, define acceptable and prohibited uses, set a risk appetite, and assign owners. Then choose controls built to enforce those decisions. So where does your organization stand today: are you governing AI, or controlling it?
I'm sharing these observations to bring some clarity to a noisy market, not to take sides. The tools are getting better, and that is good for everyone. But no tool can own accountability for you. That part is ours.
When you hear “AI governance” in your next vendor conversation, which job is really on the table: governance, or controls?
Share your perspective in the comments. I'd like to hear what you're seeing.