The AI Playbook for the UK Government is Government Digital Service guidance setting ten principles for public sector AI: knowing its limitations, lawful and ethical use, security, meaningful human control at the right stage, life cycle management, the right tool, openness, early commercial involvement, skills, and assurance alongside your own policies. It is guidance, not law.
What is the AI Playbook for the UK Government?
The Playbook is guidance from the Government Digital Service for civil servants and public sector staff considering the use of AI. It was published in February 2025 and it is labelled guidance, not legislation. Its purpose is to give people inside departments a shared starting point: what these systems do well, where they fail, and what has to be in place before one of them touches a decision about a real person.
I read it as a supplier does: a list of the questions a buyer will put to me. It is written for the inside of government, so it talks about business cases, spend controls, commercial colleagues and assurance. If you sell into the public sector, those are the conversations your product has to survive without you in the room.
What are the 10 principles?
The ten principles are: know what AI is and what its limitations are; use AI lawfully, ethically and responsibly; know how to use AI securely; have meaningful human control at the right stage; understand how to manage the AI life cycle; use the right tool for the job; be open and collaborative; work with commercial colleagues from the start; have the skills and expertise needed; and use these principles alongside your organisation's policies, with the right assurance in place.
As a list they read like a poster. Used as a filter they are sharper. Six of them concern the system you deploy. Four concern the organisation deploying it: skills, commercial involvement, openness and assurance. That split matters. A department can buy a sound tool and still fail the Playbook, simply by having nobody who can explain afterwards what it did and why.
The life cycle principle is the one people underestimate. A system assured at go-live is not the system running eighteen months later: the data has moved, the thresholds have been tuned, the staff have changed, and the original evaluation has quietly expired. Whatever you buy has to keep producing evidence about itself while it runs, not only while it is being piloted.
What does meaningful human control mean in practice?
It means a named person takes the consequential decision, and that person had enough information and enough time to have decided differently. The qualifier "at the right stage" is the load-bearing part of the principle. Control applied after an outcome has already landed on a citizen is not control. It is an appeal process, and it shifts the burden onto the person least equipped to carry it.
Three failure modes show up repeatedly. The first is the rubber stamp: a queue of four hundred items and an afternoon to clear it, so the reviewer approves everything. The second is control at the wrong point, where the reviewer sees the recommendation but not the inputs that produced it. The third is the quiet one. Control genuinely happened, but it left no durable trace, so six months later nobody can establish who decided, what they were shown, or when.
That third failure is the one I designed around. In the Mickai Sovereign Intelligence Operating System, a consequential action does not proceed until a named person approves it, and the approval, the identity, the timestamp and the context that person was shown all become part of the record rather than a line in an application log that rotates out in thirty days.
What does the Playbook say about using AI securely?
Secure use is a principle in its own right, which tells you where government thinks the risk sits. In practice it means treating an AI system as an attack surface rather than a feature: the model, the data reaching it, the prompts, the integrations, and the people with access to any of them. The NCSC guidelines for secure AI system development are the natural companion here, organised around secure design, development, deployment, and operation and maintenance.
For OFFICIAL and OFFICIAL-SENSITIVE material, one question sits ahead of the rest: where does this actually run, and what leaves the building? That is a security question before it is a commercial one. It is why SIOS runs on hardware the customer owns, works offline, and moves no data off the estate. If nothing egresses, a long list of questions about sub-processors, jurisdictions and retention periods stops needing an answer.
Is the Playbook legally binding?
No. It is guidance, and no department will be prosecuted for departing from it. That is a thinner shield than it sounds.
Underneath the Playbook sit obligations that do bind: data protection law, enforced by the Information Commissioner's Office, including the rules governing decisions taken by automated means; public law duties to act fairly and to give reasons; and the procurement rules governing how the contract was let. Guidance is what an auditor, an ombudsman, a select committee or a court reaches for when it needs a yardstick for reasonable behaviour. Following it is not a legal requirement. Departing from it is something you should be willing to explain in writing, to someone hostile, eighteen months later.
How does it change what a public body buys?
Two principles do most of the work: work with commercial colleagues from the start, and use the right tool for the job. Together they pull the AI conversation out of the innovation team and into the procurement pipeline early, while requirements can still be written properly.
The effect on suppliers is straightforward. Questions stop being about capability and start being about evidence. Not "can your system flag anomalies" but "show me the record of the last thousand flags, who approved each one, and what that approver was looking at". Transparency of AI use in procurement is now a policy topic in its own right: Procurement Policy Note 017 asks suppliers to disclose their own use of AI in preparing a bid, and it replaced PPN 02/24 for procurements commencing on or after 24 February 2025. It is a disclosure duty on bidders rather than a standard for the AI being bought, so read it alongside the Playbook rather than instead of it.
The right tool principle quietly rules things out. A large general-purpose model is the wrong instrument for a narrow, repeatable task that has to be defensible afterwards. That is why SIOS is assembled from 50 specialised models across 63 studios, 14 of them production-ready at launch and 49 in development, rather than one system asked to be everything.
What evidence satisfies the assurance principle?
Assurance is where most AI projects turn out to be thin. A policy document is not assurance. A vendor attestation is not assurance. Assurance is something a third party can verify without needing our cooperation.
That is the standard the Open Audit Record was built to meet. Every consequential action is sealed under ML-DSA-65, the post-quantum signature scheme NIST published as FIPS 204 in 2024. An auditor takes an exported record, a public key and tooling that is not ours, and verifies it offline. We are not in that loop, which is the point.
The record is tamper-evident, not tamper-proof, and the distinction is worth stating plainly. I cannot stop someone altering a copy of a record. What I can do is ensure that any alteration makes verification fail, visibly, against the original signature. Anyone offering you tamper-proof is offering a word rather than a mechanism.
If you are writing the business case, three artefacts do most of the work. First, a plain statement of where processing happens and what crosses the boundary. Second, the approval trail: which role signed off which class of action, and what that person could see at the time. Third, a verification procedure your internal audit team can run alone, on an export, without calling the supplier.
Mickai is in closed beta, with one regulated company onboarding as a design partner. The company holds 104 filed UK patent applications carrying 2,340 claims. None of that means SIOS has been assessed, accredited or endorsed against the Playbook. One further caveat if your use case involves scanned documents: a local OCR runtime has read scanned PDFs in controlled tests, and extraction and ingestion integration into SIOS is still being completed.
Frequently asked questions
Is the AI Playbook mandatory for government departments?
No. The Playbook is guidance published by the Government Digital Service, not legislation, so no department is compelled to follow it. In practice it functions as the expected standard. Auditors, committees and internal assurance functions use it as the yardstick for reasonable behaviour, so a department departing from it should be able to record why in writing.
What are the 10 principles in the AI Playbook?
Know what AI is and its limitations; use AI lawfully, ethically and responsibly; know how to use AI securely; have meaningful human control at the right stage; manage the AI life cycle; use the right tool for the job; be open and collaborative; work with commercial colleagues from the start; have the skills needed; and apply these alongside your organisation's policies with the right assurance.
What does meaningful human control actually mean?
A named person takes the consequential decision, with enough information and enough time to have decided otherwise. The phrase "at the right stage" matters: review that happens after the outcome has reached a citizen is an appeal, not control. Good practice records who approved, when, and what they were shown, so the control can be evidenced later.
Does the Playbook apply to suppliers as well as departments?
It is written for public sector staff, not suppliers, so it does not bind a vendor directly. It still shapes every question a vendor is asked, because the department has to satisfy it. Expect requirements on secure deployment, where data is processed, named human approval and evidence an auditor can verify without the supplier's help.
How do we evidence Playbook alignment in a business case?
Map each principle to an artefact rather than a statement of intent. Where processing happens and what crosses the boundary. Which role approves which class of action, and what that person sees. How the life cycle is monitored after go-live. And a verification procedure internal audit can run alone on an exported record, without contacting the supplier.
Related briefings
UK AI regulation
- Is There a UK AI Act? How the UK Regulates AI Today
- AI Cyber Security Code of Practice: Who It Applies To
- Does Cyber Essentials Cover the AI Tools Your Staff Use?
- ICO Code of Practice on AI and Automated Decision-Making
- ISO 42001 vs ISO 27001: Do You Need Both Standards?
Data protection and UK GDPR
- UK GDPR and AI: Does Your Data Have to Stay in the UK?
- UK Data Storage vs AI Processing: What Is the Difference
Part of a series of 60 briefings on deploying and governing AI in UK regulated organisations, archived with a DOI at 10.5281/zenodo.22975756.
Evaluating AI for a regulated organisation? Mickai runs on hardware you own, offline. Consequential actions wait for a named person to approve them, and what the AI did is sealed into a signed record an auditor can check without us. Applications for the invitation-only closed beta are open. Apply for the closed beta.
Written by Micky Irons, founder and chief executive of Mickai LTD.
Top comments (0)