EU AI Act delay exposes the AI inventory gap in enterprise governance

At a glance

What this is: JupiterOne says the EU AI Act delay exposes a basic governance gap: most organisations still cannot inventory AI assets, connect them to data and identities, or prove the controls the law assumes are already in place.

Why it matters: For IAM, NHI, and AI governance teams, this matters because compliance breaks down when AI systems, service accounts, and data flows are managed separately instead of as one live control surface.

Context

The core problem is not the deadline extension itself, but the assumption behind the regulation that organisations already know what AI they run, where it sits, what data it touches, and which identities can reach it. Without that inventory, requirements such as risk management, logging, transparency, and human oversight cannot be evidenced in a defensible way.

That gap is especially relevant where AI systems are connected through cloud services, APIs, service accounts, and embedded features that bypass central governance. In practice, AI inventory is also an identity and access problem because untracked models still depend on workloads, tokens, and privileged paths that can expand the attack surface long before compliance teams see them.

Key questions

Q: How should organisations prepare their AI inventory for EU AI Act compliance?

A: Start by building a complete inventory of every AI system in use or development, then classify each one by risk level and business purpose. Capture data sources, governance controls, and where the system is deployed. That inventory becomes the control point for scoping obligations, prioritising remediation, and proving to regulators that compliance decisions were made systematically rather than ad hoc.

Q: Why does AI governance fail when asset discovery and compliance attestation are separate?

A: Because discovery tells you what exists, while attestation tells you what you believe is controlled. When those records are disconnected, teams can certify policies that no longer match production reality. The failure is structural: governance loses evidential value when it cannot see the live asset state it is meant to govern.

Q: What are the signs that an AI compliance programme is not evidence-ready?

A: Common signs include shadow AI in business units, model records that do not match cloud reality, undocumented datasets feeding production systems, and access paths that security cannot trace to named owners. If the control team cannot prove who can reach the model and what data it uses, readiness is weak.

Q: Why do AI governance rules increase the importance of identity and access management?

A: Because AI rules depend on proving who approved use, who can change the system, and who can access the data it touches. IAM and IGA provide the audit trail for those questions. Without identity-linked ownership and entitlement control, organisations cannot demonstrate accountability when regulators request evidence of decisions or incidents.

Technical breakdown

Why AI inventory is the control foundation for the EU AI Act

The EU AI Act’s high-risk obligations are layered on top of an unstated prerequisite: you must know the AI assets you operate before you can classify, govern, or evidence them. Inventory is not a register for its own sake. It is the control plane that links systems to owners, data sources, deployment locations, and the identities that can invoke them. Without that relationship map, risk management becomes a document exercise detached from production reality.

Practical implication: Treat AI inventory as a live control, not a compliance spreadsheet.

How AI discovery tools and governance tools split the problem

AI security posture tools tend to find models, pipelines, and AI services, which helps with discovery but not with obligation tracking. Governance and compliance tools tend to manage policies and attestations, which helps with control intent but not with live asset context. The gap appears when discovery and policy are not connected by the same dataset, because conformity evidence then describes a system that may already have changed. That is why evidence quality depends on continuously reconciling assets, relationships, and control state.

Practical implication: Connect discovery output to governance evidence so controls are tested against current AI state.

Why AI governance now overlaps with identity governance and NHI control

AI systems rarely operate in isolation. They are reached by service accounts, API keys, workload identities, and embedded application permissions, which means the AI governance problem quickly becomes an identity governance problem as well. If an AI feature can be invoked by an untracked workload or a loosely governed token, the organisation may have the model listed but still lack control over who or what can use it. That is where AI inventory, NHI governance, and access oversight converge.

Practical implication: Include machine identities and access paths in every AI asset review.

NHI Mgmt Group analysis

Live AI inventory is now a governance control, not an asset-management convenience. The article is right to frame the inventory gap as the hidden dependency beneath risk management, logging, transparency, and oversight. If an AI system is not continuously known, those obligations become aspirational statements rather than testable controls. Practitioners should treat inventory freshness as a compliance boundary, not a reporting preference.

AI governance debt is forming where discovery and attestation are split. Discovery without evidence produces visibility without accountability. Attestation without live asset context produces paperwork without operational truth. That split is where many enterprise programmes will fail the EU AI Act in practice, because they will be able to describe policy intent while being unable to prove the state of the environment that policy is meant to govern. Practitioners need a joined-up model of assets, controls, and evidence.

AI inventory gap: this is the specific failure mode the delay exposes. The issue is not simply that organisations lack documentation. It is that they lack a current map of models, datasets, runtime dependencies, and reachable identities, so the control environment cannot keep pace with change. This same failure mode will recur across AI governance regimes unless teams make relationships first-class in their operating model. Practitioners should design for continuous reconciliation, not periodic discovery.

Machine identities are part of AI compliance scope whether the regulation names them or not. The article correctly points to the connective layer between models, data, and access. In most enterprises, that layer is carried by service accounts, API keys, and workload identities that are invisible to traditional compliance artefacts. Once those credentials are out of sight, AI governance becomes a subset of broader identity governance and PAM discipline. Practitioners should bring NHI controls into AI readiness planning.

ISO 42001 can structure governance, but it cannot compensate for missing asset truth. The article is right that policies, controls, and attestations matter, yet they depend on accurate underlying inventory and operational evidence. Standards help organise responsibility and repeatability, but they do not discover what an organisation has failed to register. Practitioners should anchor AI management systems in live telemetry and asset relationships, then map governance processes onto that state.

What this signals

AI governance debt is now an operating model issue. The teams most likely to struggle are not those that lack a policy document, but those that have not joined inventory, access, and evidence into one control loop. That loop has to cover models, data sources, and the identities that can invoke them, or the programme will remain fragile as the environment changes.

Continuous reconciliation will matter more than point-in-time readiness. A conformity assessment built from a snapshot will always lag the real environment in modern AI estates. Practitioners should expect the useful control boundary to move upstream into discovery, ownership, and access review, because that is where AI risk becomes visible enough to manage.

For practitioners

• Build a continuously updated AI inventory Track each model, dataset, AI service, owner, deployment location, and connected workload as a living record rather than a one-time register.
• Map AI controls to live evidence Tie each high-risk obligation to technical checks that validate current logging, transparency, oversight, and data governance state in production.
• Include machine identities in AI governance scope Review service accounts, API keys, tokens, and workload identities that can invoke or feed AI systems, then assign ownership and review cadence.
• Reconcile discovery and attestation views Use one operating model that compares what discovery finds with what governance records claim, then flag mismatches as compliance defects.
• Treat AI assets as part of the attack surface Classify AI systems alongside other production services so security reviews, access control, and monitoring include them by default.

Key takeaways

• The article shows that the EU AI Act delay mostly buys time for organisations that still need a live AI inventory, not for those already able to prove control state.
• The governance gap is broader than documentation because AI systems, datasets, and identities are often deployed outside central visibility.
• AI readiness will depend on continuous reconciliation between discovery, access paths, and evidence, not on a one-time compliance file.

Key terms

• 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.
• Conformity evidence: Conformity evidence is the structured record used to show that a system met required governance, safety, or regulatory conditions. For financial AI, that includes evaluation results, model versioning, policy mappings, and incident history. It must be traceable enough for auditors and compliance teams to verify.
• API Governance Debt: API governance debt is the accumulation of weak, inconsistent, or missing controls around how APIs are designed, approved, documented, secured, and retired. It creates hidden risk over time. Technically, it includes gaps in authentication, authorization, versioning, inventory, ownership, logging, and policy enforcement that make APIs harder to trust and govern.
• Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity control to the broader programmes that need durable operational evidence.