At 4:17 a.m. on February 6, 2023, a magnitude 7.8 earthquake tore through southeast Turkey while most of the region was asleep. Ten million people within the alert radius were within reach of a warning system built to give them up to 35 seconds to get away from a collapsing building. The system sent its highest-level warning to 469 of them.
This is not a story about a rare, unforeseeable technical glitch. It’s a story about what happens when a live, high-stakes AI system runs for years without the governance structure to catch, disclose, and correct its own failure. More than 55,000 people died in the earthquake and the aftershock that followed it that same day. The system built to warn them had been misjudging the earthquake’s severity in real time, and the company that built it spent more than two years insisting otherwise before finally admitting what had gone wrong, as the BBC’s investigation later confirmed.
For anyone working in AI governance, this case is close to a textbook example of why post-deployment monitoring, honest incident reporting, and documented risk tradeoffs aren’t paperwork. They’re the difference between a system that improves after failure and one that quietly keeps failing.
Watch the full case breakdown:
How the System Was Supposed to Work
Google launched the Android Earthquake Alerts (AEA) system in 2020 in partnership with the U.S. Geological Survey, turning ordinary Android phones into a distributed seismic network. Rather than relying solely on dedicated ground stations, the system watches for large numbers of phones detecting shaking at the same time, uses that pattern to estimate the earthquake’s location and magnitude, and pushes a warning ahead of the worst shaking.
The system issues two tiers of alert. A lower-tier “Be Aware” notification behaves like an ordinary alert. A “Take Action” warning is designed to override Do Not Disturb and other device settings with a full-screen, audible alarm, because it’s meant for shaking severe enough that a few seconds of notice could mean getting away from a wall or a doorway before it matters. Which tier a user receives depends entirely on the AI’s real-time magnitude estimate, and that estimate is where the system broke down.
The Technical Failure: A Model That Misjudged Its Own Inputs
Google’s algorithm read the shaking from the Turkey earthquake and classified it as a magnitude 4.5 to 4.9 event, roughly a hundredfold underestimate of the actual energy released by the 7.8 magnitude quake. Because the system’s alert tier is a direct function of that estimate, a system built to detect exactly this kind of event failed at the one moment it existed for.
This is a known, documented failure mode for crowdsourced earthquake detection: distinguishing a genuinely massive quake from a smaller, more localized one using only phone accelerometer data gets harder, not easier, as the event gets larger, because the shaking pattern near the epicenter of a huge quake can initially look similar to a moderate one before the full scale becomes apparent. Google later published research acknowledging limitations in its detection algorithms, and after revising its models, the company simulated how the same earthquake would have been handled under the updated system. According to Google, the corrected algorithm would have sent Take Action alerts to the full 10 million people in range, plus tens of millions more Be Aware notifications. That gap, between what the system did and what it was capable of doing with a corrected model, is the entire story in one comparison.
It’s also worth noting the system’s failure wasn’t confined to the first quake. When a second magnitude 7.5 earthquake struck the same region later that day, the system again underestimated the shaking, though it performed somewhat better on the second event.
The Governance Failure: Nobody Caught It in Time
A model that misjudges a rare, extreme event during a live deployment is a hard engineering problem. What turns it into a governance failure is that nothing in Google’s process caught the gap between predicted and actual performance in the moment it mattered, or in the months immediately after.
This is precisely what the “Measure” and “Manage” functions in the NIST AI Risk Management Framework exist to prevent. NIST’s guidance calls for AI systems affecting human life, health, or safety to be evaluated regularly against real-world outcomes, not just pre-deployment test sets, and for organizations to track failure response times as a safety metric in its own right. ISO/IEC 42001 builds the same expectation directly into its clause structure: Clause 9 requires organizations to define metrics for AI system performance and regularly analyze whether the system is meeting its objectives in production, not just at launch.
A live earthquake is about as clean a real-world test as an AI safety system will ever get. Every seismic event the AEA system responded to after 2020 was an opportunity to compare its magnitude estimate against ground-truth seismological data and flag discrepancies before a catastrophic one arrived. There is no public evidence that this comparison happened in a way that surfaced the underestimation risk ahead of February 2023, which is the gap that formal post-deployment monitoring, not just the underlying model, is supposed to close.
The Transparency Failure: Two Years Between “Performed Well” and the Admission
The technical failure happened in a matter of seconds. The disclosure failure took over two years to resolve, and it may be the more instructive part of this case for anyone building an AI governance program.
In the months following the earthquake, Google told the BBC it was confident the system had performed correctly. It took a sustained BBC Newsnight investigation, including interviews with survivors across three Turkish cities, none of whom had received a warning before the first tremor, before Google acknowledged in July 2025 that the system had, in fact, failed to deliver the correct alert level to the people who needed it. A researcher who reviewed the case put the frustration bluntly, noting that people died and the system’s real-world performance didn’t match what was claimed.
Both the EU AI Act’s post-market monitoring obligations and ISO/IEC 42001’s Annex A controls treat rapid, honest incident disclosure as a control in itself, not an optional follow-up to fixing the underlying model. Annex A explicitly extends monitoring obligations past the point of deployment, requiring organizations to keep watching a system’s real-world behavior on an ongoing, risk-based schedule rather than treating a launch review as the last checkpoint. A two-year gap between an incident and a public, technical accounting of what happened is difficult to reconcile with that standard, regardless of how the underlying model performed.
This isn’t an isolated pattern for the AEA system, either. In August 2025, a false alarm sent unwarranted earthquake alerts to users in Brazil during a period with no actual seismic activity, a reminder that both false negatives (Turkey) and false positives erode the same thing: public trust that the alert, when it comes, means something.
Speed vs. Accuracy Was a Governance Decision, Not Just an Engineering One
Every real-time detection system trades speed for accuracy. Waiting longer to confirm an earthquake’s true magnitude produces a more accurate estimate, but it also shrinks or eliminates the warning window that makes the system useful in the first place. That tradeoff is unavoidable, but where an organization sets the dial, and how explicitly that decision is documented, reviewed, and revisited, is a governance choice, not a purely technical one.
Nothing published about the AEA system indicates the speed-versus-accuracy threshold was treated as a standing risk decision subject to periodic review, rather than a parameter set once at launch and left alone until a real disaster exposed its limits. For any organization deploying an AI system where the failure mode is measured in human lives, that threshold decision belongs in the same governance record as the model’s performance metrics: reviewed on a cadence, owned by a named accountable role, and revisited every time real-world performance data comes in, exactly as continuous monitoring is intended to feed back into risk management under both ISO 42001 and the NIST AI RMF’s Manage function.
A Practical Checklist for High-Stakes AI Monitoring
For any organization running an AI system where a false negative could cost someone their safety, not just a metric on a dashboard, this case suggests a concrete, minimum set of governance controls:
- Treat every real-world event as a live test. Don’t wait for a catastrophic failure to compare model output against ground truth; log and review the gap after every relevant event, however minor.
- Set an explicit, documented speed-versus-accuracy threshold, owned by a named accountable role, and revisit it on a fixed schedule and after every material incident.
- Define a disclosure SLA before an incident happens. Decide in advance how quickly a confirmed system failure gets communicated externally, and to whom, so the decision isn’t made under pressure after the fact.
- Separate “the system technically ran” from “the system worked.” A system that stayed online and issued an alert during the Turkey earthquake could still be reported internally as functioning; the metric that mattered was whether the alert matched the actual severity.
- Audit vendor and platform-level AI, not just in-house models. The AEA system operates independently of national disaster agencies in the countries where it’s deployed; organizations relying on third-party safety-critical AI need the same monitoring rigor they’d apply to a system they built themselves.
- Map the control to a framework you can be audited against. ISO 42001 Clause 9 and Annex A.10.3, and the NIST AI RMF’s Measure and Manage functions, both give this kind of monitoring program a documented, auditable structure rather than an informal practice.
The Bottom Line
Google’s earthquake alert system is not a bad idea, and the underlying concept, turning a billion phones into a seismic sensor network, is genuinely valuable in the dozens of countries that have no dedicated warning infrastructure of their own. That’s exactly why the governance gap matters: the technology worked well enough, often enough, that nobody built the monitoring discipline to catch it on the one day it mattered most.
AI governance professionals exist to close that specific gap: between a system that passes its lab tests and a system that keeps performing once it’s making life-or-safety decisions in the real world, unsupervised, at 4:17 in the morning. That’s not a compliance formality. It’s the actual job.
If you’re working toward a career built around catching these gaps before they cost lives, GAICC’s ISO/IEC 42001 Lead Implementer Certification covers exactly this kind of post-deployment monitoring and incident governance in depth, worth a look if this case study hit home.
