A few weeks ago, I was en route to an airport I'd earmarked for landing when I noticed bad weather closing in on it. I checked the alternative, the backup airport I initially planned for, and saw that we'd have to fly through bad weather to get there too. So, I picked a third airport, landed, waited it out for a few hours, and continued safely once the system had passed.
Could we have beaten the weather to the original airport? Maybe. Could we have threaded the patches en route to the alternate? Maybe. But “maybe” is not a risk management strategy. Good risk management doesn't ask whether you can get away with something. It asks whether the risk is worth taking at all. We landed. We waited. We lived to fly another day.
Every pilot learns a simple framework for making this kind of call in the moment. It is clearly laid out in the FAA's Aviation Instructor’s Handbook. It's built for cockpits, but it translates almost line-for-line into how managers decide how fast, and how far, to push AI deployment.
Accept no unnecessary risk
In aviation, the rule isn't “avoid all risk". Flying is impossible without risk. The rule is that risk needs a corresponding return. A new pilot doesn't take a new airplane into low-visibility conditions on day one. There's no benefit that justifies that specific risk, even though the same pilot might accept real risk elsewhere.
Applied to AI, the question managers should be asking isn't “Is this AI system risky?” It’s: What, specifically, are we getting in return for this specific risk, and would we accept it if we wrote it down?
Shipping an unvetted model into a workflow that touches medical records, financial approvals, or safety-critical decisions because it's faster to ship than to test is an unnecessary risk with no commensurate return. If a competitor's speed advantage is the only justification, that's fear dressed up as strategy.
Make risk decisions at the appropriate level
On a single-pilot flight, the pilot decides. Not air traffic control. Not the passengers. The person accepting the risk has to be the person who can actually build and implement the controls that manage it.
This is where a lot of AI governance quietly breaks down inside organizations. Decisions about deploying a customer-facing model or giving an agent write-access to production systems, often get made by whoever is closest to the deadline: a product leader, an engineer under pressure; rather than by the manager who actually owns the downstream consequences.
Ask: “Who in this workflow has the authority to say no, and does that person have full visibility into what's being deployed?” If the answer is “Nobody, really,” the decision is happening at the wrong level, and it needs to be pushed up the chain until it lands with a manager who has both the information and the authority to own it.
Weather is a good analogy here too: A clear day is a far better time to fly an unfamiliar airplane for the first time than a day with deteriorating conditions. Deploying AI is the same. The acceptable risk changes with the environment.
Managers should be asking the equivalent question before every material AI deployment: “Is this the right environment for this risk?” A generative AI pilot in an internal, low-stakes workflow, with a human reviewing every output, is a clear-weather flight.
The same model, wired into an autonomous decision loop with no human check, touching customer money or physical safety, is flying in questionable conditions into weather you haven't checked.
The technology's raw capability doesn't change between those two cases. The acceptable level of risk does.
Integrate risk management into planning at all levels
The earlier a risk gets caught, the cheaper it is to fix. Changing course mid-flight is harder than choosing the right route before takeoff. It's exactly the same with AI systems bolted together in production versus designed with guardrails from the get-go.
Retrofitting oversight, auditability, and kill-switches onto an AI system that's already embedded across a team's workflows is the equivalent of trying to change your destination airport after you've already flown into weather. It's not impossible, but it's expensive, stressful, and far more likely to end badly. Risk management belongs in the design conversation on day one, and not in the incident review six months later.
The diversion wasn't a failure.
Nobody remembers that flight as a bad day. We made the airport, on schedule for what mattered, with nothing more dramatic than a longer layover than planned. That's what good risk management actually looks like - not heroics, not close calls retold as bravado - just a series of unremarkable, disciplined decisions that never had to become a story about what went wrong.
The managers who will deploy AI well over the next few years won't be the ones who moved fastest. They'll be the ones who knew, at every stage, exactly which airport they were headed to, and were willing to divert the moment the weather said otherwise.