# Why HITL

Modern AI systems are good enough to act, but rarely good enough to act alone. The interesting question is not *whether* humans should be in the loop — it is *where* in the loop they sit.

## Two failure modes of automation

**Over-automation.** Ship the model directly to customers. Fast, cheap, and one hallucinated refund / leaked PII / libelous reply away from a front-page incident. Recovery costs dwarf the savings.

**Under-automation.** Route every AI suggestion to a human. Safe, auditable, and unable to scale beyond the size of the review team. The AI becomes an expensive autocomplete.

Both failure modes share a root cause: treating human review as a binary, not a routing decision.

## The shift from hot path to exception path

|                   | Hot path HITL                | Exception path HITL                     |
| ----------------- | ---------------------------- | --------------------------------------- |
| **Who decides**   | Human, every time            | Policy first; human only when uncertain |
| **Latency**       | Human-bound                  | Machine speed for the common case       |
| **Reviewer load** | Linear with volume           | Sublinear; shrinks as model improves    |
| **Audit trail**   | Trivial                      | Same — every decision logged            |
| **Failure mode**  | Reviewer fatigue, bottleneck | Policy drift if untuned                 |

LoopDesk is built for the right column.

## When you need HITL

You need a loop when **any one** of these is true:

* A wrong answer has real cost (money, safety, brand, legal exposure)
* Your model's accuracy is high but not 1.0, and the long tail matters
* You need an auditable record of who decided what and why
* You are subject to regulation (EU AI Act, sector-specific rules) that requires human oversight of "high-risk" automated decisions
* You want to capture corrections as a training signal instead of throwing them away

You probably don't need a loop for: search ranking, autocomplete, recommendation tiles, internal analytics, or anything where the worst case is "user scrolls past it".

## What a good loop looks like

1. **Most items skip the human.** If your reviewers see >40% of traffic, your thresholds are too tight or your model is the wrong one.
2. **Reviewers see context, not just the suggestion.** Original input, confidence, risk flags, guidelines, and similar past decisions.
3. **Every override is structured data.** Free-text reasons are fine; unstructured override events are not.
4. **The queue shrinks over time.** Overrides feed back into prompts, guidelines, and (eventually) model updates. If the queue is flat after three months, the loop isn't actually closing.
5. **Escalation has a name.** "Senior reviewer" is a role, not a vibe. Sensitive items go to a specific, accountable person.

LoopDesk's defaults — routing policy, learnings capture, role gating, signed webhooks — exist to make these properties cheap.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://hitl-01.gitbook.io/hitl-docs/human-in-the-loop/why-hitl.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.