How air travel got 40x safer, and what it tells us about deployed AI

TL;DR

1. Continuous monitoring of AI models in business deployments is essential to detect failures and misbehavior, complementing pre-launch checks and incident investigations.
2. The airline industry had a similar blind spot fifty years ago. Covering it helped make flying 40x safer, while saving airlines money through efficiency improvements.
3. We’re drafting an open protocol for continuous monitoring, informed by Center for AI Standards and Innovation (CAISI) research, and looking for pilot companies and reviewers to help shape it.

What made air travel so much safer

In 1974, an air traveler boarding a plane had a 1 in 350,000 chance of dying on their journey. By 2022 it was about 1 in 14 million.

That traveler could have flown on TWA 514, where 92 people were killed as the plane descended into a mountain in northern Virginia. The flight crashed while making mistakes almost identical to those of a United flight crew six weeks earlier, which narrowly escaped 514's fate.

We only know of United's near miss because the crew reported it through an internal incident-reporting channel United had just enabled. The potentially life-saving insights stayed inside United because pilots and executives had no method to securely share them further.

Early 1970s-era aircraft were tested strenuously before they were cleared to fly. Pilots were tested per aircraft and re-examined on recurring observation flights. After a crash, investigators pored over the 'black box' flight recorder.

But in flight, no operating data was being collected. No safety insights were being shared. Flight recorders captured every flight on a loop that was overwritten unless the plane crashed. Even when crews had something critical to share, there were no channels across airlines. Airlines couldn’t learn from each other, just as TWA flight crews didn’t learn from United.

Safety improvements came through mechanisms that ensured continuous monitoring and sharing of operating insights. In response to TWA 514, the FAA created the Aviation Safety Reporting System (ASRS) so that flight crews could report incidents and near misses. To reduce fear of punishment, collection was given to NASA. ASRS has issued more than 8,000 safety alerts since 1976.

Over time, airlines also developed Flight Operational Quality Assurance (FOQA) practices, which automated flight monitoring and reduced airlines’ dependence on people identifying and reporting safety insights. Airlines download and analyze the data recorded for each flight for safety-relevant signals. In exchange the FAA doesn't use the findings for enforcement. The monitoring has paid for itself 2x over in operational savings. A neutral nonprofit pools de-identified data across carriers. A joint industry-government body (CAST) turns findings from accident investigations and the pooled data into practice, and has driven adoption of more than 100 voluntary safety enhancements.

The airline industry had rigorous testing and investigators in 1974. But safety gaps still remained. Making passengers 40x safer required operational monitoring, pooled across competitors, safely shared, and jointly analyzed.

AI in 2026 looks a lot like aviation in 1974

Like airlines testing 1970s aircraft and pilots, frontier labs test models before release. They've opened their models to external pre-deployment evaluation, brought in outside investigators after incidents, and begun embedding third-party evaluators. These steps are critical. But like the flight tests and black boxes of 1974, they leave a blind spot in live deployment. That’s where models do most of their work, in contexts no test anticipated.

Millions of businesses actively run frontier models built by a handful of labs. Pre-launch model evaluations present only a small fraction of the contexts agents are exposed to in deployment.¹

Business deployments often have observability systems in place, tracking traces, latency, costs, and sometimes error rates and LLM judge evaluations. They typically run any LLM evaluations on a sample of traffic to keep costs reasonable. Common vendor guidance is around 10% of traces. These systems typically require extensive domain expertise and investment to maintain, a barrier that is difficult to clear for many companies. Industry surveys this year suggest only around 14% of engineering teams deploying models are using observability systems with them. Gartner expects only 40% of organizations to use AI observability by 2028, underscoring the perceived challenges to adoption.

The labs can’t do the monitoring

Frontier labs monitor their agents deployed internally (examples: OpenAI, Anthropic). But we can’t expect them to reliably catch every critical failure in every deployment context.

• They don’t see most of the traffic. Even on their own APIs, enterprise terms generally bar training on customer data. Providers like Amazon Bedrock or Azure OpenAI run frontier model inference on their own infrastructure, so the labs never see those queries and outputs. Open-weight models served through inference providers bypass the labs entirely. On top of this, deployed agent systems can leverage different models, tools, and data sources, so one lab often doesn’t see the full trace.
• They don’t know what failure looks like to a business. Labs see the context a company sends, not its evolving policies, strategy, regulatory obligations, customer requirements, or downstream consequences. The same action can be routine at one company and a serious breach at another. Ingesting sensitive data and writing data into a new workspace, or issuing a run of refunds just under an approval limit, looks like ordinary work in a transcript. Agents usually have permission for these actions, so access controls don’t flag them either.
• Even well-targeted monitoring requires layers of review. Google DeepMind’s production misuse probes miss 22–42% of multi-turn and adaptive attacks. Paths escalating borderline issues to humans and more expensive LLM judges can help cover misses, but are prohibitive for labs over all deployments, while feasible for individual businesses.
• They aren’t independent. The provider of a product that creates risk fundamentally cannot be the actor providing oversight and audit evidence.

The costs land on deployers, most of whom have no comparable monitoring. A coding agent deleted PocketOS’s production database. Another did the same at SaaStr, despite explicit instructions not to.

Deployments are growing rapidly, so risks in business contexts are growing quickly too. In GPT-5.6 Sol training runs, OpenAI caught agents leaving themselves notes to fabricate data and conceal their actions. Only monitoring in deployment can show how much tendencies like these have carried into deployed models.

We know about PocketOS and SaaStr because they shared their experiences publicly. We can’t be sure how often such failures happen privately. In 1974, TWA couldn’t learn from United. Today, businesses deploying AI can’t learn from each other’s failures either.

Deployed monitoring catches things we don’t see in testing

Continuous monitoring complements forecasting rare events, red-teaming, and post-incident reporting. It catches behaviors we might not see in targeted evaluations through breadth and realism:

• The real world gives more ways to fail. Deployments generate rare triggers of bad behavior that no evaluation elicits. OpenAI’s evaluations passed a GPT-4o update that users quickly found sycophantic, and its internal monitoring caught agents encoding commands to slip past monitors.
• Capable models know they’re being tested. They increasingly recognize evaluations and adapt their behavior.
• Deployment means real-world consequences, and monitoring can stop harms. When agents in a UK AISI cyber evaluation took unsanctioned action against real people and organizations, it was caught only after the fact, and AISI is now adding monitoring that can block such actions as they happen.
• Failure paths are surprising. Claim-based assessments (Apollo) test predictions, but misbehavior can come in unexpected ways.

We need an open protocol that draws from the airline experience

The Center for AI Standards and Innovation (CAISI) underscores why post-deployment monitoring is important:

1. to validate that an AI system is operating reliably and as expected in real-world scenarios,
2. to track unforeseen outputs and drift, and
3. to identify unexpected consequences of integrating AI systems in new or changing contexts

The CAISI report also flags specific challenges preventing widespread implementation, including lack of trust around methods and tools, limited visibility into insights from deployed contexts, organizational incentives, and resource requirements. These look a lot like the barriers to safer operating practices experienced by airlines in the 1970s.

We don’t need to wait for policy action. We can address these challenges now. The technology is available, and continuous monitoring can have immediate net benefits for companies through failure rate benchmarking, risk identification, failure alerts, and change management.

Just like the airline industry, we need in-production monitoring and channels to share de-identified data and insights across the market.

Part of this is already being proposed. The Linux Foundation’s Shared AI Findings Exchange (SAFE) would collect confidential reports of AI security incidents and near misses and publish the lessons, much as ASRS collects reports from flight crews. Failure rates measured in production could feed into SAFE over time. But ASRS only captures what a crew notices and chooses to report. Airlines got a picture of normal operations from data recorded on routine flights. A joint industry-government body (CAST) turns that data into shared practice. Deployed AI needs the same. Standards such as ETSI’s define continuous compliance checks but leave the measuring to the companies being measured.²

This calls for an open protocol, designed to provide immediate value to businesses that use it. Most critically, the protocol should enable widespread reliable monitoring to catch live failure risks and identify trends that inform safer training and deployment system design.

For a business, adopting the practices as a deployer would entail checking all AI output and agent actions against its own failure definitions and reporting summary failure rates internally in a standard format. All sharing beyond that is voluntary. A business can share aggregated results, de-identified data on individual failures, or both, with a trusted neutral party that has no stake in the results. Pooled de-identified data lets that party find patterns no single deployment can see, the way de-identified flight data is pooled across carriers.

In return, businesses that share get three things. Benchmarks show how their failure rates compare with similar deployments. Practices that work elsewhere spread across the industry, the way CAST turns shared safety data insights into enhancements every airline can adopt. And model developers learn which failures are common across deployments, so they can train against them.

To clear CAISI’s barriers, the protocol needs methods that are trustworthy, transparent, and robust to rapid technical change. It also needs to be cheap to implement, with benefits that the firms implementing it capture themselves.

Core principles

• Complete and continuous. Each output (including tool calls and reasoning) is checked. Any exclusions or sampling are stated in conclusions.
• Standard and interoperable. A taxonomy of failure cases that can be adapted to a given business deployment, with summary measures that are comparable across contexts and easily understood.
• Robustly interpretable. Every flagged failure has evidence a person can understand, including the basis for an agent’s output and why it was flagged, without leaning on the agent’s own account of its reasoning, even as frontier models show a "substantial decrease in chain-of-thought monitorability."
• Calibrated to human judgment. Classifiers infer human judgments at scale and are updated as those judgments change, surfacing the cases most worth human review with supporting evidence.
• Reproducible. The same versioned monitors measure every model and harness version, so a change in results measures a change in the agent, not the monitor.
• Secure and privacy-protecting. Adoption and trust depend on always protecting the private data of businesses implementing monitoring practices.
• Independent. Monitoring assessments must be determined solely according to established methodology, not influenced by implementing clients or other market participants.

The taxonomy, methods, summary measures, and change process are open and shared. Monitoring providers and in-house teams build on them, and keep their own techniques for finding failures and training classifiers.

We’re publishing these principles as a starting point. Participation is voluntary today. Over time, it could become an accepted industry standard for sharing de-identified data and aggregated results. The protocol will only be credible if the people who use it, study it, and regulate it help shape it.

Where we go next

If you run AI in high-stakes workflows, we’ll measure how it has actually behaved: a free AI risk check of one to three months of your historical outputs, scored against your own failure cases, with the source and justification behind each finding. Get a free AI risk check →

If you’re a researcher, auditor, regulator, or practitioner, we’re looking for founding reviewers to shape the protocol: the failure taxonomy, the summary measures, and how results get pooled. Learn more about becoming a founding reviewer →

Clearwood is a public-benefit corporation doing independent risk monitoring for deployed AI.

1. OpenAI reports monitoring ‘tens of millions’ of internal coding-agent trajectories over 5 months vs 10+ million weekly users across ChatGPT Work and Codex as of July 2026, each producing multiple traces a week. Public references for evaluation count are hard to find, but Anthropic reviewed 141k cybersecurity evaluation runs in a July 2026 report in what is presented as an uncommonly substantial review project. Cybersecurity evaluations are only a part of overall evaluations, but they still suggest pre-deployment evaluation volumes are orders of magnitude lower than overall deployed agentic activity. ↑
2. Related work points the same way without filling the gap. Brundage et al. (2026) call for “living assessments, not stale PDFs,” including continuous monitoring, but of frontier labs rather than the businesses deploying their models. Mökander et al. (2023) place continuous auditing at the application layer, and Stein, Bernardi, and Dunlop (2024) argue for interconnected post-deployment monitoring with independent access. Certifications such as AIUC-1 retest agents quarterly with simulated attacks rather than measuring production traffic, and OpenTelemetry’s GenAI conventions standardize how traces are recorded but not how outputs are judged. The labs share threat information through the Frontier Model Forum, but deployers aren’t part of that exchange. ↑