Where human approval belongs in travel AI

Most discussion of AI agents focuses on capability: what can the system do. In an operating travel business the more useful question is permission: what is it allowed to do, decided in advance, by someone accountable for the consequence.

That decision is an organisational one. It cannot be delegated to a model, and a design that implies otherwise has created a liability rather than an efficiency.

Three categories, decided before you build

Every action an automated system might take belongs in one of three categories, and the categorisation should be written down and signed off before any of it is built.

• Unattended. Reversible, low-value, high-volume. A misclassification costs a correction, not a customer.
• Approval required. The system prepares and proposes; a person accepts, edits or rejects. Most of the value, a fraction of the exposure.
• Never automated. Irreversible, commercially sensitive, or carrying duty-of-care weight. These sit on the human side by default and are removed only with a deliberate decision.

The common mistake is treating this as a technical configuration rather than a commercial decision. The person who should sign it off is whoever answers for the consequence, not the project team.

Default to approval, then earn unattended

A useful operating principle: new actions start in the approval category and move to unattended only after the assisted version has run long enough for the proposals to be trusted.

This is not caution for its own sake. The approval version generates the evidence needed to make the unattended decision responsibly — how often the proposal was accepted unchanged, what the edits corrected, which cases were rejected outright. Without that evidence, moving an action to unattended is a guess.

Approval is not a permanent constraint. It is how an action earns the right to run unattended.

Make approval cheap, or it will be bypassed

An approval step that takes a person as long as doing the task themselves will be routed around, and the system will quietly stop being used. This is the most common failure of well-governed AI deployments: the governance is sound and the ergonomics are not.

Approval is cheap when the context is assembled, the reasoning is visible, the proposed action is specific, and accepting or rejecting is one interaction. If a reviewer has to open another system to judge a recommendation, the design has failed.

Decide what uncertainty does

A system that resolves uncertainty by producing its best guess generates errors that are confident and documented. A system that escalates uncertainty generates a small amount of visible work and no silent failures.

In travel the second is almost always correct, because the cost asymmetry is severe: a flagged enquiry costs a consultant two minutes, and a wrongly cancelled booking costs a relationship.

This needs specifying per action rather than globally, because the tolerance genuinely differs. Misrouting an internal task and amending a live booking do not deserve the same threshold.

Log for the question you will be asked later

The question that eventually arrives is "why did this happen", and it arrives months after the fact from someone who was not involved.

That means logging the information the system acted on, not just the action it took. What was proposed, what context was available, what the confidence was, who approved it, and what they changed. Without the inputs, a log tells you what happened and not whether it was reasonable.

Duty of care is not an optimisation target

Travel carries obligations that are not commercial. A traveller in a disrupted location, a medical situation, a security incident — these are cases where the correct behaviour is to get a person involved immediately, with everything assembled.

Automation has a genuine role: detecting the situation, assembling the context, alerting the right person faster than a human triage queue would. What it should not do is decide the response. That boundary is worth stating explicitly in the action register, because it is the one most likely to be eroded gradually by efficiency pressure.

A general framework drawn from delivery experience. Specific obligations vary by jurisdiction, contract and insurance position; this is not legal advice.