Turn the UK AI Risk Toolkit Into a Release Decision

AI Trust & Governance

26 October 2026 | By Ashley Marshall

A completed AI risk spreadsheet cannot tell your team whether to press launch. A named decision, backed by real tests, can.

A risk register is not a release decision

The UK Department for Science, Innovation and Technology published its AI Risk Management Toolkit on 8 September 2026. It is useful precisely because it does not pretend that buying a model or completing a spreadsheet makes an AI service safe. The guidance covers design, operation, procurement and delivery. It describes a workbook, a monitoring dashboard and a set of questions that a multidisciplinary team can use to identify risks. For a UK business, the strongest application is to turn those materials into a decision at a specific point: is this workflow ready to handle real work, with these users, data and permissions?

Too many pilots have a risk register that exists separately from the person pressing the launch button. A row says an output could be wrong, but the release plan does not say how often wrong answers are tolerable, which cases require human review, or who can stop the service. That is documentation, not control. A proper release gate links each material risk to an owner, evidence from realistic tests, a treatment and a decision. The decision can be to proceed within limits, run a smaller pilot, redesign the workflow or stop. Every one of those can be rational. The mistake is treating a completed template as automatic permission to launch.

Start with one use case, such as an assistant drafting replies to customer enquiries. State the intended users, input data, permitted actions, forbidden actions and the cost of a bad output. Record who owns the business outcome, not just who administers the software. Then ask that owner to sign off the evidence, including any unresolved risks. Keep the approval tied to a named version of the tool and workflow. If the supplier changes the model or your team connects another data source, the decision needs reopening. DSIT explicitly calls the toolkit a starting point and says an existing risk register is acceptable if it tracks risks, mitigations and owners. That is permission to use a lean process, not to skip the decision.

Make the gate small enough to use

The temptation is to copy a public-sector framework into a 40-page internal policy. Most smaller firms will struggle to maintain that. Instead, create a one-page release record supported by test results. It should say what the AI system does, what data enters it, what it can change, what the expected benefit is, which failure modes matter and who can pause it. Attach a short risk table with severity, likelihood, treatment, evidence and residual owner. This preserves the point of the DSIT guidance without creating an approval theatre that staff route around.

For the customer enquiry example, a meaningful test set includes ambiguous requests, angry customers, missing account data, requests to change bank details and messages that contain instructions aimed at the assistant. Test against the actual knowledge base and permissions the service will use. Record both ordinary performance and serious exceptions. A 95% answer score can conceal the one wrong refund promise that creates a financial or regulatory problem. The gate should therefore define specific failure thresholds, not merely an average accuracy score. Decide which outputs remain drafts and which, if any, can be sent without review. If no one can explain why a class of messages is safe to send automatically, keep that class behind human approval.

What this means in practice: a small business can hold a 30-minute release review with the workflow owner, an IT or security lead and someone who understands the customer or employee impact. A single person may hold several roles, but the perspectives still need to be represented. DSIT's guidance names governance, leadership, data, engineering, security, legal, domain experts and users as relevant contributors. You do not need eight committees. You do need someone to challenge the assumptions made by the person most excited to launch. Record the decision and date. Set a review trigger rather than letting the document expire quietly.

Test the boundary, not just the answer

An AI system that can read, retrieve or act has a different risk profile from a standalone chat window. The National Cyber Security Centre's guidance for leaders points to hallucination, biased responses, prompt injection and data poisoning. It asks managers to understand accountability, critical assets, supplier dependencies and the worst operational consequence if a tool fails. Those are release questions. The NCSC also notes that its secure AI development guidelines were developed with the US Cybersecurity and Infrastructure Security Agency and agencies from 17 other countries. Security is not a final technical checklist after the business has decided to go live.

For a retrieval assistant, test whether a user can get information they could not access in the underlying system. For an agent, test whether a document or web page can persuade it to send data elsewhere or take an unauthorised action. For a drafting assistant, test whether it invents policy or cites an outdated document. The expected result must be defined before the test. Otherwise teams tend to reclassify a failure as an interesting edge case after seeing it. Save examples of the input, output, model or tool version and reviewer decision, while handling personal data according to your retention rules.

What this means in practice is separating three powers: reading information, recommending an action and executing an action. The same model may be adequate for the first and unacceptable for the third. Give the system the least access needed and place payment, deletion, external send and permission changes behind a deliberate confirmation step. A prompt saying 'be careful' is not a substitute for a permission boundary. The release record should identify what the system cannot do even if it is tricked. That is a testable claim, and one the business owner can understand without becoming a model engineer.

Privacy and supplier claims require local evidence

The Information Commissioner's Office said on 8 October 2026 that ten major foundation-model developers had made, or committed to make, data protection changes following its supervision. It also launched a six-week call for evidence on the data protection risks of agentic AI, with responses due by 20 November 2026. Those are concrete developments, but neither is a certificate that your particular workflow complies with UK data protection law. The ICO explicitly says autonomy is not an excuse for poor compliance. Its enquiries into reported agent testing incidents are ongoing, so do not present those incidents as settled findings.

Your release gate needs a local data map. Which personal information reaches the model, retrieval store, logs and connected tools? Can a supplier use inputs to improve its service? Where are records retained and for how long? Can people exercise their rights in relation to your outputs and records? Who notices if an agent accesses the wrong customer file? These are operational questions, not supplier-marketing questions. Ask for the contract and technical settings that answer them. If a feature promises 'enterprise privacy', verify what that phrase means for the precise plan, region, connectors and retention settings you will use.

A common counterargument is that a provider's controls make another internal review redundant. A mature supplier can certainly reduce your burden, but it cannot define your customer promises, choose your lawful use of data or decide how much autonomy your staff should grant. The supplier controls part of the stack. You control the task, permissions, data sources, human supervision and customer-facing consequences. A practical compromise is to reuse supplier assurance evidence where it is relevant, then test the remaining local risks. Do not run a fresh audit of a provider's entire model if the real risk is that your own CRM connector exposes every customer record to a general-purpose assistant.

Set an operating trigger before launch

DSIT's toolkit says AI systems evolve during their lifetime and there is no final version to validate against. It calls for ongoing risk management from use-case selection to retirement, with reassessment after changes in inputs, models and context. That matters because a safe pilot can become an unsafe service without anyone changing the original prompt. A new team may start using it, a supplier may alter a model, a knowledge base may go stale, or an integration may add write access. A release gate is only credible if the business knows which changes force a fresh decision.

Define a short list of triggers: new data category, new user group, new external connector, change from draft to automatic send, material model change, a serious incorrect output, unexpected access, or a measured fall in performance. Assign someone to monitor each trigger and say where staff report concerns. The review should compare current outcomes with the baseline recorded at launch. Include business outcomes, such as resolution quality or time saved after human correction, as well as safety incidents. A system that passes every security check but makes the team slower is not a successful deployment.

There is a sensible route for firms without an AI governance department. Pilot one bounded task for a few weeks, log exceptions, review samples with staff who do the work, and expand only when the evidence supports it. Keep the ability to revert to the previous workflow. The release record should name the fallback process and the person authorised to activate it. Do not wait for a dramatic breach before using the stop switch; persistent low-quality outputs are enough reason to pause. This is the larger point of the toolkit: risk management should help a business take a justified risk in pursuit of a benefit, not produce paperwork that says every possible risk has disappeared.

Frequently Asked Questions

Is the DSIT AI Risk Management Toolkit mandatory for private businesses?

No. It is guidance and a starting point. Private firms can adapt its questions and workbook to their own risk process while meeting the laws that apply to their use case.

Do we need to use the government workbook?

No. The guidance says an existing risk register may be used if it records risks, mitigations and owners well enough to observe and update them.

Who should approve an AI release?

The person accountable for the business outcome should own the decision, informed by security, data protection, technical and frontline perspectives as relevant.

What evidence belongs in the release record?

Include the intended task and permissions, realistic test cases and results, material risks, controls, residual owners, approval date and review triggers.

Can a supplier assurance report replace our tests?

It can reduce duplicated supplier checks, but it cannot test your local data, connectors, prompts, permissions and customer-facing decisions.

When must we repeat the release review?

Review after material changes to the model, data, users, connectors or autonomy, and after a serious failure or sustained decline in measured outcomes.

Should every AI output need human approval?

No. Match the review level to the consequence. Low-impact suggestions may be automated; payments, deletion, external sends and consequential decisions warrant stronger controls.

What if a pilot performs well but has one serious failure?

Do not hide the failure inside an average score. Identify its cause, reduce the possible impact, retest that failure class and decide explicitly whether residual risk is acceptable.