David Julian is the CTO and cofounder of Netradyne.
getty
Human-in-the-loop (HITL) has emerged as the default answer to concerns about AI trust, safety and governance. The logic is that when AI systems make decisions that affect people, a human should be involved.
In many cases, that instinct is correct. However, in real-time, safety-critical systems—particularly those operating in physical environments—treating HITL as a universal requirement is impractical and can even be counterproductive.
The problem is simple: Humans are slow relative to machines. Physics does not wait.
With physical AI, the feedback loop is often sub-second.
Take real-world driving, for example. A lane change with a fast-approaching vehicle in a blind spot, a sudden stop ahead or a pedestrian stepping off a curb—these situations unfold in fractions of a second. For real-time driver coaching or collision prevention, a human cannot be “in the loop” at the moment action is required. Any system that waits for human approval introduces latency and fragility precisely when determinism matters most.
Delays also fundamentally reduce the effectiveness of feedback. If a driver is alerted immediately after running a stop sign, they can recall the exact moment, understand what happened and adjust behavior. If that same alert arrives minutes later, after transitioning to a completely different driving context, the learning opportunity is largely lost. Real-time context is what makes feedback actionable.
The reliability that HITL is often meant to provide cannot be deferred to a person watching from afar. Indeed, where HITL goes wrong is when it is treated as a substitute for engineering discipline.
Positioning human approval as a runtime dependency often masks deeper issues: poor calibration, weak handling of long-tail scenarios, unbounded false positives or architectures that cannot deliver deterministic performance under real-world conditions. It also introduces new dependencies on connectivity and availability, where systems may degrade or fail entirely in low-network environments or during outages precisely when consistent performance is most critical. In these cases, HITL becomes a crutch rather than a safeguard.
True reliability has to be engineered directly into the system itself—into the models, the software stack and the operational policies governing when the system acts, abstains or escalates. That does not mean humans should be removed from the system, but it does mean they should be placed where they provide the highest leverage.
The more useful distinction is not whether humans are involved, but how. In practice, there is a critical difference between “human-in-the-loop” and “human-on-the-loop.” In the former, humans must approve decisions before action is taken. In the latter, systems operate autonomously in real time while humans oversee behavior, audit outcomes and intervene only when explicitly escalated.
For sub-second safety decisions, an on-the-loop model is often the only viable approach. The system must act now, and humans must be able to review later. Rather than serve as control mechanisms for real-time execution, humans should be force multipliers for learning, governance and accountability.
This framing clarifies where HITL genuinely excels. Human involvement is invaluable in the asynchronous loop: improving training data, labeling hard or rare scenarios, auditing outcomes for drift, enforcing policy, and handling the small number of escalation cases that require contextual judgment. None of this work depends on millisecond-level response times, and all of it benefits from human insight.
It also enables broader and more cost-effective analysis. When every event requires human review, cost constraints limit both the volume and type of events that can be evaluated. By contrast, systems that rely on automation in real time can capture a more complete, 360-degree understanding of driver behavior, including both risky and compliant actions.
To gain and maintain driver trust, however, these systems must achieve consistently low error rates. Reliability is foundational to user adoption and long-term effectiveness.
That is why edge-first architectures are essential in physical AI. On-device intelligence delivers low latency, availability even when offline, and consistent performance through real-world challenges such as dead zones, tunnels, depots and remote routes. These are exactly the environments where best-effort safety is unacceptable. Regardless of how hardware evolves, the principle holds: Real-time safety loops belong on the edge.
The ongoing debate about HITL is often framed as “AI versus humans,” but the real question is whether AI systems are designed to operate reliably under the constraints of the physical world, and whether human involvement is applied where it meaningfully improves outcomes.
In safety-critical environments, insisting that humans be in every real-time loop does not make systems safer. Designing for reliability does.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。