EU AI Act turns AI governance into a control challenge

At a glance

What this is: This is Delinea’s analysis of the EU AI Act as a governance problem, with the central finding that AI compliance now depends on visibility, classification, access control, and auditability rather than policy alone.

Why it matters: For IAM, NHI, and AI governance teams, the article matters because it reframes AI regulation as an identity and control issue that touches human owners, non-human access, and emerging agentic systems.

By the numbers:

• The AI Act entered into force on August 1, 2024, and the broader regime applies from August 2, 2026, while certain high-risk systems embedded in regulated products follow on August 2, 2027.
• The law can fine organisations up to €35 million or 7% of worldwide annual turnover for certain infringements.

Context

The EU AI Act is a governance problem because it asks organisations to classify what AI is doing, who is responsible for it, and what risk it creates. That shifts the discussion from broad policy statements to control evidence, access scope, and accountability across the AI lifecycle.

Delinea’s analysis frames the act as relevant well beyond frontier model developers, including organisations that build, buy, embed, or use AI in the EU. The practical question is whether the business can inventory AI use, govern access, and produce evidence of controlled operation when the system acts in motion.

For identity teams, the core change is that AI governance now intersects with runtime authorization, audit trails, and human ownership. That makes the topic relevant to human IAM, NHI governance, and emerging agentic AI control models at the same time.

Key questions

Q: How should organisations classify AI systems for EU AI Act compliance?

A: Start with intended use, not technical complexity. If the system is used for hiring, credit, performance evaluation, or another Annex III activity, it may be high risk even if it looks routine. Classification should be tied to the actual business function, the people affected, and whether the organisation is acting as provider or deployer.

Q: Why is policy alone not enough for AI compliance?

A: Because the EU AI Act asks for evidence of controlled operation, not just stated intent. Policies cannot show what an AI system accessed, which identity it used, or whether exceptions were contained. Practitioners need runtime visibility, access control, and logs that can stand up to audit after the system has acted.

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 should teams do when vendor AI is embedded in internal workflows?

A: Treat it as part of your own control surface and assign a clear owner, because deployer obligations do not disappear when the model comes from a supplier. Teams should document what the AI can reach, what data it processes, and how they would explain the action later. That is the only way to preserve accountability through procurement and legal delegation.

Technical breakdown

Why the EU AI Act is a control problem, not just a policy problem

The EU AI Act does not only regulate AI outcomes. It also requires organisations to show classification, traceability, and ongoing control over how AI systems are used. That moves compliance away from static documentation and toward operational proof: what identity the system acts under, what it can reach, and what evidence exists after execution. In identity terms, the act exposes the gap between saying a system is governed and actually governing the identities and permissions behind it.

Practical implication: treat AI governance as an access, logging, and ownership problem, not a policy-only exercise.

How deployers inherit accountability across the AI value chain

The act distinguishes between providers, deployers, and general-purpose model providers, which means downstream users can still carry obligations even when they did not build the model. That matters because embedded SaaS features, third-party assistants, and internal automation can all create governed AI use without obvious ownership lines. The governance challenge is therefore less about who wrote the model and more about who can explain its operation, constrain its access, and evidence oversight when something goes wrong.

Practical implication: map AI obligations to the actual operating role, not to the vendor relationship alone.

Why runtime visibility matters once AI starts acting in motion

The article’s strongest operational point is that documentation is insufficient once AI systems start acting inside business workflows. If an AI agent can request access, interact with data, and generate records inside a session, then the security model must follow the action rather than the policy binder. That is the same reason NHI and identity teams care about temporary credentials, audit trails, and access scoping: the control has to exist at the point of use, not only at approval time.

Practical implication: govern AI at issuance, execution, and logging time, not only during procurement or legal review.

NHI Mgmt Group analysis

The EU AI Act is converting AI governance into an identity and control discipline. That is the real shift beneath the legal language: organisations now have to prove who or what acted, under which authority, with what access, and with what evidence afterward. Policy documents cannot answer those questions on their own. The implication is that AI governance now belongs inside access governance, auditability, and ownership models, not alongside them.

Visibility is the first control barrier, and invisible AI is unmanaged AI. The article correctly points out that organisations cannot classify risk they cannot inventory, especially when AI is embedded in SaaS features, copilots, developer tools, and internal workflows. That creates a governance blind spot across human-owned, vendor-provided, and machine-executed activity. The practical conclusion is that inventory quality now determines whether regulation is manageable or reactive.

Accountability no longer ends at the model builder. The EU AI Act spreads obligations across providers and deployers, which means downstream users still own control evidence even when the AI came from a third party. That matters for procurement, access review, and audit preparation because the duty to explain operation does not disappear with outsourcing. Practitioners should therefore treat vendor AI as part of their own control surface.

Runtime authorisation is becoming the named concept that matters most for AI governance. Once AI can act inside business processes, the decisive question is not whether a policy exists but whether the system can be constrained while it is operating. That changes the security conversation from static approval to dynamic control of access, logging, and exception handling. Practitioners should build governance around execution-time evidence rather than paper compliance.

AI governance is converging with NHI governance because the control problems are now shared. The article’s emphasis on temporary access, identity context, and auditable action shows why AI systems increasingly need to be governed like non-human identities. That does not make every AI use case autonomous, but it does mean the same identity discipline applies once a system acts through credentials. The practical conclusion is that identity teams should own part of the AI compliance conversation from the start.

From our research library:

• Only 37% of organisations had policies for managing AI or detecting shadow AI, according to IBM's 2025 Cost of a Data Breach Report.
• Read next: Agentic AI Identity Risk Board Briefing

What this signals

Runtime governance is now the deciding factor in AI compliance. The AI Act pushes organisations past policy-only governance and into controls that can prove what a system accessed, under which identity, and with what record afterward. For practitioners, that means AI inventory, access scope, and logging need to sit in the same programme as review and approval.

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. This gap shows why the market is moving from AI awareness to governance execution, especially where AI systems act inside business workflows.

Identity teams should expect AI compliance to converge with non-human identity controls. When an AI system can act, not just answer, the relevant questions become ownership, entitlement, and auditability. That makes AI governance a shared problem for IAM, NHI, and security operations rather than a standalone legal workflow.

For practitioners

• Inventory all AI uses across the business Include embedded SaaS features, copilots, internal assistants, and third-party tools so the organisation can classify what is in use and who owns it.
• Classify AI systems by role and risk Separate provider, deployer, and general-purpose model obligations, then map use cases to risk category, geography, and business impact.
• Map identity and access behind each AI system Document what identity each AI capability acts under, what data it can touch, and which permissions are overprivileged for the use case.
• Strengthen logging for AI-triggered actions Ensure the record shows what the system accessed, what policy applied, and how exceptions were handled so audit evidence survives after the event.
• Assign a human owner for every AI use case Make ownership explicit for review, escalation, and compliance evidence, especially where vendor models are embedded inside internal workflows.

Key takeaways

• The EU AI Act changes AI governance from a policy exercise into a control challenge that depends on inventory, access scope, and auditability.
• The law spreads accountability across providers and deployers, so downstream users still need to prove controlled operation even when the model comes from a vendor.
• For identity teams, the operational priority is to govern AI through runtime visibility, ownership, and logging rather than relying on documentation alone.

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.
• Deployer: A deployer is the organisation that puts an AI system into service or uses it in a real environment. Under risk-based regulation, deployers may inherit obligations even when they did not build the model, especially when the system touches sensitive data or regulated decisions.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
• AI Inventory: An AI inventory is a governed record of all AI-related assets, enriched with owner, purpose, access, and risk context. It turns discovery into something security, compliance, and IAM teams can use to make approval, review, and revocation decisions.

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.