Where should the control live?

Ask where AI controls should exist across the lifecycle and the usual answer is everywhere. True, and useless. Controls cost attention, and attention runs out. The practical question is placement: for each failure mode, find the last point where catching it is still cheap, and put the control there.

The Atlas cases sort themselves along the lifecycle once you look at them this way.

Design time. Some failures are structural after design, so the control has to happen in the review. MCAS needed the cross-check against the second sensor and the cap on its authority decided before certification, because no operational control fully compensates for a single-sensor system with unlimited trim authority already in the air. The Dutch childcare model needed nationality kept out of the inputs, full stop. Design-time controls are the cheapest ones available and the hardest to retrofit. Skipping them is what makes the later ones expensive.

Build and release. Some failures are born in the gap between what you tested and what actually shipped. Knight Capital is the canonical case. A release check that all eight servers ran the same code would have cost nothing and saved the firm. That control has to live at release, because release is where the divergence happened.

Deploy. Blast radius is a rollout property. CrowdStrike’s malformed file was going to get past its validator eventually. What turned a bad file into a global outage was sending it to every machine at once. A staged rollout, small ring first, is the control, and it only exists at deploy time.

Run. Some hazards only exist in the moment of action. The Replit agent needed a hard approval gate in front of irreversible commands at the second the command was issued, because no design review constrains what an improvising agent does on a Thursday afternoon. Uber needed the automatic emergency braking left on, because run time is when the rare case shows up and the human is too slow.

Three placement rules come out of this. Match the control to the point where the failure becomes irreversible, which is usually earlier than where monitoring is easiest to bolt on. Give critical failure modes two controls, one early and one late, since the early one erodes and the late one has to assume it did. Therac-25 shows what happens when the late one gets deleted on the theory that the early one is enough. And when a review finds a missing control, ask where before asking what. The same idea, verify before acting, shows up as a design principle, a release check, a rollout ring, and an approval gate. It only works if it sits where your particular failure is born.