Part 3 of "Trust the Machine" -> a series on building AI infrastructure that is secure, compliant, and governable by design.
The performance of an AI system draws most of the attention: the model, the architecture, the benchmark scores. The trustworthiness of that system, however, is determined largely by something less visible: the data behind it. A model is a compressed representation of its training and retrieval data. Whatever that data contains, lacks, or was not permitted to include propagates directly into the model's behavior and into the organization's risk.
This has become a practical constraint on adoption, not merely a theoretical concern. Industry reporting in 2026 has indicated that a substantial majority of enterprises (on the order of 81%) have delayed, scaled back, or abandoned AI initiatives because of data-permission and governance problems. Data is no longer the fuel that accelerates AI; for many organizations it has become the bottleneck that stalls it.
This post examines why data governance sits at the root of AI trust, and how lineage and provenance provide a single control that satisfies security, compliance, and governance requirements at once.
Data-related failures in AI systems fall into three categories, each with distinct consequences.
The organization trains on or retrieves from data it did not have the right to use: personal data without a lawful basis, licensed content beyond its terms, or information collected for an unrelated purpose. Once such data is absorbed into a model's weights, it cannot be surgically removed; remediation may require retraining. This is the failure mode behind much of the stalled-initiative statistic above.
Sensitive information present in training or retrieval data resurfaces in outputs. A model may reproduce personal data, credentials, or confidential material either through ordinary generation or in response to deliberate extraction attempts. The exposure is a direct function of what entered the system.
An adversary who can influence training or retrieval data can shape model behavior, introducing backdoors, biases, or targeted failures. Because the data pipeline is often less scrutinized than application code, it can be an attractive and under-defended target.
Each of these failures originates in the data layer, which is why controls applied only at inference are insufficient. Trust must be established upstream.
Two related concepts underpin data trust.
Provenance is the origin and history of a piece of data: where it came from, how it was collected, under what terms, and how it has been transformed. Provenance answers the question, "are we permitted to use this, and for what?"
Lineage is the end-to-end trace of data as it flows through a system: from source, through processing and transformation, into training sets or retrieval indices, and ultimately into a model or an output. Lineage answers the question, "if this source is compromised or must be removed, what is affected?"
Together, provenance and lineage make the data layer legible. Without them, an organization cannot demonstrate what its models learned from, cannot scope the impact of a compromised source, and cannot respond to a deletion or consent-withdrawal request. With them, each of these becomes a query rather than an investigation.
Provenance must be captured at the point of ingestion, when context is still available; reconstructing it later is unreliable and often impossible.
Minimizing sensitive data in the pipeline reduces both leakage risk and compliance burden.
The data pipeline warrants the same security rigor as production code.
The practices above may appear to serve compliance alone. In fact, a complete lineage and provenance capability functions simultaneously as a security, compliance, and governance control:
This is the series thesis applied to the data layer: a single capability, built once, satisfies three demands. An organization that can trace its data end to end has simultaneously strengthened its security posture, its compliance position, and its governance maturity.
Post 4: From Policy to Pipeline: Making Compliance an Engineering Property. The final post brings the series together, mapping the requirements of the EU AI Act, the NIST AI Risk Management Framework, and ISO/IEC 42001 onto the concrete controls established in Posts 1 through 3, and showing how compliance can become a property of the pipeline rather than a document maintained beside it.
Data is the true source of a model's trustworthiness, and lineage and provenance are the controls that make the data layer accountable. An organization that cannot describe what its models learned from cannot claim to secure, govern, or certify them.