The Governance Inversion

In most complex organizations, AI governance is doing the opposite of what it should be doing.

The decisions that need central coordination, risk frameworks, model approval standards, vendor evaluation, ethics review, are being handled inconsistently across business units, with different rules in different functions and very little shared visibility.

The decisions that need local autonomy, which use cases to pursue, how to design the workflow, when to test and iterate, are being routed through central committees that meet monthly, can't see the operating context, and slow good work to a standstill.

This is the governance inversion. And it is the single most common operating mistake in AI adoption inside matrix organizations.

This piece is about how to fix it, without rebuilding everything from scratch.

The principle in one line

There is a clean principle that resolves the inversion in almost every case:

Centralize what protects the enterprise. Decentralize what creates value.

That sentence is not new. Versions of it have existed in management literature for thirty years. What is new is what it means in the AI context, because AI introduces a set of decisions that didn't exist before, and most governance structures haven't been redesigned to handle them.

The leaders who get this right have done the structural work to figure out which AI decisions are which.

What to centralize

Some AI decisions need to be made the same way across the entire enterprise. They are decisions that protect the institution, its risk posture, its data, its members or patients, its regulators, its brand.

The risk framework. Not the approvals themselves. The framework that defines what counts as low, medium, or high risk; what mitigations are required at each level; what kinds of decisions must have human review. This framework needs to be one document, owned by one function, applied everywhere.

The model inventory. Every AI model running in the organization should appear on a single, current, accessible list. Owner, purpose, data sources, risk tier, status, dependencies. Most large organizations have no such list. The first time someone tries to make one, the count is usually two or three times what leadership thought.

Vendor evaluation standards. Not which vendors get picked, that is a local decision. The standards by which any vendor is evaluated. Security posture, data handling, model transparency, exit terms, contractual safeguards. These standards belong in one place, applied uniformly.

Ethics and responsible AI review. The criteria by which a use case is examined for fairness, bias, harm, and member impact. The committee that reviews high-risk cases. The escalation path when a tradeoff is ambiguous. All centralized.

Security and infrastructure standards. The platforms, the access controls, the audit trails. These are not domains where local variation is acceptable.

These five areas should be owned by a small central function, small, because the work is policy and standards, not approvals. The job is to set the guardrails, not to drive the car.

What to decentralize

Some AI decisions should be made by the people closest to the work. They are decisions about what creates value, which problems to attack, how to design the workflow, what to measure, when to iterate.

Use case identification. The business unit knows where the friction is. They know which workflows are painful. They know which numbers their leadership is asking them to move. Centralizing use case identification puts the decision in the wrong hands and slows it down by a factor of ten.

Workflow design. What gets automated, what gets augmented, what stays fully human. The unit of design is the task, and the task is local. The frontline knows it better than any central team will.

The pace and rhythm of testing. How often to iterate, when to expand scope, when to pause. The operating context determines this. A central committee meeting monthly cannot run the cadence of a function moving weekly.

Local performance measurement. What success looks like for this use case, in this function, against this baseline. Central scorecards aggregate; they don't replace local measurement.

Adoption and change management. How the team is trained, how resistance is handled, how the tool is rolled out. Adoption is a deeply local discipline. It cannot be centrally administered.

These five areas should sit with the business unit. The job of central governance is not to approve them, it is to make them safer to do quickly.

---

How to tier the work

The hardest decision in fixing the governance inversion is what to do with the middle, the decisions that aren't clearly central or clearly local. The answer is tiered governance.

Most organizations have one approval path that every AI use case is forced through. That single path is calibrated for the highest-risk case the organization has ever feared, which means it adds friction to all the cases that don't deserve it. Productivity tools wait in the same queue as member-facing decision tools. Internal analytics wait in the same queue as clinical decision support.

The fix is to publish a small number of tiers, typically three or four, with a clear definition of what falls in each, and a distinct, predictable approval process for each.

The point is not the specific tiers. It is the principle: one approval path is the wrong number. Four is roughly right for most organizations.

Most leaders who tier their governance for the first time discover they can move two to three times faster on the bulk of their portfolio without taking on any meaningful new risk.

What this looks like in practice

If a sponsor is sitting in an organization with the governance inversion in place, which is most organizations, there is a clean sequence for fixing it.

First, name the problem. Articulate the inversion explicitly, in front of the people who own governance today. The diagnosis is not personal. The structure was built for an earlier moment, and the moment has changed.

Second, convene the working group. Risk, legal, compliance, clinical (if applicable), IT, and AI leadership in one room. Sometimes finance. Their job is to draft the tier definitions and approval paths in thirty days.

Third, publish the tiers. Make them visible to the whole organization. Give every existing AI use case an explicit tier assignment. Migrate the approvals accordingly.

Fourth, prove it works. Move three high-value use cases through the new tiered process in the first quarter. Measure cycle time. Compare to the old path. Publish the result.

The organizations that do this find that governance stops being the thing that slows them down, and starts being the thing that lets them move with confidence.

Why this matters now

The governance inversion was tolerable when AI was small. Five use cases, two sponsors, one approval committee. Slow, but manageable.

It is not tolerable at the next scale. Fifty use cases, twenty sponsors, three business units running in parallel. The old structure breaks. And the leaders who don't fix it discover that their AI portfolio has quietly stopped scaling, not because the technology stopped working, but because the governance stopped fitting.

The fix is structural. It is not about more committees. It is about fewer committees, applied with more precision, in the right places.

The leaders who do this work in 2026 will be the ones who are still scaling in 2028.

The rest will be wondering why their pilots never reached the people they were supposed to serve.