AI for Airlines: Customer Service Pilots That Stay Grounded

Where AI fits in an airline today

AI is a reasonable candidate for a narrow passenger-service workflow. It can answer approved questions, collect the reason for a call, retrieve authorized flight or itinerary information, schedule a callback, and transfer a passenger with useful context. It should not invent operational information, interpret safety procedures, or control a flight-related system.

That distinction is more than wording. “What time does my flight depart?” is not a general-knowledge question. The answer depends on a current, authoritative source. “Am I entitled to a refund?” depends on the itinerary, the reason for the change, the airline's approved policy, and applicable rules. A language model can manage the conversation, but the airline's systems and policies must supply the facts and permissions.

Treat the first deployment as a measured customer-service pilot, not evidence that AI will make flights safer, improve on-time performance, or reduce costs. Those outcomes require separate operational evidence and are outside the scope of a passenger conversation agent.

Four airline customer-service pilots worth testing

1. FAQ and intent routing

Begin with questions whose answers come from a small, versioned knowledge base: check-in windows, baggage-policy navigation, lounge directions, loyalty-program contacts, or how to request special assistance. The agent should cite or identify the policy it used, state when it cannot find an answer, and transfer policy exceptions to a person.

This pilot can also collect intent—delay, baggage, seat, accessibility, refund, loyalty, or another category—and route the call. It should not decide the passenger's entitlement from a keyword.

2. Flight-status explanations

The agent may read a status only after retrieving it from the airline's authorized real-time flight-status source. The response should carry the source timestamp and avoid adding a reason, gate, departure estimate, or connection outcome that the source did not provide.

If the feed is unavailable, stale, or contradictory, the correct response is not a plausible estimate. The agent should say it cannot confirm the current status and move the passenger to an approved fallback channel.

3. Authenticated itinerary lookup and request intake

After the airline's identity check succeeds, an agent can read limited itinerary details and collect a request such as “I need to change this flight” or “I did not accept the replacement itinerary.” For an initial pilot, keep these connections read-only. Send the structured request to a human service team rather than changing a passenger name record (PNR), ticket, ancillary service, or order.

If the airline later considers transactional tools, each action needs explicit authorization, eligibility rules enforced outside the model, a preview the passenger can confirm, idempotency protection, and a durable receipt. The AI's interpretation of a conversation is not sufficient authority to commit a ticketing or payment action.

4. Disruption triage and callbacks

During irregular operations, an agent can identify the passenger, capture the issue, read approved service options already present in the airline's system, and schedule a callback or transfer. It should prioritize according to a policy the airline defines—not a model-generated judgment about who “sounds urgent.”

Airlines publish different commitments for controllable cancellations and delays. An agent should use the airline's current approved commitment and disruption-policy source rather than generalizing from another carrier or an old web page.

Every itinerary-specific answer needs an authoritative source

An airline voice agent is only as reliable as the tools behind it. A pilot architecture usually needs some of the following:

Some airline commerce systems exchange offers and orders through the IATA New Distribution Capability standard. That standard can be part of an integration strategy, but it does not guarantee that a particular carrier, aggregator, or service exposes the operation your agent needs. Confirm the exact API, version, data owner, authentication method, rate limits, and write semantics for each airline environment.

Do not give the model raw database access. Put a narrow service in front of each system. Validate inputs, allowlist operations, enforce passenger and agent permissions, redact unnecessary data, and return typed errors the conversation can handle. Keep read and write tools separate so a status lookup cannot become a booking change.

Customer-service controls that should be non-negotiable

Authentication before disclosure

Do not reveal an itinerary, contact detail, loyalty balance, or case status based only on caller ID or a name. Use the airline's approved authentication flow, limit failed attempts, and transfer when identity cannot be established. The conversation model should receive the result of the check, not the secret used to perform it.

Source and freshness checks

Every dynamic response should include machine-readable provenance: which system returned the value, when it was retrieved, and whether the result is complete. Define freshness thresholds by field. A schedule cached minutes ago may be unacceptable during a disruption even if it is adequate for a future trip.

Explicit confirmation for any future write

If a later phase permits an action, the system—not the language model—must check eligibility and calculate the result. Read the exact action back to the passenger, including flight, date, airports, price or refund amount, and restrictions. Commit only after unambiguous confirmation, then return the system's confirmation number.

Immediate human escape

Let the passenger ask for a person at any point. Transfer on repeated misunderstanding, authentication failure, policy conflict, tool failure, accessibility need, time-critical connection, payment dispute, fraud concern, threat, medical issue, unaccompanied-minor issue, or any safety-related statement. Preserve context for the agent, but let the passenger correct it.

Traceability and privacy

Log the prompt and workflow version, tool calls, returned source fields, transfers, and errors. Apply the airline's rules for notice, recording, consent, retention, redaction, and access. A transcript may contain identity, travel, payment, accessibility, or incident information; it is not harmless telemetry.

Keep passenger service separate from aviation operations

This article concerns customer communication. It does not propose AI control over dispatch, aircraft maintenance, flight planning, load control, crew legality, air traffic, security response, emergency procedures, or other safety-critical functions.

A service agent may relay an approved operational status from an authorized system. It must not create that status, diagnose its cause, override it, or advise airline staff or passengers on a safety decision. When a passenger raises a safety or security issue, the workflow should transfer to the airline's designated human channel.

This boundary also changes how to describe the business case. A customer-service pilot can be measured on whether it retrieves the right source, completes the defined task, and transfers correctly. It is not evidence that the airline has improved safety, reliability, resource management, or flight operations.

A reference Dasha pilot

Suppose an airline wants to test an inbound voice line for flight status and disruption triage.

1. Publish a narrow scope. The agent may authenticate a passenger, retrieve current status, answer from an approved disruption FAQ, collect intent, and transfer or create a callback case. It may not change a booking or determine compensation.
2. Create typed, read-only tools. One retrieves flight status, one retrieves minimum itinerary fields after authentication, one reads the current approved policy, and one creates a case.
3. Define failure behavior first. Stale or conflicting status, no matching itinerary, failed authentication, policy uncertainty, or tool timeout all produce a transparent fallback—not a generated answer.
4. Build a test set from real scenarios. Include codeshares, cancelled segments, schedule changes, missed connections, multiple passengers on a booking, accessibility requests, background noise, accents, and attempts to prompt the agent beyond its authority.
5. Run in shadow or employee mode. Compare the agent's proposed response and tool sequence with a trained service agent before speaking with passengers.
6. Launch to a limited queue. Cap traffic, staff the transfer route, and preserve a rapid disable switch for the workflow or individual tool.
7. Review failures daily. Fix the source, integration, policy, or routing rule behind the failure. Do not hide a weak integration with a more persuasive prompt.

We support inbound and outbound phone conversations, web voice, and web chat, as described in our conversation documentation. MCP connections can expose allowlisted external tools, and webhooks can report call completion, failures, transcripts, and transfer requests to airline systems. Call history and inspection can support pilot review.

These are integration mechanisms, not prebuilt airline access. The airline must provide or authorize every flight, reservation, policy, identity, case, payment, and contact-center connection. It must also define permissions, retention, escalation, and which actions are prohibited.

What to measure in the pilot

Choose metrics tied to the workflow rather than a generic promise of “efficiency”:

• percentage of answers backed by an authorized source within its freshness threshold;
• task completion and transfer rate by intent;
• incorrect, incomplete, or unsupported statements found in review;
• authentication failures and attempted data disclosures before authentication;
• tool errors, timeouts, duplicate requests, and unauthorized-action attempts;
• passenger corrections to captured intent or transfer summaries;
• time to reach a person after an escalation trigger;
• accessibility failures and alternative-channel requests; and
• cases created with the fields a service agent needs to continue.

Set stop conditions in advance. An unauthorized disclosure, booking write, unsupported operational claim, repeated failure to transfer, or missing audit record should pause the affected workflow.

Frequently asked questions

Can a voice agent provide live flight information?

Only if it can retrieve that information from the airline's authorized live source and verify that the result is fresh enough for the situation. Without that connection, it should direct the passenger to an approved source or a person rather than answer from model memory.

Can AI rebook a passenger automatically?

That should not be the first pilot. Start by authenticating, gathering the request, retrieving approved options, and routing the case. A later transactional phase needs deterministic eligibility and pricing outside the model, narrow write permissions, explicit passenger confirmation, idempotency, receipts, monitoring, and a reversal or human-recovery process.

Can an agent explain refund rights?

It can quote or summarize an approved policy and retrieve the status of a specific request. It should not make up an eligibility determination. In the United States, the current federal refund requirements include consumer-notification provisions in 14 CFR 260.9 and prompt-refund provisions in 14 CFR 260.10. The airline should encode the applicable rule and itinerary facts in a controlled policy service and route disputed cases to a person.

Does customer-service AI improve aviation safety?

This use case does not establish that. Passenger communication is separate from safety-critical airline operations. Evaluate it on source-grounded answers, task completion, access control, escalation, and passenger experience—not on safety or operational-performance claims.

Pilot one bounded passenger-service workflow

The strongest airline AI pilot is not the one with the broadest prompt. It is the one with a narrow job, authoritative data, explicit permissions, visible failure behavior, and a staffed human fallback.

If you are building that kind of passenger-service layer, evaluate Dasha's voice AI backend. Start with read-only status or triage, connect only the systems the workflow requires, and earn the right to expand through measured results.