Skip to content
Insights·2026-05-29·Updated 2026-07-27·5 min read

Governance that helps AI move faster

Governance that reviews everything reviews nothing well. Risk-tiering, a named owner, and clear defaults let teams ship — and beat the August 2026 EU deadline.

By Robin Fitzpatrick

Governance that helps AI move faster

What this article covers

Governance that reviews everything reviews nothing well. Risk-tiering, a named owner, and clear defaults let teams ship — and beat the August 2026 EU deadline.

Most AI governance is designed to prevent the worst thing that could happen. That is a reasonable goal that produces, with striking reliability, a process nobody follows.

The failure is not excessive caution. It is undifferentiated caution — applying the same scrutiny to a marketing team drafting copy as to a system making credit decisions. When everything requires review, the review queue becomes the constraint, and people learn to work around it. You end up with governance that is simultaneously burdensome and ineffective: slow for the harmless work, and routinely bypassed for the work that actually mattered.

The deadline that changes the calculus

Governance has become time-boxed in a way it was not two years ago.

Under the EU AI Act, general-purpose AI obligations took effect on 2 August 2025. High-risk system requirements become fully applicable on 2 August 2026, which is also when European Commission enforcement begins. Systems already on the market before August 2025 have until 2 August 2027.

If you sell into the EU and operate anything that lands in the high-risk classification, that is a fixed date requiring risk assessments, bias testing, documentation, and monitoring. It is close enough now that "we'll formalise governance later" has become a scheduling decision rather than a philosophical one.

Three frameworks, three different jobs

The framework landscape looks more confusing than it is, largely because the three most-cited options are not alternatives to each other.

EU AI Act — binding law. Classifies systems by risk: unacceptable uses banned, substantial obligations on high-risk, lighter transparency duties below. Tells you what you must do if you operate in scope.

NIST AI Risk Management Framework — voluntary, program-level, no certification. Organised around Govern, Map, Measure, Manage. Gives you a methodology for managing risk. Nobody audits you against it.

ISO/IEC 42001 — a certifiable international standard for an AI management system. Matters when you need to hand external evidence to a customer, regulator, or procurement team.

They compose rather than compete: regulation supplying legal requirements, framework supplying methodology, standard supplying certifiable evidence. The practical pattern for organisations operating across jurisdictions is to use NIST as the structural foundation and layer EU AI Act conformity work on top where it applies, rather than maintaining two separate governance architectures.

For most mid-market companies not selling regulated products into the EU, none of these need adopting wholesale. They are useful as a source of structure, not as a compliance program to import.

What fast governance looks like

Governance speeds work up when it removes the need to ask. That means the default answers have to be written down.

Tier by risk, and make most things tier one. Drafting internal copy, summarising documents, generating first-pass code that a human reviews — these should proceed under standing rules with no approval step. If a use case cannot touch customer data, cannot act without a human in the loop, and cannot be published externally without review, the residual risk is low enough that a queue costs more than it protects.

Name an owner per tier who can actually decide. Not a committee. Committees convert a two-day decision into a three-week one and diffuse accountability to the point where nobody feels it. One person, with the authority to say yes.

Write the prohibitions explicitly. The shortest and most valuable governance artefact is the list of things that are never acceptable — client data in consumer tools, automated decisions affecting employment or credit without human review, whatever is specific to your business. People follow bright lines. They ignore judgment calls that require them to reason about principles under time pressure.

Log enough to reconstruct a decision. Which system, what inputs, what it produced, who accepted it. This is the requirement that looks like overhead until the first time something goes wrong, at which point it is the difference between a contained incident and an unbounded investigation.

Set a review date for the rules themselves. AI capability moves faster than policy. Rules written eighteen months ago are probably prohibiting things that are now routine and permitting things that are now risky.

The shadow AI problem governance actually has

Here is the constraint that makes the case better than any regulatory deadline: more than 80% of workers report using unapproved AI tools at work, and between a fifth and a third operate entirely outside IT's governance.

Your governance is not being applied to a blank slate. It is being applied to an organisation where AI use is already widespread and largely invisible. A policy that is heavy enough to be worth evading will be evaded — and the usage does not stop, it just stops being visible.

Which means the practical test for any governance rule is not "does this prevent the risk" but "will people follow this when they are busy". A moderately strict rule that gets followed protects more than a strict one that gets bypassed. This is also why governance and training fail together: 31% of shadow AI users have received no employer training, and untrained people cannot follow rules they were never taught.

Where this connects to delivery

Governance designed separately from the operating model becomes a parallel process — a gate teams pass through rather than a property of how work is done. That is the version that gets routed around.

Tied to the operating model, the same decisions become part of the workflow: the risk tier is established when the use case is scoped, the owner is the person who already owns the process, and the logging is built during implementation rather than retrofitted. We build this into strategy work rather than treating it as a separate compliance exercise, for the same reason we build the production handoff into implementation from day one.

The goal is not to make the business safe from AI. It is to make the business comfortable enough to ship at a sensible speed — which requires knowing, in advance and in writing, which decisions actually need to be made.

Frequently asked questions

What are the main AI governance frameworks?
Three dominate, and they do different jobs. The EU AI Act is binding law that classifies systems by risk tier. The NIST AI Risk Management Framework is a voluntary methodology organised around Govern, Map, Measure, and Manage — useful as structure, carries no certification. ISO/IEC 42001 is a certifiable standard for an AI management system, which matters when you need to show a customer or auditor external evidence. Most organisations use NIST as the operating structure and add EU AI Act conformity work where it applies.
When do EU AI Act obligations take effect?
General-purpose AI obligations began on 2 August 2025. High-risk system requirements become fully applicable on 2 August 2026, when European Commission enforcement also begins. Models already on the market before August 2025 have until 2 August 2027. If you sell into the EU and operate anything classed high-risk, the 2026 date is the binding one.
Does AI governance slow teams down?
Only when it is undifferentiated. Governance that routes every use case through the same review queue creates a backlog and teaches people to route around it. Governance that tiers by risk — most work proceeds under standing rules, a defined minority gets review — reduces decision latency, because teams stop guessing whether they need permission.
What is the minimum viable AI governance?
Four things. A risk tiering rule that sorts use cases into proceed, review, and prohibited. A named owner per tier who can actually decide. A written list of what is never allowed. And a logging standard so decisions can be reconstructed later. That fits on two pages and covers most of what NIST and ISO 42001 ask for structurally.