The ai register is not enough for eu ai act readiness

At a glance

What this is: This is an analysis of why an AI register alone does not satisfy AI Act readiness when agents change risk as data, jurisdiction and runtime access conditions change.

Why it matters: IAM and GRC teams need controls that enforce policy at the moment of access, because static inventories cannot govern agent behaviour once it moves across datasets, systems and jurisdictions.

👉 Read Nexis's analysis of why the AI register is not enough for EU AI Act readiness

Context

AI register readiness is the practice of inventorying models, copilots and agents, assigning ownership and risk classes, and keeping the record current enough to support compliance. The gap in this article is that a register captures intent, not runtime behaviour, so it cannot enforce what an agent is allowed to do once data context changes.

For IAM and GRC teams, the operational problem is not whether the registry exists, but whether identity policy and data classification actually constrain access at the point of use. That distinction matters most where agents can reach regulated or jurisdiction-bound data without a human approval step.

The article treats EU AI Act readiness as a control problem shared by governance and identity teams. In that sense, the register is a starting point, but dynamic authorization is the control that decides whether the system remains aligned when tasks, data and hosting geography shift.

Key questions

Q: How should organisations govern AI agents when the register no longer matches runtime behaviour?

A: They should treat the register as evidence, not enforcement. The control that matters is a policy decision point that evaluates task, data class and jurisdiction at the moment of access, so an agent cannot drift into higher-risk behaviour between reviews.

Q: Why do AI registers fail to control regulated data access in practice?

A: Because a register records declared scope, while access risk changes when the agent touches different data. If the policy does not evaluate the request in real time, the documented classification can stay stale while the actual behaviour moves outside it.

Q: What breaks when AI governance and IAM use different policy definitions?

A: The organisation gets compliant records without enforceable controls. Governance can say an agent is approved, but identity enforcement may still allow requests that violate data class or jurisdiction rules, leaving a gap between intent and runtime control.

Q: Should organisations prioritise dynamic authorization over expanding the AI register?

A: Yes. Expanding the register helps with visibility, but dynamic authorization prevents the higher-risk event itself by denying disallowed access before data leaves the control boundary. Without that runtime gate, inventory growth only improves documentation.

Technical breakdown

Why a static AI register goes stale at runtime

A register is a snapshot of declared scope, ownership and risk class. That snapshot becomes unreliable when an agent’s task changes, because risk follows the data touched, not just the model named on the inventory line. In practice, the same copilot can move from low-risk summarisation to higher-risk processing the moment it reads regulated personal data. A register can support accountability, but it cannot observe or block that change in real time. The technical gap is temporal: documentation is updated after the fact, while access decisions happen in the moment.

Practical implication: treat the register as governance evidence, not as a runtime control.

How dynamic authorization enforces data and jurisdiction rules

Dynamic policy evaluates the actual request context each time an agent acts. That means the decision can combine identity, task, data classification and jurisdiction, then fail closed if the request violates policy. This is where role-based, attribute-based and rule-based control work together: roles define broad intent, attributes add data and location context, and rules enforce hard boundaries such as no access to regulated EU data from an unauthorised foreign-hosted model. The key difference from static registration is that enforcement happens before the access succeeds, not after the audit trail is written.

Practical implication: move sensitive-agent decisions into policy evaluation at request time.

Why IAM and GRC must share the same control model

The article’s central point is that AI Act obligations sit across two control domains. GRC defines what data is regulated, what risk class applies and what policy should exist. IAM defines which identity can request access and where enforcement occurs. If those two views diverge, the organisation ends up with documented intent on one side and unenforced permissions on the other. The stronger model is a shared control plane where the same classification terms drive both auditability and authorization, so traceability and access control are derived from one policy source instead of separate records.

Practical implication: align data classification, policy definitions and identity enforcement under one governance model.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Static AI registers are necessary but insufficient because they describe intent, not authority. The article correctly identifies a familiar governance failure: organisations stop at inventory and assume compliance is established. That works for documentation, but not for access control, because an agent can change scope after registration. The implication is that AI governance needs a runtime enforcement model, not just a record of approved use.

Risk in agent governance moves with data access, not with model registration. A copilot can be low risk in one workflow and materially higher risk in another if the data set changes. That is effectively permission creep for agents, and it means the classification on file can become stale the first time the task shifts. Practitioners should treat data context as the governing variable, not the model label.

AI Act readiness is an IAM and GRC convergence problem, not a documentation problem. The register lives on the governance side, but the access decision happens in the identity layer. If the same policy vocabulary does not drive both, the organisation will produce clean records and still leak control at runtime. The named concept here is runtime authorization drift: the point at which declared scope and enforced access stop matching.

Dynamic policy is the only control shape that scales with agent populations. Static, manually maintained records do not scale when agent counts grow quickly and when each agent can change behaviour by task or jurisdiction. The more relevant question is not how to register more agents, but how to make the policy engine evaluate the request every time. That is the control model that remains defensible as AI usage expands.

The hard boundary is not the model, it is regulated data leaving the control plane. The article’s jurisdiction example shows why policy must consider hosting location and data class together. Once sensitive information can be sent to an external service without approval or logging, the register becomes a passive artifact. Practitioners should build controls that stop that transfer before it occurs.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: NHI Lifecycle Management Guide

What this signals

Runtime authorization drift: governance programmes should expect the documented risk class on an agent to become stale as soon as its task or data scope changes. The practical response is to move control from registration to request-time policy, especially where regulated data or jurisdiction boundaries are involved.

The most important design question is whether the same classification vocabulary drives both GRC and IAM. If those teams describe risk differently, the organisation will keep producing inventories that satisfy audit questions while missing the access decision that matters operationally.

For practitioners

• Define runtime policy triggers for agent requests Tie authorization to task, data class and jurisdiction so policy evaluates every request instead of every registration entry.
• Separate registry evidence from enforcement Keep the AI register as governance inventory, but require a policy decision point before any agent can reach regulated data.
• Align GRC classifications with IAM attributes Use the same data-classification labels in governance records and in the identity policies that approve or deny access.
• Test cross-jurisdiction access blocks Simulate requests from foreign-hosted models to EU regulated data and confirm the policy denies them in the moment.

Key takeaways

• The article shows that an AI register is a governance artifact, not a runtime control, and that distinction is where many readiness programmes fail.
• The visibility problem is real: only 5.7% of organisations have full visibility into their service accounts, which is a useful proxy for the broader inventory gap.
• Practitioners need dynamic, data-aware authorization that evaluates task, data class and jurisdiction at access time, or the documented control model will not hold up in operation.

Key terms

• AI Register: A record of models, copilots and agents that shows what the organisation intends the system to do, who owns it, and how it is classified. On its own, it is governance evidence, not an enforcement mechanism, because it cannot stop an agent from changing behaviour at runtime.
• Dynamic Authorization: Dynamic authorization is an access model that makes the trust decision at request time using current identity and context. It replaces reusable stored credentials with short-lived, policy-scoped tokens issued only after the workload proves itself.
• Runtime Authorization Drift: A narrower form of authorization drift where policy intent and runtime behaviour diverge specifically at request time across multiple enforcement points. It becomes especially important when non-human identities and automated actors generate high volumes of decisions that small inconsistencies can magnify.
• Jurisdiction-Aware Policy: A control model that applies different verification or authorization rules depending on the legal or regulatory environment. In practice, it prevents teams from reusing one identity workflow across regions where licensing, privacy, and evidentiary requirements are not the same.

What's in the full article

Nexis's full article covers the operational detail this post intentionally leaves for the source:

• How the AI register is structured for owners, risk classes and documentation workflows
• The policy-based authorization logic that evaluates task, data class and jurisdiction together
• The runtime enforcement model for blocking external model calls to regulated data
• Why audit traceability and access control need to share the same governance definitions

👉 The full Nexis article expands the governance and policy model behind AI register readiness.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.