The EU AI Act Deadline Is Here and Why Compliance Without Governance Will Fail – Part 2
- 3 hours ago
- 7 min read
Naómi Oosthuizen is the Founder and Managing Partner of Sentio™, specialising in cybersecurity, AI governance, digital resilience, and board-level risk management across Europe. She writes about the intersection of technology, governance, regulation, and human decision-making.
This is Part 2 of a three-part series on the EU AI Act's 2 August 2026 deadline. Part 1 covered what the Act requires and what changed under the Digital Omnibus, Part 3 covers the evidence regulators will expect and five questions for your board.
An extension buys time and nothing else. It will be worth very little to any organisation that arrives at December 2027 still unable to say where artificial intelligence sits inside the enterprise, who owns it, and what evidence the board has every right to demand. The temptation is to run a legal exercise against the date, produce a policy, and call the matter closed. That instinct is understandable, administratively convenient, and strategically dangerous.
The National Institute of Standards and Technology organises artificial intelligence risk work around four functions, govern, map, measure, and manage. Governance is designed as a cross-cutting function that informs and is infused throughout the other three, rather than as an approval gate bolted onto the end of a development pipeline.[6] Organisations that begin with classification tend to end up knowing precisely which tier a system occupies while remaining entirely unable to say whether building it was a sound decision in the first place.
The same framework makes a point that compliance programmes routinely miss, in my experience. It is voluntary and outcome-based, and it does not prescribe risk tolerance, stating instead that tolerance is highly contextual and must be set by the organisation itself, informed by legal requirements but not determined by them.[6] Regulation tells you the floor. Governance tells you the appetite, and the gap between the two is where most reputational damage occurs. Artificial intelligence risk therefore belongs alongside cybersecurity and privacy inside enterprise risk management rather than being quarantined in a new committee, which is exactly what the framework recommends.
Can you produce a complete and current AI inventory?
The first practical requirement is a living inventory. NIST asks for mechanisms to inventory artificial intelligence systems, resourced according to the organisation's risk priorities, together with processes for decommissioning and phasing systems out safely.[6] It stops there because it is outcome-based guidance rather than a data schema, so what follows is my recommendation rather than an obligation the framework imposes.
Security has already been through a version of this argument. When software supply chains became indefensible, the answer was the software bill of materials, and the artificial intelligence equivalent now exists in two forms, the CycloneDX machine learning bill of materials maintained by OWASP and the AI and Dataset profiles introduced in SPDX 3.0. Both describe what a system is made of, the model, its architecture, the datasets it was trained on, its configuration, its licences, and its known limitations. Both are useful, and any organisation buying models rather than building them ought to be asking its suppliers for one. Neither, however, is a governance inventory. A bill of materials tells you what is inside a system. It does not tell you who answers for it when it fails, whose risk appetite it sits inside, or which named human is supposed to be able to stop it. Those fields do not exist in either standard, and no amount of automation will conjure them because they are organisational facts rather than technical ones.
An inventory therefore earns its place only if it covers internally developed models, embedded functionality inside purchased products, employee use of public tools, automation introduced by suppliers, and the components buried inside cloud platforms that nobody deliberately procured. In my experience, each material use case also needs to record a named business owner, a technical owner, a data owner, a risk classification, a stated purpose, an assessment of who is affected, its vendor dependencies, its decision impact, and its lifecycle status. Without those fields, the register can tell you that a system exists. It cannot tell you who answers for it.
Yes, a spreadsheet can serve as an interim mechanism, but it is not a governance architecture, and the difference between the two is connection. The inventory has to be wired into procurement, architecture review, data governance, change management, incident management, third-party risk, and retirement because an inventory that is not connected to the processes that change the estate is a historical document describing an organisation that no longer exists. An organisation that has done this properly can detect the moment a vendor swaps out a model beneath a product it has already assured, the moment a use case starts consuming a new category of personal data, the moment human oversight is reduced to clear a backlog, and the moment a pilot becomes production without anyone declaring it. NIST treats this as a third-party problem as much as an internal one, asking that risks arising from third-party resources be monitored regularly and that pre-trained models used in development be monitored as part of ordinary maintenance.[6]
Who is accountable when an AI system behaves unexpectedly?
The board does not need to approve every model, prompt, or configuration, but it does need clarity on decision rights. Management defines which artificial intelligence decisions can be taken inside a business unit, which require independent risk review, which require executive approval, and which sit outside risk appetite altogether. Escalation then follows impact rather than novelty, since a technically unremarkable tool touching employment, credit, health, safety, or public rights deserves considerably more scrutiny than a sophisticated system summarising internal meeting notes.
This is where artificial intelligence committees typically fall short. They convene representatives from legal, privacy, cyber, data, technology, and the business, and in doing so, they distribute accountability until it dissolves. A committee can coordinate, challenge, and advise, but it cannot accept a risk, and it cannot be held to account for an outcome. NIST places executive leadership responsibility, clear roles, and documented lines of communication at the centre of effective governance, asking that executive leadership take responsibility for decisions about the risks associated with development and deployment, and that roles and lines of communication be documented and made clear across the organisation.[6] Good governance names the person who owns the business outcome, the person who controls the technology, and the independent function whose job is to ask whether the evidence is sufficient and to be unpopular when it is not.
What does meaningful human oversight actually look like?
The phrase human-in-the-loop has become a reassuring abstraction, invoked in board papers as though the presence of a person were itself a control. The Act is a tad less romantic about it. Deployers of high-risk systems must assign human oversight to a person within the organisation, and that person must be sufficiently equipped and enabled to exercise it, which is a rather higher bar than nominating a reviewer and hoping.[3] Meaningful oversight requires an individual with the authority to stop the process, the information to understand what the system has done, the competence to recognise when it is wrong, and, less romantically but no less importantly, the time to look. A reviewer who cannot see the model’s limitations, cannot access the relevant context, or is measured primarily on throughput is not oversight. That reviewer is a signature.
NIST is quite blunt about why this fails in practice. NIST warns that people may assume artificial intelligence systems work, and work well, in all settings, and that such systems are often perceived as more objective than humans or as more capable than ordinary software, whether or not that perception is correct. It goes further, noting that, in certain conditions, the artificial intelligence element of a human-machine pairing can amplify human bias, producing decisions more biased than either the person or the system would have produced alone.[6] Oversight designed without that in mind is not a safeguard. It is a formality that manufactures false confidence.
The remedy is to design oversight rather than declare it, and to document it. The framework asks that processes for human oversight be defined, assessed, and documented in line with organisational policy, and that personnel and partners receive risk-management training sufficient to perform their duties.[6] Training follows the role rather than the organisational chart. A board member needs to understand risk appetite and accountability, a product owner needs to understand purpose, impact, and monitoring, an engineer needs to understand secure development and model risk controls, and an end user needs to know what the tool cannot do, what must be disclosed, and what is simply not permitted. There is a further reason to take this seriously. Where the output of a high-risk system has been used to take a decision producing legal effects for a person, that person has a right to a clear and meaningful explanation, and an organisation whose oversight exists only on paper will not be able to give one.[3]
Part 3 covers what evidence regulators, auditors, and boards will accept, five questions for your board before August, and a frequently asked questions section.
Read more from Naómi Oosthuizen
Naómi Oosthuizen, Interim Specialist, CISO & CIO
Naómi Oosthuizen is the Founder and Managing Partner of Sentio™, a European cybersecurity and governance advisory firm. With more than two decades of international leadership experience across financial services, government, and critical infrastructure, she specialises in cybersecurity, AI governance, enterprise risk management, and digital resilience. Through her writing, she explores the future of technology, governance, organisational behaviour, and digital trust.
References:
[1] Deloitte. (2024). EU Artificial Intelligence Act: Deep dive. Deloitte.
[2] European Commission. (2026a). Code of practice on transparency of AI-generated content. Shaping Europe's Digital Future.
[3] European Commission. (2026b). Navigating the AI Act: Questions and answers. Shaping Europe's Digital Future.
[4] European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/1689 of 13 June 2024 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, L, 2024/1689, 12 July 2024.
[5] European Parliament and Council of the European Union. (2026). Regulation (EU) 2026/1744 of 8 July 2026 amending Regulations (EU) 2024/1689, (EU) 2018/1139, and (EU) 2023/1230 as regards the simplification of the implementation of harmonised rules on artificial intelligence (Digital Omnibus on AI). Official Journal of the European Union, L, 2026/1744, 24 July 2026.
[6] Tabassi, E. (2023). Artificial intelligence risk management framework (AI RMF 1.0) (NIST AI 100-1). National Institute of Standards and Technology.
