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

At a glance

What this is: Holistic AI argues that delaying parts of the EU AI Act would shift dates, not reduce the need for internal AI governance, inventory, ownership and testing.

Why it matters: For AI governance, IAM and security teams, the article reinforces that regulatory timing does not remove the need to know what systems exist, who owns them, and how they are controlled.

Context

AI governance is the discipline of defining inventory, ownership, accountability, testing and operating principles for systems that can affect people and business outcomes. The article argues that regulation can set a baseline, but it cannot create the internal controls that make AI safe, explainable and manageable.

That distinction matters because many AI risks arise before a legal deadline ever arrives. For teams running AI programmes, especially where models, agents or decision systems touch human identity or customer-facing processes, governance has to exist as operating discipline rather than a compliance project.

Key questions

Q: What breaks when AI adoption outpaces governance?

A: What breaks first is attribution. Teams lose visibility into which tools are in use, which data they can reach, and which actions were taken automatically versus manually. Once adoption is ahead of control design, security teams end up retrofitting policy around live workflows instead of governing them from the start.

Q: Why does a delay in AI regulation not remove the need for internal controls?

A: Because regulation sets external obligations, but it does not create the organisation’s operating discipline. Internal controls are still needed to define accountability, test systems, document purpose and monitor drift. A delay only changes enforcement timing, not the underlying need to manage safety, trust and risk.

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 structure AI governance before focusing on compliance?

A: Start by defining ownership, risk tolerance, approval paths, data access boundaries, and monitoring responsibilities. Compliance becomes achievable when those controls already exist in day-to-day operations. Without that structure, teams end up chasing requirements reactively and cannot prove that AI systems were controlled when decisions were made.

Technical breakdown

Why compliance does not equal AI governance

Compliance answers whether a system meets a minimum external requirement. Governance answers who owns the system, what risks it creates, how it is tested, and how decisions are challenged. In AI programmes, those are not interchangeable because the same regulatory requirement can be satisfied by very different operating models. One model may be document-heavy but weak in practice, while another may embed real accountability, monitoring and review. The article’s central point is that a delayed regulation can change filing dates, but it cannot create trustworthy operating discipline. Practical implication: treat regulation as a baseline control set, not as the programme itself.

Practical implication: Build governance around ownership, testing and accountability rather than around deadline-driven compliance tasks.

AI inventory and ownership are the real control layer

An AI inventory is the authoritative record of what systems exist, what they do, who uses them, and who is accountable for them. Ownership converts a dispersed collection of pilots, models and tools into something a business can govern. Without both, organisations cannot answer basic questions about risk exposure, escalation paths or whether a system should remain in use. The article’s recommended delay response aligns with this: inventory the systems, map the risks, and assign responsibility before trying to optimise policy detail. Practical implication: if you cannot identify an AI system and its owner, you cannot govern it.

Practical implication: Create a complete inventory with named owners before expanding policy, assurance or deployment.

Red teaming and transparency are governance mechanisms, not extras

Red teaming tests how a system behaves under stress, misuse and adversarial prompting. Transparency documentation explains what the system is for, where its limits are, and what assumptions support its outputs. Together, they move AI governance from aspiration into repeatable control. The article’s message is that these activities should not wait for a regulatory clock to force them. They are part of the operating model that reduces surprise when systems drift, fail or are repurposed. Practical implication: make testing and documentation recurring controls, not one-time launch activities.

Practical implication: Run recurring stress tests and maintain clear system documentation as standing governance controls.

NHI Mgmt Group analysis

Compliance is a floor, not a governance model. A delay in the EU AI Act may change enforcement timing, but it does not change the operational reality that AI systems still need ownership, testing and accountability. Organisations that treat regulation as the end state will always run behind the actual risk surface. The practitioner conclusion is simple: govern the system first, then map the regulation onto it.

AI governance debt is the more dangerous problem than regulatory delay. When deployment moves faster than inventory, documentation and approval structures, the organisation accumulates blind spots that no deadline extension can fix. That is true whether the system is a model, workflow or agent touching human decisions. The practitioner conclusion is to treat governance backlog as a measurable control gap, not an abstract policy issue.

Trust is the operating outcome that compliance alone cannot deliver. The article is right to separate legality from safety, because stakeholders judge AI by how reliably it behaves, not by whether a filing was late or on time. In practice, trust depends on repeatable controls such as risk ownership, stress testing and transparent system purpose. The practitioner conclusion is to make trust measurable through governance artefacts and testing evidence.

AI inventory is the prerequisite control for any serious assurance programme. If teams do not know what AI they have, they cannot assign responsibility, assess impact, or decide where stronger guardrails are needed. That problem becomes more severe as shadow AI and embedded model use spread through business units. The practitioner conclusion is to start with discovery and ownership before debating finer policy details.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: NHI Lifecycle Management Guide

What this signals

Governance lag is becoming the real AI risk metric. If deployment, documentation and testing advance at different speeds, the gap turns into unresolved exposure that no regulatory pause can fix. Teams should measure that lag explicitly and treat it as a control failure, not a planning inconvenience.

Discovery has to come before policy refinement. Once AI systems are already embedded in workflows, the hardest question is not whether they are allowed, but who owns them and how they are controlled. That is where inventory discipline, accountability mapping and recurring assurance become the core programme requirements.

AI governance belongs inside the operating model, not outside it. Organisations that wait for regulation to force structure are likely to accumulate shadow use, inconsistent review and weak evidence of control. The practical response is to make testing, documentation and ownership part of normal change management rather than a separate compliance track.

For practitioners

• Establish a full AI inventory Catalogue every model, embedded AI feature, workflow and externally sourced system in use, and assign a named owner for each one.
• Map risk and accountability before policy refinement Record the intended use, affected users, material risks and decision owner so governance discussions start from evidence rather than assumptions.
• Run recurring red teaming and jailbreak testing Test systems on a schedule for unsafe outputs, prompt abuse, drift and boundary failures, then track remediation through to closure.
• Document operating principles for AI use Write down the organisation’s commitments on transparency, oversight, human responsibility and acceptable use so teams have a common control baseline.
• Measure governance lag as a programme risk Compare deployment speed with the status of inventory, testing, ownership and review controls, and escalate when the gap widens.

Key takeaways

• AI regulation delay does not change the fact that organisations still need inventory, ownership and testing for the systems they already run.
• The article’s central warning is that compliance can set a baseline, but it cannot substitute for governance discipline or trust-building controls.
• Teams that use extra time well will close governance gaps before deployment scale makes remediation slower and more costly.

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 Debt: The accumulation of unresolved identity control weaknesses created when teams prioritise speed over lifecycle design. In NHI environments, it shows up as accounts with unclear ownership, undocumented purpose, stale credentials, and no reliable retirement path, all of which make later security work harder.
• Red Teaming: Red teaming is structured adversarial testing used to find how an AI system fails under realistic misuse or attack conditions. In AI security, it is a discovery method, not a proof of safety, because probabilistic behaviour and changing models prevent any lasting guarantee.
• 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

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle and secrets management for practitioners building controlled, auditable access models. It is a useful fit for teams that need governance discipline across identity security and adjacent automation programmes.