Put data behind every decision

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

Access the webinar by completing the form

There is a question that doesn’t get asked often enough in AI projects: “Where did this data actually come from?”

Not “what does it contain” or “how clean is it” — those matter too — but the more fundamental question of origin, ownership and handling. Without a clear answer, you are not building on a foundation. You are building on assumptions.

Consider how the best restaurants approach their ingredients. The farm-to-table movement didn’t take off because people suddenly cared about carrots — it took off because provenance became a proxy for quality and trust. Diners started asking which farm, which season and which supplier. And chefs who could answer those questions with confidence built reputations that those who couldn’t simply couldn’t match.

The same principle applies to AI. Data provenance — the ability to trace the origin, ownership and handling of every dataset used in a model — is the farm-to-table standard for responsible AI. And just like in food, the organisations that can’t account for where their ingredients came from are the ones most likely to end up with problems on their hands.

This idea was explored in more depth during a recent webinar based on Maja’s presentation for Digital Leaders AI Public Sector Week, where the discussion highlighted how provenance is rapidly becoming a core requirement for trustworthy AI — not just a “nice to have” for governance teams.

The farm-to-table standard for data

In food, farm-to-table means complete transparency: you know which farm your tomatoes came from, when they were picked and how they were transported. In data terms, this is provenance — and data lineage takes it further still, tracing every transformation the data has undergone on its journey into your model.

In practice, this means being able to answer questions like the following: Who collected this data? Under what conditions? Has it changed hands? Has it been filtered, merged or modified? Is the consent still valid for the way we’re now using it?

These aren’t bureaucratic questions. They are the difference between data you can rely on and data that quietly undermines everything built on top of it.

When provenance is unclear, data stops being an asset and becomes a potential liability. Organisations working in regulated environments — government, healthcare, defence, finance — know this all too well. “Dark data” (unlabelled, unused, untracked, unverified or poorly governed) is the equivalent of ingredients with no label and no known supplier. A chef who used them would lose their kitchen. An organisation that builds AI on them risks much the same.

Clean data is not the same as trusted data

This is a distinction worth making clearly, because the two are often confused.

Clean data has been processed by data quality rules: duplicates removed, formats were standardised and outliers were handled. That is genuinely important work. A dataset where “Male”, “M” and “1” all coexist in the same column is going to cause problems downstream. Consistency matters — it is the data equivalent of mise en place, making sure everything is prepared and in order before you start cooking.

But a vegetable can be perfectly scrubbed, peeled and sliced, and still be dangerous if it was grown in contaminated soil. That is the limit of cleaning. It removes surface-level problems, but it can’t fix what’s built in from the start.

Trusted data goes further: it’s verifiable, sourced through transparent channels, with a clear audit trail and an ethical basis for the way it is being used. You can have perfectly formatted data that was collected without proper consent or that was originally gathered for a completely different purpose. Cleaned up, it still looks fine. But it carries risks that no amount of standardisation can remove.

The question isn’t just “is this usable?” It is “is this appropriate for what we’re building?”

The data bias problem starts earlier than you think

A lot of the conversation around AI bias focuses on the model itself — on fine-tuning, on output testing and on fairness metrics. And those things matter. But bias is often introduced much earlier, at the data collection stage, and it is harder to fix after the fact.

If your training data over-represents certain demographics, geographies or time periods, your model will reflect that. If it was collected during an unusual period – such as a global pandemic or a period of economic disruption – it may not generalise well to normal conditions. Think of it like a restaurant that only sources ingredients from one small region: the menu might be excellent, but it won’t represent the full range of what’s out there and it will be brittle when that one supplier has a bad season.

This is why provenance and representativeness need to be considered together. Understanding where data came from helps you understand what it might be missing — and whether those gaps matter for the task at hand.

Asking the right questions before you build

Good data governance means asking harder questions at the start of a project, not after something goes wrong. Before feeding a dataset into a model, it is worth working through a few fundamentals:

•        Is the origin verified? Was this data acquired through transparent, documented channels?

•        Is it fit for this specific purpose? Data collected for one use case doesn’t automatically transfer to another. Consent and intended use both matter.

•        Is it still current? Data has a shelf life, just like produce. A model trained on population data from five years ago may produce conclusions that no longer hold — and stale data, like stale ingredients, can quietly ruin the final dish.

•        Could the people behind the data see this outcome? It is a useful sanity check. If the answer gives you pause, that’s worth paying attention to.

Why data provenance matters more as AI scales up

There is a compounding effect here. The larger the model, the more data it needs and the harder it becomes to maintain a clear audit trail across all of it. That is a problem that doesn’t get easier over time — it gets harder.

Organisations that invest in data provenance early are building something genuinely valuable: the ability to explain their models. Explainability is increasingly a regulatory expectation, particularly in public sector contexts and increasingly a commercial differentiator too. People and institutions want to work with AI systems they can trust and trust requires transparency about what went in.

The UK Government’s Data Quality Framework, GDPR and sector-specific governance standards all push in the same direction: know your data, document it, and be able to demonstrate that it was ethically sourced and appropriate for the purpose.

Final thoughts

Building AI on poorly understood data isn’t just a technical risk. It is a credibility risk. The farm-to-table movement taught the food industry that people care deeply about where things come from — not just how they are presented. The same shift is happening in AI. The organisations getting this right aren’t necessarily those with the biggest datasets — they are the ones who can clearly account for what they have, where it came from and why it’s appropriate for the job.

Great chefs don’t just cook well. They know their supply chain. That is what data provenance is really about.