When deploying autonomous or agentic procurement tools, organizations often fall into the trap of applying a single restrictive setting across every workflow, resulting in oversight that is too heavy for routine tasks and too light for complex decisions. Effective autonomous sourcing oversight cannot be treated as a binary switch or a rigid maturity ladder; instead, it requires a graduated approach calibrated to how expensive a mistake is to undo. In this guide, we break down the four levels of human oversight, how to weigh regulatory boundaries, and how to calibrate intervention gates to protect your operations without creating unnecessary delays.
TL;DR
- Set oversight by how expensive a mistake is to undo, not by how important the task feels.
- Four levels: notify, confirm on exception, review, and direct. Most policies name two and use one.
- In regulated settings, weight oversight at the boundary where actions have externally examinable consequences.
- Measure interventions rather than incidents. A review gate that approves everything unchanged is a delay, not a control.
Set oversight by how expensive the mistake is to undo, not by how important the task feels.
Every autonomous sourcing decision sits somewhere between fully automatic and fully reviewed, and most organizations pick a single setting for everything. That is why oversight ends up simultaneously too heavy for routine work and too light for the decisions that matter. Reversibility is the variable that sorts them, and it sorts them cleanly enough that most of the policy writes itself once you accept it.
This is written for procurement leaders defining an oversight policy before deploying agentic capability, particularly in regulated environments where the policy will be examined. Wider AI governance research sets the context.
What are the levels of human oversight?
Four, set out in Figure 1, and the distinction between them is who acts and when. They are not a maturity ladder, and treating them as one leads organizations to aim for the lightest level everywhere, which is exactly the failure the policy exists to prevent.
- Notify. The system acts and tells a human afterward. Oversight is retrospective and the human intervenes only if something looks wrong.
- Review. The system prepares an action and a human approves before it executes. Oversight is a gate.
- Confirm on exception. The system acts autonomously within defined bounds and escalates only when a condition is met, such as a value threshold or an unrecognized supplier.
- Direct. The human decides and the system executes. Oversight is total and the system is a tool rather than an agent.
Most policies name two of these and use one. Naming all four is what makes it possible to assign different work to different levels, and assigning work by level is the entire point of having a policy. A single setting applied everywhere is not a policy, it is a default nobody chose.
Figure 1: Four levels, ordered by how expensive the mistake is to undo.
Which level does a task need?
Ask what it costs to undo the action after it has happened. Not whether it can be undone in principle, but what undoing it actually involves, who has to be told, and whether anyone outside the organization learns of it.
A supplier record enriched incorrectly is corrected in minutes and nothing downstream depends on it yet. That is a notify task. A purchase order issued to the wrong supplier has created an external commitment, and undoing it means a conversation with a counterparty. That is a review task at least. The transaction sizes could be identical and the correct oversight level would still differ.
The test is not the value of the transaction. A low-value order that commits the organization to a new supplier under new terms is less reversible than a high-value order against an existing contract, and reversibility is what should set the level.
Applying this consistently usually moves more work to lower oversight than expected, and a small number of tasks to higher oversight than the current policy applies. Both movements matter, and only the second gets discussed.
What does oversight look like in regulated sourcing?
Heavier at the boundary, not heavier everywhere. This is a design choice that has to be made explicitly, because the default under scrutiny is to review more of everything.
In healthcare and other regulated settings the binding question is which actions have external consequences that a regulator, auditor, or counterparty can examine. Executing a contract, sharing data with a supplier, and committing to a clinical product all cross that boundary. Drafting, summarizing, comparing, and preparing do not. That line is usually easy to draw once someone is asked to draw it, and it is almost never drawn without being asked.
The common error is applying regulated-grade oversight to the preparation because it feeds the decision. That is a real relationship and it is not a reason to review a draft with the same rigor as an execution. Review the crossing, not everything upstream of it. Oversight applied evenly is oversight diluted, since every review receives less attention when everything is reviewed.
Gartner was assessing agent governance across enterprises generally rather than sourcing specifically. The finding bears directly on this piece because the failure it describes is the one the four levels exist to prevent: a single setting applied to every action, discovered to be wrong only after something has already gone into production.
The AMA was measuring physician sentiment on clinical AI rather than procurement oversight design. The bearing on this piece is that the preferred involvement is itself graduated: consulted and responsible are two different levels, named by the people subject to them, which is the same distinction the four levels above make between review and direct.
What must the policy state explicitly?
Four things, and the fourth is the one that gets left out. All four should be written before deployment rather than assembled afterward from what the system turned out to do.
Which actions sit at which level, with reversibility as the stated reason. What triggers escalation from one level to another. Who holds the authority to change a level, and how that change is recorded. A policy that can be altered without a record is not a control, whatever it says on the page. And what happens when the system is uncertain rather than wrong.
That last one matters because uncertainty is not an error condition. Figure 2 shows the shape this should produce. A system that cannot classify a request should have a defined path, and if the path is undefined the request either stalls silently or gets forced into the closest category, which is worse. Defining the uncertain path is usually a ten-minute decision that nobody makes because uncertainty does not appear on a risk register.
Figure 2: Escalation is the exception by design, not a gap in coverage.
How do you review whether the levels are right?
Measure interventions, not incidents. Incidents are rare enough that their absence tells you very little, whereas intervention rates move continuously and are already being recorded.
For each task at notify or confirm-on-exception, count how often a human intervened after the fact. Near-zero intervention over a meaningful period suggests the oversight is heavier than the risk warrants. Frequent intervention suggests the level is wrong or the bounds are drawn incorrectly, and the second is more common than the first. Bounds set at deployment rarely survive contact with real request variety.
For each task at review, count how often the human changed the prepared action. A review gate that approves everything unchanged is a delay wearing the costume of a control, and it is worth retiring rather than defending. Retiring it also frees attention for the gates that genuinely need it.
Properly managing autonomous sourcing oversight means moving away from a one-size-fits-all approach and concentrating human review where actions create external, hard-to-reverse commitments. By defining clear escalation triggers, measuring actual human interventions rather than rare incidents, and matching oversight levels to task reversibility, procurement teams can protect compliance while maintaining process speed. Ready to implement autonomous sourcing within defined, transparent governance?
Request a demo today to see how Merlin Autonomous Sourcing balances full automation with robust human control.
Frequently asked questions
1. What is human-in-the-loop oversight in procurement?
Human-in-the-loop oversight means a person is involved in an automated decision process, either by approving actions before they execute, reviewing them afterward, or being escalated to when defined conditions are met. It is a spectrum rather than a binary, and the useful policy question is which level applies to which task.
2. How much oversight does agentic sourcing need?
It depends on the reversibility of each action rather than on the value or perceived importance of the task. Actions that are cheap to undo need light oversight. Actions creating external commitments that require a counterparty conversation to reverse need a gate before execution.
3. What is the difference between human-in-the-loop and human-on-the-loop?
Human-in-the-loop generally means a person approves before an action executes. Human-on-the-loop means the system acts and a person monitors, intervening when something appears wrong. The first is a gate and the second is supervision, and they suit different levels of reversibility.
4. Should every AI action in procurement be reviewed?
No, and doing so usually produces worse oversight rather than better. Reviewing everything means each review receives less attention, so the decisions that genuinely need scrutiny get the same cursory look as routine ones. Concentrating oversight where actions are hard to reverse is more protective than spreading it evenly.
5. How does oversight work in regulated industries?
Heavier at the boundary where actions have externally examinable consequences, such as contract execution, data sharing with suppliers, and commitments to clinical products. Preparation activities that feed those decisions do not need the same rigor, even though they influence the outcome.
6. What should an AI oversight policy include?
Which actions sit at which oversight level and why, what triggers escalation between levels, who can change a level and how that is recorded, and what happens when the system is uncertain rather than wrong. The last is the most commonly omitted and the most likely to cause a silent stall.
7. How do you know if your oversight level is correct?
Measure how often humans actually intervene. Near-zero intervention on reviewed tasks suggests oversight heavier than the risk warrants. A review gate that approves everything unchanged is functioning as a delay rather than a control. Frequent intervention suggests the bounds are drawn in the wrong place.
8. Who should own the oversight policy?
Procurement should own which actions sit at which level, since that is a judgment about commercial and operational risk. Compliance or legal should own the definition of which actions have externally examinable consequences. Splitting it this way avoids the common failure where neither function owns the boundary itself.
