EU AI Act - Governance Consultants
- The Act's substance is governance work, not legal work: risk management, data governance, human oversight, logging, monitoring.
- Human oversight is the requirement most often written as a sentence and least often built as a capability.
- Data governance under Article 10 reaches into how training, validation and testing data was assembled, which is an engineering task.
- Post-market monitoring runs for the life of the system, so the governance function has to be permanent.
- Governance work and legal classification are different jobs. Most programmes need both and buy only one.
What the governance workstream covers
Once a system has been classified, almost everything the EU AI Act requires is governance work. Risk management that runs. Data governance that reaches into how a model was trained. Human oversight designed around a real person. Logging that retains what the Act requires. Monitoring that continues after launch.
That work is not legal work and it is not purely technical work. It sits between the two, which is why it is the part most often left unowned.
| Requirement | What it means in practice |
|---|---|
| Risk management system (Article 9) | A continuous process across the system's lifecycle: identify foreseeable risks, evaluate them, adopt measures, test, and repeat as the system changes |
| Data governance (Article 10) | Training, validation and testing data examined for relevance, representativeness, errors and bias, with the examination documented |
| Technical documentation (Article 11, Annex IV) | A file describing the system, its development, its monitoring and its performance, kept current |
| Record keeping (Article 12) | Automatic logging over the system's lifetime, retained for an appropriate period |
| Transparency to deployers (Article 13) | Instructions that let a deployer understand the system's capabilities, limitations and correct use |
| Human oversight (Article 14) | Measures enabling a competent person to understand, monitor, override or stop the system |
| Accuracy, robustness, cybersecurity (Article 15) | Declared performance levels, resilience to error and to adversarial manipulation |
| Quality management (Article 17) | The system that makes all of the above repeat rather than happen once |
| Post-market monitoring (Article 72) | Active collection of performance data after deployment, feeding back into risk management |
The requirement most often missed
Human oversight is written as a sentence in most policies and built as a capability in very few.
The Act asks for measures that let a competent person understand what the system does, remain aware of automation bias, interpret its output, decide not to use it, and intervene or stop it. Each of those implies something concrete: the person needs training, they need time, they need visibility of the output before it takes effect, and they need the authority to override without a committee.
The failure mode is a named overseer who is already fully occupied, who sees the output only after it has been acted on, and whose override would need sign-off from someone senior. On paper the requirement is met. In practice nobody is overseeing anything, and that becomes apparent the first time something goes wrong.
Designing this properly is governance work, and it usually means changing a process rather than writing a document.
Data governance is an engineering task
Article 10 asks questions about data that were never asked when most models were built. What was the data collection process. What assumptions were made about what the data represents. Is it relevant, sufficiently representative, and as free of errors as possible for the intended purpose. What gaps or shortcomings exist and how are they addressed. What bias examination was carried out.
Answering these for a model trained two years ago by people who have since left is a real piece of work, and it is the reason data governance is often the longest item in a build.
Where the model was bought rather than built, the questions transfer to your supplier, and your contract may or may not give you the right to ask them. Checking that is worth doing before the technical file is due rather than after.
Governance and classification are different jobs
Classification is a legal judgement about which tier a system falls in. Governance is the operational work that follows.
Most programmes buy one and assume the other. Organisations that start with a law firm often end up with a defensible classification and no technical file. Organisations that start with a platform often end up with an organised register and no decisions in it.
The practical answer is to know which you are buying and to assign the other deliberately. Our implementation service covers the governance build, and where a classification is genuinely borderline we say so rather than presenting a marginal call as settled.
How this relates to ISO/IEC 42001
ISO/IEC 42001 is the management system standard for AI. Its structure maps closely onto what the Act's high-risk duties require: policy, roles, risk assessment, impact assessment, controls, internal audit, management review and continual improvement.
An organisation that implements ISO/IEC 42001 has built most of the governance substance the Act assumes, and turns the Act's documentation requirement into a mapping exercise rather than a writing exercise. It is voluntary and it does not make you compliant on its own, but it is the most efficient route for any organisation that will hold high-risk systems. See our ISO/IEC 42001 service page.
Why the function has to be permanent
Post-market monitoring is not a phase. It is an active duty to collect and review performance data across the life of the system, feed it back into risk management, and update the technical documentation so it describes the system as it currently is.
Add serious incident reporting, models that get retrained, and new systems arriving through ordinary business growth, and the work does not have a completion point. That is why the governance owner matters more than the build supplier, and why our continuous governance and assurance service exists.
What to do next
Name the person who owns AI governance in your organisation and check they have the time. If the answer is unclear, that is the first gap, and it is the one that makes every other gap harder to close.
Our free AI impact assessment gives a first view, and the EU AI Act service page sets out how we build the governance workstream.
References
FAQ
What does an AI governance consultant do for the EU AI Act?
Builds the risk management process, the data governance evidence, the human oversight design, the logging, the technical documentation and the monitoring that the Act requires after classification.
Is human oversight just naming someone?
No. The named person needs competence, time, visibility of output before it takes effect, and authority to override. A name without those does not meet the requirement in substance.
Does Article 10 apply to models we bought?
The provider carries the data governance duty. If you have become a provider by rebranding or modifying a bought system, it transfers to you, and your supplier contract may not give you the information you need.
Does ISO/IEC 42001 satisfy the AI Act?
No, but it builds the governance substance the Act assumes and makes the documentation work substantially smaller.
When does the governance work end?
It does not. Post-market monitoring and incident reporting run for the life of each system.
About Hael
Hael is an advisory firm specialising in AI governance and security compliance. We do the work rather than only advising on it: risk management, data governance, human oversight design, documentation and monitoring, across the EU AI Act, ISO/IEC 42001, SOC 2 and ISO 27001. On engagements involving regulated financial services firms we work alongside Buckingham Capital Consulting, the partner firm that has advised payment and e-money firms on authorisation and compliance since 2013.
This guide is general information and is not legal advice on your particular circumstances.