Aviation · AI Governance
Before Your Airline Becomes Agentic, Build the AI Control Plane
An airline agent needs more than a good answer. It needs clear limits on what it can see, which systems it can use, and when a person must take over.
When an answer becomes an action
A service assistant that explains a refund policy is useful. An agent that checks a booking, decides which rules apply, and initiates a refund is a different proposition. The second system has authority over a business process. Its access and approval boundaries need to be designed as carefully as its responses.
This is already an operational question. In its September 15, 2026 announcement, Salesforce reported that Air India had more than 30 agentic AI initiatives underway across an ecosystem of over 140 enterprise systems. That scale makes a collection of separately configured agents difficult to govern.
Before adding another agent, an airline should be able to answer a basic question: who controls what it is allowed to do?
The problem with giving every agent its own access
Consider a refund agent, a loyalty assistant, and an employee knowledge copilot. Built independently, each might acquire its own credentials, model connection, document permissions, and logging conventions. An apparently small pilot can leave behind a permanent integration that nobody quite owns.
A wrong answer is only one failure mode. An agent could retrieve records outside the employee’s role, send confidential information to an unapproved model, or call a write API when the task only required a lookup. These are access-control failures, even when the model follows its prompt.
IATA’s 2026 World Data Symposium announcement brought cybersecurity, data, AI, and automation into the same aviation agenda. Our architectural conclusion is straightforward: teams should design these controls together.
What the AI control plane actually does
An airline AI control plane is a shared layer for enforcing policy across agents, models, data, and tools. It works alongside the passenger service system, CRM, loyalty platform, ERP, and operational applications. Those systems remain the sources of record.
For each request, the control layer checks the user and agent identities, the data classification, the permitted processing environment, and the allowed actions. An AI gateway can handle part of this work; tool services and downstream systems must enforce the same boundaries. A diagram with a single central box is not enough.
- Identify the user, agent, and task.
- Check data access and allowed models.
- Retrieve approved context and validate tool requests.
- Apply action limits and obtain approval where required.
- Record the outcome, including failures and denied actions.
Keep this layer available and observable. For a blocked or unavailable service, define a safe handoff to the existing manual workflow rather than silently relaxing the policy.
Six controls worth making reusable
Identity and access
Give agents their own scoped identities and carry the requesting user’s permissions into retrieval. A service employee and an operations controller should not see the same records simply because they share an assistant.
Data classification and loss prevention
Identify sensitive passenger, employee, commercial, and operational information before it leaves an approved boundary. Minimize the data passed to a model and apply data-loss prevention checks at the relevant interfaces.
Model routing
Choose among rules, private models, specialist models, and approved external services according to the task and policy. The cheapest model is irrelevant if it is not permitted to process the data.
Tool permissions
Expose narrow operations such as “check refund eligibility,” with validated inputs. Avoid handing an agent a broad reservation-system credential and relying on a prompt to limit its use.
Action limits and approval
Keep reading, recommending, and executing separate. Validate a proposed change against current policy and transaction state before it runs. Approval should apply to a specific action, not become reusable permission for whatever the agent does next.
Audit and monitoring
Capture the request identity, source references, model and policy versions, tool calls, approvals, and result. Logs need access controls and retention rules too; copying every sensitive prompt into a permanent log creates another exposure.
Put human review where the consequences justify it
Requiring approval for every document search would slow down useful work. Allowing every transaction to run unattended would remove essential oversight. Define the boundary by the consequence of the action and the quality of the available evidence.
| Workflow | Processing approach | Action boundary |
|---|---|---|
| Approved SOP lookup | Permission-aware retrieval and an approved model | Read-only; show the current source |
| Passenger email summary | Approved processing with data minimization | No booking changes |
| Refund eligibility | Deterministic policy checks with AI assistance where useful | Explain the result; separate it from execution |
| Refund execution | Validated transaction workflow | Apply airline-defined limits and required approval |
| Request outside the agent’s role | No tool execution | Block, log, and escalate |
A model’s confidence score alone should not authorize a consequential transaction. Missing evidence, unusual cases, and conflicting records need a defined escalation path. Safety-related authority remains with qualified people and approved operational systems.
Private models still need security engineering
A private Small Language Model can keep inference within infrastructure the airline controls. That is useful for sensitive, repeatable work, but the deployment location does not solve prompt injection, excessive permissions, or incorrect retrieval.
Test documents and messages that try to redirect an agent, restrict network access, validate tool arguments, and keep approved knowledge current. The model is one execution option inside the security architecture. It is not the security boundary by itself.
The same decision also affects operating cost. Our companion guide explains how airlines can route work across rules, SLMs, and larger models.
Start with one agent and test the boundaries
Inventory the models, integrations, data sources, and actions already in use. Then choose a contained workflow, such as a read-only employee knowledge assistant or a customer-service draft that requires review.
Test denied access and failure cases alongside answer quality. Can the agent retrieve another team’s records? Can a malicious document make it call a tool? What happens if the approval service is unavailable? Can an investigator reconstruct a failed transaction without exposing unnecessary passenger data?
EASA’s Proposed Issue 03 concept paper, released in June 2026, develops its human-centric AI trustworthiness framework and explores more advanced automation. It does not mandate this enterprise architecture or make a customer-service agent aviation-certified. It is relevant context for treating human responsibility and technical assurance as design concerns.
At Sovereign SLM Labs, we start by mapping the workflow, the information it needs, and the authority it should have. Explore our Aviation practice to see where governed private AI can support operational teams. Establish reusable controls while the agent estate is small, and make each new deployment inherit them.