Picture this. An aircraft goes AOG. An AI assistant identifies a replacement tail, drafts the revised itinerary, and writes the customer update. A busy coordinator
hits send. The customer now expects the recovery. Except maintenance hasn’t confirmed the replacement aircraft is airworthy, and nobody has resolved the crew question. The message turned a possible solution into a promise before the people responsible had made the call. No autonomous aircraft required. This year’s BACE will be thick with AI demos. Somebody has to decide what this technology is allowed to participate in, under whose authority, and what happens when its recommendation is wrong. 

A vendor’s claim that its software is “FAA-approved” doesn’t settle your responsibilities. Where authorization is required, your operation needs the applicable approval or acceptance for its own use. Another customer’s authorization doesn’t transfer to your certificate, and it doesn’t answer who may act on an AI recommendation. 

An aircraft recovery crosses dispatch, maintenance, scheduling, sales, flight crew, and accounting. Each brings information the others need, and a change in one area can alter the entire plan. AI can help assemble that picture, but its contribution still needs to fit the operation’s established responsibilities, verification steps, and approvals. 

At SayFlight, I call the structure built around those questions Operational Decision Architecture. It defines how decisions move through the operation and where human authority holds. It also says where AI may participate, and what gets captured when the call is made. 

The starting point is two sentences. Pick one place AI already touches your operation: write down who is accountable for the output and what the tool is not permitted to conclude on its own. Then, separate permission to draft from permission to send, and separate permission to recommend from permission to execute. Why? A person clicking approve needs the information, the time, and the authority to challenge the output. Otherwise, you have built an approval button, not oversight. 

Next, keep a record proportionate to the decision: what the system proposed, who made the call, and why. A completed task won’t tell you whether the judgment behind it was sound. 

None of this should slow adoption down. Clear boundaries let a team use useful technology with confidence, and they expose the decisions the business never clearly assigned in the first place. Before you leave Las Vegas with another promising tool, ask whether your operation can explain the decisions it will touch.

The demo shows you what the software can do, but your operation has to decide what it is allowed to do. 

Remember, you can only automate what you can clearly articulate.