An AI travel assistant must never invent a flight time
There is a version of an AI travel assistant that demos beautifully and is unusable in production. You ask it what time your flight leaves and it answers instantly, fluently, and sometimes wrongly — because the model is very good at producing something that looks like a departure time.
In most software, a wrong answer is a bug. In travel, a wrong departure time is a missed flight, and the traveller does not blame the software. They blame the agency whose logo is on it.
The distinction that matters
There are two very different things a language model can do in this setting:
Interpret. Take a fact that is already in your system and say it clearly, in the traveller's language, at the right moment. "Your flight leaves at 17:10 from Terminal 4, and check-in is already open."
Generate. Produce a plausible answer when no fact is available.
The first is enormously valuable. The second is a liability. Everything hinges on the assistant being architecturally incapable of the second — not merely instructed to avoid it.
What "grounded" actually requires
An assistant is grounded when structured data is the source of truth and the model is only allowed to phrase it. Concretely:
- Times, dates, locators, terminals, addresses and policies come from records, never from the model's memory of how airlines usually work.
- If the record is missing, the answer is "I don't have that yet — let me check with the team." That sentence is a feature. An assistant that cannot say it will invent instead.
- Unverified data does not drive anything. A booking parsed from a PDF should not trigger a reminder until a human has confirmed the parse. Extraction is a proposal, not a fact. (How import review works.)
- Anything consequential escalates. Rebooking, refunds, medical questions, visa advice for a specific nationality — these get handed to a person with the context attached.
Two things worth asking any vendor
"Where does a departure time come from?" If the answer involves the model at any point, walk away. If it is "from the segment record, rendered in the traveller's timezone", you are talking to someone who has thought about this.
"What does it say when it doesn't know?" Ask for the literal sentence. Ask what triggers it. A vendor who has not designed that path has an assistant that improvises.
Where a model genuinely helps
Grounding is not a limitation you tolerate. Within those bounds the model does the parts that were never automatable:
- Reading the mess. Airline PDFs, hotel confirmations, a photo of a booking taken sideways in bad light — turning those into structured segments for a human to approve is a real saving.
- Answering in the traveller's language, at 2am, in their timezone, without a night shift.
- Knowing which facts are relevant now. "Where's my hotel" means something different on the morning of arrival than it did last Tuesday — which is why the clock a traveller is living on matters as much as the itinerary.
- Judging when to stop. Recognising that a question has become a complaint, and getting a human involved before it becomes a review.
The test
Ask it something it cannot possibly know — a gate number three weeks out. A grounded assistant says gates are published a few hours before departure and offers to tell you the moment it appears. An ungrounded one gives you a gate.
Only one of those is safe to put in front of your travellers with your logo on it. Related: what should reach a traveller when a flight moves overnight.
Viaquo answers only from the itinerary your team has approved. Nothing a model extracted drives a message until a human confirms it.
