Airports should consider linking artificial intelligence expenditure and supplier payments more closely to measurable operational results, according to AWS, as the sector moves from experimentation towards larger deployments.
The approach could change how airports build business cases for AI, shifting attention from licences, computing consumption and project costs towards the value delivered. Instead of simply recording how much a system costs, an airport could calculate the amount spent for each minute removed from passenger queues, each disruption resolved more quickly or each additional passenger movement accommodated.
Bob Kwik, Worldwide Head of Airports and Ground Transportation at AWS
“Cost per outcome is not only applicable to airports, it’s arguably more important for airports because so many of the benefits are non-revenue,” Bob Kwik, Worldwide Head of Airports and Ground Transportation at AWS, told the Alliance.
“The key insight is that the ‘outcome’ doesn’t have to be revenue. It can be any measurable business result: passenger throughput at a checkpoint, minutes saved in disruption recovery, safety incidents avoided, or gate utilisation percentage.”
AWS defines cost per outcome as the total cost of an AI deployment divided by a measurable business value metric. The figure is not itself a complete measure of return on investment but provides a basis for comparing expenditure with the operational or financial value created.
For airports, the model offers a way to quantify projects whose benefits do not directly generate revenue. Passenger satisfaction, resilience and safety improvements can be difficult to represent in a conventional financial case, even when they support important organisational objectives.
An airport could measure the cost of every point of improvement in passenger satisfaction or minute removed from average processing times. A disruption-management system could be assessed against the reduction in recovery time, while an AI capacity tool could be measured by the additional movements enabled without new infrastructure.
“This framing makes the CFO conversation easier, not harder, because it directly connects AI spend to the KPIs the airport is already reporting on,” Kwik said. “The critical point is to establish a pre-AI baseline for each metric before deployment. Without a baseline, you can’t demonstrate movement.”
The idea also has implications for procurement. AWS is advocating a wider shift from fixed-cost contracts towards outcome-based pricing, under which payments to technology providers are tied to agreed results.
This would transfer some financial risk from airports to suppliers and give providers a stronger incentive to improve systems after deployment. Airports could test different solutions and expand them according to demonstrated value, rather than committing substantial budgets based mainly on promised capabilities.
However, airports and suppliers must agree outcomes that are measurable, attributable to the technology and difficult to manipulate. Queue times can be influenced by staffing, passenger volumes and airline schedules as well as AI. Safety improvements may be valuable but difficult to attribute to one system, particularly when incidents are already rare.
The cost side can be equally complicated. Model fees or software licences may represent only a fraction of the expenditure associated with an airport AI application.
Airports must also consider data storage and retrieval, connections to operational systems, monitoring, governance, cybersecurity and the staff needed to prepare data and maintain the system. AI agents completing multi-stage tasks can generate additional costs by repeatedly calling external applications.
Real-time airport data is a particular concern. An application may rely on information from an airport operational database, airlines, weather services, sensors and third-party providers. The cost of moving and processing this data can exceed the cost of running the AI model itself.
“For airports with real-time operational data, this integration layer can easily exceed the AI inference cost itself,” Kwik said.
He recommends auditing feeds before connecting them to an AI application. A system may not require second-by-second information if updates every minute would produce the same result at a lower cost. Data-pipeline expenditure should also be included in the initial business case.
Airports will also need to distinguish between different forms of AI. Employee productivity tools normally have predictable per-user subscription costs, while AI embedded in operational software is generally covered through supplier contracts. Bespoke models and agentic systems are more likely to generate variable charges based on tokens, computing requirements and data consumption.
“These categories have distinct differences in budget governance, ROI calculations, and cost visibility, and mixing these three categories into a single ‘AI budget’ line is a recipe for confusion, both when costs spike and when stakeholders ask what they’re getting for the money,” Kwik said.
The assessment period will vary. Kwik suggests productivity tools can begin to show adoption patterns within two or three months. AI embedded in an operational application may need to be evaluated across an entire IATA season, while bespoke projects may require three to six months, supported by monthly reviews.
A falling cost per outcome may support expansion, while rising costs without improved performance could indicate that the model, data pipeline or project scope needs to change.
Outcome-based pricing will not remove the uncertainty surrounding airport AI investment. It could, however, give airport technology and finance teams a clearer basis for deciding which projects to scale, redesign or stop, while retaining the flexibility to adopt more effective models as the market develops.
“The simple answer is pick the right model for the task, and build flexibility into the solution so you’re not locked-in to a specific model,” Kwik said.
Main image: 1000words| Dreamstime.com
