Most agree that humans must be able to control AI in the enterprise. The disagreement arises when it has to be put into practice: what must the system do itself? This article provides a concrete level model that makes the conversation and design precise.
In this article
The short answer
"Human-in-the-loop" means that a human is involved in the decision before or while the AI is doing work. But as a requirement, the sentence is too imprecise: it does not say when, where and with what responsibility man enters.
A useful model divides the agent's agency into four levels: read, propose, act with approval, and act within fixed limits. The level is selected per workflow based on impact and reversibility, not as one principle for the entire company.
Why "a human in the loop" is not enough
Two solutions can both be called human-in-the-loop and yet be very different. In one, an employee approves each action before it is carried out. In the second, an employee monitors a dashboard while the system acts itself, and can intervene afterwards. The difference in risk is huge, but the language hides it.
Therefore, the requirement should be formulated as a level of agency with associated control points, not as a principle in a policy. This makes the conversation between management, IT and the process owner concrete: what must the system do itself, what requires approval, and what must it never do?
The four levels of agency
Level 1: Read. The system retrieves and collates information from approved sources, but does not change anything. Typical use: search, status collection, control of documentation. The risk lies solely in access and confidentiality, and is managed with rights, data minimisation and logging.
Level 2: Suggest. The system prepares drafts, classifications or amendment proposals, which a human decides on. Errors become fixes, not incidents. This is where most pilots should start: the value can be measured on real tasks, while the consequence of failure is a bad draft.
Level 3: Act with approval. The system prepares a concrete action, and an authorised person approves the individual action and its consequence before it is carried out. Suitable for actions of real consequence: send, create, change. The approval must be informed: the person who approves must be able to see the basis, sources and expected effect.
Level 4: Act within fixed limits. The system performs pre-approved, limited and reversible actions itself, for example within amount limits, whitelisted recipients or certain object types. Anything outside the limit is stopped or escalated. The limits are defined in code and can be revised.
An imaginary example: invoice processing
Follow the four levels through one familiar workflow. At level 1, the solution reads the invoice and looks up the order, supplier and contract. At level 2, it proposes the account coding, accounting dimension and approver, then places the proposal in a queue. At level 3, an employee approves the posting of the individual invoice on an informed basis: match against order, deviations and history are visible. At level 4, recurring invoices from known suppliers within a fixed amount limit can be posted automatically, while everything else continues to be approved.
The sample is a pattern, not a product. The point is that the levels are not an either-or: a mature workflow typically uses all four at the same time, distributed according to consequence and reversibility per action type.
How to choose the level per workflow
Two questions decide most things. What is the consequence if the action is wrong: internal and small, or external and embarrassing, or irreversible and expensive? And can the action be undone: Can a draft be deleted or an entry rolled back, and can an email be stopped before it is sent?
Low impact and high reversibility point towards level 2 or 4. High impact or low reversibility point towards level 2 or 3, regardless of how good the model is. Critical, external or irreversible actions should basically require human approval.
Note that one workflow can accommodate several levels: the agent reads freely (level 1), suggests responses (level 2), sends routine responses within a narrow limit (level 4) and submits everything else for approval (level 3).
Control must be enforced by code, not by the prompt
A level is only real if it is enforced outside the free judgment of the model. The instruction "always ask before sending" is not a control; it is a hope. Enforcement must reside in deterministic control code: rights that do not provide write access at levels 1 and 2; an approval queue that actions must physically pass through at level 3; and technical limits with level 4 validation.
Added to this is traceability: who or what proposed, who approved, what was carried out and on what basis. An audit trail is not bureaucracy; it is the prerequisite for being able to expand the power of action later with a clear conscience.
Three typical objections
"Approvals become a bottleneck." Only if the queue is designed badly. Bundle approvals in sensible bundles, show the basis clearly, and move only those action types to level 4 where data shows that the proposals are still approved without change.
"People just click yes." It's a real phenomenon, and it's handled by design, not exhortation: show deviations rather than raw data, make the consequence visible, and use spot checks of approved actions as part of operations.
"Level 4 is too dangerous." Level 4 without limits is not level 4, but level 5: full autonomy, and we do not work with it in critical workflows. The very point of level 4 is that the limits are tight, defined in code, reversible and auditable.
A brief note on regulation
The EU AI Act requires human supervision for AI systems in high-risk categories. Most administrative workflows fall outside those categories, but the direction is clear: the greater the consequence, the more explicit the human responsibility must be. A level model like the one above makes that responsibility concrete and documentable, regardless of whether a system is covered or not.
Regardless of regulation, the organisational aspect applies: there must be a named owner of the solution, and the person who approves must have both the competence and the time to really assess, not just click yes.
Roles: who approves and who owns?
A tier model only works if the roles are named. The approver must have the professional competence to assess the action, the mandate to reject it and time for the task in his everyday life. The owner of the solution, often the process owner, is responsible for quality in operation, for sampling and for proposing changes to levels and limits.
Avoid the diffuse model where "the team" approves. When everyone approves, nobody approves and the audit trail loses its value because responsibility cannot be placed. One action type, one approver role, one owner.
Practical start-up
Start at level 1 and 2: read access to approved sources and proposals in a queue. Measure quality against a baseline and let validation data show where the system hits the mark. Then expand selectively: the actions where the proposals are consistently approved unchanged are candidates for Level 3 or 4, one action type at a time.
Write down the level choice per workflow along with limits, approvers and log. That document is small, but it is the difference between controlled operation and gradual drift.
Also read
Should your next AI solution be designed with clear control?
Describe the workflow and we suggest action level, approval points and logging as part of the solution design.
Evaluate a workflow →