Webinar: Trustworthy AI in the Public Sector - Why Data Provenance Matters

Designed for public sector leaders, data professionals, and AI governance teams, this 20-minute talk by Butterfly Data's data scientist, Maja Strawinska, focuses on real-world implementation of data provenance to help you assess whether your data is truly fit for AI use.

What you will learn:

• Why data provenance is essential for trustworthy AI
• Common data risks in public sector AI projects
• How to evaluate data readiness for AI initiatives
• Practical steps to improve data governance and quality
• A “farm-to-table” framework for ethical AI data

Video transcript:

Introduction

Hello everyone, and thank you for choosing this session. I'm Maja Strawinska, a data scientist at Butterfly Data, and I'm going to guide you through trusted data for trusted AI, and how we get data provenance right in the public sector. I'll introduce these two topics, go through some core concepts, look at the challenges we currently face within the public sector, and finish with an actionable framework to help make sure we're getting things right.

A little bit about us: Butterfly Data is a UK-based, employee-owned B Corp, made up of data professionals who have worked across the board, from the Royal Navy and HMRC to the NHS. We help our clients navigate the full data lifecycle, making sure we're advising in the right way on all of these topics.

Why data matters for the public sector

If we think about AI within the public sector, it's not just about productivity. It becomes a tool for government. The Artificial Intelligence Playbook for the UK Government describes two key tasks that AI performs in this context.

First, machine learning can analyse very large datasets, identify trends and anomalies in complex historical data, and support the data-driven decision making we're all looking for. Think of models that work across huge census datasets and pull out the key findings.

On the flip side, AI can review and summarise huge amounts of information, and identify and correct errors in long algorithms. If you have a 60-page document for a service, for example, you can pull out the key information straight away and then dive into the parts that are most relevant to you.

Data provenance and trusted data

Let's separate the two terms. Data provenance is the origin: the original data entry point, or when the data was created. Trusted data covers accuracy, security, integrity and privacy. It's everything that makes our data trustworthy. Data provenance enables trusted data. It shifts data from an opaque, unknown state to a transparent, auditable asset that we can use in our day-to-day work.

The farm-to-table approach

To explain the core concepts of data provenance and data governance, I'm going to use a farm-to-table approach.

First, we have the source. This is where our data came from: the farm, the original point. We need to know this to understand whether we can use the data for what we're trying to achieve, and whether it's allowed within the frameworks we're working with.

Next, we have the handling. How was our data handled and transported? Have any changes happened along the pipeline that we need to be aware of, and that might affect our work?

Then we have lineage. That's every hand that has touched our food. We need to know those actions and those people, and we need to know we can trust the outcomes they produced.

Next is labelling. These are our nutrition facts. We need to know all the details about our food, and in this case that's the metadata.

Finally, we have the manufacturing date: how fresh our data actually is. If our data comes from a census in 2012, is it truly representative of the current state of the economy? We want to make sure it's accurate and up to date.

So trusted data is traceable, documented and fresh.

Data quality versus trusted data

Breaking those terms down further, data quality is our trusted ingredients. It's the technical foundation, making sure our produce meets the standards. Those standards are accuracy, completeness, timeliness, validity, consistency and uniqueness. Not every data point needs to meet every standard, but they need to be met wherever they apply. The question we ask ourselves is: is this individual data point correct?

Trusted data, on the other hand, is the data for the end user. That's the complete meal. In your case, think of it as the business outcome: the combined result of quality, governance and security. Here we ask ourselves: is the final dish safe to eat? Is it ethical? Is it fit for consumption, meaning is it fit for the purpose we want it to serve?

On the right-hand side of the screen you can see the data governance wheel from the DAMA DMBOK, which shows all the different areas that feed into data governance. Data quality is highlighted, alongside all the other activities we need to perform to get data governance right.

Ethical risks

Let's think about ethical risks.

Transparency, or the black box problem, is the idea that we need to understand what's happening behind closed doors to understand why decisions are being made. Is the kitchen door open? Can we pop in and have a look?

Algorithmic bias is like contaminated soil. Is there something at the origin, or in any of the models the data passes through, that could lead to biased outcomes?

Information integrity asks whether everything has been labelled correctly and standardised across the ecosystem. If it hasn't, we need to find a way to fix that.

Environmental impact is like a carbon meter in the kitchen. In our case, we want to make sure we're not creating a lot of technical debt, and that there isn't a lot of duplication in our processes or in the data itself.

Then there are accountability gaps. Who takes ownership of the final product, and who is responsible at each stage?

The AI Act is like a health inspection. Would you pass the inspector's checks? Would you meet all the requirements to be a good kitchen, or in this case, a good use of AI?

Finally, there's individual responsibility. Does the head chef take all the responsibility? Does the product owner need to be responsible for everything? Or how do we divide accountability so that everyone is accountable for their own part?

Public sector challenges

Now let's look at challenges more specific to the public sector. What are some of the common pitfalls?

In the world of AI, we have a common phrase: garbage in, garbage out. It highlights how important the quality and completeness of data are at the start. If the input isn't complete or isn't good, we won't get a good output. What comes out is only ever as good as what we put in.

An example of where this went wrong is the Dutch childcare benefits scandal of 2012. There were several issues. The input data was biased: it was weighted towards people on lower incomes, with more data on those individuals used in training. There was also significant algorithmic bias. People were automatically flagged as potentially fraudulent because they had dual nationality, came from a low-income family, or even because they had twins.

Unfortunately, the investigations that followed were quick, and families were forced to pay large sums of money back to the government, which pushed many of them into poverty. This went on for several years. Families didn't understand why they had been flagged, and didn't know how to challenge it, because the system was a black box. It highlights issues I'm sure many of you have seen internally too, and it shows why we need to get things right from the very start.

Governance and auditability

Data governance is our kitchen rules: our responsibilities, our roles and who does what. It's the exercise of authority, control and shared decision making over the management of data assets. It's about making sure that structure is in place.

Auditability is the health inspector's trail. It's the capacity to verify the accuracy, integrity and provenance of data through comprehensive, traceable and documented records. In practice, it means keeping records of what we do to the data, where it goes and anything that happens to it, so that we're covered.

On the side of the screen there's another visualisation from the DAMA DMBOK, which shows the foundational activities of data governance. Privacy, security and risk management sit at the bottom, and these are the most important to get right before building anything on top. Data science and data visualisation are great things to be doing and great assets to have, but we need to get the baseline right first.

Examples from our work

I promised some examples, so here are two.

One of our clients ingests multiple data sources from third parties. As you can imagine, these all arrive in different structures and formats, so we built a pipeline that standardises and assesses the data on ingestion. We check data quality as the data comes in, so we know what remediation is needed. We also enrich the data, by which I mean adding open-source data that bulks it up and supports more downstream analysis. One great business outcome is that downstream services now have easier access to clean data, and a streamlined way to get it in and start their analysis without having to clean and prepare it first.

I also promised an example of where we use AI. During a SAS hackathon, we wanted to tackle misinformation spreading online. We used natural language processing and SAS Viya to build a news plugin, because it's hard to verify manually what is true and what isn't. The system assigns trustworthiness scores to sources, and we used a large language model at the end to explain why each source was given its score. That removes the black box concern we often have with AI and the decisions made behind the scenes.

An actionable framework

Finally, I'm going to guide you through an actionable framework, with some examples of how you can reduce these risks.

At the very start, we have our rules. This is where we clearly set out what we're going to do: whether we're using this data, what we're using it for, and the schemas and standards we can build into our frameworks.

Next is the ingestion phase, where we focus on the supply chain. Here we want to detect changes in the data, so we need to build processes that flag those changes and standardise how they're managed.

Then we have validation. This is our quality control, where we assess data quality and make sure the data is what we expect it to be. It's also where we build the metadata in the background, so we're tracking all of this.

Finally, we have constant monitoring. This is your health inspector: auditing, and setting up alerts so that if an important job fails, you're notified and can tackle the problem as soon as possible, before it affects the business.

Roles and checkpoints

There are also some roles to consider.

The farm is the owner: the data owner. This is the person who holds responsibility for the data, and who you need to communicate with to use the data and make sure you're using it correctly.

The logistics and storage team are the data custodians: data engineers and anyone else who physically works with the data.

The executive chef is the chief data officer, the person responsible for overseeing all of this from a business perspective.

A level below, the sous chef is the data steward, who makes sure changes are correct against both data governance and quality standards and business standards.

The menu designer is the data architect, who makes sure everything works together, so your menu is built to last the full week and you don't run short of stock halfway through.

Alongside these roles, there are three checkpoints.

The supply chain checkpoint covers the whole lifecycle. We need processes in place to check that everything aligns with both business needs and data standards.

The kitchen checkpoint covers operational and quality checks. This could be your data quality checks, or a report you produce at the end of the week to confirm you're meeting the standards you expected.

Finally, the restaurant checkpoint covers structural and strategic checks. Is it actually giving you the output you expected? Can you actually use the data for what you intended, or isn't that possible?

Closing

I've referenced a few articles during this presentation, and they're all listed here. The links will be provided too, along with some extra reading and links to government websites for their specific frameworks.

That's everything from me. Thank you so much for choosing this session, and please feel free to reach out to me or anyone at Butterfly Data for more information. Thank you.