AI Data Provenance: Why Knowing Where Your Training Data Came From Is Now a Board-Level Issue

What AI Data Provenance Actually Means

Data provenance is the documented history of data: where it originated, who created or collected it, under what authority or consent basis, how it was processed, and how it was transformed before reaching its current form. In the AI context, provenance operates across two distinct dimensions that require separate treatment.

The first is training data provenance: what data was the AI model trained on? This question applies most directly to organisations building or fine-tuning their own AI systems, but it also surfaces as a due diligence question for any organisation deploying a third-party model — because the legitimacy and legality of the model's outputs depends partly on the legitimacy and legality of what the model was trained on.

The second is inference data provenance: what data is being provided to the AI as input during deployment? This dimension is fully within the control of the deploying organisation — and is the most immediately actionable provenance question for most Singapore businesses.

ISO 42001 Annex A.7.5 specifically mandates data provenance documentation for both dimensions as part of a conformant AI management system. This is not a general best-practice recommendation — it is a documented control requirement.

It is important to distinguish provenance from data lineage, a related but different concept. Data lineage traces how data moves through a system after collection: transformation steps, pipeline dependencies, database writes and reads. Lineage answers the traceability question within your systems. Provenance answers the prior question: where did this data actually come from, and does the organisation have the legal and ethical basis to use it? Lineage is largely a technical discipline; provenance is where legal and reputational risk lives. Boards are generally comfortable treating data lineage as an IT matter. Provenance — because it determines the fundamental legitimacy of an AI system's data inputs — belongs at the governance level.

Foundation Models and the Provenance Problem

The majority of Singapore businesses using AI today are deploying foundation models — large language models and multimodal systems from major providers, accessed via API or embedded in third-party software. These organisations did not train the models they are using. They are deploying systems built by others, on data assembled by others, through processes they had no part in.

This creates a provenance gap that cannot be fully closed from the deployer's side. Foundation model training data documentation varies widely across providers, from relatively detailed model cards that describe data sources and filtering methodology, to minimal public disclosure that offers little beyond broad categorical statements. An organisation deploying a foundation model via API cannot audit the model's training data in any granular sense.

What Singapore businesses can and should document is their due diligence at the point of deployment: the model name, version, and provider; the provider's published statements on training data scope, linked and dated; the vendor contract terms governing data handling, input data usage, and whether customer interactions are used for model retraining; the context in which the model is being deployed and the categories of data being provided as input.

The IMDA AI Governance Framework, published in May 2024, identifies data management and transparency as two of its nine governance dimensions. Both dimensions directly implicate provenance — data management because provenance is foundational to responsible data use; transparency because being able to explain your AI systems' data basis is a transparency obligation. Organisations that maintain documented records of their foundation model choices and the basis for those choices are significantly better positioned for regulatory scrutiny than those whose AI deployments are undocumented. The documentation does not have to be perfect; it has to be credible, current, and honest about what is known and what is not.

The Copyright and Consent Dimension

The provenance question is not purely a governance abstraction. It has concrete legal dimensions that are playing out in courts across multiple jurisdictions and that will, eventually, affect how AI is used commercially in Singapore and the markets where Singapore companies operate.

Foundation models trained on internet-scraped data face active litigation in the United States and Europe over the use of copyrighted material in training data without licence or compensation. These cases have not yet been fully resolved in any jurisdiction, and the relevant legal frameworks vary significantly across markets. Singapore law does not yet have established precedent on AI training data and copyright. But Singapore businesses that operate internationally — exporting services, using AI-generated outputs in markets with established copyright frameworks — may face exposure that Singapore domestic law has not yet addressed.

The consent dimension is more immediately concrete for Singapore businesses. Singapore's Personal Data Protection Act governs the collection, use, and disclosure of personal data. Two specific risks arise at the intersection of PDPA and AI provenance. First, if a foundation model was trained on personal data without appropriate consent — including data generated by users of platforms and services that later contributed to AI training sets — there are questions about whether using that model for processing Singapore personal data is consistent with PDPA obligations. Second, if an AI tool's vendor contract includes terms permitting the use of customer input data for model improvement or retraining, Singapore personal data provided as AI input may enter future training sets without the data subjects' explicit awareness.

Inference Data Provenance — The Dimension You Can Fully Control

Even where training data provenance is constrained by what a foundation model provider discloses, inference data provenance is entirely within the deploying organisation's control. Inference data provenance asks: what data is being provided to this AI system as input, where did that data come from, and does the organisation have the legal and ethical basis to use it in this way?

ISO 42001 Annex A.7.5 applies to inference data as much as to training data. For a sustainability reporting AI that extracts emissions figures from utility bills — such as VerityOS's data extraction layer — the provenance of each input document is fully documentable: the invoice identifier, billing period, upload timestamp, file hash, and the user who submitted it. That documentation creates a clear evidence chain from raw document to verified emissions data entry.

The same logic applies across AI use cases. For a customer service AI, inference data provenance asks whether the customer interaction data being fed to the model was collected with appropriate consent and is within PDPA retention limits. For a document analysis AI, it asks about the source, date, and classification of the documents being processed. For a contract review AI, it asks whether the contracts being submitted contain third-party confidential information and whether the AI vendor's data handling terms permit that submission.

Inference data provenance is the most actionable provenance dimension for most Singapore organisations — the documentation can begin today, without requiring any change to AI vendor behaviour, and it directly addresses the PDPA compliance question of whether personal data fed to an AI system is being processed on a lawful basis. Organisations that have never considered provenance can make substantial progress simply by asking, for each AI system they operate: what data goes in, where does that data come from, and have we documented our legal basis for providing it?

How to Document AI Data Provenance Practically

Practical documentation requirements vary by the type of AI system an organisation is operating. Two tiers cover the range most Singapore businesses face.

For foundation model deployments — which describes the majority of Singapore SME and enterprise AI usage — the minimum documentation programme covers five elements. First, record the model name, version, and provider for every AI system in use. Second, link to and archive the provider's published documentation on training data scope — their model card, data statement, or equivalent — dated at the time of review. Third, document your prompt and input data sources: what categories of data do users or automated systems provide as AI input, and what is the consent or legal basis for that use? Fourth, record output handling: are AI outputs logged, retained, used for internal training, or fed back to the provider? Fifth, maintain your vendor contract review records, specifically noting provisions on data usage rights, retraining, and IP.

For proprietary or fine-tuned AI systems — where an organisation has built or customised a model on their own or client data — full training data documentation is required. ISO 42001 Annex A.7.5 expects this to cover data sources and collection dates, the consent basis for each data source, any data exclusions or filtering steps applied, preprocessing steps and their rationale, and data quality metrics. This documentation is maintained as part of the AI system's evidence record and reviewed when the system is updated.

For most Singapore SMEs, the practical minimum is an AI system registry: a structured table of every AI system in use, recording provider, model version, primary input data categories, data handling contract terms, and last review date. This registry, reviewed at least annually, is the foundation of a defensible provenance programme. It is also the most common gap finding in ISO 42001 readiness assessments — not because organisations are using AI irresponsibly, but because AI adoption has outpaced documentation habits. A registry closes that gap with a single structured document.

The Board-Level Implication

AI data provenance is not a problem that can be delegated entirely to IT or legal and considered resolved. It has dimensions that belong at the board level, and increasingly the regulatory and governance frameworks that Singapore organisations operate within make this explicit.

It is a risk management question because copyright litigation exposure and PDPA breach risk are financial risks, not technical footnotes. Even where current Singapore law does not create immediate liability, the trajectory of international litigation and regulatory development is clearly toward greater accountability for AI data practices, and organisations that have invested in provenance documentation today will face lower remediation costs when standards tighten.

It is a governance question because ISO 42001 and the IMDA AI Governance Framework both require organisational accountability for AI risk at leadership level. SS ISO/IEC 42001:2024, Singapore's adopted standard with SAC certification available from February 2025, is explicit that an AI management system requires documented board-level commitment and designated accountability. The OECD AI Principles, updated in 2024, and UNESCO's 2021 Recommendation on the Ethics of AI — adopted by 193 member states — both identify data quality and provenance as foundational AI governance obligations that extend to deploying organisations, not only to developers.

It is potentially a financial reporting questionif AI-related legal liability materialises. An organisation with no documentation of its AI data practices is in a materially weaker position than one with a maintained registry, vendor review records, and an annual provenance review.

Boards of Singapore companies using AI commercially should, at minimum, receive an annual briefing on what AI systems the organisation operates and what data those systems use; have sight of a maintained AI system registry; and understand which vendor contracts address data rights, retraining terms, and IP indemnification. This does not require deep technical expertise from board members. It requires the same structured risk governance discipline that boards already apply to cybersecurity, financial controls, and environmental compliance. What has changed is that AI data provenance has joined that list — and the window for addressing it proactively, before a regulator or litigant asks, is still open.