Aviation · Model Economics
One AI Model for Every Airline Use Case? That Could Be an Expensive Mistake
Classifying a baggage email and reviewing a complex supplier contract are different jobs. Your AI architecture—and its cost model—should reflect that.
Start with the work, then choose the model
A pilot often starts with one model because that is the quickest way to test an idea. The expensive mistake is letting that early choice become the default for every workflow that follows.
A passenger email might need a category and a routing decision. A shift report needs a faithful summary. A supplier agreement may require comparisons across clauses and supporting documents. Paying for the same level of inference across all three makes little sense unless testing shows they need it.
The stakes are growing. SITA’s Air Transport IT Insights 2025 reports airline IT spending of about $36 billion for 2025. AI must compete for budget within that wider operational estate. A useful architecture connects model capability to a defined business outcome, rather than treating token consumption as evidence of adoption.
Map the workloads before shopping for models
Build a short inventory with the people responsible for each process. Record expected volume, peak demand, data sensitivity, acceptable errors, response-time requirements, and who handles exceptions. Include the existing manual or software process as the baseline.
Then separate tasks that require language understanding from tasks that follow an explicit rule. If refund eligibility is determined by known policy and ticket conditions, deterministic checks are a stronger starting point than asking a model to invent a decision.
| Workload | Candidate approach | What to test |
|---|---|---|
| Refund eligibility | Rules engine | Policy coverage and exception handling |
| Passenger email classification | Specialist classifier or private SLM | Accuracy across languages and mixed intents |
| SOP questions | Permission-aware retrieval plus an approved model | Source quality, freshness, and grounded answers |
| Operational summaries | Private SLM where suitable | Missing facts, incorrect inferences, and latency |
| Complex contract analysis | Larger approved model if evaluation supports it | Cross-document accuracy and review effort |
These are candidates, not purchasing instructions. A smaller model that fails the task is not economical once corrections and escalations are counted.
Route by policy before comparing price
A routing layer sits between the application and its available processing options. It first decides which options are allowed. Only then should it compare capability, latency, and cost.
- Identify the task and sensitivity of the data.
- Exclude models and environments the policy does not allow.
- Select a tested rule, retrieval, specialist, or language-model path.
- Validate the result and escalate uncertain cases within the same data boundary.
- Measure quality, latency, cost, and human review.
For example, a routine internal summary may stay on a private model. An ambiguous commercial analysis could use a larger approved model, provided the data policy permits it. If external processing is prohibited, a failed private-model attempt should trigger an approved private fallback or human review—not an automatic external API call.
Give smaller models a defined job
Private SLMs are useful when the task is narrow enough to evaluate well: classifying messages, extracting fields, or summarizing approved records. Retrieval can supply current airline knowledge rather than expecting the model to remember policies learned during training.
Larger models may justify their cost for harder analysis, longer context, or tasks where they materially reduce review effort. Specialist predictive or optimization models may be better than either kind of language model for forecasting and scheduling.
At Sovereign SLM Labs, the aim is to choose the smallest suitable capability that meets the workflow’s requirements. That may be a rule. It may be an SLM. It may be a larger model. The evaluation should decide.
Measure cost per completed task
Token prices are easy to compare. Total operating cost takes more work. Include infrastructure, serving, integration, monitoring, evaluation, security, and the people needed to resolve failed or uncertain requests.
Private inference changes the bill, but does not remove it. Utilization matters: an idle accelerator still costs money, and peak disruption demand may require capacity that sits underused on quieter days. A smaller external service can be cheaper than a private deployment for some low-volume tasks.
Cost per accepted outcome = model, infrastructure, operating and review costs ÷ successfully completed tasks
For a routing pilot, compare this measure with the existing process and a single-model baseline. Track the escalation rate, repeated calls, retrieval costs, and time spent checking answers. Use representative cases, including messy emails and peak-volume periods, rather than only easy demonstrations.
There is no credible universal savings percentage. The financial case depends on your workload mix, required quality, available capacity, and review process.
Cost controls and data controls belong together
The routing policy can keep passenger information in an approved private environment, limit a knowledge assistant to current internal manuals, and allow public marketing content to use an approved external model. Redaction is helpful where appropriate, but should not be treated as a guarantee that sensitive information cannot be inferred.
These checks become more important as agents call tools and trigger transactions. Our article on the airline AI control plane covers the identities, permissions, approval boundaries, and audit records that need to surround those actions.
Scale makes the choices repeatable. Salesforce reported in September 2026 that Air India had more than 30 agentic AI initiatives across over 140 enterprise systems. This illustrates the breadth of deployment; it is not evidence of a particular routing strategy or a promised cost saving.
Run a pilot that can change your mind
Pick two or three contrasting workflows: one deterministic process, one frequent language task, and one task requiring more complex analysis. Set acceptance criteria before choosing models.
- Evaluate accuracy and source grounding against reviewed examples.
- Measure response time and cost at expected traffic, including peaks.
- Record how often a cheaper path escalates and why.
- Test unavailable models, restricted data, and failed tool calls.
- Include human review and ongoing operations in the business case.
Keep the route only if it meets the agreed quality and control requirements. A larger model that saves substantial specialist review time may be the economical choice. A stable rule that removes a model call altogether may be better still.
Our Aviation practice starts with that workload map and the path to production. The goal is a portfolio of tools the airline can evaluate, govern, and change as its needs evolve.