A mediocre control at the right phase of an AI system’s life routinely beats an excellent control at the wrong one. Organizations spend most of their effort choosing controls and almost none deciding when those controls apply.
So the useful question is never which control to add. It is where the problem was actually created.
The seven phases
The most widely referenced description of an AI system’s life comes from the OECD, whose Recommendation on Artificial Intelligence was the first intergovernmental standard on AI. It is not law and nobody is fined for departing from it, but it supplies the vocabulary that the binding regimes borrowed: the EU AI Act’s own definition of an AI system was aligned with the OECD’s.
It defines seven phases.
Nothing in that list is surprising on its own. What is useful is treating it as a map of where accountability sits, because each phase creates a different class of risk and closes off a different set of remedies.
Why the phase matters more than the control
Three different problems look identical from the outside. Each one shows up as the same complaint: the model said something it should not have. The symptom is shared. The cause, and the fix, are not.
| What actually happened | Where it originated | The control that works |
|---|---|---|
| The model repeats its training data, and someone’s personal details surface in an answer. | Collect and process data | Remove duplicates and strip personal data before training. An output filter is a compensating control, a safety net, not a fix. |
| The model reveals a document it was handed at run time that the user was never allowed to see. | Retrieval, at run time | Check permissions at the moment of retrieval. Retraining changes nothing. |
| The model has quietly gone stale: no attacker, no leak, the world changed and the model did not. | Operate and monitor | Monitoring, with a threshold and a pre-agreed consequence when it breaks. |
One symptom, three phases, three unrelated fixes. A team that has not decided where its controls belong will reach for whichever one it already owns.
The law already works this way. The EU AI Act attaches its high-risk requirements by phase: data governance to the data, documentation and logging to the build, human oversight to operation, and monitoring to the period after release. It is phase-shaped because the risk is.
The loop that most diagrams leave out
Here is the part worth reading twice. The OECD is explicit that these phases “often take place in an iterative manner and are not necessarily sequential,” and that the decision to retire a system may be taken at any point during operation and monitoring.
That is not a footnote. Drawn as a one-way conveyor, the life cycle quietly teaches a governance model where you inspect once, at release, and then you are finished. That model is how the eight-month bias problem happens.
In practice the two returns matter more than the forward path:
- Operate sends you back to build. Drift, a new data source, a fine-tune, or a provider updating the model underneath you all put you back at an earlier phase, and they should put you back through the gate that belongs to it. A fine-tune that skips safety evaluation because “we already validated this model” is the common version of this failure.
- Retirement is not the end of the line. It can be triggered from operation, at any time, and deciding in advance what evidence would trigger it is a governance act rather than a technical one.
What to actually gate
The practical version of all this is small. Four questions, each attached to a phase, each with a named owner.
Before data is collected: on what lawful basis, and for what purpose? Data gathered to run a service is not automatically available to train on. This is the cheapest gate in the whole life cycle and the one most often skipped, because at that point there is no system yet to point at.
Before release: what would have to be true for us not to ship? Accuracy alone does not answer this. If there is no written threshold for bias, robustness, or unsafe output, then “it performed well” is the only available verdict, and it is not a verdict about risk.
During operation: what are we measuring, and what does a breach of it trigger? A threshold with no pre-agreed consequence is a metric, not a control. The consequence should be decided while nobody is under pressure.
At any point: who can switch it off, and what happens to the business when they do? If the answer is that the process simply stops, you do not have a fallback, you have a dependency.
The uncomfortable part
Most organizations gate once. They gate at release, because release is visible, schedulable, and feels like the moment of decision. It is the phase where the fewest problems originate and the fewest remedies remain available.
The life cycle is worth internalizing not because ordered lists are satisfying, but because it tells you where to stand. When something goes wrong with an AI system, the useful first question is not “which control failed.” It is “which phase did this originate in, and what were we doing at that phase.” That question tends to produce an answer you can act on, and it is usually less flattering than the one about controls.