The question that decides whether a public-sector AI tool ships is rarely "does it work?" It is "can we publish what it does, and stand behind it?" When we built an evidence and reporting workspace for a policy and social-impact organisation working in partnership with a UK regional public authority, the build was finished long before it was allowed near a user. What stood between a working system and go-live was a list — the set of artefacts a combined authority's information governance, procurement and risk functions expect to see before an algorithmic tool touches public-facing work.
This post is that list. It is drawn from the controls we engineered into a real public-sector build (described, anonymised, in our public-sector evidence reporting case study). None of it is exotic. All of it is the difference between a pilot that quietly dies and a system someone will sign off.
Key takeaways
- A combined authority's pre-go-live gate comes down to five artefacts: an ATRS record, a DPIA plus Article 30 entry, an NCSC 14-principles mapping, advisory-only design, and citation provenance.
- The DPIA and the Article 30 record are separate documents — a risk assessment and a register entry — and a data protection officer will ask for both.
- Advisory-only design — the AI assists, a named officer decides, enforced in the system prompt — keeps the tool clear of automated-decision-making rules and makes the other artefacts honest.
- The NCSC's 14 Cloud Security Principles are the vocabulary a SIRO recognises; a documented target posture is not the same as the current state, and answering which is which is part of passing.
- Chunk-level citations let a reviewer click any sentence and land on the exact source, making the ATRS transparency claim true rather than aspirational.
The checklist is shorter than the regulation, and more demanding
There is no single UK statute that tells a public body how to deploy AI. The UK's approach is principles-based and regulator-led — five cross-cutting principles applied by existing regulators under the Department for Science, Innovation and Technology, not one omnibus AI law (GOV.UK government response, 6 February 2024). We cover what that means for boards in our companion piece, the UK has no single AI Act.
But "no single Act" does not mean "no requirements." A public body inherits a stack of duties that already apply, and a combined authority's governance team will ask you to evidence each one. In our experience the pre-go-live gate comes down to five things.
| Artefact | Owner asking for it | What it actually demands |
|---|---|---|
| ATRS record | Transparency / digital lead | A published description of the tool and why it is used |
| DPIA + Article 30 entry | Data protection officer | A documented risk assessment and a record of processing |
| NCSC 14 Cloud Security Principles mapping | Information security / SIRO | Evidence the hosting and data handling are sound |
| Advisory-only design | Risk / legal | Proof the AI cannot make or influence a decision on its own |
| Citation provenance | Subject-matter reviewers | Every claim traceable to a real source |
Each one is below.
An ATRS record is the artefact that makes the tool publishable
The Algorithmic Transparency Recording Standard is the standardised template public bodies use to publish what algorithmic and AI tools they use and why. It became mandatory for central government departments and arm's-length bodies in 2024, with the scope and exemptions policy published in December 2024 (GOV.UK ATRS Hub, as at May 2026). Combined authorities are not always strictly in central-government scope, but the standard has become the de facto expectation: if you cannot fill in an ATRS record, you cannot explain your tool to the public, and the governance team knows it.
Filling one in is a useful discipline, because it forces you to answer questions the build should have answered already:
- What does the tool do, in one paragraph a resident could read?
- What data does it use, and where does that data come from?
- Who is accountable for it, by role?
- What is the human's role in any decision it informs?
For our build the answers were clean because the system was designed around them. The tool retrieves evidence and drafts reports; it draws on a tiered evidence base plus live public datasets (labour-market statistics and public-health indicators); a named officer is accountable; and the AI never decides anything — it assists a person who does. An ATRS record is hard to write for a system that cannot answer those questions. It is straightforward for one that was built to.
The DPIA and the Article 30 record are not the same document
A Data Protection Impact Assessment is a risk assessment: it identifies the processing, the risks to individuals, and the mitigations. The Article 30 record is the register entry: a record of processing activities under UK GDPR. A combined authority's data protection officer will ask for both, and will not accept one in place of the other.
The DPIA is where the engineering decisions earn their place. Ours could point to specific, code-level mitigations rather than promises:
- Data minimisation by design. The system works with aggregated and anonymised data only, enforced as a hard constraint in the agent's instructions, not a guideline in a policy document.
- Tenant isolation. Row-Level-Security is written into the database schema so one tenant's data cannot be read by another. We are careful here: the design is real and present in the SQL, but we describe it as designed-in rather than independently test-proven, and we hold ourselves to that distinction in our own security and trust posture.
- Data residency. Embeddings and data at rest are held in the UK; model calls run under the cloud provider's data-processing agreement, with no training on the organisation's data.
One honest note that belongs in any public-sector DPIA: where automated decision-making is involved, the UK regime changed in early 2026. The Data (Use and Access) Act 2025 brought new Articles 22A–22D into force on 5 February 2026 (ICO guidance on the DUAA). The ICO's updated guidance on automated decision-making and profiling is still in draft — its consultation closed on 29 May 2026 with final guidance expected in summer 2026 — so a DPIA written today should treat the detailed ADM expectations as draft and date the assumption. In our case the point was moot by design: the tool makes no decisions at all, which is the cleanest way to stay clear of the ADM rules entirely.
NCSC's 14 Cloud Security Principles are the security baseline a SIRO recognises
The National Cyber Security Centre's 14 Cloud Security Principles are the common vocabulary UK public-sector security teams use to assess a hosted service (NCSC Cloud Security Guidance). A Senior Information Risk Owner does not want a vendor's marketing security page; they want each of the 14 principles addressed — data in transit, asset protection, separation between consumers, governance, supply-chain security, and the rest.
We map our public-sector build's compliance artefacts to those 14 principles, alongside Cyber Essentials and a CHECK/CREST penetration test, because that is precisely the vocabulary a public authority demands. A word of caution we apply to ourselves: a documented target posture is not the same as the current state of a development environment. We frame hardening work as designed-for and on the roadmap to certification, and we do not present a planned control as a live one. A SIRO will ask which is which, and answering honestly is part of passing the gate. We align to these standards and prepare for assessment against them; we do not claim certifications we have not earned.
Advisory-only is the design decision that makes everything else defensible
The single control that did the most work was the simplest to state: the AI assists, a named person decides, and the system cannot do otherwise. In our build this is a hard constraint in the agent's system prompt — no bid scoring, no influence on contract decisions, no automated outcomes, aggregated and anonymised data only. The model can search evidence, pull an area profile, fetch a document and read live public statistics. It cannot make a call that affects a person or a procurement.
This matters beyond tidiness. Advisory-only design is what keeps the tool clear of the automated-decision-making provisions, makes the ATRS record honest, and lets the DPIA conclude that the residual risk to individuals is low because no individual is subject to a solely automated decision. It is also the principle that runs through every system we build — the same human-in-the-loop discipline shows up as a cost-approval gate in one build and a named-reviewer ledger in another. We treat it as an architectural commitment, not a setting. Governance teams in other regulated sectors recognise the same move; our financial services playbook covers how individual accountability rules push toward exactly this design.
Chunk-level citations are what subject-matter reviewers actually check
The last thing the reviewers want — the analysts and policy officers who will use the output — is for every claim to be traceable to its source. Not "the model said so," but a clickable link to the exact passage: page number, character offsets, source tier and source URL. Our build records citation provenance at chunk level, so a reviewer can click any sentence in a generated report and land on the precise text it came from.
This is the public-sector form of a control we apply everywhere AI makes a claim: an extraction is only allowed to assert something it can point at. We write about the engineering of that elsewhere — making every AI claim quote a real source — but in a public authority it earns its keep twice over. It lets a reviewer verify the work without re-doing it, and it makes the ATRS transparency claim true rather than aspirational. A tool that cannot show its sources cannot be published with confidence, because the moment a figure is challenged, no one can say where it came from.
One honesty note we apply to our own writing about this system: a confidence-scoring feature is documented in places but is not implemented in the build, so we do not claim it. Citations are real and present; a confidence score is not. Saying which is which is the same discipline the checklist demands of the tool.
The list is a build specification, not a paperwork exercise
The pattern across all five items is the same. Each artefact a combined authority asks for is far easier to produce when the corresponding control was engineered in from the start, and close to impossible to retrofit onto a system that was not. An ATRS record is easy when the tool can explain itself. A DPIA is easy when minimisation and isolation are in the schema. The NCSC mapping is easy when hosting was a design decision. Advisory-only is easy when the model was never given the power to decide. Citations are easy when the system was built to quote its sources.
That is why we treat governance as something written into the code, not bolted on after a pilot works. The checklist above is, in effect, the specification we hand ourselves before a public-sector build begins.
Last reviewed: 29 May 2026.
If you are preparing an AI tool for a public-sector go-live and want a second read on the artefacts your governance team will ask for, have a conversation with us or see how we work.
