I’ve spent years building compliance into security products. FedRAMP and Department of War Impact Level authorizations, vulnerability management pipelines: They all follow the same pattern. Build the product, then prove it meets requirements. The compliance layer sits outside the engineering workflow. It reviews what already exists.

That model worked when the product stayed static between audits. It breaks for AI.

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.

AI systems do not hold still. A model fine-tuned on last quarter’s customer data produces different outputs once this quarter’s data enters the pipeline. A retrieval-augmented generation system returns different answers depending on which documents sit in its index today versus yesterday. An agentic workflow that chains three models together produces emergent behaviors that no single-model evaluation captures. Governance-as-periodic-review was built for a world where the artifact under review doesn’t change. We are deploying artifacts that change continuously.

The gap between how fast AI systems evolve and how slowly review-layer governance cycles operate is the core vulnerability. Every week that gap widens, organizations accumulate governance debt they will eventually have to repay, either on their own terms or on a regulator’s.

What release infrastructure looks like in practice

When I researched China’s AI deployment process, I expected to find a heavy-handed approval system that slowed companies down. I found the opposite.

China requires companies deploying generative AI to complete a regulatory filing before their product reaches consumers. The filing demands documentation of training data sources, content safety mechanisms, output controls and user-facing disclosures. Companies that clear the process ship. Companies that do not, wait.

What surprised me was the speed. Baidu launched Ernie Bot to the public on August 31, 2023, sixteen days after China’s generative AI rules took effect. Dozens of companies followed within weeks. The filing process did not stop deployment. It sorted companies by those that had already built the evidence machinery to pass. The firms that treated compliance as a last-mile legal exercise fell behind.

That finding matters for Western security leaders. We should not replicate China’s regulatory model. The underlying operational problem, though, is identical. The EU AI Act reaches the same conclusion from a different regulatory tradition: Its conformity assessment and ongoing risk management requirements for high-risk AI systems assume continuous compliance, not one-time certification. The operational question both frameworks share is the same one I face in my own work: Where in the development process does governance actually live? If the answer is “after the model is trained and before it ships,” you’ve recreated the review-layer bottleneck. Engineering teams will find ways around it.

I saw the same pattern with SBOMs. When teams treated the SBOM as a document someone assembled for a customer questionnaire, it aged out almost immediately. When they generated it from the build pipeline, it became part of the product’s living operating record. Model documentation has to move the same way. A model card written by hand after release is a snapshot. A model card generated from the pipeline is evidence.

Three shifts security leaders should make now

I’ve started applying this principle in my own work and in how I advise teams evaluating AI deployment readiness. Three operational shifts make the difference.

First, move model documentation into the CI/CD pipeline. Treat model cards, training data provenance records and output behavior baselines the same way you treat SBOMs: As artifacts generated automatically during the build process, not as documents written by a compliance analyst after the fact. If your model documentation isn’t versioned alongside your code, it’s already out of date. Every model retraining cycle that doesn’t produce updated compliance artifacts widens your governance gap.

Second, make compliance evidence a deployment gate rather than a post-launch audit item. Your release pipeline probably already blocks deployment if unit tests fail or if a container image carries a critical vulnerability. Add AI governance checkpoints to that same pipeline. Does the model have a current risk evaluation against your organization’s defined thresholds? Is the training data lineage documented and traceable? Are output controls configured, tested and monitored? If the answer to any of those is no, the deployment doesn’t proceed. The pipeline already blocks vulnerable containers. AI governance checkpoints belong in the same layer. It’s extending your existing security architecture to cover a new class of risk.

The problem gets sharper when the AI system stops generating recommendations and starts taking actions. Third, treat agent identity as a first-class security control. As AI agents move into production environments, each one needs an identity in your IAM system with scoped permissions, audit trails and session-level accountability. An agent calling external APIs, reading customer data or triggering automated workflows is an actor in your environment. It requires the same identity governance you apply to human users and service accounts. I wrote about the identity and persistence challenges in stealthy ransomware operations earlier this year here at CSO. The same principles apply: If you can’t identify the actor, you can’t govern the action.

None of this requires waiting for regulation. The organizations that will be best positioned when AI-specific compliance mandates arrive, whether from the EU AI Act’s enforcement timeline, emerging US state-level legislation in Colorado and California or sector-specific rules from financial and healthcare regulators, are the ones building governance into their release infrastructure now. The ones still treating it as a review layer will scramble to retrofit what their competitors already ship with.

I learned that lesson by studying how a very different system solved this problem first. The regulatory traditions are different. The operational logic is the same: Governance that ships with the product beats governance that reviews it after the fact.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?