A client asked a simple question. A marketing firm in Manchester had just started using an AI tool to segment its mailing lists and generate first-draft campaign copy. When one of their larger clients reviewed the new process, they asked: “Where does this system get its intelligence from, and has any of our data been used in its training?”
The firm’s founder had no ready answer, not out of recklessness but because the question had never come up before. It sat at the heart of something called data provenance, and in that moment it stopped being an academic term and became a live business problem.
What is data provenance in AI?
Data provenance is the documented record of where data came from, who handled it, how it was changed, and under what terms it was used before training an AI system. It covers the original source, the legal basis for using that data, any cleaning or labelling steps, and who did that work. The UK’s National Physical Laboratory describes it as making data “understandable, reproducible and discoverable” through documentation of origin, lifecycle, and meaning.
The term is often confused with “data lineage”, which mostly tracks where data flowed between systems. Provenance adds the context: what the data was used for, who authorised that use, and what happened to it along the way. For a training dataset, that might mean knowing whether a web scrape was authorised, which filters were applied in cleaning, and whether anyone with rights in the original material had consented to its use in a commercial AI system.
The simplest mental model for a business owner is keeping receipts. If neither you nor your vendor can produce those receipts, you cannot prove the AI is lawful, unbiased, or defensible when a client or regulator asks.
Why does it matter for your business?
Provenance matters for owner-managed businesses on three levels: legal accountability, regulatory expectation, and supply chain risk. The ICO classifies large-scale web scraping for AI training as “invisible processing” under UK GDPR, a high-risk activity because individuals do not know their data is being used. Businesses training a model on personal data must identify a lawful basis and be able to evidence it. Without provenance records, that evidence does not exist.
The ICO’s 2022 enforcement action against Clearview AI illustrated what happens when provenance is absent. Clearview scraped billions of images from social media without consent and could not demonstrate any transparent legal basis for using them in facial recognition training. The firm faced enforcement in the UK, the EU, and Australia. The underlying regulatory principle, that you must account for how personal data entered your training pipeline, applies equally to a 15-person services firm fine-tuning a model on client records.
The supply chain risk is different but equally real. Generative AI providers often will not fully disclose their training data, citing commercial confidentiality. A 2024 academic survey described data authenticity, consent, and provenance in current AI practice as “all broken”, with no standardised tools for documenting sources and licences across major datasets. The FCA’s 2023 discussion paper on AI made the same point: firms in regulated activities need to understand the data behind a model to manage bias, discrimination risk, and governance obligations.
Where will you actually meet it?
Provenance shows up in practical terms at three decision points for owner-managed businesses. The first is vendor selection. When you sign up to any AI tool that processes client or employee data, you are making an implicit provenance decision. The questions to ask are: how was the model trained, was any scraped data involved, and does the vendor use your data to improve its own models unless you opt out?
The ICO has confirmed that businesses remain responsible for how they share personal data with third-party AI tools and must have an appropriate legal basis for doing so. Vendor due diligence is therefore part of your GDPR obligations, alongside the commercial reasons for asking.
The second decision point is client transparency. If you use AI in work you deliver to clients, some will ask how it works. The clients most likely to ask are in regulated sectors, but the expectation is spreading. Having a clear and honest answer, backed by vendor documentation and your own records, is a commercial advantage as well as a compliance matter.
The third point is your own training or fine-tuning. If you have customised an AI model on your own business data, or plan to, provenance tracking starts in your own systems. You should record the source system, the data categories involved, the legal basis, and any cleaning steps applied. That aligns with ICO expectations on records of processing and costs very little to build as a standard practice from the outset.
When does it really matter, and when can you step back?
The level of rigour depends on three factors: the sensitivity of the data, whether the AI makes decisions affecting people’s rights, and your sector. In financial services, healthcare, employment, or education, the expectations are high and enforceable. The Equality and Human Rights Commission has stressed that AI-driven decisions must not discriminate, and firms need evidence about data and models to demonstrate that.
For lower-stakes uses, proportionality is the guide. If you are using a general AI assistant to summarise internal policies and no personal data is involved, strict provenance logging may be more effort than the risk warrants. The practical test: if a regulator, client, or insurer asked you to explain this AI use, could you give a coherent, honest account of what data went in and under what terms? If yes, you are in reasonable shape. If the question produces a blank, that is the gap worth closing.
The counterpoint is worth acknowledging. Many widely-used foundation models were built without public, auditable provenance, and have become standard tools across sectors. UK enforcement on this specific issue remains relatively light. Provenance standards are catching up with practice. That trajectory matters more for planning the next two years than for what you do tomorrow.
What related concepts should you know?
Data provenance sits alongside a cluster of terms that appear in AI documentation, vendor contracts, and regulatory guidance. Data lineage is the narrower version: it tracks where data flows between systems but leaves out the legal context and processing history. Model cards are vendor-published documents covering a model’s intended use, training data, and known limitations. They are the closest thing the AI industry currently has to a standardised provenance reference.
The Data & Trust Alliance, a consortium of 19 large companies including Mastercard, has published cross-industry standards for what model documentation should include: sources, legal rights, privacy protections, timestamps, and intended uses. The Data Provenance Initiative, a research collaboration, has catalogued the training data origins and licences for over 2,000 datasets used to build large language models, and its explorer tool is publicly available for anyone evaluating a vendor’s claims about their training data.
The EU AI Act adds a further layer for businesses with EU clients. High-risk and general-purpose AI systems require technical documentation of training data sources and governance processes. UK businesses selling into the EU will find themselves in scope for those requirements regardless of where they are based. The practical entry point for any owner-managed business is simply to ask for a model card before committing to a vendor, and to keep a lightweight data register for any training you run yourself.
