Data Provenance Infrastructure for Traceable AI Systems

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

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, or a data poisoning incident where you cannot identify which training batches were compromised because nothing in your pipeline recorded the answer.

Data provenance is the infrastructure that makes these 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. We build this across the pipeline tools our clients use: 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. First, catalog lineage tracks datasets but not individual records. GDPR Article 17 deletion requires record-level provenance to identify every downstream artifact that incorporated a data subject's data, including model weights. Second, catalog lineage stops at the model boundary. MLflow or Weights and Biases knows which dataset version was used for a training run, but not which records, what preprocessing was applied, or how specific examples influenced model behavior. Third, catalog lineage is passive with no integrity guarantee. An engineer overwriting a staging table leaves no trace. Cryptographic provenance makes tampering detectable.

We work with whatever catalog you already own. The provenance layer we build sits 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.

We calibrate provenance granularity to the actual risk profile. For high-risk pipelines feeding regulated AI systems (credit scoring, clinical decision support, fraud detection), we implement per-batch Merkle trees: content-addressed hashing at the partition level with Merkle root verification across the full batch. This provides tamper-evidence with 2-5% throughput overhead instead of 15-40%. For lower-risk analytical pipelines, metadata-only provenance, recording source identifiers, transformation parameters, and software versions without per-record hashing, delivers regulatory documentation at near-zero overhead.

Pipeline instrumentation uses OpenLineage as the emission standard where integrations exist (Spark, Airflow, dbt, 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), we build supplementary instrumentation that captures what the standard integration misses.

For unstructured training data, documents, images, audio, and video used in fine-tuning or RAG pipelines, we implement content fingerprinting with perceptual hashing (pHash for images, chromaprint for audio) alongside cryptographic hashes, enabling provenance tracking even when content undergoes lossy transformation.

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. The GDPR offers no framework for interpreting what "erasure" means when 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 prevention (keeping PII out of training data through pre-processing gates), fast remediation (deleting from retrieval indices, caches, and logs), and defensible documentation (provenance records proving what data entered which models, supporting retraining decisions when unlearning is insufficient).

The provenance infrastructure we build creates 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.

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

We build Article 10 compliance as a pipeline capability. Each run produces 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 produces 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, the ASTRA algorithm) bring influence computation to practical scale. We implement 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. 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, or examples bypassing the standard ingestion pipeline. We build detection layers on top of the provenance graph that 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, and 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.

Teams without lineage spend 40% longer debugging data issues. EU AI Act penalties reach 15 million EUR or 3% of worldwide turnover. The 51+ copyright lawsuits against AI companies have made provenance a litigation prerequisite. We scope to actual risk: metadata-only for lower-risk pipelines, full cryptographic chains for regulated systems, and honest assessment of where existing tooling already covers the need.