An AI approval can rest on one promise, that a person reviews every output before anything happens. The approval names a role. It may say nothing about what that person sees, how much time they have or what happens when they disagree.
If the reviewer ends up confirming nearly everything the system recommends, the review exists on paper while the system makes the decision. This article calls that rubber-stamp oversight, which is the author’s label. The EU AI Act calls the tendency to over-rely on a system’s output “automation bias,” and both the Act and NIST’s AI Risk Management Framework treat human oversight as something to design, assign and support.
Note: statements attributed to a named source come from that source. Everything else, including passages marked “Interpretation,” is the author’s interpretation. The examples in this article are illustrative and do not describe any real organization or system.
A reviewer is not the same as oversight
Human review is an appealing control. A qualified person checks an automated output before it shapes a decision. It works only if that person forms their own view and acts on it.
Automation bias sits where psychology meets technology. The EU AI Act uses the term in Article 14(4)(b), discussed below, for a tendency of the people overseeing a system. A better model does not remove it.
Interpretation: a review step counts as oversight when the reviewer can understand the output, disagree with it and act on that disagreement. A name on an approval form shows that someone was assigned, and nothing more.
How a named reviewer drifts into approving by default
Consider an illustrative review step. An AI tool summarizes supplier contracts and suggests a risk rating, and a named reviewer signs off on the rating before it goes into the procurement file. Ordinary design choices can push that reviewer toward agreement.
- The suggested rating appears before the contract text, so the reviewer reads the contract as a check on an answer already given.
- The day’s volume, not the contract, decides how long each review takes.
- Agreeing takes one click. Disagreeing takes a written reason, a second sign-off or a conversation with a manager.
- Nobody told the reviewer where the system is weak, so there is nothing specific to look for.
None of these choices needs bad intent. Each is a reasonable local decision about workflow. Together they can turn a decision-maker into a confirmation step.
Interpretation: rubber-stamp oversight is often a design outcome rather than a personal failing. Asking reviewers to try harder will not fix a workflow that makes disagreement expensive.
What the EU AI Act says about human oversight
Article 14 is one of the requirements for high-risk AI systems set out in Chapter III, Section 2 of the Act. Providers of high-risk systems must “ensure that their high-risk AI systems are compliant with the requirements set out in Section 2” (Article 16(a)). Article 14(1) says high-risk AI systems “shall be designed and developed in such a way, including with appropriate human-machine interface tools, that they can be effectively overseen by natural persons during the period in which they are in use.”
Article 14(3) describes two types of oversight measure, which can be used alone or together. Some are built into the system by the provider, when technically feasible. Others are “identified by the provider before placing the high-risk AI system on the market or putting it into service and that are appropriate to be implemented by the deployer.” Article 13(3)(d) requires the instructions for use to include “the human oversight measures referred to in Article 14,” along with technical measures that help deployers interpret outputs.
Article 14(4) says the system must be provided to the deployer in such a way that the people assigned to oversight are enabled, “as appropriate and proportionate,” to do several things. Interpretation (paraphrase of points (a) to (e)): they should be able to understand the system’s relevant capacities and limitations and monitor its operation, interpret its output correctly, decide not to use the system or to “disregard, override or reverse” its output, and intervene in its operation or interrupt it through a stop button or a similar procedure. Point (b) addresses automation bias directly. It asks that these people be enabled “to remain aware of the possible tendency of automatically relying or over-relying on the output produced by a high-risk AI system (automation bias), in particular for high-risk AI systems used to provide information or recommendations for decisions to be taken by natural persons.”
Article 26 sets out obligations of deployers of high-risk AI systems. Article 26(2) states: “Deployers shall assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support.”
These are different duties held by different roles. Designing the system so that it can be overseen, and building or identifying the oversight measures, falls to the provider under Articles 14 and 16(a). The deployer’s duties include assigning oversight to suitable people and supporting them, under Article 26(2).
Interpretation: these provisions apply to high-risk AI systems. According to the European Commission, the high-risk rules apply from December 2, 2027 for systems in the areas listed in Annex III and from August 2, 2028 for systems covered by Annex I. Whether a particular system is high-risk is a legal question. Read together, Articles 14(4) and 26(2) still describe a useful test for any review step. Can the reviewer understand the system’s limits, disagree with it and stop it? Do they have the competence, training, authority and support to do so?
What NIST’s AI RMF says
The NIST AI Risk Management Framework (AI RMF 1.0) does not use the term “automation bias.” It does treat human oversight as something an organization defines and documents. GOVERN 3.2 reads: “Policies and procedures are in place to define and differentiate roles and responsibilities for human-AI configurations and oversight of AI systems.” MAP 3.5 reads: “Processes for human oversight are defined, assessed, and documented in accordance with organizational policies from the GOVERN function.”
Appendix C of the framework, on human-AI interaction, goes further. It notes: “Some AI systems may not require human oversight, such as models used to improve video compression. Other systems may specifically require human oversight.”
The same appendix names the question at the center of rubber-stamp oversight. It says that “the degree to which humans are empowered and incentivized to challenge AI system output requires further studies. Data about the frequency and rationale with which humans overrule AI system output in deployed systems may be useful to collect and analyze.”
Interpretation: NIST presents this as an open research question, not a settled method. It still points in a clear direction. Whether reviewers can and will challenge output matters, and how often and why they overrule it is worth recording.
Design checks before naming a reviewer
The following checks are interpretation, offered as a starting point rather than a complete program.
- Decide what the review is for. NIST notes that some systems may not need human oversight. Where review is needed, state which errors it should catch.
- Give the reviewer the system’s limits. For high-risk systems, Article 13(3)(b) requires the instructions for use to cover “the characteristics, capabilities and limitations of performance of the high-risk AI system” among other information. Turn that into guidance the reviewer uses at the point of decision.
- Make disagreeing as easy as agreeing. Use the same steps for both. Where the task allows, show the case before the recommendation.
- Size the time to the review, not to daily volume.
- Give real authority. The reviewer should be able to override, pause or escalate without asking permission first, and someone should own what happens next.
- Record overrides and reasons. Collect how often and why reviewers overrule the system, as NIST’s Appendix C suggests.
- Write the design down. An AI inventory entry can record who reviews, with what information and authority.
Oversight that fit at approval can stop fitting later. A reviewer’s sense of the system’s limits may not survive silent model changes or intended-use drift.
Conclusion
Human oversight is a set of conditions. For high-risk systems, the EU AI Act expects providers to build systems that the people overseeing them can understand, override and stop, and expects deployers to assign oversight to people with the necessary competence, training, authority and support. NIST’s AI RMF expects oversight processes to be defined, assessed and documented. Both ask for more than a name on an approval form.
For every AI system with a human review step, two questions are worth asking. Can the reviewer say no as easily as yes? And if they never said no, would anyone notice?
This article reflects the author’s personal views, not those of any employer, and interpretation of publicly available materials from NIST and the European Commission’s EU AI Act Service Desk, as available on October 21, 2026. It is not affiliated with or endorsed by either body and does not reproduce their full requirements. It is general information, not legal, compliance or certification advice, and reading it does not create any advisory relationship. Laws, guidance and application dates change. Refer to the official texts, including the EU AI Act as published in EUR-Lex, and get qualified advice before acting on how they apply to your organization.
Sources: NIST, AI Risk Management Framework (AI RMF 1.0), NIST AI 100-1, https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf; European Commission AI Act Service Desk, Articles 13, 14, 16 and 26, https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-13, https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-14, https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-16 and https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-26; European Commission, AI Act, https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai