Data trust is now the control plane for enterprise AI governance

At a glance

What this is: BARC’s 2026 scorecard and Collibra’s commentary argue that trustworthy, governed data has become the baseline requirement for enterprise AI and data intelligence programmes.

Why it matters: IAM, NHI, and AI governance teams should read this as a reminder that identity controls, access enforcement, and data governance now intersect at the point where AI systems consume enterprise data.

By the numbers:

• 44% of organisations now cite data quality as their biggest barrier to successful AI projects.

👉 Read Collibra's analysis of the 2026 BARC data intelligence score

Context

Enterprise AI programmes fail fast when the data layer is untrusted. That is especially true when models, GenAI features, and agentic workflows depend on governed context at inference time, because access, lineage, classification, and policy enforcement have to work together before the AI output can be trusted.

In identity programmes, this shifts the conversation from cataloging data to controlling who and what can use it. For NHI, autonomous systems, and human operators alike, the practical question is no longer whether data exists, but whether it is governed well enough to support decisions, automation, and accountability.

Key questions

Q: How should teams govern AI systems that rely on enterprise data for decisions?

A: Treat the data layer as part of the control plane. Governance should combine classification, access enforcement, lineage, and lifecycle review so AI systems only consume authorised, current, and explainable context. If those controls sit in separate silos, the model may still produce outputs, but the organisation cannot reliably trust or audit them.

Q: Why do data governance gaps become identity risk for AI programmes?

A: Because AI systems inherit trust from the identities that access and route data into them. If human users, service accounts, or agents can reach data without clear lifecycle controls, the AI layer inherits that exposure. The result is not just poor data hygiene, but a governance failure that affects decision quality and accountability.

Q: What breaks when governance only documents policy instead of enforcing it?

A: The programme loses the ability to prevent misuse at the point of access. Documentation can show who should have access, but it cannot stop an over-privileged identity from reading or moving data in production. In AI environments, that gap matters because systems often act immediately on whatever data they can reach.

Q: Who should be accountable for governance when models and agents use enterprise data?

A: Accountability should sit with the teams that own both the AI use case and the underlying data controls. That usually means identity, data governance, and platform teams sharing responsibility for provisioning, review, and enforcement. If ownership is unclear, AI risk becomes everybody’s problem and nobody’s control.

Technical breakdown

Data trust as an AI control plane

AI systems do not create trustworthy outputs on their own. They inherit the quality of the data, metadata, and access controls that feed them. In practice, the control plane includes classification, policy enforcement, lineage, and access decisions that are applied consistently where the data lives and where it is consumed. If those controls are only descriptive, AI can still act on stale, incomplete, or overexposed context. That turns governance into documentation rather than enforcement.

Practical implication: treat data trust as an operational control layer, not a reporting function.

Governed context for model and agent decisions

Modern AI programmes increasingly treat models, agents, and training datasets as enterprise assets. That means governance has to extend beyond storage into the moment of use, where inference, retrieval, and decision-making happen. The technical challenge is not simply finding data, but ensuring the right context is available, authorised, and current when a model or agent acts. Without that, the system may be well documented yet still make unsafe decisions.

Practical implication: connect data governance to runtime access decisions for models and agents.

Policy enforcement where the data resides

A key architectural distinction is between platforms that define policy and platforms that actually enforce it in the underlying data systems. Enforcement in warehouses and analytics platforms reduces the gap between governance intent and operational behaviour. When violations are detected automatically, remediation can be triggered without waiting for manual review. That matters because AI workflows move at machine speed, while governance processes often still assume human-paced correction cycles.

Practical implication: verify that policy is enforced in the source systems, not only recorded in a governance catalogue.

NHI Mgmt Group analysis

Trustworthy data is becoming an identity governance problem, not just a data management problem. Once AI systems consume governed data directly, access, classification, and accountability all become part of the same control surface. That means the quality of identity decisions now affects the quality of AI decisions, especially where machine identities and human approvals both touch the same data estate. Practitioners should treat data trust as part of identity architecture, not a separate analytics concern.

Governance that stops at documentation cannot keep pace with AI execution. A catalogue can describe ownership and sensitivity, but it cannot by itself prevent overexposure or misuse at runtime. The market signal here is that operational enforcement is becoming the differentiator, because AI workloads need controls that act where the data is accessed, not where it is described. Practitioners should separate visibility from enforceability in every governance review.

Models and agents are now enterprise objects, which changes how lifecycle thinking applies. When models and agents are treated like managed assets, they need provisioning, access review, and offboarding discipline comparable to other privileged identities. That widens the scope of governance from static data stewardship to ongoing control of who can influence, retrain, query, or route data into AI systems. Practitioners should map AI assets into their existing identity lifecycle models rather than inventing a parallel process.

Data intelligence is increasingly acting as context infrastructure for autonomous systems. That makes governance quality a prerequisite for reliable machine action, not an afterthought once the model is live. The more an organisation delegates decisions to AI, the more the underlying data layer has to absorb the burden of trust, lineage, and enforcement. Practitioners should assume that weak data governance will surface as weak AI governance, not as a separate failure mode.

Ephemeral credential trust debt: the moment an AI or data workflow depends on live access to governed data, any gap between entitlement and enforcement becomes operational debt. This is not solved by visibility alone, because the problem is not knowing that trust is missing but proving it is enforced consistently across storage and execution layers. Practitioners should re-evaluate whether their governance programme can actually constrain AI consumption at runtime.

From our research:

• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• For broader NHI governance context, see Ultimate Guide to NHIs , Key Research and Survey Results for the enterprise survey data that frames lifecycle and control maturity.

What this signals

Data trust is becoming the practical test of AI governance maturity. If a programme cannot enforce access, lineage, and classification where data is consumed, it is relying on documentation to do the work of control. That is why the governance conversation is shifting from policy intent to runtime enforcement, especially as AI systems become part of production decision paths.

Policy-only governance creates a false sense of readiness. The gap between describing controls and enforcing them will widen as more AI workloads consume unstructured and governed data at scale. Organisations should expect that weak enforcement will show up first as inconsistent AI output quality, then as audit friction, and finally as accountability gaps in the identity stack.

Fragmentation is the signal to watch. When teams maintain multiple secrets management paths and separate governance workflows, they usually also lose confidence in whether controls are applied consistently. That is a cue to align identity lifecycle, secrets governance, and data access controls before AI usage expands further. For a deeper lifecycle perspective, compare this with the Ultimate Guide to NHIs , Key Research and Survey Results.

For practitioners

• Map AI assets into identity governance workflows Classify models, agents, and training datasets alongside human and machine identities so provisioning, review, and offboarding are handled through one governance model.
• Verify policy enforcement at the data layer Confirm that access controls are enforced in Snowflake, Databricks, BigQuery, or equivalent platforms, not only documented in a catalogue or policy register.
• Separate visibility from enforceability Review whether the governance platform only reports policy drift or actually triggers remediation when access violations occur in live systems.
• Extend lifecycle controls to AI assets Define offboarding and review triggers for models, datasets, and agents that can influence decisions long after initial deployment.
• Reduce secrets fragmentation before scaling AI usage Inventory distinct secrets manager instances and remove duplicated paths that make enterprise control inconsistent across teams and workloads.

Key takeaways

• Trustworthy data has become a prerequisite for AI governance, not a downstream benefit of it.
• Governance that does not enforce controls at the data layer leaves AI systems acting on untrusted context.
• Identity, lifecycle, and data governance teams now need a shared model for models, agents, and the data they consume.

Key terms

• Data trust: Data trust is the degree to which data can be relied on for operational decisions, AI outputs, and auditability. It depends on classification, lineage, access control, and enforcement working together, not just on having a catalogue or policy document.
• Control plane: A control plane is the layer that defines and enforces how access, policy, and governance are applied across systems. In AI and identity programmes, it matters because the system must control real runtime behaviour, not only describe what should happen.
• Data intelligence platform: A data intelligence platform discovers, organises, and governs data so people and systems can find and use it safely. In mature programmes, it becomes part of the trust layer for AI because it carries metadata, policy, and context into operational use.
• Governed context: Governed context is approved, classified, and policy-bound information made available for decisions by humans or machines. It is more than metadata because it combines relevance with control, allowing systems to act on data that is both useful and authorised.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance maturity, it is worth exploring.

This post draws on content published by Collibra: Three years a Market Leader. In 2026, Collibra came out on top. Read the original.