Two AI weather/flood tools crossed my feed within a few months of each other, both with genuinely impressive claims. DeepMind’s GraphCast could generate a full 10-day global forecast in under a minute on a retail-grade GPU, and was already competitive with the ECMWF’s operational model on several parameters. Google’s Flood Hub was forecasting river levels up to 7 days out — trained on public weather products, gauge records and satellite imagery, and claiming better skill than GloFAS, the widely-used global standard.
Neither of those claims surprises me, and I’d expect the state of the art to have moved further again by the time you’re reading this — this is a fast-moving space and anything I say about specific coverage or benchmark numbers will be stale within a year. What’s more durable is the set of questions worth asking before any of these get near an actual warning decision, and six years running DELFT-FEWS in Seqwater’s Flood Operations Centre shaped mine fairly specifically.
The questions that actually matter operationally
Where does the training data come from, and does that match your catchment? A global model trained predominantly on well-gauged basins in the northern hemisphere is not obviously going to perform the same way on a flashy, poorly-gauged Australian catchment with a completely different rainfall-runoff regime. “Trained on publicly available global weather products, river gauge measurements and satellite imagery” is a reasonable pedigree — it’s also a description that could apply equally well to a tool that performs brilliantly on the Mississippi and mediocrely on Norman Creek.
Is the skill claim benchmarked against events you’d actually care about? Beating GloFAS on aggregate skill metrics across a global gauge network is a real achievement. It’s a different question from “would this have given useful lead time on the February 2022 Brisbane event,” and the second question is the one that matters to an emergency manager deciding whether to trust a 7-day forecast enough to act on it.
Can you explain a bad forecast after the fact? Traditional hydraulic and hydrologic models have an interpretable failure mode — you can trace a bad forecast back to a rainfall input, a loss parameter, a routing assumption. A learned model’s failure mode is a black box until someone builds the tooling to open it. For a tool sitting upstream of an evacuation decision, “the model was wrong and we don’t fully know why” is a materially worse position to be in than “the model was wrong because the rainfall forecast busted,” even when both produce the same bad outcome.
What’s the actual deployment path into an operational system? A public API and a genuinely useful research result are not yet an operational flood forecasting system. Getting from “impressive demo” to “trusted input alongside DELFT-FEWS in a 24/7 flood operations centre” involves validation, redundancy, failure handling, and institutional trust-building that has nothing to do with the underlying model’s skill score — and everything to do with why operational forecasting systems tend to be conservative about adopting new components regardless of how good the headline numbers look.
Where I actually expect this to land first
Not, I think, as a wholesale replacement for physically-based operational systems in the near term — the explainability and validation gaps above are real, not just bureaucratic caution. More likely: as a genuinely valuable second opinion sitting alongside a traditional system, flagging situations worth a forecaster’s attention, or extending lead time in catchments where a physically-based model isn’t economically justified to build and maintain (which, for a country the size of Australia with the gauge density we actually have, is most of them).
That’s not a small role. A tool that gives a reasonable early warning on a catchment that currently has no forecasting capability at all is a genuine public safety improvement, even with all the caveats above attached. The risk isn’t AI forecasting existing — it’s AI forecasting arriving in an operational context faster than the validation and explainability tooling needed to trust it in a warning decision, which is a people-and-process problem as much as a modelling one.