AI systems change even when the base model does not. A retrieval index updates overnight. A new tool gets added to an agent’s action space. An evaluation that passed on Tuesday no longer reflects what the system does on Thursday. The compliance-as-review approach assumes that the thing you’re reviewing remains unchanged between review cycles. For AI, that assumption is fundamentally wrong. Most organizations I talk to are still trying to govern AI the way they govern traditional software: Build it, ship it, then ask legal to check the box. For AI, it leaves the release process blind to the thing most likely to change.
When I started researching how other countries handle this problem for my forthcoming book on China’s AI ecosystem, I found something that challenged my assumptions. Chinese AI companies don’t treat governance as a gate they pass after the model works. They treat it as release infrastructure: Compliance checkpoints embedded in the deployment pipeline itself. No checkpoint clearance, no product launch. The governance layer doesn’t review the product. It is part of the product.
In one AI deployment review I joined, the product team had everything the launch meeting usually rewards: Performance metrics, customer use cases, latency numbers and a firm release date. The missing pieces were not on anyone’s checklist. No one could point to a current, pipeline-generated record of the retrieval index feeding the model. No one owned the output-monitoring thresholds. No one had tied model evaluation results to an enforceable release gate. The team wasn’t ignoring governance. Governance simply had no place to live inside the actual release process.
The review layer is already failing
That scene is not unusual. When governance lives outside the engineering workflow, it competes with delivery timelines. Delivery timelines win every time. The NIST AI Risk Management Framework identifies govern, map, measure and manage as core functions for AI risk, but it doesn’t prescribe where those functions sit inside a release process. That leaves the hard architectural question to the security organization. Most companies default to what they know: A periodic review cycle borrowed from traditional IT compliance. That cycle was designed for systems that hold still between audits.
