Put data behind every decision

Government AI systems are only as reliable as the data behind them. Before departments can deploy AI safely and effectively, they need accurate, complete, and well-governed data — because poor data quality produces unreliable AI outputs regardless of model sophistication. The Artificial Intelligence Playbook for the UK Government identifies data quality as a foundational requirement, yet many departments prioritise AI investment ahead of the data work that makes it trustworthy.

At a glance

The UK Government is racing to adopt artificial intelligence (AI) across public services. But there is a problem that no amount of investment in algorithms can fix: some of the underlying data is not good enough to support it.

— Sara Boltman, Founder & CEO, Butterfly Data

What is data quality in the context of government AI?

Data quality refers to the accuracy, completeness, consistency, timeliness, and provenance of the datasets that train or operate an AI system. In a government context, this typically means records that match across systems, fields that are populated rather than left blank or defaulted, formats that are standardised, and a clear, auditable trail of where each data point originated.

Why can't AI governance alone solve this?

AI governance frameworks address ethical and procedural risk — bias review, explainability requirements, and accountability structures. They don't fix the data itself. A well-governed AI system built on flawed data still produces flawed outputs. Governance and data quality are complementary, not substitutes: governance tells you who is responsible and how decisions get checked; data quality determines whether there's anything trustworthy to check in the first place.

What happens when government AI is built on poor-quality data?

●      Biased outcomes — models trained on unrepresentative or incomplete records replicate and amplify that gap

●      Inaccurate risk scoring — decisions in areas like fraud detection or eligibility assessment inherit the errors in the source records

●      Unreliable predictive models — forecasts degrade in proportion to the noise in the input data

●      Loss of traceability — with data provenance under increasing scrutiny, poor lineage makes it difficult to explain how a decision was reached, which is a growing legal and audit risk, not just a technical one

How should departments sequence this?

1. Data quality audit and remediation — establish the actual state of the data before building on top of it

2. Governance and stewardship structures (DAMA-aligned) — assign ownership and accountability

3. AI/analytics deployment on the now-trustworthy data foundation

4. Ongoing monitoring — data quality isn't a one-off cleansing exercise; it degrades again without continuous checks

FAQ

Does UK government policy require data quality checks before AI deployment?

The AI Playbook for the UK Government identifies data quality as foundational, though it isn't a hard procurement mandate in the way transparency-of-AI-use disclosure is under PPN02/24. It is best-practice guidance — strongly recommended rather than legally required.

What's the difference between data quality and data governance?

Data quality is about the state of the data itself — is it accurate, complete and consistent? Data governance is about the structures and accountability around it — who owns it, who's responsible for maintaining it, and how decisions about it are made. Quality work typically has to come first, or governance frameworks end up managing bad data.

Can AI itself be used to fix data quality problems?

Partially. AI-assisted anomaly detection and pattern analysis can accelerate quality checks, but it can't substitute for the foundational governance and cleansing work — especially where data provenance and lineage need to be established for audit or legal purposes.

‍

This resource builds on our CEO Sara Boltman's piece for UKAuthority, The Missing Prerequisite: Why Data Quality Must Come Before Government AI.

Government organisations are sitting on vast stores of internal knowledge — policy documents, operational guidance, and procedural notes. The challenge isn’t having the data. It’s being able to find and trust the right answer quickly. Retrieval Augmented Generation (RAG) is changing that.

The hidden knowledge problem in government

Think about how your team finds answers to policy questions. Someone searches a shared drive. Someone else emails the person who’s been in the role longest. Another person pulls up a PDF that might be the right version — or might be two updates out of date.

This is not a technology failure. It is an information architecture problem, and it affects almost every large public sector organisation we work with. The guidance exists. The knowledge is there. But it is scattered across repositories, intranets, legacy systems and the heads of experienced colleagues who have learned the hard way where things actually live.

When AI is introduced into that environment without proper grounding, the results are predictable: responses that sound plausible but cite the wrong version of a policy, or miss a more recent update entirely. The model is not lying, but it simply does not have access to the right information at the right time.

What is Retrieval Augmented Generation (RAG)?

Retrieval Augmented Generation — RAG, for short — is a technique that gives AI models access to your own internal documents when answering a question, rather than relying purely on what the model learnt during training.

Here is a simple way to think about it. Imagine an AI assistant that, before answering your question, first searches your organisation’s document library, finds the most relevant pages, reads them, and then gives you an answer — with a footnote pointing to exactly where that answer came from. That is broadly what RAG does.

For public sector teams, this matters enormously. It means:

●      Responses are grounded in your most current internal guidance, not general training data

●      Every answer can be traced back to a source document — which supports accountability and audit requirements

●      Knowledge that previously lived only in long documents or experienced colleagues becomes accessible to everyone

What we saw at SAS Innovate on Tour

As a SAS Gold Partner, our team attends SAS Innovate on Tour each year to stay close to what is coming next across the platform. Last month, at the conference, one announcement stood out for its relevance to the public sector knowledge access problem: SAS Retrieval Agent Manager (RAM), part of a wider set of agentic AI advances SAS unveiled for its Viya platform. 

SAS RAM is a no-code RAG platform. That means teams can build and manage AI workflows that pull from internal document repositories — without needing a data engineering team to set it up. It ingests unstructured documents like PDFs, policy notes, and operational guidance and enables AI agents or chatbots to return accurate, citation-backed answers from that content.

A few things make it particularly well suited to regulated environments like UK government:

●      On-premises or hybrid deployment — your documents do not have to leave your environment

●      Citation-backed responses — every answer links to the source material it used

●      Human-in-the-loop oversight — people stay in the decision chain

●      Built-in evaluation tooling — so you can monitor and improve response quality over time

●      No vendor lock-in — it works with multiple large language models and vector databases

Why governance-conscious organisations should pay attention

We often hear from public sector teams that AI governance concerns are slowing down adoption. That is understandable. The questions are real: Is this the right version of the guidance? Who approved it? Is it still a live policy?

But here is the thing: those questions are exactly what a well-designed RAG architecture is built to answer. Version-controlled document ingestion means the model works from current material. Citation-backed outputs mean decisions are traceable. Human oversight means a caseworker or policy analyst remains in the loop.

Good AI governance – as defined in the UK Government's AI Playbook – and good RAG implementation are pointing at the same requirements. You do not have to choose between them.

Departments with the most complex policy environments — where guidance updates frequently, where inconsistent answers carry real consequences, and where experienced staff carry knowledge that has never been formally documented — often have the most to gain from getting this right.

Beyond live queries: requirements gathering and standards alignment

It is not just live caseworker queries that benefit. The same retrieval and citation mechanics are just as useful earlier in the project lifecycle — during requirements gathering.

When teams are scoping a new system, drafting a business case or writing a set of non-functional requirements, they are often working from a patchwork of organisational standards – security policy, accessibility requirements, data retention rules, interoperability standards, and department-specific technical guidance – much of it scattered across the same repositories, causing the labyrinth problem in the first place.

A RAG-backed tool can pull the relevant policy and standards directly into that process, rather than leaving it to whoever happens to know where the latest version sits. In practice, that means:

●  Automatically retrieving current standards — pulling the organisational policy that applies to a given system or service, rather than relying on a project team’s memory of what was agreed last time

●  Populating generic NFR templates with department-specific detail — security classification, accessibility level, retention period — pulled straight from current policy and citation-backed, rather than copied from an older project

●  Keeping requirements aligned as policy changes — so documentation does not quietly drift out of step with the standards it is supposed to reflect

This matters for consistency as much as for speed. Where requirements are gathered project by project, with each team interpreting the same policies slightly differently, the result is exactly the kind of inconsistency that governance teams worry about. Grounding requirements gathering in the same retrieval layer used elsewhere in the organisation means every team is working from the same version of the same standards and can show where each requirement came from.

What good implementation looks like in practice

Getting RAG working well in a government context is not just a technology question. It also requires thinking carefully about which documents go into the system and how they are maintained, how retrieval quality is evaluated on an ongoing basis (not just at launch), what happens when the system returns a low-confidence answer, and how the AI layer fits into existing workflows rather than sitting alongside them.

No-code platforms like SAS RAM lower the technical barrier significantly. But the best outcomes come when data management, governance, and technology expertise work together from the start — which is exactly the kind of cross-functional approach Butterfly Data brings to these projects.

If you are working on AI adoption in a public sector setting and want to talk through how RAG could work in your environment, get in touch. We’d love to help you find the right path through the labyrinth.

___ 

Frequently asked questions

What is Retrieval Augmented Generation (RAG)?

Retrieval Augmented Generation (RAG) is a technique that improves AI accuracy by grounding model responses in retrieved documents from a specific knowledge base, rather than relying solely on training data. The model retrieves relevant source material at query time, uses it as context, and returns a response with citations traceable to that source material.

Why is RAG particularly suited to public sector AI deployments?

Public sector organisations hold large volumes of policy documentation, operational guidance, and procedural knowledge that changes frequently and must be applied consistently. RAG ensures AI responses are grounded in the most current internal documents, supports auditability through cited sources, and can be deployed on-premises to meet government data sovereignty requirements.

What is SAS Retrieval Agent Manager?

SAS Retrieval Agent Manager (RAM) is a no-code RAG platform built on the SAS Viya platform. It enables organisations to deploy AI that retrieves and responds from unstructured enterprise documents — policies, procedures and guidance notes — with citation-backed, auditable outputs. It supports on-premises or hybrid deployment and integrates with multiple large language models and vector databases without vendor lock-in.

What was showcased at SAS Innovate on Tour?

SAS Innovate on Tour showcased advances in SAS Viya’s agentic AI capabilities, including SAS Retrieval Agent Manager as a no-code tool for enterprise RAG deployment. The event highlighted use cases in regulated industries including public sector, where knowledge access and auditability are primary concerns.

How does RAG support AI governance requirements in government?

RAG supports government AI governance by grounding responses in specific, identifiable source documents (enabling auditability), supporting version-controlled document ingestion (ensuring currency of guidance), and enabling human-in-the-loop oversight of outputs. These characteristics align with the transparency and accountability principles in the UK government’s AI governance framework.

Can RAG be deployed without a large in-house AI team?

Yes. No-code RAG platforms like SAS Retrieval Agent Manager are specifically designed to allow non-technical users to build and manage retrieval workflows without deep AI engineering resources. Implementation typically still benefits from expertise in data management, governance design, and document curation to ensure retrieval quality is maintained over time.

When an organisation starts looking for data consultancy support, the procurement process tends to focus on the obvious things: technical capability, relevant experience, certifications and price. These matter. But they do not always surface the thing that makes the biggest practical difference to whether a project actually succeeds.

Choosing the right data consultancy partner is not the same as choosing a capable vendor. The distinction shows up in how work gets done: how a team responds when requirements change mid-delivery, whether they understand the governance pressures your organisation operates under and whether they are invested in the outcome or the invoicing cycle.

For organisations in the public sector and regulated environments — where data is sensitive, accountability is real and the margin for error is low — that distinction matters more than most procurement processes are designed to surface.

What is the difference between a data vendor and a data partner?

A data vendor delivers to a specification. That is not a criticism — it is simply how a transactional relationship works. You define the requirement, they fulfil it and then the contract closes.

A data consultancy partner does something different. They help you define the right specification in the first place. They ask the questions that reveal whether the brief you have written is actually the problem you need to solve. And when reality turns out to be more complicated than the initial scope anticipated — which it usually does — they adapt rather than raise a change request.

This distinction becomes especially visible in complex environments. In a central government department or a regulated organisation, a data project rarely sits in isolation. It touches existing systems, existing governance frameworks and existing political sensitivities. A team that treats the work as a defined technical task to be completed and handed back will often leave the organisation technically improved but practically no better off.

How do you choose the right data consultancy partner for a public sector or regulated organisation?

Procurement processes are good at filtering for capability. They are less good at filtering for fit. These are the questions that tend to surface the difference.

1. Does the consultancy understand your governance environment — not just your technical requirements?

There is a significant difference between a team that can build a data pipeline and a team that can build one inside a public sector environment, where every design decision needs audit trail, GDPR compliance is structural rather than a checkbox and decisions may need to be explained to a parliamentary committee in twelve months. Ask about the governance frameworks they have worked within specifically and probe whether they understand why those frameworks exist, not just how to document compliance with them.

One useful signal is whether they engage during the pre-market phase. Under the Procurement Act 2023, contracting authorities are actively encouraged to use early market engagement to inform requirements before an ITT is published — and the best data consultancies take that seriously. A partner who asks to be involved at the prior information notice stage or who proactively requests a pre-market conversation is demonstrating exactly the kind of governance awareness that matters in practice. One who only appears when the tender lands is, functionally, a vendor.

2. How does the consultancy handle changing requirements?

Scope change is not a failure of planning. In complex environments — where policy shifts, new data sources emerge mid-project or stakeholders evolve their understanding of what they actually need — it is inevitable. Ask for a concrete example of a project whose requirements changed during delivery. How did they respond? Did they adapt, or did they escalate through a formal change process that added months and cost? The answer tells you a great deal about how the relationship will function when things get difficult.

3. Is the consultancy genuinely technology-agnostic?

A consultancy with a commercial relationship with a specific vendor will, consciously or not, tend to recommend that technology — even where it is not the best fit. A genuinely technology-agnostic partner assesses your specific infrastructure, capability and long-term direction first, then recommends accordingly. A useful test: ask what technology they have recommended against and why. Procurement frameworks like those from the Government Commerical Agency, i.e. G-Cloud, are designed to give you choice; a good partner will help you use that choice, not narrow it.

4. Will the consultancy leave your team more capable, or more dependent?

Some consultancies are structurally incentivised to create dependency — the more your team cannot operate without them, the more readily contracts are renewed. A genuine data partner measures success differently. They want your people to understand what was built, be able to interrogate it and maintain and extend it without constant external support. Ask what knowledge transfer looks like in practice and ask for examples of clients who no longer needed them.

5. Do the consultancy's values align with yours?

In regulated environments, the data you are working with belongs ultimately to citizens. How a partner thinks about data ethics, responsible AI and privacy by design shapes every practical decision made during a project — often in ways that are invisible until something goes wrong. A partner who treats responsible data practice as an external constraint is a different proposition from one who treats it as a professional standard.

6. What does a good data consultancy partnership actually look like in practice?

Organisations that tend to get the most from data consultancy partnerships share a few characteristics. They bring their data partner in early — before requirements are finalised, not after the RFP has been issued. They are open about the constraints they are operating under, including the political and organisational ones that do not always make it into a brief. And they measure success by whether the organisation is in a meaningfully better position, not just by whether milestones were hit on schedule.

The best partnerships start with a shared understanding of the problem, not a shared understanding of the solution. The solution tends to be better for the time taken to get there.

7. Does the size of a data consultancy matter?

Large consultancies offer scale and brand reassurance, which for some organisations matters. What they can find harder to offer is consistent senior expertise across every stage of delivery or the genuine agility that comes from a smaller, more cohesive team where decisions do not require multiple layers of sign-off.

The question is not really about size. It is about whether the people who pitched the work are the people who will be doing it. Ask directly: Who will be working on this day-to-day? How readily and specifically that is answered tells you a great deal about what the working relationship will actually look like.

Butterfly Data is a data consultancy partner for public sector and regulated organisations — employee-owned, a certified B Corp and built around the principle that the right foundations make everything else possible. If you are thinking through what you actually need from a data partner, we would be glad to talk.