EU AI Act compliance shifts from policy to continuous governance

At a glance

What this is: This is a compliance guide showing that EU AI Act obligations have moved from future planning into active operational governance, with transparency rules now in force and high-risk controls on a later timetable.

Why it matters: For AI, identity, and governance teams, the practical issue is proving control over which systems exist, what they do, who owns them, and how decisions and data flows are documented.

By the numbers:

• The EU AI Act carries maximum fines of €35 million or 7% of annual turnover for prohibited AI practices, according to Anjuna.
• High-risk AI system or GPAI non-compliance can trigger maximum fines of €15 million or 3% of global annual turnover, according to Anjuna.
• Providing incorrect or misleading information to authorities can result in maximum fines of €7.5 million or 1% of global annual turnover, according to Anjuna.

Context

The EU AI Act turns AI governance into an operational control problem, not a policy exercise. Organisations now have to know which systems they run, what data those systems process, which people they affect, and which tier of obligation applies to each use case. That is especially relevant where AI supports decisions, interacts with EU citizens, or handles sensitive information that demands traceability.

For NHIMG, the governance lesson is clear: this is not just about compliance documentation, it is about inventory discipline, decision accountability, and evidence generation. Where AI systems are embedded in business workflows, identity governance, data governance, and model governance start to overlap, and weak ownership becomes a control failure rather than an administrative gap.

Key questions

Q: How should organisations prove EU AI Act compliance across the AI lifecycle?

A: They should treat compliance as a continuous evidence chain that spans design, development, deployment, and post-market monitoring. That means maintaining versioned documentation, traceable datasets, logged decisions, named ownership, and tested human oversight. If any stage cannot be reconstructed, the compliance case weakens and the organisation should close that gap before audit time.

Q: Why do high-risk AI systems require stronger governance than ordinary AI tools?

A: High-risk systems can affect employment, finance, health, or other sensitive outcomes, so regulators expect traceability, transparency, and human intervention. Ordinary operational controls are not enough if teams cannot show who approved the model, what data it uses, and how changes are controlled. The governance bar rises because the consequences are higher.

Q: What breaks when AI governance is only a one-time review?

A: A one-time review breaks as soon as the agent gains a new tool, a new dataset, or a new workflow. Governance that is frozen at approval time cannot keep up with runtime drift, which means the real access path and the approved access path quickly diverge.

Q: Should organisations use existing security and privacy frameworks for EU AI Act compliance?

A: Yes, but only as a baseline. Frameworks such as GDPR, ISO 27001, SOC 2, and NIST AI RMF cover overlapping controls, but the Act also introduces AI-specific duties around tiering, transparency, and prohibited practices. The practical task is to map overlap clearly and fill the AI-specific gaps rather than starting from scratch.

Technical breakdown

Risk tiering changes the compliance unit of control

The EU AI Act does not regulate AI as a single category. It divides systems into minimal, limited, high, and unacceptable risk, then applies different duties depending on the use case and impact on rights, safety, or access to services. That means governance has to begin with classification, not with a general policy statement. Once a system is in scope, the organisation must map obligations to the tier, the deployment context, and the role it plays in decision-making. This creates a lifecycle requirement, because a model can move into a different risk category as its use changes.

Practical implication: Build tiering into AI intake and change management so every deployment is classified before it enters production.

Transparency obligations require evidence, not reassurance

For limited-risk and high-risk systems alike, the Act expects organisations to prove what the system does, what data it uses, and when a user is interacting with AI-generated output. That makes logging, documentation, and disclosure part of the control surface. In practice, this is close to identity and access governance for AI systems: ownership, traceability, and accountable decision paths become mandatory evidence. When a chatbot, recommender, or decision engine affects an EU user, regulators will expect a record that is consistent, current, and reviewable.

Practical implication: Treat disclosure, logging, and technical documentation as auditable controls rather than optional compliance artefacts.

Confidential computing supports verifiable AI governance

Confidential computing uses a hardware-based trusted execution environment to isolate workloads while they are processing data. In EU AI Act terms, that matters because governance is not only about what a model is supposed to do, but whether its data handling and behaviour can be verified after the fact. Attestation and tamper-resistant logs provide a stronger evidence path than policy documents alone. This is particularly relevant where AI systems process sensitive or regulated data, because the Act emphasises documentation, data governance, and traceability.

Practical implication: Use attestable runtime controls when regulated AI workloads need demonstrable processing integrity and tamper-resistant records.

NHI Mgmt Group analysis

EU AI Act compliance is now a continuous governance problem, not a deadline problem. The article is right to emphasise that annual review cycles are too slow for systems that can change function, user impact, and legal tier over time. For identity and governance teams, the key question is whether AI ownership, logging, and decision traceability are maintained as live controls. Practitioners should treat AI governance as a standing operational discipline.

Risk classification is the named control concept organisations are still underbuilding. The Act’s value lies in forcing enterprises to identify, tier, and document every AI system instead of treating all AI as one governance category. That matters because limited-risk chatbots, high-risk decision systems, and prohibited uses trigger very different obligations. The practical conclusion is that inventory quality now determines compliance quality.

Confidential computing is becoming part of the evidence layer for regulated AI. The article correctly frames attestation and tamper-resistant logging as governance enablers rather than infrastructure features. That is important because regulators do not just want policy assertions, they want proof that data and model behaviour were handled consistently. For AI programmes, verifiable runtime evidence is fast becoming a control expectation.

Identity governance and AI governance are converging around accountability. Where AI systems influence decisions, the control question becomes who owns the system, who can change it, and who can explain its outputs. That is an identity problem as much as a model-risk problem. Organisations that cannot connect system ownership to evidence of operation will struggle to defend compliance claims.

The European scope of the Act forces global organisations to adopt a single AI governance standard. If an AI system touches EU users, geographic distance no longer reduces regulatory responsibility. That means multinational enterprises need one control framework for inventory, classification, and documentation across regions. Practitioners should stop designing local exceptions and start designing reusable governance patterns.

What this signals

Risk classification will become the organising principle for enterprise AI governance. Teams that can reliably inventory, tier, and review AI systems will be able to show control maturity; teams that cannot will struggle to prove scope or accountability. The real operational shift is that AI governance now depends on live system knowledge, not policy ownership alone.

Identity and AI governance are converging through ownership and evidence. When an AI system makes or influences decisions, the programme has to know who owns it, who can change it, and what proof exists for its operation. That places AI systems inside the same accountability discipline that already governs privileged access and lifecycle control.

Continuous documentation is now part of the control stack. Organisations should expect regulators and auditors to ask for current records of system purpose, data use, disclosure, and oversight, not just a policy deck. For enterprises with broad AI adoption, the next practical step is to turn documentation into a managed, reviewable workflow.

For practitioners

• Map every AI system in scope Inventory all models, chatbots, decision tools, and embedded AI services. Record ownership, data processed, affected groups, and whether the system interacts with EU users.
• Classify systems by EU AI Act risk tier Assign each AI use case to minimal, limited, high, or unacceptable risk, then tie required controls to that classification before production use.
• Build evidence into the AI lifecycle Collect technical documentation, logging, disclosure records, and human-oversight evidence during development and change management, not after deployment.
• Separate prohibited-use screening from general compliance Block use cases that fall into prohibited categories first, then work the remaining systems through tier-specific remediation and documentation.
• Use attestable runtime controls for regulated workloads Where processing integrity matters, require attested execution and tamper-resistant logs so AI behaviour can be demonstrated to auditors and regulators.

Key takeaways

• The EU AI Act turns AI governance into a standing operational requirement rather than a one-time legal exercise.
• Enterprises need a complete, current inventory of AI systems before they can classify risk or prove compliance.
• Evidence quality now matters as much as policy design, because regulators will expect traceable ownership, logging, and oversight.

Key terms

• Risk tiering: Risk tiering is the practice of grouping vendors by the level of exposure they create based on data access, system criticality, and business dependency. It lets organisations spend more control effort where the blast radius is largest and keep lower-risk relationships under lighter governance.
• High-Risk AI System: A high-risk AI system is one whose outputs can materially affect a person’s rights, opportunities, or safety. These systems need stronger oversight because errors, bias, or unauthorized actions can create legal exposure as well as security and trust problems.
• AI Transparency: AI transparency is the ability to show what an AI system did, on what data, under what policy, and on whose authority. It is proven through records, lineage, accountability, and enforcement evidence rather than through a narrative of the model's internal reasoning.
• Confidential Computing: A method of processing sensitive data inside a protected hardware enclave so the cloud operator cannot inspect the data while it is in use. It combines isolation, attestation, and controlled execution to reduce exposure during cloud-side computation without forcing plaintext access.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, helps practitioners understand NHI governance, agentic AI identity, and machine identity security in regulated environments. It is designed for teams that need to connect identity control with broader security and compliance programmes.