Public Sector AI Isn't Stuck on Models. It's Stuck on Data Governance

The UK has one of the most ambitious AI strategies in the world on paper. An AI Opportunities Action Plan. A national AI Playbook. A Digital Centre of Government. A National Data Library backed by over £100 million. A Compute Roadmap aiming to expand sovereign compute capacity twenty times over by 2030.

And yet the Public Sector AI Adoption Index 2026 ranked the UK sixth out of ten countries, with a score of 47 out of 100.

That gap between strategic ambition and what's actually shipping is the most interesting story in government technology right now, and it's not a story about model capability. It's a story about data. If you build software that touches public services, this is the terrain you're actually working in, whether the brief mentions it or not.

I run AI44, a London based AI training and delivery firm, and most of the friction I see in public sector AI projects has nothing to do with which model a team picks. It's whether the data underneath the model is trustworthy, traceable, and safe to touch. Here's what that looks like in practice, and what it means for how you build.

The strategy is real. The plumbing isn't finished.

It's worth being fair to what's actually been built. The AI Opportunities Action Plan set out 50 recommendations in January 2025 covering compute, data, skills, energy, and regulation, and DSIT's one year progress report in January 2026 showed real movement on most of them. The National Data Library completed its discovery phase and published the first set of "AI ready data" guidelines, the first time a UK government department has set structural standards for how public data should be prepared for machine consumption rather than just published as open data. Five kickstarter projects are underway. The Compute Roadmap landed in April 2026.

None of that is nothing. But a parliamentary Public Accounts Committee report was blunt about the underlying problem: out of 72 of the highest risk legacy digital systems flagged in the 2022 to 2025 digital and data roadmap, 21 still had no remediation funding attached. Data quality and data sharing barriers were described as "persistent and long standing," which is committee language for "we've known about this for years and it's still broken."

That's the actual bottleneck. Public sector bodies in the UK spend an estimated £30 billion a year on data assets, with an estimated potential value to the economy somewhere between £15 billion and £200 billion. Most of that value is locked behind fragmented systems, inconsistent metadata, and departments that legally can't or operationally won't share data with each other. You can drop the most capable model in the world on top of that and it will still hallucinate confidently on garbage inputs, or worse, it'll be accurate on the data it can see and systematically blind to everything it can't.

What "data governance" actually means when you're the one building

"Data governance" gets used as a compliance word, something legal signs off on before a project starts. For developers actually shipping AI into public sector environments, it's closer to an architecture decision than a policy document. A few things I've learned matter more than they get credit for:

Provenance and lineage aren't optional extras. If a caseworker, a clinician, or a benefits officer is going to act on an AI system's output, someone downstream will eventually ask "where did this come from and can I trust it." If your pipeline can't answer that at the row level, you have a liability, not a feature.

Human in the loop needs to be a real checkpoint, not a rubber stamp. The UK's own AI Playbook and GenAI frameworks lean heavily on this, and for good reason. But a human in the loop step that's designed as a formality (a button that says "approve" with no real ability to catch an error) doesn't satisfy the intent of the requirement even if it satisfies the letter of it.

Metadata governance and stewardship roles need owners, not just documentation. The National Data Library's early guidance is explicit about this: quality standards, metadata governance, and clearly defined data stewardship roles are treated as foundational, not nice to have. If nobody in your project owns "who is accountable for this dataset's accuracy," that gap will surface in production, usually at the worst possible moment.

Sensitive data needs to stay inside a trusted boundary by design, not by policy. This is less about picking the right vendor and more about architecture: enterprise deployment patterns with logging, access controls, and governance built into the data layer itself, so sensitive information never has a path out of the trusted environment in the first place.

Here's roughly how I sketch this out with teams before writing a line of pipeline code. Think of it as a governance manifest that sits alongside your actual data schema:

dataset: citizen_case_records
classification: sensitive_personal
lineage:
  source_system: legacy_case_management_db
  transformation_owner: data_stewardship_team
  last_quality_check: 2026-07-14
access:
  boundary: trusted_environment_only
  logging: full_audit_trail
  cross_department_sharing: not_permitted
ai_pipeline:
  human_in_loop: required_before_action
  confidence_threshold: 0.85
  fallback_on_low_confidence: route_to_caseworker
retention:
  policy: statutory_retention_schedule
  review_date: 2027-01-01

That's a simplified example, but the structure matters more than the syntax. Every field on that manifest maps to a question an auditor, a citizen, or a parliamentary committee could reasonably ask later. If your team can't fill it in before deployment, that's the actual signal that the project isn't ready, regardless of how good your model evaluation numbers look.

Why this matters even if you're not building for government directly

If you're a developer who's never touched a government contract, this might feel like someone else's problem. It isn't, for two reasons.

First, the standards being set here don't stay contained. The National Data Library's "AI ready data" guidelines are the first structural attempt by a UK government department to define what machine ready public data actually looks like. Frameworks like this tend to leak into procurement requirements, then into the vendor ecosystem, then into what "good practice" means more broadly. If you're building AI products that might ever sell into public sector or regulated industries, this is the direction the bar is moving.

Second, the underlying lesson applies well beyond government. Any AI system operating on data with real consequences, healthcare records, financial history, employment decisions, hits the same wall eventually. Data governance isn't a public sector quirk. Government is just where the stakes and the scrutiny are high enough that the gap between "the model works in the demo" and "the system is trustworthy in production" becomes impossible to paper over.

What I'd tell a team starting a public sector AI project today

A short, practical list, roughly in the order I'd actually raise these:

1. Map data lineage before you scope the model. You cannot govern what you haven't traced. Do this first, even though it's the least exciting part of the project.
2. Assign a real owner for data quality and stewardship, someone whose job it is to be accountable, not a shared responsibility that quietly belongs to no one.
3. Design the human in the loop step to genuinely catch errors, with enough context and time for a real decision, not a single click approval.
4. Build audit logging into the architecture from day one. Retrofitting it after a procurement review flags it is far more expensive, and it usually means the first six months of deployment have no defensible trail.
5. Assume the data is messier than the demo dataset suggests. Legacy systems and inconsistent metadata are the norm across the public sector, not the exception, and your pipeline needs to fail safely, not silently, when it hits that mess.

None of this is glamorous work. It's also the actual work. The UK's public sector AI strategy is ambitious and, on the evidence so far, genuinely well intentioned. Whether it closes the gap between a 47 out of 100 adoption score and its own stated ambitions will come down to exactly this kind of unglamorous plumbing: data lineage, stewardship, and governance built in from the start rather than bolted on at the end.

If you're working on AI in a regulated or public sector context, I'd love to hear what governance patterns are actually holding up in your projects versus what's just surviving audits. Drop a comment, I read every one.

---

I am the founder of AI44, a London based AI training and delivery firm, and I hold a UK Global Talent visa endorsement in digital technology. I write about AI adoption, governance, and what it actually takes to ship these systems responsibly. Unstoppable.