AI transformation is a problem of governance because the scarce resource is decisions. Which processes may use AI, and who answers when it gets something wrong? A company can buy access to a capable model in an afternoon. Settling those two questions takes months, and most transformation programmes stall inside that gap.
Governance, in this article, means the decision rights and review loops around an AI system: who approves a use case and who watches it once it runs. That is narrower than a policy PDF on the intranet, and far more useful.
The failure forecasts point the same way. In June 2025, Gartner predicted that over 40% of agentic AI projects will be canceled by the end of 2027. The causes it named include unclear business value and inadequate risk controls. Both are decisions somebody skipped before the build started.
What the AI governance problem looks like inside a company
The AI governance problem rarely announces itself. It shows up as a pilot that works, gets applause in a demo, and then sits in a sandbox for nine months.
The pattern is familiar. A team builds a prototype in three weeks. Then the questions arrive: may it read customer records, and who signs off on what it produces? Legal sends the first question to security. Security sends it to the data owner, who was never invited to the demo. Each answer is reasonable on its own, and together they add up to a project with no route into production.
The prototype took three weeks. Agreeing who should attend the meeting about it took four.
Vendors make the fog thicker. Gartner describes "agent washing", the rebranding of chatbots and robotic process automation as agents, and estimates that only about 130 of the thousands of agentic AI vendors are real. A buying decision made without an owner and a success metric tends to land on whichever vendor demoed best.
The failure is organisational, so more engineering effort leaves it in place. We made the engineering half of this argument in the AI systems engineering problem nobody budgets for. This piece covers the half that lives above the engineering team.
AI governance failures start with an unowned decision
Most AI governance failures trace back to one decision that nobody owned. The model behaved the way models behave, and no person was positioned to catch it.
Michigan's automated unemployment system is the cautionary case we covered in our piece on AI caseworker policy assistants. Between 2013 and 2015 it flagged more than 50,000 potential fraud cases, and an initial state review found a 93% error rate. The software made the accusations. The missing piece was a person reviewing them before they reached the public.
Air Canada met a smaller version in 2024, when a Canadian tribunal held the airline responsible for a refund policy its website chatbot had described incorrectly. The airline argued that the chatbot was responsible for its own words. The tribunal disagreed.
Strip the details away and the same gaps recur:
- No owner for the output. The system answers customers, and no team is accountable for what it says.
- No bar for going live. The pilot ships because the demo went well, with no agreed accuracy threshold.
- No one watching after launch. Inputs drift, the vendor updates the model, and nobody reruns the tests.
- No way to switch it off. Pausing the system needs a sign-off from someone who has left the company.
The third gap is the one engineers underestimate. A model provider can change behaviour under the same product name, and a prompt that passed every test in March can fail quietly in June. Governance that stops at launch day is governing a system that no longer exists.
Each gap is cheap to close before launch and expensive afterwards. That asymmetry is the whole business case for governance.
Enterprise AI governance: the decision rights that matter
Enterprise AI governance comes down to a short list of decisions, each with one named owner and a defined piece of evidence. Write the list down and most of the stalled meetings disappear.
| Decision | Owner | Evidence required |
|---|---|---|
| Approve a use case | Business owner of the process | The failure being removed and what it costs today |
| Grant data access | Data owner | Data classification and retention rules |
| Go to production | Product owner, with risk sign-off | Evaluation results against an agreed threshold |
| Monitor in production | The team running the system | A dashboard and an incident log |
| Pause or retire | Business owner of the process | Trigger conditions agreed before launch |
NIST's AI Risk Management Framework, released in January 2023 and now under revision, puts the same idea at its centre. Its Govern function cuts across the framework's other three, which is NIST's way of saying the table above has to exist before the risk work means anything.
The step most frameworks leave to you is refining governance to the business context. A tool that drafts marketing copy and a model that scores loan applications should not pass through the same gate. Tier your systems by what a wrong output costs, and give the low tiers a fast lane. Governance that treats a slide-deck summariser like a credit model teaches everyone to route around it.
AI governance leadership: who should own it
One named executive should own the AI portfolio, and each system should be owned by the business owner of the process it changes. Everything else is support staff.
The usual alternative is a steering committee. Committees feel safe because responsibility is shared, and shared responsibility is the problem being solved. A committee of twelve has never once been blamed for anything, which is most of its appeal.
The title matters less than two powers. The owner needs budget authority over AI spend, and the standing to stop a project that cannot show value. A chief AI officer without either is a spokesperson. A CIO with both will do fine.
Measure the owner on two numbers. The first is the time from an approved use case to production, which shows whether governance is a fast lane or a toll booth. The second is the share of live systems with a named owner and a current evaluation. If the first number climbs while the second stays flat, the process is producing meetings.
Agents raise the stakes, because an agent acts where a chatbot only answers. The agentic AI use cases already in production show where autonomy pays off, and each of them runs inside an explicit boundary on what the agent may do alone. Setting those boundaries is a leadership decision, the subject of Agentic AI in Business, which works through autonomy limits and accountability for the people who sign off. The engineers enforcing the boundary will find the build side in Agentic AI Engineering.
AI governance and compliance after the EU AI Act delay
Compliance is the floor that governance stands on. Regulation tells you the minimum; governance decides how you run everything above it.
For anyone selling into Europe, the EU AI Act sets that floor in stages. Prohibited practices became effective in February 2025, and the rules for general-purpose AI models followed in August 2025. The AI Omnibus, adopted in 2026, moved the high-risk obligations to 2 December 2027.
High-risk covers uses such as CV-sorting software for recruitment and credit scoring among others. From that date those systems need risk assessment and human oversight before they reach the market, along with activity logging and documentation among other duties.
The delay is a reprieve on paperwork only. Every one of those obligations assumes the decision rights in the table above already exist: someone owns the risk assessment, and someone can show the logs. A company that builds its governance now will find most of the compliance file already written in 2027.
Where to start this quarter
Starting takes five decisions, written down and owned:
- Inventory every AI system in use, including the ones bought on a team credit card.
- Name one accountable owner for each system, by name and by role.
- Agree a go-live threshold for each system before its next release.
- Write the pause triggers, and test that someone can pull them.
- Tier the inventory by the cost of a wrong output, and fast-track the low tier.
Do that and the empty flipchart in the steering committee room finally gets something written on it: a name next to every system.