An AI governance framework should do more than document policies or approve projects. It should tell leaders who is accountable, what evidence is required, where controls apply and when an AI initiative should be built, reshaped, deferred or stopped.
A no-build decision is not the whole of AI governance, but it is one of its most important controls. NIST’s AI Risk Management Framework explicitly includes a determination on whether an AI system’s development or deployment should proceed. NIST AI Risk Management Framework.
For CIOs and CTOs in regulated organisations, the objective is not to block AI. It is to stop weak use cases consuming budget, delivery capacity and governance attention that should be reserved for systems with a defensible path to value.
What Is an AI Governance Framework?
An AI governance framework is the system of policies, decision rights, controls, evidence and lifecycle oversight an organisation uses to govern how AI is selected, designed, built, deployed, monitored, changed and retired.
ISO/IEC 42001 treats AI governance as a management-system problem: organisations need policies, objectives and processes that can be implemented, maintained and continually improved. NIST similarly treats governance as a cross-cutting part of AI risk management rather than a single approval gate. ISO/IEC 42001.
A useful framework should answer two questions:
- Should this AI initiative proceed at all?
- If it proceeds, how will it be governed throughout its lifecycle?
The first is where many organisations remain weak. AI portfolios fill with promising use cases, but few teams are given explicit criteria for saying no.
What an AI Governance Framework Needs to Control
A practical AI governance framework needs enough structure to make decisions consistently without turning every use case into a committee exercise.
| Governance component | Question it should answer |
|---|---|
| Strategic purpose | Why does this AI system need to exist, and what outcome should it improve? |
| Ownership and accountability | Who owns the outcome, risk and decision to proceed? |
| Risk and regulatory scope | Which harms and obligations need to be controlled? |
| Data and technical controls | Can the system be built and operated defensibly? |
| Assurance and evidence | What must be demonstrated before approval or release? |
| Lifecycle oversight | How will the system be monitored, changed and retired? |
This does not automatically require a new AI committee. The UK Government AI Playbook allows for AI governance within existing or dedicated structures, but stresses clear accountability, review and escalation. UK Government AI Playbook.
Whatever the structure, decision rights must be explicit enough that teams know who can approve, challenge, reshape or stop an initiative.
Why No-Build Decisions Belong in AI Governance
Most AI programmes are good at generating ideas. They are less good at eliminating them.
Each pilot competes for engineering time, data access, security review, risk attention, integration work and operational ownership. A technically viable idea can still be a poor investment once those dependencies are visible.
This is why AI governance is partly a capital-allocation discipline.
NIST’s AI RMF says organisations should determine whether an AI system achieves its intended purpose and whether development or deployment should proceed. Its playbook also notes that AI may not be the right solution for a given business task. NIST AI RMF Core.
The practical implication is simple. A governance framework should not produce only approved or rejected. It should make space for four outcomes: build, reshape, defer and stop.
A weak use case is not always a permanently bad idea. The business case may be sound but the data unready, or a smaller solution may produce most of the value with less risk and governance overhead.
The Five Feasibility Gates Before You Build AI
Catapult uses five practical feasibility gates to pressure-test an AI use case before significant build investment. They are not a substitute for ISO, NIST or sector regulation. They turn broader governance principles into a commercial go/no-go discussion.
For a deeper examination of approval blockers before development begins, Catapult’s AI risk assessment before you build covers data, architecture, risk and approval readiness in more detail.
1. Data lineage and rights of use
Having data is not enough. Leaders need to know where priority data came from, who owns it, whether it can be accessed, whether its quality is sufficient and whether the intended use is defensible.
For systems involving personal data, ICO guidance says AI risk and controls depend heavily on the specific use case and processing context. It also says organisations should be prepared to halt deployment if risks cannot be sufficiently mitigated to meet data-protection requirements. Its AI guidance is currently under review following changes made by the Data (Use and Access) Act. ICO guidance on AI accountability and governance.
If you cannot answer the data question with evidence, defer the initiative rather than assuming the gap will resolve during development.
Where the problem is broader data readiness, Catapult’s FAIR Data Assessment tests priority datasets across quality, metadata, governance, access, architecture and legal/security considerations before AI investment proceeds.
2. Explainability threshold
Not every AI use case requires the same level of explainability. The required level depends on what the system does, who is affected, which decisions it influences and which obligations apply.
Define the required transparency, human oversight and defensibility before selecting the model or architecture. If the proposed design cannot meet that threshold, reshape the use case or choose a different approach.
3. Lifecycle cost
Development is only part of the cost of operating AI.
A serious business case should include monitoring, evaluation, infrastructure, security, documentation, support, changes where required, incident handling and eventual retirement.
The question is not whether the organisation can fund the pilot. It is whether expected value still makes sense once the operating model needed to keep the system dependable and governed is included.
4. Integration reality
An AI capability that works in isolation can still fail as an operational service.
Ask where it sits in the real workflow. What systems must it connect to? What permissions, APIs, legacy interfaces and manual hand-offs sit in the path? Who supports it when something breaks?
If value depends on brittle integrations, permanent manual workarounds or major replatforming absent from the original business case, reassess before development.
Sometimes a different hosting or deployment model changes the answer. Catapult’s existing guidance on private AI and hosting decisions makes that distinction: a constraint on SaaS deployment is not automatically a reason to reject AI itself.
5. Regulatory surface area
Regulatory exposure is use-case and jurisdiction dependent.
In the UK, organisations may need to account for data-protection law, sector rules, security requirements, contractual obligations and regulator expectations. UK government guidance sets out five principles for regulators: safety, security and robustness; appropriate transparency and explainability; fairness; accountability and governance; and contestability and redress. UK AI regulatory principles.
For organisations operating in or serving the EU, the AI Act is no longer an emerging framework. It is in force and applying progressively. Article 50 transparency obligations apply from 2 August 2026. Following the 2026 AI Omnibus changes, rules for certain high-risk AI systems apply from 2 December 2027, while high-risk AI embedded in regulated products applies from 2 August 2028. European Commission guidance on AI transparency obligations.
The governance question is: what controls, evidence and ongoing obligations does this use case create, and does the business case still hold once they are included?
| Gate | Question | Response if weak |
|---|---|---|
| Data lineage | Can we defend the origin, access and intended use of the data? | Defer, reshape or stop |
| Explainability | Can the system meet the transparency and oversight level required? | Reshape or stop |
| Lifecycle cost | Does value remain compelling after operating and governance costs? | Reshape or stop |
| Integration | Can it work reliably inside the real estate and workflow? | Reshape or defer |
| Regulatory surface | Can required controls be met without destroying the business case? | Reshape, defer or stop |
Build, Reshape, Defer or Stop: The Governance Decision
A binary build/no-build gate is too crude for most enterprise portfolios.
| Decision | Meaning |
|---|---|
| Build | Value, feasibility, risk and operating conditions justify proceeding. |
| Reshape | The use case has value, but scope, architecture or operating model needs to change. |
| Defer | The use case may be viable once a dependency or readiness gap is resolved. |
| Stop | Risk, economics or feasibility do not justify further investment. |
The important thing is that the decision is explicit and evidenced.
Governance and AI readiness are related but different. A single use case may fail a feasibility gate even when the organisation is AI-ready. Equally, a promising use case may need to pause because data, governance or delivery capability is not yet strong enough.
Catapult’s AI Advisory work is designed around that decision problem: understanding what organisations should and should not invest in based on their systems, data and business outcomes rather than assuming AI is automatically the answer.
Who Owns AI Governance Decisions?
AI governance fails when everyone can recommend but nobody is accountable for the decision.
A regulated use case will often require input from the business owner, technology and architecture, data, security, and legal, risk or compliance. But the organisation still needs a clear route from evidence to one accountable decision.
The UK Government AI Playbook recommends clear review and escalation processes, lifecycle responsibility and a named Senior Responsible Owner for government AI projects. UK Government AI Playbook. The wider principle applies beyond government: someone must own the decision and be able to explain why the organisation proceeded.
The same applies in reverse. If nobody has authority to reshape, defer or stop a marginal initiative, the governance framework is incomplete.
How AI Governance Fits Across the AI Lifecycle
Use-case intake → feasibility and risk assessment → build decision → design and development controls → pre-release assurance → runtime monitoring → material-change review → retirement
NIST treats AI risk management as an ongoing lifecycle activity, and the UK Government AI Playbook similarly requires management across the full AI lifecycle. NIST AI RMF Core.
This article focuses on deciding whether an initiative deserves to enter delivery and under what conditions. Once it does, governance has to move inside the delivery system: evidence capture, release controls, monitoring, escalation and change management need to operate with the work.
Catapult’s separate article on why AI governance fails in PDFs and committees covers that operational layer in more detail.
AI Governance Standards and UK Regulatory Context
There is no single framework that removes the need for organisational judgement.
ISO/IEC 42001:2023 provides an international AI management-system standard for establishing, implementing, maintaining and continually improving how an organisation manages AI risks and opportunities. ISO/IEC 42001.
NIST AI RMF provides a voluntary risk-management framework built around Govern, Map, Measure and Manage, including the decision on whether development or deployment should proceed. NIST AI RMF.
UK guidance and regulation are context-specific. The UK Government AI Playbook is aimed at government and public-sector organisations, while ICO AI guidance applies in the data-protection context and sector regulators may impose additional requirements. UK government guidance also provides the five cross-sector principles for regulators described above. UK Government AI Playbook.
These are reference points, not substitutes for local decision rights.
A useful enterprise framework should tell a team which standards and obligations apply, what evidence is required and who has authority to act on it.
AI Governance Framework Checklist
Before an AI initiative moves into build, leaders should be able to answer:
- What business outcome or decision will the system improve?
- Why is AI the right approach rather than a simpler solution?
- What data will it use, where did it come from and can the intended use be defended?
- Who owns the business outcome and the system after launch?
- What transparency, explainability and human-oversight threshold applies?
- What architecture, hosting and integrations are required?
- Which legal, regulatory, security and contractual obligations apply?
- What evidence or assurance is required before release?
- How will performance, risk and material changes be monitored?
- What is the full lifecycle cost, not just the build cost?
- What would trigger a reshape, defer or stop decision?
- Who has authority to make and enforce that decision?
If those questions cannot be answered clearly, the next step should not automatically be a pilot. It should be a governance or readiness review.
If the gaps extend beyond one use case, Catapult’s AI Readiness Playbook provides a wider framework across strategy, data foundations, delivery capability, governance and adoption.
Build Fewer AI Systems. Build Better Ones.
No-build governance is not anti-innovation. It protects investment and delivery capacity for AI systems that can survive real-world operation.
It also gives leaders a more credible portfolio view: this is what we will build, what we will change, what we will wait for and what we will not fund.
The strongest governance framework is not the one with the most policy. It is the one that makes difficult decisions early, records why they were made and carries the right controls into delivery.
Start with a gate, not a pilot.
AI Governance FAQs
What is an AI governance framework?
An AI governance framework is the system of policies, decision rights, controls, evidence and lifecycle oversight used to govern how AI is selected, built, deployed, monitored, changed and retired.
What should an AI governance framework include?
It should cover strategic purpose, ownership and accountability, risk and regulatory scope, data and technical controls, assurance requirements and lifecycle monitoring.
Why does AI governance need a no-build decision?
Because technical feasibility alone does not prove an AI use case is worth funding or safe to operate. Governance needs a route to reshape, defer or stop initiatives when the evidence does not support proceeding.
Who should own AI governance?
Business, technology, data, security, legal, risk and compliance may all contribute evidence, but an accountable owner or governance forum needs authority to decide.
How is AI governance different from AI risk management?
AI risk management is one part of governance. Governance is broader: it establishes decision rights, accountability, policies, approval routes, evidence requirements and lifecycle oversight.
Which AI governance standards should UK organisations consider?
Useful reference points include ISO/IEC 42001 and the NIST AI Risk Management Framework, alongside applicable UK law, ICO guidance and sector-specific regulation. Public-sector organisations should also consider the UK Government AI Playbook. Organisations operating in the EU may need to assess whether the EU AI Act applies.
