The AI Register Is Not Enough
25 Jun 2026
Every conversation about EU AI Act readiness starts in the same place: build the register. Inventory every model, every copilot, every agent, assign each one a risk class and an owner, and keep the documentation current for the August 2026 deadline. That work is necessary, and most organizations still cannot produce the list when an auditor asks for it. But the register is where readiness usually stops, and that is the problem. A register records what you intend to be true. It does not make it true, and it does not hold the line when an agent reaches for data it should never touch.
The gap shows up most clearly with data, and it is the part a static inventory cannot close. The answer to it lives exactly where IAM and GRC meet.
The Risk Moves With the Data, Not the Model
An agent’s risk classification is not a fixed property of the model behind it. It changes with the data the model touches. The same copilot is minimal-risk when it summarizes a public knowledge base and high-risk the moment it reads regulated personal data. Register that copilot once, at deployment, and the entry is already out of date the first time its task shifts. This is the agent version of permission creep: the classification on file describes yesterday’s behavior while the agent does something else today.
That matters because the obligations under the AI Act attach to what the system actually does, not to what you wrote down about it months earlier. A register that does not move with the data will pass a documentation review and fail a runtime incident.
The Hard Rule is About Data and Jurisdiction
Most European companies will need a rule that sounds simple and turns out to be the whole problem:
Regulated, high-risk data in the EU must never be reachable by a US-hosted model, and the reverse wherever contractual or jurisdictional terms demand it.
The difficulty is that many agents do not stay inside the organization. They call external, often foreign-hosted AI services, which means sensitive company data can leave your sphere of control without approval, without logging, and without any way to recall it. A register can document the intent to prevent that. It cannot stand between the agent and the API call. Enforcement has to happen at the moment of access, and it has to weigh three things at once: the identity of the agent, the jurisdiction of the model behind it, and the classification of the data it is reaching for.
Static Registration Cannot Enforce This, Dynamic Policy Can
This is where policy-based authorization earns its place. Combining role-based, attribute-based, and rule-based control lets you tie access to the actual context of the request rather than to a static role: which task, which data class, which risk level, which jurisdiction. The policy runs every time the agent acts, evaluates the combination, and fails closed when the rule forbids it. A US-hosted model that requests EU high-risk data does not produce a documented violation after the fact. The policy denies it in the moment.
The same approach scales in a way that manual registration never will. Because policies are defined once and applied across many agents, they can be recertified independently of the agents themselves. The number of policies stays small while the agent population grows by a factor of fifty or a hundred. You govern the rules, not each individual identity, and that is the only version of this that holds up as agent numbers climb.
This is Where IAM and GRC Stop Being Separate Functions
The reason this is hard is that it sits across two organizational borders that have always sat apart. The classification of data, the risk model, and the policies that say what is allowed in the company come from the GRC side, out of the ISMS and frameworks like DORA and NIS2. The identities, the scopes, and the enforcement point come from the IAM side. The AI Act needs both at the same time, working off the same definitions.
Treat AI agents as an IAM problem alone and you miss the regulatory dimension entirely. Treat them as a compliance problem alone and you have a policy no system enforces. The register defines what should be true, the identity layer makes it true at runtime, and the same audit log that proves least-privilege access also satisfies the AI Act’s traceability requirement. One control answers to two regulators. An Identity Visibility and Intelligence Platform exists to hold exactly this convergence: a single governance layer across fragmented IAM systems, where the data classification on the GRC side actually drives the policy the identity layer enforces.
Start Before the Deadline Forces It
The practical takeaway for anyone working toward August 2026 is to stop running the AI register and the access controls as two projects. Build the register so data classification drives policy automatically, and build the policy engine so it reads data type and jurisdiction, not just agent identity. The register tells you what should be true. Dynamic, data-aware policy is what makes it true, and proves it when the audit comes.
Want to see what data-aware enforcement looks like in your own environment?
The NEXIS Platform brings the GRC and IAM sides into one governance layer, so the policies you define hold the line when an agent acts. Maybe you are building toward AI Act compliance for August 2026. Maybe you already have it and need it to stay intact as your agent count grows. Either way, a demo is the fastest way to see how the platform maps to your stack: