Picture a Friday, 5:40 p.m. An AI agent in the accounts payable team is processing an invoice from a long-standing supplier. Amount: PLN 380,000. Everything checks out - except the bank account number, which differs from the one in the contract. The agent has thousands of cases in its training data where suppliers changed accounts legitimately. It classifies the discrepancy as low risk and prepares the payment for execution.
Who should be notified at that moment? In a well-designed process - a specific person, with full context, before anything leaves the company. In many deployments we see on the market - nobody. Because the agent’s autonomy was configured as a default property, not as a decision that somebody consciously made and constrained.
This article is about that decision. It is called a human-in-the-loop gate - HITL gate for short - and in our view it is the most important element of agentic architecture in 2026. More important than the choice of model.
Autonomy is not a model feature. It is an architectural decision
Conversations about AI agents are dominated by the question “what can the agent do”. That is a demo question. The production question sounds different: what is the agent not allowed to do on its own, and who approves the rest.
The difference is fundamental. The language model that powers an agent has no concept of accountability. It generates next steps based on context and - as we show below - can announce success with full conviction without having run any verification. Accountability has to be built one layer up: in process orchestration and in platform policy.
Regulation says the same thing in a different language. Article 14 of the AI Act requires effective human oversight of high-risk systems - and on 2 August 2026, two weeks from now, the next wave of obligations under that regulation takes effect. For organisations covered by NIS2 and DORA there is an additional auditability requirement: every decision of a system that touches data or money must leave a trail you can show an auditor. “The agent decided so on its own” is not an entry in an event log. It is the beginning of a very difficult conversation.
We wrote about this more broadly in our piece on governed autonomy - if more than one agent is already running in your organisation, that article is a good starting point. Today we go one level down: to the concrete mechanisms in the UiPath platform.
Anatomy of a HITL gate
A human-in-the-loop gate is a point in the process where the agent stops and waits for a human decision. The definition sounds trivial. The devil sits in three design questions.
When does the gate open? Not at every step - a process in which a human approves everything is slower than manual work and nobody will sustain it. The gate stands at high-risk intersections: a payment above a threshold, a change of counterparty data, an action on a production environment, a decision concerning a person (a complaint, a claim, a loan application). The catalogue of those intersections is the first thing we write down with a client - before configuring anything.
Who decides? A role, not a person. With a clear escalation path when the first addressee does not react within the allotted time, and with an SLA limit after which the process does not hang in a vacuum but moves to a defined safe state.
What does the decision-maker see? This is the question most often skipped. A person who receives a bare message saying “the agent proposes a payment, approve?” is not exercising oversight. They are clicking. The gate makes sense when it provides context: what the agent established, on what basis, what deviates from the norm and what the consequences of either decision are. And when the decision itself lands in the audit log together with that context.
These three questions are universal. In the UiPath ecosystem the answers live in two places: in orchestration (Maestro, Action Center) and in the governance layer (AI Trust Layer). Let us walk through both.
Maestro: the human as a participant in the process, not an exception to it
UiPath Maestro is the orchestration layer for agentic processes - we covered it when it entered the market. From a HITL perspective one property matters most: in Maestro the human is a first-class participant in the process, on a par with the RPA robot and the AI agent. A human stage is modelled the same way as an automated one: it has an input, an output, success criteria, a time limit and an escalation path.
That sounds like a notation detail, but it changes the way of thinking. In classic RPA deployments the human appeared in the process as exception handling - something went wrong, an e-mail flies to the team. In an agentic process designed in Maestro the human appears where the process requires it by definition: at the gate.
In practice it looks like this. The invoice-handling process from our example has four stages in Maestro. First: the agent analyses the document and compares the data against the contract and the supplier’s history. Second: a transactional robot posts the entry in the ERP system - deterministically, repeatably, with a full log. Third: everything the agent flagged as a deviation goes to Action Center, where a controller sees the invoice, the discrepancy and the agent’s recommendation side by side and makes the decision. Fourth: notifications and closing the loop. The bank account change from our opening scene has no way of bypassing stage three - regardless of how confident the agent is in its classification. We will come back to that “regardless”, because it is the most frequently broken element of the whole puzzle.
In our architecture reviews we treat this as binary: a Maestro pipeline that has no human escalation point for high-risk stages gets a critical status and does not proceed to deployment. Not because we enjoy blocking projects. Because that gap always comes to light - the only question is whether at the review or in production.
A second example, closer to our SAP projects. An agent supporting a Basis team analyses tickets and proposes changes: unlocking a user, correcting a parameter, transporting a fix between environments. Unlocking an account in a test system can go through automatically, with a log entry. A transport to the production environment - never. In Maestro that difference is simply two different process paths: one goes through a human stage, the other does not. The agent does not have to “understand” why production is different. The process knows it on the agent’s behalf.
The mechanics of the human stage in Maestro also deserve credit, because they decide whether the gate survives contact with everyday reality. The stage has a time limit - when the controller does not decide within the given window, the case escalates to the next role or the process moves to a defined safe state, for example holding the payment pending clarification. It also has an explicit data flow: everything the agent established in earlier stages travels to the Action Center task as decision context, and the decision returns to the process as ordinary input data for the next stage. Thanks to this, six months later you can reconstruct not only what the human decided, but exactly what they knew at the moment of the decision. In a dispute with a supplier or a question from an auditor, that difference is priceless.
Michał Korzeń, CTO of SNOK, puts it from a project perspective: “In agentic projects the hardest part is not teaching the agent to act. The hardest part is deciding when it has to stop. For us, around 70 percent of the conceptual work is defining gates, escalations and guardrails - the agent itself is the rest.”
Agent Builder and Coded Agents: escalation built into the agent
Gates at the process level are one layer. The second is built into the agent itself.
An agent built in Agent Builder (low-code, Studio Web) has escalation points as part of its definition: when it hits a situation outside its scope or when a guardrail raises an issue, it routes the case to Action Center, to a Teams or Slack channel - to a human, with context. In our review, an agent without a defined escalation for high-risk decisions is, again, a critical finding.
Coded agents (Python, LangGraph) have an equivalent in the form of interrupt points: the agent halts execution at a defined point in the graph, waits for approval and resumes exactly where it stopped. This matters technically - the process can wait for a human for hours without holding resources and without losing state.
The third mechanism is guardrails, and here it gets interesting, because a guardrail can be a gate in its own right. The UiPath platform distinguishes three layers: guardrails built in at the agent level (detection of prompt attacks and prompt injection, personal data, harmful content, and intellectual property protection), central policies enforced by Automation Ops across the whole platform (in public preview since the end of May 2026), and custom guardrails at the level of a single tool, with rules and regular expressions. Each of those rules has an assigned action - and next to “block” and “log” there is an “escalate” action, which routes the case straight to Action Center. A guardrail with an escalate action is a mechanical HITL gate: it requires nobody’s memory or goodwill, it simply fires.
AI Trust Layer: the gate needs a foundation
Everything above happens at the level of the process and the agent. Underneath works a layer that we describe to clients as the foundation of the whole structure: the UiPath AI Trust Layer.
The AI Trust Layer is the central point of control for all generative AI traffic in the platform. Every request to a model - from an agent, from Autopilot, from Document Understanding, from GenAI activities - follows the same path: authentication, policy enforcement, optional masking of personal data, routing to the model and an entry in the audit log. That path cannot be bypassed from inside the platform. And that is its entire value.
For designing HITL gates, three elements of the AI Trust Layer have practical significance.
The audit log. Every AI action leaves an entry: who, when, from which product, with which model, with what result - including the status “blocked by policy”. Since the end of May 2026, OpenTelemetry export also covers guardrail evaluation results, so you see not only what the agent did, but also what it tried to do and what stopped it. The human’s decision at the gate plus this log together form the evidence an auditor for DORA or NIS2 expects. We saw how strong the hunger for this kind of visibility is in the public sector at the PWCyber webinar - we wrote about it in our report from the session for KSC entities.
Masking personal data in flight. In-Flight PII Masking pseudonymises personal data in the prompt before it leaves the environment and reaches the model. Since the June platform update, masking also covers files downloaded by the agent, which closes a significant gap for agents processing documents. One caveat from practice: masking changes the content the model sees, so it can change the quality of answers. Test the process with masking enabled before a broad rollout, not after.
Your own model instead of a managed one. The AI Trust Layer lets you connect a model on your own subscription or in your own infrastructure: Azure OpenAI, AWS Bedrock, Google Vertex, any endpoint compatible with the OpenAI standard, and since version 25.10 also self-hosted models via NVIDIA NIM. For regulated clients this is not a catalogue option but a condition of entry - data cannot flow to a model over which you have no contractual and technical control. The June update added Claude Opus 4.7 and GPT-5.5 to the selection, which is a timely reminder of a less comfortable truth: models change, and every model change means a mandatory return to the agent’s regression tests.
One thing we want to say plainly, because the market likes to confuse it: the AI Trust Layer is a platform layer, not an exemption from thinking. Platform governance will not design the gates in your process for you, will not decide which action is high risk, and will not review the agent’s prompts for vulnerabilities. Both layers are needed. The platform layer without the process layer gives you audit without control. The process layer without the platform layer gives you control without evidence.
The trap most teams fall into: “we will bring in a human when the agent’s confidence drops below 80%”
This idea comes up in almost every design workshop. It sounds reasonable: the agent knows its confidence, so let low confidence open the gate and high confidence allow it to act on its own. An elegant threshold, a single number, a ready-made slide.
The problem is that for an agent’s decision, that number does not exist.
A language model has no calibrated indicator of the correctness of its own decisions. What gets presented as “confidence” is in reality one of three entirely different signals: next-token probabilities (which can be high during hallucinations), the model’s own declaration along the lines of “I am 95 percent sure” (dependent on how the question is asked and systematically inflated by models trained on user preferences), or the output of a separate evaluation mechanism, for example a document extraction classifier. Only the third is suitable for thresholding - and only after calibration on your data, separately for each field and task. Research on model calibration has shown this for years: declared confidence and actual accuracy are two different curves, and the gap between them has to be measured before anything is built on it.
In the UiPath ecosystem this distinction translates very concretely. Confidence from Document Understanding for invoice field extraction is a real signal - the classifier returns a score per field, and after validation on a historical sample you can base a threshold on it that routes the document to Action Center. Guardrail thresholds in the AI Trust Layer are also real signals, but with different semantics: they measure content risk, not decision correctness. But the agent’s “confidence” that an entire multi-step decision is right? The platform has no native, calibrated indicator for that - and frankly, nobody has one today.
That is why at SNOK we apply a rule that clients remember better than many a methodology: the HITL gate opens on a low score OR on a high-risk action, regardless of the score. A change of a counterparty’s bank account goes to a human always. Even if every indicator glows green. The risk of an action is a property of the action, not of the model’s mood.
And one more thing, because it keeps coming back in compliance conversations: a confidence threshold is not human oversight within the meaning of Article 14 of the AI Act. Oversight means a person who understands what they are approving, has a real ability to refuse, and leaves a record of the decision. A number on a screen will not replace that.
Jarosław Zdanowski, the partner responsible at SNOK for SAP cybersecurity, looks at it from the audit side: “The regulator will not ask how advanced the model was. They will ask who approved this specific decision, on what basis, and where the record is. If the answer is: the agent rated its own confidence at 93 percent - that is not the answer you want to give first.”
Autonomy grows in stages - and every transition is a gate too
There is one more dimension that is rarely discussed, and which in practice decides whether the board trusts the entire agentic programme: autonomy is not a setting you switch on once. It is a level the agent earns with results.
In our deployments an agent usually goes through three stages. In the first it works like an assistant: it prepares decisions, but every one passes through a human. This stage can be frustrating for project sponsors, because the savings are still small - but it collects priceless material: which cases the agent gets wrong, how often, under what conditions. In the second stage the agent receives autonomy in a narrow, well-measured scope: routine cases, low amounts, reversible actions. Everything above the threshold still goes through the gate. In the third, the scope of autonomy grows where - and only where - data from the previous stages shows that the human correction rate is consistently low.
The key point is that every transition between stages is a formal decision with data on the table, not a gradual loosening that nobody noticed. Who makes that decision? In a well-organised company, the same collective risk owner who approved the gate map at the beginning. The register keeps an entry: from today the agent handles class X cases on its own, because for N months humans corrected fewer than Y percent of them.
This model also solves a problem that every second operations director raises with us: “surely I cannot keep people clicking in Action Center forever”. You do not have to. The human stage in a mature agentic process does not disappear, but it changes character: from approving everything it becomes oversight of exceptions and periodic sample checks. The number of tasks falls, the weight of each one grows. That is a healthy evolution - provided it is steered by measurement, not by fatigue.
And the reverse holds too: autonomy can also shrink. A model change in the AI Trust Layer, a new document type, a reorganisation on the data supplier’s side - each of these events can push the agent down a level until regression tests confirm that quality has returned. Organisations that only design the way up discover the missing way down at the worst possible moment.
The dark side of gates: oversight that is theatre
We would be dishonest if we ended with “deploy gates and you are done”. A HITL gate can fail in several well-documented ways - and we have seen every one of them.
Mechanical approval. A person who receives 200 cases a day and clicks “approve” on 98 percent of them stops reading after two weeks. Formally, oversight exists. In fact the process is autonomous, only slower and with a false sense of security. The remedy is a design one, not an appeal: the gate should receive only cases that genuinely require judgement, and its effectiveness has to be measured - a rejection rate close to zero over a longer period is an alarm signal that the threshold stands in the wrong place.
Alert fatigue. Guardrails tuned too sensitively flood Action Center with noise in which the one case the whole mechanism was built for gets lost. Threshold tuning is iterative work on real traffic, not a one-off configuration.
Cost and latency. Every gate lengthens the process. If you promised the business invoice handling in 4 minutes and the controller picks up tasks twice a day, you have a conflict that will surface in the first week. The SLA of the human stage has to be designed and staffed as seriously as robot throughput.
Silent failure of safeguards. In coded agents, a guardrail wired up incorrectly can do nothing at all - no error, no warning. That is why in our reviews we verify not only that safeguards are declared, but that they actually fire, with a test that deliberately tries to bypass them.
None of these problems invalidates gates. All of them invalidate gates deployed without measurement.
How we put it together at SNOK: from risk map to go-live
To close, something concrete - this is the path we walk with clients on agentic projects. Not as a rigid methodology, rather as an order of steps that protects against the most expensive mistakes.
We start from a decision map, not from technology: which actions in the process are irreversible or costly, whom they affect, what regulation says about them. From that map comes the gate catalogue - where a human is required always, where conditionally, where a log is enough. Only then do we design the process in Maestro with human stages as first-class participants, configure guardrails on all three layers with an escalate action wherever it makes sense, and tie it all together with the AI Trust Layer: audit log on from day one, personal data masking tested on real documents, the model connected in line with the client’s regulatory requirements.
And a rule we never depart from: no evaluation set, no go-live. The agent passes tests on a versioned set of cases - happy-path, edge and deliberately malicious - and every model change means repeating those tests. This is not bureaucracy. It is the only way we know to answer the question “how do you know it still works well” after a year in operation with something better than a shrug.
Does all of this slow the project down at the start? Yes, by a few weeks. We have also seen the alternative: a fast start, autonomy at maximum, then one incident after which the board switches off all agents for six months. The slower start is cheaper.
If you are building an agentic architecture right now - on UiPath, or still choosing a platform - and want to confront your gate design with someone who has done this many times, we invite you to talk. An agentic architecture review with a risk map and a gate catalogue is a standard, well-defined workshop at SNOK. Write to us: office@snok.ai.
Sources
- UiPath Academy, “Get started with UiPath AI Trust Layer” and docs.uipath.com, admin guide “About AI Trust Layer” and “Configuring LLMs” (accessed May-June 2026)
- UiPath Automation Cloud, release notes June 2026 (agentic models, In-Flight PII Masking extension, 2026-06-16/17)
- UiPath docs, guardrails and Automation Ops centralized policies (public preview, 2026-05-29)
- Regulation (EU) 2024/1689 (AI Act), Article 14 - human oversight; application timeline from 2 August 2026
- Guo et al., “On Calibration of Modern Neural Networks” (arXiv:1706.04599); Tian et al., “Just Ask for Calibration” (arXiv:2305.14975); Leng et al., “Taming Overconfidence in LLMs” (arXiv:2410.09724)