Skip to content
Back to Blog
July 29, 2026

Audit Trails for AI-Assisted Bookings

How we maintain a complete record of what the AI agent did, why, and at whose request — tool call logging, recommendation tracking, and immutable audit architecture.

Audit Trails for AI-Assisted Bookings
M

"Why did the AI recommend that flight?" Three different people ask this question for three different reasons. The traveler asks because the recommended flight has a 4-hour layover and they want to know if there were better options. The support agent asks because the traveler filed a complaint about the recommendation. The regulator asks because they're evaluating whether AI-assisted booking platforms are acting in their customers' best interests.

Each of these people needs a clear, trustworthy answer. And the only way to provide that answer is if every decision the AI agent made, every tool it called, every option it considered, and every recommendation it surfaced is recorded in an immutable audit trail.

Why AI decisions need audit trails

Illustration for this section

A human travel agent's decisions are auditable by nature. They remember the conversation, they can explain their reasoning, and if pressed, they can reconstruct why they suggested a particular flight. An AI agent's decisions are opaque by default. The model processes tokens and produces output. Without explicit logging, there's no record of why it chose that output.

This matters more for travel booking than for many other AI applications. A content recommendation that's slightly off-target wastes a few seconds of attention. A flight recommendation that's suboptimal can cost the traveler hundreds of dollars. A booking executed on incorrect information is a financial transaction that's difficult to reverse.

The AI agent in our platform has a large set of tools. It can search flights-layer-ai-agent-search-flights), search hotels, check visa requirements, look up weather, calculate costs, create bookings, process payments, and more. Each tool call is a decision. The sequence of tool calls is a reasoning chain. The final recommendation is the output of that chain. All of it needs to be auditable.

What we log

Every agent turn generates a set of audit events. Here's what we capture.

User request. The exact message the traveler sent, with a timestamp and user ID. This is the trigger for everything that follows.

Agent reasoning. The agent's internal reasoning before and between tool calls. What it decided to search for and why. This is captured through the thinking/reasoning traces that the model produces.

Tool calls. For each tool the agent invokes: the tool name, the parameters it was called with, the timestamp of the call, and the full response from the tool. If the agent searched for flights from London to Tokyo on specific dates, the audit trail shows exactly those parameters and exactly the results returned.

Ranking and filtering. When the agent selects which options to present to the traveler, the audit trail shows what was filtered out and why. If 30 flights were returned by the search and the agent presented 8, the trail shows the ranking criteria that selected those 8.

Recommendation. The specific options the agent presented to the traveler, including the order of presentation and any commentary the agent provided ("This flight has a shorter layover" or "This hotel is closest to your meeting location").

User confirmation. The traveler's explicit confirmation to proceed with a booking. This is the authorization step. The audit trail records that the traveler said "Yes, book that flight" before any booking action was taken.

Booking action. The booking creation call, including the booking reference, the payment amount, and the provider confirmation. This closes the loop: request, reasoning, recommendation, confirmation, execution.

Each event has a trace ID that connects it to the same agent session. The trace ID links the chat message, the tool calls, and the booking action into a single auditable chain.

Immutable audit log architecture

Supporting diagram

Audit logs must be immutable. If someone can modify the log after the fact, the log has no evidentiary value. "The AI recommended Flight A" means nothing if someone could have changed the log from "Flight B" to "Flight A."

Our audit events are written to an append-only log. Once written, events cannot be modified or deleted through the application. The log is separate from the operational database. It has its own access controls, and write access is limited to the audit logging service. No application code can update or delete audit records.

The operational data (chat messages, booking records) has its own lifecycle. Messages can be deleted if the user requests account deletion. Bookings have retention policies. But the audit log operates on a separate retention schedule dictated by compliance requirements, not user preferences.

This creates a tension with privacy. The traveler's right to deletion applies to their personal data. The audit log contains personal data (their messages, their booking details). We handle this by anonymizing the audit log when a deletion request is processed. The audit events remain (preserving the decision chain), but the user-identifying information is replaced with anonymized tokens. The audit shows "User [ANONYMIZED] requested a flight search" rather than "John Smith requested a flight search." The decision chain is preserved for compliance. The personal data is removed for privacy.

Querying audit trails

An audit log that can't be queried is just an expensive storage bill. The log needs to support several query patterns.

By booking. "Show me every decision that led to booking #12345." This is the most common query. It starts from the booking record, follows the trace ID to the agent session, and retrieves every event in that session: the user's messages, the agent's tool calls, the search results, the recommendations, and the booking execution.

By user. "Show me all agent interactions for this traveler in the last 30 days." This supports support investigations when a traveler reports a pattern of problems.

By tool. "Show me all flight search calls that returned zero results last week." This supports product investigations into search quality and provider coverage gaps.

By time range. "Show me all bookings and their decision chains from yesterday." This supports daily reconciliation and spot checks.

The audit log is indexed on trace ID, user ID, tool name, and timestamp. These indexes support the common query patterns without full scans. For complex analytical queries (like "what percentage of agent sessions use more than 5 tool calls"), we run batch analytics against the audit log on a schedule rather than querying it in real time.

Retention policies for audit data

Audit data grows continuously and indefinitely. Every traveler interaction generates audit events. At scale, the storage volume is substantial.

Our retention policy balances compliance requirements with storage costs. Booking-related audit trails are retained for 7 years, matching financial record-keeping requirements. Non-booking audit trails (conversations that didn't result in a booking) are retained for 2 years. Anonymized audit data (after user deletion) is retained for the full compliance period.

After the retention period, audit data is archived to cold storage for an additional period, then permanently deleted. The archive is compressed and stored at lower cost, accessible for legal discovery but not for routine queries.

We review the retention policy annually. Regulatory requirements change, storage costs change, and the volume of data grows. The policy should reflect current requirements, not historical assumptions.

Design audit trails for your AI system

If your AI system makes decisions that affect users financially, legally, or materially, you need an audit trail. Here's the approach.

Log the complete decision chain. Not just the final output, but every intermediate step: tool calls, parameters, results, reasoning. The chain is what makes the decision explainable.

Make the log immutable. Append-only storage with restricted write access. No application code should be able to modify audit records.

Index for common query patterns. You will query by transaction ID, by user, and by time range. Make these queries fast.

Separate audit retention from data retention. User data can be deleted on request. Audit data follows compliance schedules. Handle the tension through anonymization, not deletion.

Start logging now. Adding audit trails to an existing system is harder than building them in from the start. Every decision that happened before you started logging is unauditable. Start early, even if the initial log is simpler than what you'll eventually need.


Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. Plan your next trip.

Share this article

Ready to Plan with Nowah?

Bring the idea. Nowah will help turn it into a trip.

Try Nowah