Article 26 asks for a name. You wrote a committee. Here's what to actually do:
Article 26 of the EU AI Act uses two words that break most compliance documentation. The four-part test that follows them is harder than it sounds.
I was reviewing the AI system register for a mid-size insurance firm in Hong Kong last month. They had done the scoping work. They had mapped their systems to the high-risk categories. They had a register.
Under “oversight mechanism” for their underwriting AI, they had written: “Risk Management Committee, with escalation to Group CRO as required.”
That entry fails the Article 26 test. Not because of the escalation language. Not because the Risk Management Committee is the wrong body. It fails because Article 26(2) says oversight must be assigned to “natural persons.”
Natural persons means a human being. First name, last name. Not a committee. Not a function. Not a title that rotates every two years when someone gets promoted.
The firm had done everything right except for the two words that define whether their documentation holds up to an audit. They were not careless. They had read the regulation. They had simply read it the way most compliance professionals read it: assuming that a well-structured committee with the right remit was sufficient evidence of human oversight.
It isn’t.
What Article 26 actually requires
The deployer obligations under Article 26 exist separately from the provider obligations under Article 14. This distinction matters and most firms get it wrong.
Article 14 says the AI system must be built so that a human can understand its capabilities and limitations, detect anomalies, remain aware of automation bias, correctly interpret outputs, and decide to disregard, override, or reverse the output. That is the system design obligation. It sits with whoever built or adapted the system.
Article 26(2) says something different. It says deployers — the firms actually using high-risk AI systems — must assign human oversight to natural persons who have all four of the following: the necessary competence, the necessary training, the necessary authority, and the necessary support.
Those four words are a test. Not a checkbox. Not a description of a committee’s mandate. They have to be documented, individually, for a named human being.
Competence means the person has to understand what the system can and cannot do. Not at the level of an engineer. But at the level of someone who can correctly interpret outputs and know when they are wrong. An oversight designation for someone who has never read the system’s technical description doesn’t satisfy this.
Training means there has to be a documented record. A date, a course, an assessment. Not “we briefed the committee in Q3.” A record for a specific individual showing they received specific training on this specific system.
Authority is the one that most firms don’t read carefully enough. The oversight person must have the authority to pause, intervene in, or override the system when it produces a harmful or erroneous output. Not the authority to escalate. Not the authority to flag for committee review. The authority to act. This is addressed directly in Article 26(5), which says deployers must suspend use of a system when they identify risks to health, safety, or fundamental rights.
The implication is that the named oversight individual has to be able to stop the system without calling a meeting first.
Support is the least discussed of the four. It means the person actually has the resources and infrastructure to exercise their oversight role. Access to the system’s logs. Access to the technical documentation. Time allocated to review outputs. An oversight role without support is a compliance document that no one actually uses.
The five patterns that fail
I have reviewed documentation at a number of regulated firms in this region since April. The same failure patterns appear repeatedly.
Naming a committee instead of a person. This is the most common. The reason firms do it is intuitive: a committee has more credibility, more permanence, more governance weight than any single individual. But Article 26(2) is explicit. The auditor asks for a name. A committee is not a name.
Naming a senior executive without halt authority. The Chief Risk Officer is named. The Chief Technology Officer is named. The position looks right. But when the auditor asks whether that individual has documented authority to suspend the system without additional approval, the answer is almost always no. Their authority runs through committee approval, escalation chains, or board mandate. None of those satisfy Article 26(5)’s requirement for the deployer to be able to suspend use when a risk is identified.
Competence gap undocumented. The named individual exists, the authority is documented, but there is no training record. The firm says the person understands the system because they were briefed in the quarterly risk meeting. That briefing is not a training record.
Confusing provider obligations with deployer obligations. If the firm bought a vendor AI system, the vendor’s documentation showing that an override capability exists satisfies Article 14. It does not satisfy Article 26(2). The vendor giving you a stop button doesn’t mean your firm has assigned a named person with the documented authority to use it.
Documentation that doesn’t reflect current state. The oversight designation was correct when written. But the person in the role left six months ago. Their replacement has not been formally designated, has not received the training, and has not had their authority documented. The file still shows the previous person’s name. Auditors check current state.
The financial services angle for HK/SG firms
Article 26 contains a provision that most HK and SG compliance teams have not yet applied to their EU AI Act work.
Article 26(9) says that if a deployer is subject to EU financial services law requiring internal governance, risk management, and internal control obligations, the monitoring obligations under Article 26 are “deemed to be fulfilled by complying with” those rules. In practice, this means that if your firm is a regulated financial institution with existing internal governance requirements, your monitoring documentation can align with those frameworks rather than creating a separate EU AI Act paper trail.
This does not eliminate the Article 26(2) requirement. The named person, the four-part test, and the halt authority all still apply. What the carve-out relieves is specifically the monitoring obligation — the ongoing check that the system is being used as intended. A firm that already has a senior individual responsible for AI oversight under MAS or HKMA requirements can use that same framework to satisfy Article 26’s monitoring requirement, if the documentation reflects the EU AI Act’s four-part standard.
For HK and SG firms with EU-resident clients: the HKMA and MAS both require human-in-the-loop controls with senior management accountability for AI-assisted decisions. MAS released AI risk management guidelines and the HKMA has set equivalent expectations for AI governance in financial services. A single named senior individual with documented stop-authority and a training record satisfies both the EU Article 26 test and the HKMA/MAS senior accountability principle. One document. Two regulatory bodies.
This alignment is achievable. Most firms have not yet structured their documentation to achieve it, because they are treating EU AI Act compliance as a separate workstream from their HKMA/MAS AI governance work. It doesn’t need to be.
What correct implementation looks like
A compliant oversight designation has five components. All five must be in place for a single named person.
First: a formal appointment. A written letter or board resolution naming the specific individual and assigning oversight responsibility for the specific system. Not the role. The person.
Second: a competence record. Evidence that this individual has reviewed the system’s technical description and understands its outputs. This can be as simple as a signed acknowledgement with a date, if the person has relevant background. It has to exist as a document.
Third: a training record. A completed training programme, with a date, specific to this system. The training can be brief. It has to be documented.
Fourth: documented halt authority. An explicit policy or authority matrix confirming that this individual can suspend the system without additional approval. This is not the same as having the general authority to make compliance decisions. It is specific to this system, and it must be explicit.
Fifth: active documentation of oversight activity. Evidence that the person is exercising the oversight role — reviewing outputs, monitoring system performance, logging observations. An appointment letter without activity logs is a designation that was never used.
For a firm with one high-risk AI system and documentation already in reasonable order, assembling these five components takes three to five days. For a firm building documentation from scratch, it takes longer because the training has to be designed and delivered, not just recorded.
The August 2 deadline is ninety days away. That is enough time to name the right person and build the documentation correctly, if the naming process starts in the next two weeks.
What to do before next week
Look up your current EU AI Act compliance documentation, or your internal AI governance documentation, for each system you have assessed as high-risk.
Find the oversight entry. Read it.
If it says a committee, a team, a function, or a job title without a human being’s name attached, you have a documentation gap.
If it names a person but cannot answer yes to all four of: competence documented, training recorded, halt authority explicit, active oversight demonstrated — you have a documentation gap.
If the named person has changed since the documentation was last updated, you have a documentation gap.
The fix is not complicated. It is specific. It requires naming the right person, assigning their authority formally, and building a paper trail that an auditor can follow. That work is easier to start now than it will be in July.
Reply if you want a quick read
I am doing a short async review of oversight documentation this week for a small number of firms. If you share your current oversight designation entry — which system, who is named, what authority is documented — I can tell you in one response whether it would hold up to an audit. No calls, no forms, no commitment.
Reply to this email with “OVERSIGHT” in the subject line. Include one paragraph describing your current oversight setup for your highest-risk system. I will reply within 48 hours with a plain-language assessment.
If I can see an easy fix, I will tell you exactly what to change. If the situation is more complex, I will say so.
The Wednesday issue covered the five scoping questions auditors ask first. This issue goes deeper into one of them. The previous issues are in the archive if you want to read them in sequence.
If this was useful, forward it to whoever your firm would designate as your AI oversight individual. That might start a useful conversation.
Until Saturday,
Dhruv.