AI governance is exposing the limits of legacy risk frameworks

At a glance

What this is: OneTrust says legacy risk frameworks are too static for AI, because AI behaves probabilistically, changes with data, and creates governance gaps around drift, leakage, provenance, and shared ownership.

Why it matters: This matters to IAM, NHI, and AI governance teams because AI controls now need continuous identity, lineage, and policy enforcement rather than periodic sign-off against assumptions that no longer hold.

Context

AI governance is the control problem that appears when systems no longer behave predictably enough for traditional review cycles to keep pace. In this article, OneTrust argues that AI changes the governance unit from a static asset or policy set to a continuously shifting risk surface shaped by data, prompts, and model behaviour.

For identity and access teams, the important crossover is that AI governance now depends on who or what can influence model inputs, outputs, and downstream workflows. That pulls lineage, accountability, and operating controls into the same conversation as data protection, security review, and engineering process.

The article treats this as a CDO-led governance shift rather than a narrow compliance exercise, which is typical of organisations trying to move from document-based assurance to operational control.

Key questions

Q: How should organisations govern AI systems that can change scope at runtime?

A: They should treat runtime behaviour as part of the compliance boundary. That means inventorying every model, tool, and integration, then checking whether the system still acts within its intended purpose after deployment. Static approval is not enough when an agent can expand scope through chained actions or delegated workflows.

Q: Why do legacy risk frameworks fail to capture AI risk properly?

A: They were built for systems that behave predictably enough to assess once and review later. AI can drift, produce different outputs from the same prompt, and change risk as data changes, so static controls miss the failure mode. The result is blind spots around leakage, bias, provenance, and unsafe outputs that only show up under continuous use.

Q: What do security teams get wrong about AI governance reviews?

A: They often treat every use case as if it needs the same level of scrutiny. That creates bottlenecks and does not reflect actual risk. Effective governance separates routine, low-risk activity from higher-risk systems and uses runtime controls for interactions that can be governed continuously instead of repeatedly reviewed.

Q: What is the difference between traditional DLP and AI-specific data governance?

A: Traditional DLP focuses on known transfer channels, while AI-specific governance has to cover prompts, agents, and integration layers that can move information indirectly. In practice, AI governance is broader because it must account for both the content being handled and the identities or secrets enabling the workflow.

Technical breakdown

Why deterministic risk models fail for AI systems

Traditional risk frameworks assume a system behaves consistently enough that a control can be tested, approved, and treated as stable until the next review. AI breaks that assumption because outputs vary, upstream data changes behaviour, and model drift can create new failure modes without a code change. That means the control object is not just the model itself, but the interaction between model, training data, prompts, and surrounding workflow. In practice, a one-time assessment is a weak signal for a system whose risk profile is continually redefined by context.

Practical implication: governance has to move from periodic approval to continuous observation of model behaviour and its inputs.

AI governance depends on data lineage, provenance, and ownership

AI risk is inseparable from data risk because the model inherits properties from the data it consumes and the systems that feed it. Lineage shows where data came from, provenance shows how it was transformed, and ownership determines who can explain or change the resulting behaviour. When those elements are unclear, the organisation loses the ability to trace bias, leakage, or unsafe outputs back to a controllable source. This is why AI governance cannot sit inside one function alone. It needs shared accountability across data, security, legal, compliance, and engineering.

Practical implication: treat lineage and provenance as governance controls, not just documentation.

Telemetry-driven governance replaces checklist-driven review

The article’s core governance shift is from static assessments to telemetry-driven monitoring. That means watching for drift, bias, leakage, and abnormal prompt patterns as live signals, then using automated scoring and workflow triggers to escalate risk. This is closer to operational security than to annual compliance review. It also aligns with how AI systems are actually deployed, because the risk emerges during use, not only during build or approval. For CDOs, the control question becomes whether the organisation can see meaningful risk signals early enough to intervene before they propagate downstream.

Practical implication: implement controls that surface AI risk in development and runtime, not after deployment.

NHI Mgmt Group analysis

AI governance debt is now a board-level operating risk: organisations are shipping AI faster than their governance structures can absorb, which means review-based models are accumulating risk debt. The issue is not only lack of policy, but mismatch between deterministic control design and probabilistic system behaviour. For identity, security, and data leaders, the practical conclusion is that AI governance must be designed as an operating model, not a document set.

Lineage is becoming a control surface, not an audit artefact: when model behaviour depends on upstream data and downstream reuse, provenance is what lets teams explain outcomes and contain failure. Without it, bias, leakage, and unsafe output cannot be traced to a governable point of intervention. That makes lineage central to trustworthy AI programmes and to any identity-aware governance model that touches data flows and delegated access.

Shared accountability is the only viable governance model for AI: the article is right to place the CDO at the centre, but the real lesson is that no single control owner can manage AI risk alone. Data, security, legal, compliance, and engineering each control part of the failure surface, and the weak point is often the handoff between them. Practitioners should treat governance orchestration as the control, because that is where fragmented ownership becomes unmanaged risk.

Telemetry-driven risk management defines the next governance baseline: continuous monitoring for drift, leakage, and abnormal prompt patterns is becoming the minimum viable control set for operational AI governance. Static sign-off does not match systems that change with every data update and interaction. The practitioner takeaway is to build governance that can measure, route, and respond to live signals at the speed of the model.

From our research library:

• 52% of respondents see AI security decision-making power shifting toward platform and infrastructure teams rather than the executive suite, according to the 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Maturity Model

What this signals

AI governance debt: organisations that keep AI controls inside annual review cycles will fall behind systems that change continuously through data, prompts, and upstream dependencies. The real governance gap is not visibility alone, but whether the programme can turn live signals into action before risky behaviour propagates.

The identity angle is now unavoidable in AI governance because access, delegation, and ownership decisions shape what data an AI system can see and how far its outputs can travel. That makes lineage, entitlement scope, and accountable handoffs part of the control surface, not adjacent documentation.

Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey. That gap shows how quickly policy intent can outrun operating discipline when governance is still organised around legacy review models.

For practitioners

• Define AI governance as a continuous control process Replace annual or project-based AI reviews with ongoing monitoring for drift, leakage, bias, and abnormal prompt behaviour across development and runtime.
• Make lineage and provenance mandatory control inputs Require traceable source, transformation, and ownership metadata for training and operational data so model outcomes can be explained and investigated.
• Assign joint accountability across data and security teams Create a shared governance workflow that makes data, security, legal, compliance, and engineering sign off on model changes and control exceptions together.
• Automate telemetry-based risk scoring Feed model and prompt telemetry into a risk engine that can flag behaviour changes quickly enough to trigger review, rollback, or containment actions.

Key takeaways

• AI governance is exposing a mismatch between probabilistic model behaviour and legacy risk frameworks built for deterministic systems.
• The article’s central control shift is toward continuous monitoring of drift, leakage, provenance, and abnormal prompt patterns.
• For practitioners, the key change is to treat lineage, telemetry, and shared accountability as governance controls rather than supporting paperwork.

Key terms

• AI Governance: AI governance is the set of controls used to discover, classify, approve, restrict, monitor, and revoke AI-enabled access. It connects identity, data, and policy so organisations can manage what AI can reach, what it can share, and when it should be stopped.
• Model Drift: Model drift is the gradual change in a model’s behaviour or performance after deployment. It happens when the operating environment, user patterns, or inputs no longer match the conditions used to validate the system. Drift matters because a model can appear functional while no longer meeting approved standards.
• Data Lineage: The record of how data moves across systems, applications, and workflows. In security operations, lineage shows where sensitive data propagates, which identities touch it, and how a compromise could spread across connected environments.
• Telemetry-driven governance: Telemetry-driven governance is a control approach that relies on runtime signals rather than periodic paperwork. For AI, that means watching drift, leakage, prompt anomalies, and other live indicators so governance decisions reflect current system behaviour instead of stale review findings.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity control to broader security and governance programmes.