Public Sector AI Governance

Last updated: 2026-08-15

Public sector AI governance is the set of rules deciding who may approve an AI system for production, who can switch it off, how risk is tiered, and who is accountable when it fails. Governance in government differs from commercial governance because citizens cannot choose another provider, decisions carry legal weight, and most systems are procured rather than built.

How public institutions govern artificial intelligence in practice rather than on paper. This page sets out the operating decisions that constitute governance: decision rights, risk tiering by consequence, approval gates with stopping conditions, and the assurance process for systems bought from a vendor.

Why government AI governance is a different problem

Three conditions separate public-sector AI governance from the commercial version. A citizen cannot take their business elsewhere, so a wrong decision is not corrected by the market. Public decisions carry legal weight and are subject to appeal, review, and audit, which means an unexplainable system is a legal exposure rather than a technical debt. And most public AI is procured rather than built, so the governing instrument is a contract and an assurance process, not an internal model card.

These conditions favour governance that produces decisions on a schedule over governance that produces documents. A principles statement constrains nothing. A rule that says no model touching benefit eligibility goes live without sign-off from the accountable business owner and the data protection lead constrains a great deal.

Start from decision rights

The first question is not which principles to adopt. It is who is allowed to put a model into production, who can switch it off, and who carries the consequence when it fails. Until those three names exist, everything else is preparation. Deriving principles afterwards is straightforward; deriving accountability from principles is not.

A workable default assigns three roles: an accountable business owner who carries the operational consequence, a technical owner who can explain and modify the system, and an independent reviewer from data protection or risk who can refuse. The reviewer needs the authority to say no, or the gate is decorative.

Tier risk by consequence, not by technology

Tiering schemes built around technology age badly, because they require a separate rulebook for each wave of capability. Tier instead on what happens when the system is wrong: who is affected, whether they can appeal, and whether the effect is reversible. On that basis a rules engine that denies a claim deserves more scrutiny than a language model that drafts meeting notes, which is the opposite of what a technology-based scheme concludes.

Every approval carries a stopping condition

Approval without a defined kill criterion is optimism with a signature attached. Before a system goes live, three things should be written down: the observable condition under which it comes down, the person authorised to take it down, and the maximum time between detection and removal. If nobody will accept that authority, the system is not ready to deploy. The AI governance playbook provides the model register and approval gate checklist that carry these fields.

Governing AI you bought rather than built

Where a system is procured, assurance replaces inspection. The buyer should obtain evaluation results on their own data and population rather than the vendor’s benchmark, know where inference happens and under whose law, hold a contractual right to withdraw, and be able to exit with their data and decision records intact. The vendor assurance question set in the AI security and assurance playbook covers this ground, and the national dimension is treated on the sovereign AI page.

Where NIST and ISO fit

The two reference points answer different questions. The NIST AI Risk Management Framework is a voluntary framework organised around four functions, Govern, Map, Measure, and Manage, and is useful for structuring how risk is identified and handled. ISO/IEC 42001, published in 2023 as an artificial intelligence management system standard, is certifiable and useful when an institution needs to demonstrate a managed system to an external party. Neither tells you who may approve a model in your organisation, which is why decision rights come first and the frameworks come second.

Why public-sector AI projects fail

Rarely because the model was inadequate. More often because the institution could not supply data of sufficient quality, because no single person owned the outcome, because the pilot was never designed to survive the operating environment, or because governance arrived after an incident rather than before launch. Portfolio discipline matters here too: an institution that cannot list its systems cannot govern them. A digital discovery across UNESCWA inventoried 181 databases and 145 portals with lifecycle verdicts, which is the kind of baseline that makes governance enforceable rather than aspirational.

Related: AI leadership and governance, AI governance in the United Nations, and the use case discovery and readiness playbook.