EU AI Act turns AI governance into a control challenge

At a glance

What this is: This analysis argues that the EU AI Act makes AI governance a control problem, not just a policy problem, because organisations must prove what AI is doing, what it can access, and who owns it.

Why it matters: For IAM and NHI practitioners, the core issue is that AI systems and agents now need identity, access, logging, and classification controls that can withstand regulatory scrutiny.

By the numbers:

• 56% of organizations reported that shadow AI incidents are occurring on a monthly basis.
• The EU AI Act entered into force on August 1, 2024, with most of the broader regime applying from August 2, 2026.
• The Regulation sets thresholds up to €35 million or 7% of worldwide annual turnover for certain infringements.

👉 Read Delinea's analysis of the EU AI Act and AI governance controls

Context

The primary issue is not whether organisations are using AI, but whether they can control it as an identity-bearing system. In practice, that means knowing which AI systems are in use, what data they touch, what access they hold, and which business owner remains accountable when those systems act inside regulated processes.

The EU AI Act shifts the burden from broad policy statements to operational evidence. That matters for IAM and NHI governance because AI agents, embedded copilots, and third-party AI features can create access paths and compliance duties that are invisible until a regulator, auditor, or incident response team asks for proof. This is a typical control gap, not a niche edge case.

Delinea’s article is framed around compliance, but the deeper lesson is about control-plane maturity. Organisations that cannot inventory AI use, classify risk, and enforce access boundaries will struggle to meet both the spirit and the letter of the law.

Key questions

Q: How should security teams govern AI systems that can act on sensitive data?

A: Security teams should treat AI systems as non-human identities with scoped access, named ownership, and full logging. The practical goal is to prove what the system could reach, what it actually did, and who approved any exception. Without those controls, AI governance stays documentary instead of operational.

Q: Why do AI systems complicate IAM and NHI governance?

A: AI systems complicate IAM and NHI governance because they blur the line between user, workload, and automated actor. They may consume delegated credentials, access multiple data sources, and act across workflows faster than humans can review. That creates a control problem if ownership, purpose, and logging are not explicit.

Q: What breaks when AI agents are not inventoried or classified?

A: When AI agents are not inventoried or classified, organisations lose the ability to assign risk, apply the right obligations, and prove control to auditors. The result is hidden access, inconsistent oversight, and weak accountability when the agent touches regulated data or triggers business actions.

Q: How do organisations prepare for the EU AI Act without slowing AI adoption?

A: They should start with visibility, then classify use cases, then enforce access and logging. That sequence lets teams keep moving while reducing surprise exposure. The objective is not to stop adoption, but to make every AI workflow explainable, owned, and reviewable.

Technical breakdown

How the EU AI Act turns AI use into a control classification problem

The EU AI Act does not treat AI as a single category. It separates providers, deployers, and general-purpose model providers, then applies different obligations based on risk, use case, and role in the value chain. That means the first technical task is classification: inventorying AI systems, determining whether they are embedded, external, or internally operated, and mapping each one to a regulatory posture. For IAM teams, this is similar to entitlement scoping. If you cannot classify the system, you cannot govern the access it consumes or the evidence it must produce.

Practical implication: Practitioners should build an AI inventory that ties each system to owner, purpose, deployment context, and expected regulatory class.

Why identity visibility matters once AI starts acting

As AI moves from recommendation to action, the control question changes from output review to runtime authorisation. The article points to temporary access tokens, identity-context logging, and request validation as the operating pattern, which means the AI must be treated as a non-human identity with traceable authority. Without that, organisations cannot tell which action was performed, under which identity, or whether the access granted was broader than necessary. This is the same failure mode that makes service accounts dangerous: persistent or unclear privilege creates an audit and containment problem.

Practical implication: Teams should bind each AI system to a named owner, a scoped identity, and logs that prove which actions were authorised.

What high-risk AI obligations mean for access governance

High-risk AI under the EU AI Act brings obligations around risk management, data quality, documentation, transparency, human oversight, accuracy, cybersecurity, and robustness. Those are not abstract legal concepts when mapped onto IAM. They require control over who can change prompts, who can approve exceptions, which data sources the model can reach, and how actions are recorded for later review. For NHI governance, the key insight is that compliance evidence depends on runtime controls, not only policy documents or procurement questionnaires.

Practical implication: Establish approval, logging, and review controls for any AI workflow that can influence regulated decisions or sensitive data access.

Threat narrative

Attacker objective: The objective is not always immediate theft. In this context, the attacker or failure mode is the uncontrolled AI action path that creates untraceable access and compliance exposure.

1. Entry occurs when an AI system or embedded tool is enabled inside a business process without being fully inventoried or classified.
2. Escalation follows when that system inherits broad access through tokens, service accounts, or delegated permissions that were never tightly scoped.
3. Impact is the inability to explain, constrain, or audit AI-driven actions when regulators or incident responders ask for evidence.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

The EU AI Act is forcing identity teams to treat AI as an access-bearing actor, not a policy topic. The law pushes organisations toward proof of control, which means AI systems need inventory, ownership, scoped access, and auditability. That shifts AI governance out of legal-only workflows and into operational identity controls. Practitioners should assume the governance model now includes every AI system that can act on data or make requests.

AI visibility is the new prerequisite for regulatory classification. Organisations cannot determine high-risk status, transparency duties, or deployer obligations if they cannot see where AI is embedded. The real issue is not model sophistication, but hidden adoption across SaaS tools, internal assistants, and delegated workflows. The practitioner takeaway is simple: if you cannot inventory AI use, you cannot govern it.

Ephemeral access does not solve AI trust debt unless ownership and logging are equally strong. Temporary tokens reduce exposure windows, but they do not answer who approved access, what the agent touched, or whether the action was appropriate. That is why runtime controls matter more than policy statements. Teams should treat every AI identity as temporary by design and accountable by default.

High-risk AI compliance will increasingly depend on NHI discipline. Risk management, traceability, and human oversight are only credible when non-human identities are managed with the same rigor as privileged human access. The market is moving toward convergence between AI governance and IAM operations. Practitioners should prepare for these functions to be assessed together, not separately.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
• Only 13% of organisations feel extremely prepared for the reality of agentic AI, according to The 2026 Infrastructure Identity Survey.
• For a deeper control framework, review Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for provisioning, rotation, and offboarding patterns.

What this signals

AI governance will converge with NHI operations faster than most teams expect. The EU AI Act pushes organisations to prove ownership, access scope, and oversight for systems that can act autonomously. With 70% of organisations already granting AI systems more access than human employees, according to The 2026 Infrastructure Identity Survey, the gap is no longer theoretical. Teams should prepare for AI identities to be reviewed like privileged workloads, not like policy exceptions.

Identity-context logging becomes a regulatory control, not a nice-to-have telemetry feature. If an AI system can influence decisions or move data, organisations need evidence of who approved the access, what was touched, and how exceptions were handled. That pushes logging, approval workflow design, and entitlement review into the same operational lane as compliance.

Visibility first, classification second, enforcement third is now the workable sequence. Organisations that start with control design before they know where AI is embedded will miss shadow deployments and overstate readiness. The better model is to inventory, classify, then constrain. For teams already managing NHIs at scale, this is a familiar lifecycle problem with a new class of actor.

For practitioners

• Inventory every AI touchpoint Map internal assistants, embedded SaaS features, developer tools, and third-party models to business owner, data scope, and regulatory role. Treat undocumented AI use as a governance gap, not a tooling issue.
• Bind each AI workflow to a named identity Use scoped non-human identities, temporary tokens, and identity-context logging so every AI action can be traced back to an owner and purpose. This is the minimum control for auditability and containment.
• Classify use cases before you classify tools Start with the business function, the sensitivity of the data, and the consequence of failure, then decide whether the AI activity falls into transparency, deployer, or high-risk obligations.
• Control data and exception paths explicitly Restrict which sources an AI system can read, which actions it can request, and which exceptions require human approval. In regulated workflows, uncontrolled exception handling becomes a compliance defect.

Key takeaways

• The EU AI Act makes AI governance an operational control problem because organisations must prove how AI is classified, owned, and constrained.
• AI systems that act on data should be managed as non-human identities with scoped access, traceable actions, and explicit accountability.
• The most effective response is not to slow AI adoption, but to inventory use, classify risk, and enforce runtime controls before exposure becomes unmanageable.

Key terms

• Agentic AI: Agentic AI is software that can choose actions, call tools, and pursue goals with some execution authority. In security terms, it behaves like a non-human identity because it can create requests, use credentials, and affect data without a human approving every step.
• 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.
• Identity-context logging: Identity-context logging records not only what an actor did, but which identity, policy, and approval path were involved. For AI systems, this makes later review possible because the record links the action back to access scope and accountability.
• High-risk AI system: A high-risk AI system is an AI use case that can materially affect rights, safety, or regulated processes. These systems require stronger documentation, oversight, and control evidence because failures can create legal, operational, and security consequences beyond ordinary business software.

Deepen your knowledge

AI identity governance and regulated access control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is moving from policy to operational controls, it is worth exploring.

This post draws on content published by Delinea: EU and AI, what you need to know about AI regulations. Read the original.