There’s a type of organizational problem that shows up in almost every large company that tries to scale AI decision-making. I call it the escrow problem because the decision gets stuck in a state where it’s technically made but functionally unmade.

Here’s how it usually starts: Your organization deploys a model. The model makes recommendations. The humans are supposed to review those recommendations before decisions are finalized. This is good risk management.

Then the model starts producing recommendations faster than the review process can handle them. And something breaks.

How the problem reveals itself

I watched it happen at a company with a lending model that ran daily. The model analyzed applications and generated recommendations. For each recommendation, there was an escalation process: If the model’s confidence was below a certain threshold, a human reviewer had to approve before the decision could be finalized.

This was a reasonable control. Humans would review uncertain cases and apply judgment.

The problem: The model was running faster than the humans could review. By the time a human looked at a recommendation, the business context had changed. A customer’s credit situation might have moved. Market conditions might have shifted. The recommendation that made sense when it was generated was now stale.

The company had two choices. They could slow down the model (run it less frequently). Or they could let decisions move forward without full review.

They did what most organizations do: They expanded the category of decisions the model could make without human review. They raised the confidence threshold. They created exception processes. They added more reviewers.

They never solved the fundamental problem: The decision authority couldn’t move as fast as the decision-generating process needed it to move.

Why this matters

The escrow problem has real consequences, and they’re usually invisible until something breaks.

First, it erodes decision quality. When humans are reviewing decisions that are already hours old, they’re not reviewing whether the decision was right then — they’re reviewing whether it’s still right now. These are different judgments. The review becomes reactive (the decision is already in flight) instead of deliberative (should we make this decision?).

Second, it creates decision drift. The organization sets out with human oversight for all AI recommendations. Gradually, as the volume overwhelms the review process, the definition of which decisions require oversight changes. But there’s no formal decision about this drift. It happens through accumulated exceptions and threshold adjustments. Six months in, the decision-making process is fundamentally different from what was designed, but nobody made a choice about it.

Third, it creates liability exposure. The organization built a control system (human review) and published that as their governance. When something goes wrong in a decision that bypassed the review, they have to explain why the published process wasn’t followed. Usually the answer is “our volume exceeded our capacity,” which is not a good explanation in a regulatory meeting.

What’s really happening

The escrow problem is usually a symptom of something deeper: The organization hasn’t actually decided who has the authority to make decisions.

It sounds like they have: “The model recommends, humans review, we finalize.” But what they’ve really said is: “The model recommends, humans might review if we have time, and then we do whatever happens next.”

That’s not decision authority. That’s hoping someone with judgment will be available.

In organizations that handle this well, decision authority is clear and it’s mismatched to speed:

Fast decisions — The model decides, using its learned judgment. Humans monitor whether the model’s decisions are working as expected, but they’re not involved in every decision. This is appropriate for high-volume, low-stakes decisions where the model’s track record of accuracy is proven.

Medium-speed decisions — The model recommends, and a human approves or overrides based on specific criteria. This requires that the human can make the decision in the timeframe the model generates recommendations. If they can’t, you have the escrow problem.

Slow decisions — Humans make the decision. The model provides input (analysis, risk assessment, comparable cases), but the human has the final authority and the time to exercise genuine judgment. This is appropriate for low-volume, high-stakes decisions.

The problem is that most organizations try to run medium-speed decisions through a slow decision process. They want the model’s speed, the human’s judgment, and the risk mitigation of oversight. They can’t have all three.

Choosing what to give up

Organizations that solve this problem usually make one of three choices:

Choice 1: Give up speed.

Slow down the model. Run it weekly instead of daily, or quarterly instead of monthly. Make sure the review process can keep up. This is the right choice if the business value of speed is low and the risk of escrow is high. It’s usually chosen by regulated organizations where decision documentation is critical, or where the stakes are high.

Choice 2: Give up human oversight.

Let the model decide for high-confidence cases. This is appropriate when the model’s track record is proven and the cost of wrong decisions is manageable. It requires confident monitoring (you actually know when the model fails) and a fallback process (if something goes wrong, there’s a clear escalation). It’s the choice many companies make when they realize their volume will never fit through human review.

Choice 3: Give up some decisions.

Don’t deploy the model for use cases where you can’t deliver fast enough human judgment. Keep it as an internal tool (gives humans better information) rather than a decision system (actually makes decisions). This is the right choice when you’re not sure about the model’s track record or when the stakes are high.

Most organizations don’t make any of these choices explicitly. They drift into Choice 2 (give up human oversight) while claiming they’re still running Choice 1 (humans review) and never actually doing Choice 3 (accepting limited scope).

How this connects to everything else

The escrow problem is actually a decision-rights problem. It shows up when you haven’t clearly assigned decision authority and you haven’t accepted the constraints that come with that assignment.

Organizations that have solved it clearly are usually clear about something else: Who actually owns the decision? Not “who reviews the recommendation,” but who has the power and the responsibility to say yes or no?

Once you know that, the speed problem becomes tractable. If the model owner has the authority to make decisions within certain guardrails, they can decide to expand those guardrails when volume exceeds human review capacity. It’s their call to make. If human reviewers have the authority, they can decide how much volume they can handle and what happens when volume exceeds capacity.

But most organizations have assigned the authority to someone in a governance role (a committee, a compliance team, a risk committee) who isn’t actually involved in day-to-day decision-making. So when volume increases, nobody has the authority to make the choice about what to do.

Where to start

If you’re building AI decision systems, ask this question early: What’s the slowest decision-making process you can tolerate for this use case?

If the answer is “we need to decide in minutes,” then human review isn’t your control mechanism. Your control mechanism is monitoring and fallback.

If the answer is “we can tolerate a few hours,” then you need enough human capacity to review decisions on that timeline. That’s a real constraint. Build for it.

If the answer is “we can tolerate a few days,” then you can probably build a human-review process that works.

But don’t answer with what you wish were true. Don’t say “humans review everything” if your volume makes that impossible. That’s how you end up in escrow.

The organizations that manage AI decision-making well know their constraints and design to them. They don’t promise speed, judgment, and oversight unless they can deliver all three. Most organizations promise all three and end up delivering none of them well.