Compliance is not governance in AI regulation, and delay changes little

At a glance

What this is: This is an opinion-led analysis arguing that a delay in EU AI Act enforcement should not slow down AI governance programmes because compliance and governance are not the same thing.

Why it matters: It matters to IAM, AI governance, and security teams because AI systems still need ownership, accountability, and control mapping even when statutory deadlines move.

👉 Read Holistic AI's analysis of why compliance is not enough for trusted AI

Context

AI governance fails when organisations treat legal deadlines as the end state instead of the minimum bar. The article argues that delaying enforcement would not remove the underlying risks created by AI systems that make consequential decisions, so the real problem is governance drift, not timetable drift.

For identity and access teams, the intersection matters because AI systems need clear ownership, access boundaries, and accountability structures just like other critical enterprise systems. When AI is deployed without inventory, risk mapping, and documented responsibility, compliance activity becomes disconnected from operational control.

Key questions

Q: What breaks when AI governance is limited to compliance mapping?

A: The organisation loses the ability to prevent harmful model behaviour in the moment it occurs. Compliance mapping can help with audits and accountability, but it does not constrain access, block malicious prompts, or interrupt data leakage. That leaves the gap between approved policy and actual system behaviour wide open in production.

Q: Why do delayed AI regulation dates still require active governance?

A: Because delay changes timing, not scope. The underlying duties remain, and the evidence needed to prove compliance still takes time to build. Organisations that pause now usually discover too late that inventory, ownership, documentation, and monitoring are harder to reconstruct than to maintain from the start.

Q: How can organisations tell whether AI governance is actually working?

A: Organisations can tell AI governance is working when they can inventory every agent, explain its purpose, show who owns it, and prove that permissions are tightly scoped. If those four things are missing, the programme has policy language but not operational control. Auditors will notice the gap quickly.

Q: How should organisations govern access to data used by AI systems?

A: Treat AI data access as an identity governance problem, not just a data storage problem. Define who or what can use each dataset, what purpose is allowed, and what runtime restrictions apply. Then review humans, service accounts, and AI agents separately so entitlement scope matches actual behaviour rather than a generic AI policy.

Technical breakdown

Why compliance and governance diverge in AI programmes

Compliance answers whether an organisation can show conformity with a rule set. Governance asks who owns the system, what risks it creates, how those risks are monitored, and when intervention is required. In AI programmes, those questions matter because models and workflows can change behaviour over time, especially when data, prompts, or downstream integrations shift. A compliant system can still be poorly understood, weakly supervised, or unsafe in practice. The article’s core point is that legal timing does not change the operational need for inventory, accountability, and testing.

Practical implication: treat regulation as a control baseline, not as the operating model for AI oversight.

Why AI system inventory is the first governance control

An AI inventory is the foundation for governance because you cannot assign risk ownership to systems you have not identified. Inventory means more than listing approved models; it includes embedded AI in products, third-party services, and internal workflows where decision support may be opaque. Without that view, organisations cannot map accountability, assess use cases, or determine which systems warrant stronger oversight. This is also where identity intersects with AI governance, because access to models, prompts, training data, and administrative functions must be governed like other sensitive enterprise privileges.

Practical implication: require an authoritative register of all AI systems, owners, and access paths before governance reviews can be trusted.

How trust depends on testing, not just policy statements

Policies and principles matter, but they do not prove that a system behaves safely under pressure. That is why red teaming, jailbreak testing, and ongoing review are central to effective AI governance. These practices expose prompt injection, unsafe outputs, policy bypasses, and drift that static documentation will miss. In security terms, they are the equivalent of validating control operation rather than assuming control design equals control effectiveness. The article correctly places stress on operating procedures because a written commitment without adversarial testing creates a false sense of assurance.

Practical implication: validate AI controls through repeated testing and review, not through policy publication alone.

NHI Mgmt Group analysis

Compliance drift is now a governance risk in its own right. When organisations interpret regulatory delay as permission to pause, they create a second-order control failure: the business confuses external timing with internal readiness. That weakens oversight, slows ownership assignment, and leaves AI systems in production before their risks are understood. In governance terms, the issue is not the delay itself but the operational complacency it can trigger. Practitioners should separate legal milestones from control maturity gates.

AI governance debt: this article describes a familiar pattern where unresolved governance work accumulates until it becomes expensive and politically harder to fix. Inventory gaps, unclear accountability, and missing testing do not disappear because enforcement moves. They compound. For teams managing AI alongside IAM and broader security programmes, the lesson is to build governance mechanisms that survive regulatory uncertainty, not depend on it.

Identity controls remain part of AI governance, even in a non-identity article. Any AI system that can access data, invoke tools, or influence decisions creates an access problem as well as a model risk problem. That means ownership, privileged administration, and access review are not adjacent concerns, they are part of the governance core. Security teams should map AI privileges, not just AI policies, to avoid blind spots in control coverage.

Regulation is a floor, not a proof of safety. NIST AI RMF and EU AI Act-style obligations can structure accountability, but neither can verify whether a deployed system is trustworthy in context. That requires evidence from testing, monitoring, and escalation paths. The practical conclusion is that teams should treat governance as an operating discipline, with controls that work before, during, and after regulatory deadlines.

The market signal is a shift from checkbox compliance to demonstrable control effectiveness. Buyers, boards, and regulators are increasingly looking for proof that AI systems are inventoried, owned, tested, and supervised. That is pushing governance programmes toward measurable control operation rather than policy language. Practitioners should expect scrutiny to move from documentation quality to evidence of actual oversight.

What this signals

AI governance programmes are moving from policy-centred discussions to evidence-centred controls, and that shift will pressure teams to prove inventory, ownership, and testing rather than just publish principles. For identity and security leaders, the practical challenge is to align AI oversight with privileged access, change control, and accountability structures already used in other critical systems.

AI governance debt: delayed action creates a backlog of unowned systems, undocumented integrations, and untested behaviours that becomes harder to fix as AI adoption spreads. Teams that address the governance layer now will have a cleaner path to regulatory alignment later, especially where access control and system accountability overlap.

For practitioners

• Build a complete AI system inventory Capture every model, embedded AI feature, external API, and internal workflow that can affect decisions or data handling. Assign a named owner, business purpose, and risk tier to each system so governance reviews have a reliable control baseline.
• Map ownership and accountability structures Define who approves use, who monitors outputs, who can change prompts or configurations, and who can retire the system. Make these roles explicit in policy and operational workflows so accountability survives personnel changes and vendor updates.
• Stress-test systems with red teaming and jailbreak testing Run adversarial testing on a recurring basis to expose prompt injection, unsafe outputs, policy bypasses, and drift. Use the findings to update approvals, guardrails, and escalation paths rather than treating testing as a one-time exercise.
• Treat AI access as a privileged access problem Review who can administer models, adjust prompts, access training data, and connect tools or agents to production systems. Apply least privilege and formal access review to those pathways because AI governance fails quickly when administrative access is unmanaged.

Key takeaways

• The article’s central argument is that compliance timing and governance maturity are different problems, and confusing them creates operational risk.
• AI programmes need inventory, ownership, and testing evidence because policy statements alone do not prove control effectiveness.
• Identity and privileged access controls remain part of AI governance, especially where systems can connect tools, data, and decisions.

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.
• Governance Maturity: The degree to which an organisation can consistently assign ownership, assess risk, monitor behaviour, and intervene when needed. In AI programmes, maturity is shown by evidence of operating controls, not by policy statements or one-time compliance checks.
• AI System Inventory: A governed record of every AI system, its owner, purpose, data scope, and risk tier. In practice, it is the control register that lets security, compliance, and audit teams decide which obligations apply and which evidence must be retained.
• Least-privileged AI access: Least-privileged AI access means granting an AI system only the data and system permissions it needs for a specific task, dataset, or workflow stage. The key control is not whether the AI can technically reach more, but whether governance prevents it from doing so by default.

What's in the full article

Holistic AI's full blog post covers the governance detail this post intentionally leaves for the source:

• How the article frames the difference between regulatory compliance and enterprise governance
• Examples of how organisations can embed AI literacy across teams and operating procedures
• The specific stress-testing practices the author recommends, including red teaming and jailbreaking
• The governance principles the article says should exist regardless of enforcement timelines

👉 Holistic AI's full post expands on the governance practices it recommends before regulatory deadlines shift again.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It is relevant for practitioners who need a stronger operating model for access, accountability, and lifecycle control across modern security programmes.