The government's AI Playbook tells civil servants to check everything. A line-by-line reading suggests nobody checked the playbook.
Estimated reading time: 8 minutes
In short. The Artificial Intelligence Playbook for the UK Government instructs every civil servant to treat AI output as plausible but not necessarily correct, and to check everything. Read against the evidence it cites, the playbook itself fails that test: it misnames its own sponsoring department three times, presents a security incident in a form that did not happen, invents a data-retention policy, overstates the single most important legal constraint on government AI, and contradicts its own security analysis on the question departments most need answered. Much of it is sensible. None of it has been revised in the nineteen months since publication.
In February 2025 the Government Digital Service published the Artificial Intelligence Playbook for the UK Government [1], a 118-page guide meant to help departments and public bodies "harness the power of a wider range of AI technologies safely, effectively, and responsibly" [2]. It carries a ministerial foreword, credits from more than twenty departments, four tech giants and five academic institutions, and a central message it repeats relentlessly: AI output is plausible but not necessarily correct, so check everything [3].
It is advice the playbook's own authors could have taken. A line-by-line reading of the document, which at the time of writing remains unrevised on GOV.UK nineteen months after publication [1], turns up verifiable factual errors, a security anecdote describing an event that did not happen that way, a misstatement of UK data protection law, and direct contradictions between the playbook's enthusiasm for autonomous AI and its own security analysis.
None of this makes the playbook worthless. Much of it is sensible, and parts of its security guidance are better than most vendor documentation. But a government document whose first principle is "you know what AI is and what its limitations are" should be held to the standard it sets for the machines.
A department that cannot spell its own name
Start with the smallest error, because it is the most telling. On pages 31, 44 and 69, the playbook names its own sponsoring department as the "Department for Science, Information and Technology" [2]. It is the Department for Science, Innovation and Technology: the department whose minister, Feryal Clark, signed the foreword, and which is named correctly elsewhere in the same document. Three occurrences is not a typo; it is a proofreading process that did not happen.
It is not alone. The acknowledgements (page 5) thank the "Department for Levelling Up, Housing and Communities", a department that had been renamed the Ministry of Housing, Communities and Local Government seven months before publication, and file BCS, a professional body, under "Academic institutes". Page 34 refers to the "UK Statistic Authority" (it is the UK Statistics Authority). Pages 41 and 43 cite the "Public Contract Regulations 2015" (Public Contracts Regulations). Page 101 tells departments to comply with standards defined by the "International Standards Organisation", and ISO's actual name is the International Organization for Standardization. Individually trivial; collectively, a signal about how carefully the rest was checked.
The security story that did not happen that way
The security chapter is the playbook's strongest section, which makes its factual stumbles more unfortunate.
On page 79, illustrating supply-chain risk, it states that "when software libraries are hacked, all downstream systems that depend on those libraries are affected", and offers as its notable example "the Faker NPM hack". The faker.js incident of January 2022 was not a hack. The package's own maintainer, Marak Squires, deliberately sabotaged faker.js and its sibling colors.js in protest at large companies using his free work [4] [5]. The distinction matters because the lessons differ: an external compromise argues for supply-chain integrity checks, while maintainer sabotage argues for dependency vetting and caution about single-maintainer open-source projects. The playbook draws the wrong lesson from a mislabelled event.
Page 94 is worse. A scenario describes a developer who "receives advice to install a specific software package, ArangoDB... When the LLM was trained, the package did not exist. A hacker has previously interrogated the LLM... They then created a malicious package with the fictitious name." ArangoDB is a real database from a real company. In the Vulcan Cyber research the playbook itself cites, ChatGPT hallucinated a non-existent npm package called arangodb, while the legitimate JavaScript client is arangojs, and no hacker planted malware; a researcher registered an empty proof-of-concept package to demonstrate the risk [6] [7]. As written, the playbook implies a real vendor's product is fictitious and presents a hypothetical as a completed attack. The underlying risk, now widely called slopsquatting, is real and worth warning about [8]. The example, as told, is not.
Then there is page 77, where the playbook says Microsoft's Azure OpenAI service offers models "running in a private instance with zero-day retention policies". There is no such thing as "zero-day retention": the phrase collides "zero-day", a class of security vulnerability, with "zero data retention", a data-handling posture. And the substance is wrong too. Azure OpenAI's default is to retain prompts and completions for up to 30 days for abuse monitoring; genuine zero-data-retention requires an application to Microsoft and approval [9]. A procurement team relying on this sentence would misdescribe its own data-handling position, in a document that exists to prevent exactly that.
The law, overstated
Page 73 tells civil servants that UK GDPR "Article 22 currently prohibits decision(s) based solely on automated processing that have legal or similarly significant consequences", and that services affecting a person's legal rights "must only use AI to support decisions that must be made by a human decision maker" [2]. That is not what the law said. Article 22 was never a blanket prohibition: it expressly permitted solely automated decisions where necessary for a contract, authorised by law, or based on explicit consent, subject to safeguards. The playbook's flat "must be made by a human" is stricter than the statute, and gives no help on the safeguards required where the lawful routes are used.
The passage has since been overtaken entirely. The Data (Use and Access) Act 2025, which received Royal Assent in June 2025, replaces the old Article 22 regime with a more permissive framework for automated decision-making (except where special category data is involved), with provisions commencing in phases [10] [11]. Nineteen months on, the playbook's account of the single most operationally important legal constraint on government AI is both overstated and out of date.
Smaller legal slips compound the impression. Page 66 attributes three separate DPIA triggers to "Article 35(3)(a)" of the UK GDPR; they are Articles 35(3)(a), (b) and (c). Page 67 says international transfers "are restricted under Article 46"; Article 46 is the provision that permits transfers subject to safeguards, and the restriction is Article 44. And page 83's claim that "a legal case in Canada found an organisation... with a hallucinating chatbot financially responsible" stretches Moffatt v Air Canada, a small-claims tribunal decision awarding roughly CA$800, in which it was never established that the chatbot was a hallucinating large language model rather than a badly scripted conventional one [15]. The liability principle is real; the framing is not established fact.
A document that disagrees with itself
The deeper problem is internal consistency.
On page 22, generative AI "learns from large amounts of specially curated training data". On page 52, the same technology is "trained on vast amounts of unfiltered data scraped from the internet". Both cannot be true as stated; the second is closer to reality, and the first reads like vendor copy.
Principle 1 (page 10) asserts that "AI systems currently lack reasoning", a contested blanket claim even in February 2025, months after dedicated reasoning models had shipped. Thirteen pages later, the playbook's own Agentic AI section describes systems that "figure out the best way to achieve the system's objectives", and page 83 describes the ReAct pattern in which "the LLM is prompted to reason about how to perform a task". The document holds both positions and reconciles neither.
Most consequentially: the Agentic AI section (page 23) is pure enthusiasm. Autonomous agents operating "with minimal human intervention" make it "easier to create more efficient and effective systems", with not one sentence of risk discussion, in a document otherwise saturated with caution. Sixty pages later, the security chapter concludes that because prompt injection cannot be reliably prevented, "there must be a human present to review the action before carrying it out", which "significantly limits the utility of generative AI in fully automated solutions". That is a direct contradiction of the agentic pitch, and the two sections never acknowledge each other, on precisely the question where departments most need joined-up guidance.
The same pattern recurs in miniature. The security recommendations (page 96) advise: "Avoid putting LLM chatbots on public-facing government websites unless the risk of direct prompt injection is acceptable", having rated that attack's likelihood HIGH. The appendix's flagship case study is GOV.UK Chat, an LLM chatbot for the public, and the document never explains how its own showcase satisfies its own criterion. That case study, meanwhile, reports an answer "accuracy threshold of 80%" under the heading "Value delivered": a public information service wrong one time in five, presented as an achievement, pages after the playbook warns that hallucination "could lead to someone being misled about a government service, policy or point of law."
What 118 pages do not contain
The single most important question such a playbook could answer, where government should not use AI, receives two bullet points (page 37): "be cautious" about fully automated significant decisions, and do not use AI "on its own" in high-risk areas. No definition of high-risk, no examples, no red lines; this from a state whose recent history includes the withdrawn visa-streaming algorithm and the A-level grading fiasco. The EU AI Act's prohibited-practice and high-risk categories are never mentioned, even as a reference point.
Nor is there a single measurable requirement anywhere in the main text. Departments are told to "ensure a net positive impact on society," to make "specific and robust measurements," and to "select low carbon emission energy grids", with no threshold, benchmark, methodology or worked example. In place of specifics, the playbook signposts: a count of its cross-references finds it defers to more than forty other frameworks, standards and guides, without resolving priorities or conflicts between them. And unlike its sibling, the Digital, Data and Technology Playbook, which departments must follow on a "comply or explain" basis, the AI Playbook has no compliance status at all. "Should" appears hundreds of times; a consequence for ignoring it, never.
Already history
Some of the playbook was stale on arrival. Page 22 cites "Google Duet AI" as a current example of embedded generative AI; Google had renamed Duet AI to Gemini a full year before publication [12]. Page 75's "Slack GPT" had long since become Slack AI. Page 22's "AWS ChatOps Chatbot" appears to confuse AWS Chatbot, a notification-routing tool, with a generative AI product. The playbook, published in the same month DSIT was announcing its own "Humphrey" AI suite for civil servants and folding CDDO into a reconstituted GDS, mentions neither [13] [14].
Other passages have aged badly since: the Procurement Act 2023 went live a fortnight after publication, superseding the playbook's framing; the Data (Use and Access) Act rewrote the automated-decision-making rules [10]; and the reassurance on page 86 that Microsoft and OpenAI had "yet to observe any particularly novel or unique attacks resulting from the use of AI" describes the threat landscape of early 2024, not today's. The foreword promised "a launchpad that we will continuously revise and improve" [3]. As of this week, GOV.UK records no revision [1].
Credit where due
Fairness requires saying what the playbook gets right, because it is not nothing. Its statement that "an LLM cannot distinguish between user input and system instructions... there is no way to prevent a user prompt affecting the behaviour of the LLM" (page 92) is more honest than most vendor documentation. Its email-attachment prompt-injection scenario anticipated attacks that later became mainstream. "Treat all LLM-generated code as inherently insecure" and "never use private data that needs different levels of user access permissions to train or fine-tune a model" are correct, crisp and actionable. The GOV.UK Chat case study is candid about hallucinations and about manual quality assurance failing to scale. And the cultural instincts, engage lawyers early, keep humans over consequential decisions, assume the model is wrong, are the right ones.
Verdict
The AI Playbook's problem is not its values but its craftsmanship. A document that instructs every civil servant to verify AI output misnames its own department three times, mislabels a famous security incident, garbles the research behind its showcase attack scenario, invents a data-retention policy, and overstates the very article of data protection law most likely to govern its readers' projects. Its promotional sections contradict its security analysis without acknowledgement, and on the hardest question, where government should refuse to deploy AI, it offers two sentences of caution in 118 pages.
The irony writes itself: the playbook is a competent first draft that needed exactly what it prescribes for AI systems, rigorous review by someone accountable for accuracy, and a maintenance plan that survived contact with publication. Until it gets one, departments should treat it the way it tells them to treat a large language model: useful, fluent, and not to be relied upon without checking.
This analysis is based on the February 2025 PDF edition (ISBN 9781036688745), published 10 February 2025 and unrevised on GOV.UK at the time of writing. Page references are to that PDF. If the playbook is revised, this piece will be updated with a diff of what changed; the document is tracked in our Daily Register.
The star score counts thirteen documented mistakes: six naming and proofreading errors (the DSIT misnaming, DLUHC, BCS, the UK Statistic Authority, the Public Contract Regulations, the ISO name), three security-chapter errors (the faker mislabel, the garbled ArangoDB scenario, the invented zero-day retention policy) and four legal misstatements (Article 22, the DPIA triggers, Articles 46 and 44, the Moffatt framing). The internal contradictions and stale product references are documented above but not counted as mistakes. Thirteen falls in the 10 to 19 band: two stars. The bands are on the ratings page.
Sources
- GOV.UK publication page, "AI Playbook for the UK Government" (checked unrevised, 11 September 2026). https://www.gov.uk/government/publications/ai-playbook-for-the-uk-government
- "Artificial Intelligence Playbook for the UK Government" (PDF, February 2025 edition; all page references). https://assets.publishing.service.gov.uk/media/67aca2f7e400ae62338324bd/AI_Playbook_for_the_UK_Government__12_02_.pdf
- GDS blog, "Launching the Artificial Intelligence Playbook for the UK Government" (10 February 2025; the foreword's revision promise). https://gds.blog.gov.uk/2025/02/10/launching-the-artificial-intelligence-playbook-for-the-uk-government/
- BleepingComputer, "Dev corrupts NPM libs 'colors' and 'faker' breaking thousands of apps" (January 2022; the sabotage, not a hack). https://www.bleepingcomputer.com/news/security/dev-corrupts-npm-libs-colors-and-faker-breaking-thousands-of-apps/
- Sonatype, "Maintainer Sabotages npm Libraries 'colors' and 'faker'" (corroborates the maintainer-sabotage account). https://www.sonatype.com/blog/npm-libraries-colors-and-faker-sabotaged-in-protest-by-their-maintainer-what-to-do-now
- SecurityWeek, "ChatGPT Hallucinations Can Be Exploited to Distribute Malicious Code Packages" (the Vulcan Cyber research; arangodb vs arangojs). https://www.securityweek.com/chatgpt-hallucinations-can-be-exploited-to-distribute-malicious-code-packages/
- Infosecurity Magazine, "New ChatGPT Attack Technique Spreads Malicious Packages" (proof-of-concept package, no planted malware). https://www.infosecurity-magazine.com/news/chatgpt-spreads-malicious-packages/
- Lasso Security, "Lasso Research: AI Package Hallucinations" (the wider package-hallucination risk). https://www.lasso.security/blog/ai-package-hallucinations
- Microsoft Q&A, "How to opt-in for zero data retention with Azure OpenAI service?" (default 30-day retention; approval needed for zero data retention). https://learn.microsoft.com/en-us/answers/questions/4372674/how-to-opt-in-for-zero-data-retention-with-azure-o
- Data (Use and Access) Act 2025, Part 5 (the replacement automated-decision-making regime). https://www.legislation.gov.uk/ukpga/2025/18/part/5
- DLA Piper Privacy Matters, "UK: Data (Use and Access) Bill passes through Parliament" (June 2025; commencement phasing). https://privacymatters.dlapiper.com/2025/06/uk-data-use-and-access-bill-passes-through-parliament/
- Google Workspace Updates, "Introducing Gemini for Google Workspace" (February 2024; Duet AI renamed a year before the playbook cited it). https://workspaceupdates.googleblog.com/2024/02/gemini-for-google-workspace.html
- Civil Service World, "DSIT previews 'Humphrey' AI package for civil servants in £45bn productivity drive" (January 2025). https://www.civilserviceworld.com/professions/article/dsit-humphrey-ai-package-civil-servants-45bn-productivity-drive
- PublicTechnology, "CDDO brought back into GDS in digital government shake-up" (January 2025). https://www.publictechnology.net/2025/01/21/education-and-skills/cddo-brought-back-into-gds-in-digital-government-shake-up/
- Moffatt v Air Canada, 2024 BCCRT 149 (British Columbia Civil Resolution Tribunal, February 2024). https://www.canlii.org/en/bc/bccrt/doc/2024/2024bccrt149/2024bccrt149.html