After 17 AI and automation deployments in aerospace defense finance — projects where errors had audit implications, where every business case required finance leadership sign-off, and where “the model got it wrong” was not an acceptable incident report — I have a short list of rules that the standard enterprise AI guidance omits. These are not about model selection or infrastructure. They’re about the organizational and process conditions that determine whether an AI system survives first contact with production.
Rule One: Baseline Before You Build
You cannot prove improvement without a baseline, and most teams skip baselining because it delays the part that feels like progress. The correct protocol is to measure the current process for four to six weeks — tracking the same metrics you plan to track post-deployment — before any model or automation is introduced. This gives you a genuine before-and-after comparison that can survive scrutiny. Without it, you have a number that represents “what the system produces” with no reference point for whether that’s better, worse, or the same as what existed before.
Rule Two: Encode Tacit Knowledge Before Automating
Manual processes accumulate undocumented corrections. Analysts know that certain data fields mean something different in context, that certain edge cases require a judgment call not captured in any procedure, that certain values get quietly adjusted based on experience. When you automate the process without surfacing those corrections first, the automation produces outputs that disagree with what experienced humans would produce — and the team spends weeks figuring out why the automation is “wrong” when actually the automation is correct and the tacit knowledge just wasn’t encoded. The fix is process mapping sessions before build, specifically designed to surface what people actually do versus what the procedure says they do.
Rule Three: Design for Consequential Decisions Differently
Not all decisions in a workflow have the same consequence profile. For a major defense aircraft program withhold tracking system, it meant mapping the consequence of each automated decision and setting a dollar threshold above which human review was mandatory — not recommended, mandatory. The model could flag, explain, and rank; a person owned the decision. This design principle — automation for volume, human judgment for consequence — is not a hedge against AI capability; it’s the correct system design for any workflow where some decisions carry disproportionate accountability.
Rule Four: Measure What the Model Gets Wrong, Not Just What It Gets Right
Accuracy metrics that report overall performance obscure the distribution of errors. A model with 94% accuracy that fails catastrophically on a specific class of inputs may be worse than a model with 89% overall accuracy that fails more evenly. In the internal tax scenario classifier — the tax scenario processing system — we tracked error rate by category, not just overall. Some categories had error rates below 2%; others had rates above 12%. The overall accuracy number looked good; the category breakdown told us where the model couldn’t be trusted, which is the information that actually shapes how you deploy it.
Rule Five: Write the Control Plan Before You Launch
A deployed model without a control plan is a model with an unknown expiration date. The control plan needs to specify: which metrics indicate the model is within acceptable performance bounds, what threshold triggers a retraining evaluation, who owns the retraining decision, and what the rollback procedure is if a retrained version performs worse than its predecessor. These are not governance overhead — they’re what separates a system that maintains its accuracy over time from one that quietly degrades until someone notices the outputs are wrong.
What Transfers
None of these rules are specific to aerospace or defense. They apply to any organization deploying AI in a context where errors have real consequences — financial, legal, operational, or reputational. The regulated environment makes the requirements explicit; in less regulated contexts, the requirements still exist, they’re just easier to ignore until something breaks.
→ Building something at the intersection of AI, edge computing, and behavioral science? Let’s connect.
Leave a Reply