There is a specific kind of meeting that happens in large organisations after a production incident. Someone pulls up the change log. Everyone in the room looks at the same thing: every change that preceded the failure was approved. Reviewed. Signed off. The CAB did its job. The system still failed.
This is not a story about a rogue change that slipped through. It is a story about what happens when the change approval process is mistaken for change failure prevention. They are not the same mechanism.
What the research actually found
Between 2014 and 2017, Nicole Forsgren, Jez Humble, and Gene Kim ran the largest study of software delivery performance ever conducted. Over 23,000 survey responses. More than 2,000 unique organisations. The results were published in Accelerate (IT Revolution Press, 2018).
One of the findings is uncomfortable for anyone who has sat on a CAB, chaired one, or required one as a condition of deployment: the use of a Change Approval Board had no statistically significant positive effect on change failure rate. In some configurations, it was negatively correlated — organisations that relied heavily on external approval processes had worse stability outcomes than those that did not.
The CAB was more common among the low performers. Not because CABs cause failure — the causality runs in the other direction. Organisations with tightly coupled, difficult-to-test systems are the ones that need heavyweight change approval processes. The CAB is a symptom of the architectural condition, not a remedy for it.
The structural reason
A CAB can review the intent of a change. It cannot predict the interaction effects of that change with the 40 other components the system touches in production. In a tightly coupled architecture — where a change to one component requires coordinated changes in dependent components — the risk surface of every deployment is the entire system, not the component being changed. No approval process can adequately govern that surface. The only thing that governs it is the architecture itself.
Forsgren et al. identify loosely coupled architecture as one of 24 capabilities that drive delivery performance. The definition is precise: teams can deploy, test, and roll back their component independently, without requiring a coordinated deployment of any other component. When that condition is met, the blast radius of any single change is bounded by design. When it is not met, the blast radius is unbounded — and no amount of CAB rigour changes that.
"High performers understand that they don't have to trade speed for stability or vice versa, because by building quality in they get both. Low-performing teams working to increase tempo but not investing enough in building quality into the process end up with larger deployment failures that take more time to restore service."
Why this matters for AI systems specifically
Enterprise AI deployments are inheriting this problem at speed. A model is deployed behind an API. The API sits in front of a data pipeline. The data pipeline feeds from a system of record. The inference service writes to an audit log. The audit log is read by a compliance dashboard.
In most organisations, each of these components is owned by a different team. Each team has its own change process. The model can be retrained and redeployed without the API team knowing. The data pipeline can be updated without the inference service being re-tested. A schema change in the system of record can alter every feature the model receives without triggering a model re-evaluation.
The CAB sees each of these changes in isolation. The system experiences them as a compound event. The failure mode is not the change that was approved last. It is the interaction between the last six changes that nobody mapped.
The question to ask before the next ARB
The EU AI Act's Article 9 requires a risk management system that identifies and evaluates risks throughout the operational lifecycle — not just at the point of initial deployment. An architecture where one component change can produce a failure in a component the change did not touch is an architecture with an unmanaged risk surface. The CAB cannot manage it. The architecture has to.
The question is not whether your change process is rigorous. It is whether your architecture makes the question relevant. And the way to answer that question before the next ARB is straightforward.
Ask this of every component in your AI system: can this component be deployed, tested, and rolled back without requiring a coordinated deployment of any other component?
If the answer is yes for every component, your architecture bounds its own failure modes. If the answer is no for any component, the blast radius of every deployment to that component is larger than the component itself — and no approval process governs what you cannot see.
The answer to this question belongs in the ADR. Not as a design aspiration. As a documented, verified constraint — with the organisational implication stated plainly: if the answer is no, the org chart is the constraint, not the technology.