Data Provenance Infrastructure for Traceable AI Systems

Your AI System Made a Decision. Can You Trace the Data Behind It?

Data provenance is the infrastructure that makes AI data questions answerable — not a dashboard or catalog entry, but a system that captures where training data originated, what transformations it underwent, which models consumed it, and whether that chain can be cryptographically verified (see our research on architecting verifiable AI for the post-trust enterprise).

A court just ordered OpenAI to produce 78 million ChatGPT output logs because plaintiffs needed to trace how copyrighted training data influenced model behavior. That is an extreme example. The everyday version is quieter but just as consequential:

• A regulator asking which data trained your lending model.
• A GDPR deletion request that reached your source tables but not the six downstream models that consumed the deleted records.
• A data poisoning incident where you cannot identify which training batches were compromised because nothing in your pipeline recorded the answer.

Our approach is to build this provenance layer across the pipeline tools enterprises already run: Spark, dbt, Airflow, Dagster, and custom ETL.

Why Catalog Lineage Is Not the Same as Training Data Provenance

Most enterprises already own a metadata catalog. Collibra, Alation, Atlan, or DataHub covers table-level lineage useful for schema-change impact analysis. It does not answer the questions regulators, auditors, and litigators ask about AI systems. The gap shows up in three places:

Our approach works with whatever catalog you already own. The provenance layer is designed to sit beneath it, instrumenting the actual pipeline execution to capture the record-level, transformation-level detail that catalogs were not designed to provide.

What We Instrument and How

The core challenge is capturing provenance at the granularity regulators require without killing pipeline throughput. Per-record SHA-256 hashing on a Spark job processing 500 million rows adds 15–40% overhead — rarely acceptable for production. Our approach calibrates provenance granularity to the actual risk profile.

Pipeline instrumentation with OpenLineage

Instrumentation uses OpenLineage as the emission standard where integrations exist (Spark, Airflow, dbt, and Dagster all have varying levels of support), with custom facets that capture ML-specific metadata: feature engineering parameters, data augmentation configurations, sampling strategies, and train/validation/test split criteria. Where OpenLineage integration is incomplete or drops events — the Spark listener is known to silently lose custom facets under high partition counts — the approach adds supplementary instrumentation designed to capture what the standard integration misses, detailed in our technical whitepaper on securing the ML supply chain across the lifecycle.

Provenance for unstructured data

For unstructured training data — documents, images, audio, and video used in fine-tuning or RAG pipelines — the approach applies content fingerprinting with perceptual hashing (pHash for images, chromaprint for audio) alongside cryptographic hashes, enabling provenance tracking even when content undergoes lossy transformation — see a working demo of audio provenance tracking.

The GDPR Erasure Problem Nobody Has Solved Cleanly

GDPR Article 17 grants the right to erasure. For traditional databases, delete and confirm. For AI systems, it is an unsolved problem dressed up as a compliance checkbox. Large language models do not store data as discrete records — they store statistical patterns derived from training data, distributed across billions of parameters. Deleting a person's data from the source table does not remove its influence from the model weights, and GDPR offers no framework for interpreting what "erasure" means once data has been absorbed into a model's decision-making architecture.

Machine unlearning research is advancing. In September 2025, UC Riverside researchers demonstrated "source-free unlearning," a certified method that works without the original training data, using surrogate datasets and Newton-update-based parameter adjustment. But no unlearning method is production-ready at enterprise scale. Current practical approaches combine three layers:

• Prevention — keeping PII out of training data through pre-processing gates.
• Fast remediation — deleting from retrieval indices, caches, and logs.
• Defensible documentation — provenance records proving what data entered which models, supporting retraining decisions when unlearning is insufficient.

The provenance infrastructure is designed to create the prerequisite for any erasure strategy: a queryable map from data subject identifier to every model, pipeline, and artifact that consumed their data. With it, you answer "which models need retraining?" within minutes of a deletion request, instead of discovering months later that a forgotten fine-tuning run used the affected data.

EU AI Act Article 10: From Policy Documents to Pipeline Evidence

Article 10 of the EU AI Act requires that training, validation, and testing data be subject to "data governance and management practices appropriate for the intended purpose." Enforcement begins August 2, 2026. The practical requirement is not a governance policy document. It is verifiable, timestamped evidence that governance was applied at the moment data entered the pipeline.

The gap is real: only 3% of financial institutions have effectively deployed AI into production (Ataccama 2025 Data Trust Report). Governance policies exist, but pipeline-level proof of adherence does not.

Our approach delivers Article 10 compliance as a pipeline capability. Each run is designed to produce a provenance record capturing: data sources with origin metadata, quality validation results, transformation parameters, sampling methodology, dataset statistical properties (representativeness, completeness, error rates), and active governance policies. This is the artifact an auditor examines — generated automatically, not assembled retroactively.

For organizations also subject to GDPR Article 30 (records of processing activities), the provenance system is designed to produce both compliance artifacts from a single instrumentation layer. The requirements overlap but are not identical: Article 30 focuses on processing purposes and legal bases, while Article 10 focuses on data quality and representativeness. A unified system avoids the duplication that plagues organizations running separate compliance tracks.

Training Data Attribution and Poisoning Detection

Regulators are beginning to ask which training examples influenced a specific prediction. Influence functions, the mathematical framework for this, have historically been too expensive for production. Recent advances — LoGra gradient projection and the ASTRA algorithm — bring influence computation to practical scale. Our approach implements attribution as a forensic capability: precomputed influence scores for critical model behaviors, cached for retrieval when an auditor or litigator needs the connection between a specific output and the data behind it.

Provenance also serves as the primary defense against training data poisoning (our research on safeguarding enterprise models against poisoning). Research confirmed in 2025 that poisoning requires only a constant number of samples regardless of model size, and even 0.001% adversarial data can degrade accuracy by 30%. When every data element has a verified chain of custody, anomalous provenance patterns become detectable:

• Data from unverified sources.
• Records with broken hash chains.
• Examples bypassing the standard ingestion pipeline.

On top of the provenance graph, the approach adds detection layers designed to flag these patterns before contaminated data reaches model training.

When This Is the Right Investment

You need provenance infrastructure when your AI systems consume data with legal, regulatory, or safety risk:

• Financial services firms facing EU AI Act Article 10.
• Healthcare under FDA 21 CFR Part 11.
• Enterprises with GDPR exposure training on user data.
• Organizations whose training data sourcing is under legal scrutiny.

You do not need this if your AI consumes only first-party, non-regulated data with a simple pipeline. If dbt's lineage graph plus a DataHub instance covers your needs, use those — we will tell you that in the first conversation.