How should organisations govern AI systems that operate across identity, data, and runtime layers?

Governing AI Across Identity, Data, and Runtime

AI governance gets harder when identity controls, data access rules, and runtime enforcement are owned separately. The governance model needs to cover who the system can act as, what data it can reach, and what it can do at execution time. That is where cross-layer policy becomes the practical control boundary, not a single product setting.

When AI systems sit across platforms, the main problem is not that any one layer is weak, it is that the combined path is harder to see. A model can inherit access through one control plane, move through another, and still produce an outcome that no single team expected or approved.

For that reason, the governance object should be the end-to-end AI system, not the individual tool, model, or platform. The policy model should define authority, data scope, logging, and runtime limits together so approvals, monitoring, and exception handling apply to the same operating path.

Where Cross-Layer Governance Fails

Fragmented governance usually fails in predictable ways. Identity teams may approve access based on account type, data teams may classify the information, and platform teams may enforce runtime guardrails, but none of them can explain the full decision path. The result is policy drift, with each layer technically compliant but collectively unsafe.

That drift becomes visible when a system can read more data than intended, call tools beyond its business purpose, or keep operating after the original approval context has changed. The issue is not just overprivilege. It is the mismatch between the identity that was authorised, the data that was exposed, and the runtime behaviour that was actually allowed.

Good governance therefore treats cross-layer dependencies as first-class. If the runtime can reach a data source only because identity scope was broad, the governance model should record that dependency explicitly and require review when either side changes. Identity Security Programme Guide is useful here because it frames the operating model as a coordinated programme rather than a set of disconnected controls.

For AI systems that rely on non-human or delegated access, lifecycle discipline matters as much as runtime logic. Provisioning, ownership, rotation, and retirement need to be governed with the same rigor as the permissions themselves, or access becomes durable long after the business need has changed. NHI Lifecycle Management Guide and Top 10 NHI Issues both reinforce why lifecycle and excessive privilege are governance problems, not just operational hygiene.

What a Unified Policy Model Should Control

A workable model links three decisions: identity scope, data access, and runtime enforcement. Identity scope answers what the AI is allowed to represent or inherit. Data access answers which systems and datasets it may touch. Runtime enforcement answers what actions, outputs, and tool calls remain permissible during execution.

This is strongest when the same policy language can express constraints across all three layers. If each team writes a different rule set, you get gaps in translation. A permission that looks safe in a directory, a data gateway, or an orchestration layer may become unsafe when combined with the other two.

In practice, that means governance should require shared ownership of policy intent, not just shared reporting. One team may operate the identity layer, another may steward data classification, and another may run the agent platform, but they all need to answer to a common approval standard. The most useful architecture is the one that makes the full chain auditable, reversible, and reviewable.

For AI platforms specifically, cross-check the runtime against the identity granted to the system and the data it is allowed to process. Agentic AI Compliance Guide is relevant because it ties agent controls to governance obligations and audit evidence, while AI Infrastructure Workload Identity Guide helps when the system spans pipelines, model services, and inference infrastructure.

Practitioner Guidance

What to prioritise: Start with a single inventory of AI systems that shows identity owner, data sources, approved actions, and runtime controls in one place. If you cannot trace all four for a system, governance is already incomplete.

What to verify: Confirm that any access approval can be revoked without waiting for a separate platform change, and that changes in data scope or runtime privilege trigger the same review path. This is the practical test for whether the policy model is truly unified.

Common mistake: Treating data governance, IAM, and platform enforcement as separate checkpoints creates false assurance. The system may pass each review independently while still failing as an integrated control path.

What good looks like: One policy decision should explain who the AI acts for, which data it can reach, which tools it can use, and what logs prove those decisions were enforced. If a reviewer needs three dashboards to reconstruct that story, the operating model is too fragmented.

Practitioner takeaway: Governance should follow the AI system’s actual control path, not the organisational chart. If identity, data, and runtime are not enforced as one policy surface, the fastest-moving layer will set the real risk boundary.

Related resources from NHI Mgmt Group

• How should transportation organisations govern AI data across cloud, SaaS, and legacy systems?
• What breaks when organisations do not apply least privilege across data systems, retrieval layers, and AI agents?
• How should organisations govern access to data used by AI systems?
• How should healthcare organisations govern AI when data comes from many systems?