AI go-live checklist for regulated organisations

An AI go-live checklist for regulated organisations should prove five things before launch: the board has approved the use case, legal and sector duties have been mapped, controls are evidenced, accountable owners are named, and post-launch monitoring is live.

This is not the same as a public-sector publication gate. Our public-sector checklist covers the more specific ATRS, DPIA and NCSC artefacts a combined authority may ask for before an algorithmic tool is released (public-sector AI go-live checklist). This article generalises the gate for boards in regulated sectors: financial services, housing, charities, education, professional services and public bodies that need a sign-off pack before an AI system touches real users, customers, tenants, pupils, clients or staff.

Key takeaways

• The board should approve the use case, not the model in the abstract: purpose, affected groups, decision rights, residual risk and stop conditions.
• A launch pack should contain evidence, not policy statements: a DPIA or documented no-DPIA rationale, an AI risk register entry, testing evidence, security review, owner map and monitoring plan.
• The UK approach remains regulator-led. The GOV.UK AI regulation response sets five cross-sector principles for existing regulators to apply within their remits, so the relevant sector rulebook still matters.
• Human oversight has to be operational. A named person must be able to review, challenge, pause and reverse the AI-assisted process where the outcome affects people.
• Go-live is a control gate, not the end of governance. Monitoring, incidents, model changes and vendor changes need board-visible triggers after launch.

AI go-live checklist for regulated organisations

Treat go-live as a board assurance decision. The paper should be short enough to read, but the pack behind it should be strong enough for a regulator, auditor, data protection officer or customer committee to inspect.

The board pack should answer seven questions:

1. What decision or workflow will the AI system support, and who is affected?
2. What legal, data protection, equality, conduct, safety, professional or fiduciary duties attach to that workflow?
3. Which risks are accepted, reduced, transferred or rejected, and who owns each one?
4. What evidence shows the control is working now, not merely designed?
5. What human judgement remains in the loop, and what can the human actually change?
6. What happens if the system behaves unexpectedly after release?
7. What event brings the system back to the board or risk committee?

Those questions align with the five principles in the GOV.UK AI regulation government response: safety and security, transparency and explainability, fairness, accountability, and contestability. They also keep the conversation anchored in the board's normal job: approving risk appetite, testing controls and insisting on evidence.

What the board must decide before launch

A regulated board should not be asked to approve a technical release note. It should be asked to make a bounded governance decision.

The paper should ask the board to decide:

• Purpose and limits. The approved purpose of the AI system, the prohibited uses, the user groups affected and the point at which the tool must stop or return work to a person.
• Risk appetite. Whether the residual risk sits within the organisation's stated appetite, especially where the system affects vulnerable people, financial outcomes, access to services, employment, complaints, safeguarding or legal duties.
• Accountability. Which executive owns the system, which function owns the control evidence, which person can pause the system, and which committee receives exceptions.
• Human oversight. Whether the human reviewer has enough information, time and authority to change the outcome. A nominal approval button is not meaningful oversight.
• Launch conditions. The evidence required before release, the first monitoring date, the incident route and the triggers for board re-approval.

Boards that want a broader test of this discipline can use the Board AI Accountability Check before the launch paper is written. It exposes whether accountability, oversight and evidence already exist or whether the project team is trying to assemble them late.

Controls and evidence required at the gate

The launch gate should be written as a control table. A director should be able to point at each row and ask, "where is the evidence?"

Control	Evidence the board should see	Owner
Use-case authority	Approved purpose, affected groups, prohibited uses, success measure and stop rule	Executive sponsor
Legal and data protection assessment	DPIA or documented no-DPIA rationale, lawful basis, processor map and record of consultation with the DPO where personal data is involved	Data protection officer or legal lead
Risk register entry	Entry in the AI risk register with risk owner, severity, control, evidence source, review date and escalation route	Risk owner
Model and output testing	Test set, known failure modes, bias or error analysis where relevant, acceptance thresholds and unresolved limitations	Product or service owner
Security and supplier review	Threat model, access controls, logging, vendor due diligence, processor terms and evidence that secrets, prompts and data flows are controlled	CISO or information security lead
Human oversight and redress	Named reviewer role, decision rights, escalation route, user-facing explanation and route to challenge where the tool affects people	Service owner
Monitoring and incident response	Metrics, drift or quality checks, complaint triggers, incident playbook, owner for pausing the system and date of first review	Operational owner

The ICO's AI accountability guidance says a DPIA can demonstrate accountability and should not be treated as a box-ticking exercise. It also says that, in most cases, AI using personal data is likely to require a DPIA, with the assessment made case by case and documented either way (ICO AI accountability and DPIAs). That is why the gate asks for either the assessment or the documented reason one is not required.

Security evidence should also be lifecycle evidence. The NCSC secure AI development guidelines split the work into secure design, secure development, secure deployment, and secure operation and maintenance. A launch paper that covers design but has no monitoring, update or incident plan is unfinished.

How the gate maps to frameworks and regulators

The checklist is useful because it translates multiple frameworks into one board decision. It does not replace those frameworks. It shows where each one should appear in the launch pack.

Framework or regulator	What it means at go-live	Evidence to keep
UK AI regulatory principles	The board should be able to evidence safety and security, transparency and explainability, fairness, accountability, and contestability for this use case	Principle-to-control mapping, risk register entry, user explanation and challenge route
UK GDPR and ICO guidance	Personal-data AI needs documented accountability, data protection by design and a DPIA where high-risk processing is likely	DPIA, lawful basis, data-flow map, controller or processor role map and residual-risk decision
NIST AI RMF	The NIST AI RMF Core organises AI risk work into Govern, Map, Measure and Manage, and says risk management should continue through the lifecycle	Governance owner, context map, measurement evidence and management actions
NCSC secure AI development	Security has to cover design, development, deployment, operation and maintenance	Threat model, access review, release controls, logs, monitoring and update process
FCA-regulated financial services	The FCA's AI approach says it does not plan extra AI regulations and will rely on existing frameworks, including Consumer Duty and accountability rules	Customer-outcome assessment, SM&CR ownership, conduct-risk review and complaints monitoring
UK Corporate Governance Code 2024	For in-scope listed companies, the FRC code applies from 1 January 2025, with Provision 29 from 1 January 2026 requiring board declarations on material internal controls	Material-control assessment, monitoring evidence, exceptions and near misses
EU AI Act exposure	If the organisation provides or deploys systems in EU scope, the EU AI Act classification should be recorded before launch	Role assessment, risk tier, obligations map and date-stamped rationale
ISO/IEC 42001	Use the management-system discipline to define scope, leadership, risk treatment, operational controls and review cadence	Scope statement, AI inventory, risk treatment plan and management review record

For a fuller UK framework view, read our guide to an AI governance framework for UK boards. For ISO specifically, use our internal explainer on what ISO/IEC 42001 requires of a board rather than relying on a certificate headline.

Common mistakes that delay sign-off

The same failures appear across sectors.

• Approving the model instead of the use case. A model may be acceptable for summarising board papers and unacceptable for triaging complaints. The risk sits in the workflow, affected group and consequence.
• Treating a pilot as low risk because it is small. A small pilot can still process personal data, shape a customer outcome or create an evidential trail the organisation later relies on.
• Writing "human in the loop" without decision rights. The paper should say what the human sees, what they can change, when they must intervene and how disagreement is recorded.
• Confusing vendor assurance with organisational accountability. A supplier's security paper helps, but the regulated organisation still needs its own data-flow map, risk acceptance and operating controls.
• Leaving monitoring until after launch. If the first metric is designed after release, the board has approved a system without knowing how performance, harm, complaints or drift will be detected.
• Using annual review for a live system. AI systems change through prompts, model releases, data shifts, user behaviour and vendor updates. The board needs trigger-based review, not only a diary date.

The questions in every UK board should ask about AI are a useful pre-read for directors who need to test whether the proposed launch pack is complete.

Next step

If the project is still early, take the Board AI Scorecard and use the result to identify the weakest governance areas before the launch paper is drafted.

If the system is within weeks of release, run a tighter assurance pass. The AI governance diagnostic reviews the use case, risk evidence, governance documents and control design before the board is asked to sign off. The output should be a board-ready evidence pack: what can go live, what must change first and what should be monitored after release.

Sources: GOV.UK AI regulation government response · ICO AI accountability and DPIAs · NCSC secure AI development guidelines · NIST AI RMF Core · FCA AI approach · FRC UK Corporate Governance Code 2024 · EU AI Act