Teams are shipping AI-generated code faster than anyone can manually review it. According to data from our recent State of Code Abundance Report, 67% of enterprise technology leaders report a significant increase in code volume, and 70% say maintaining their test suite is a bigger burden than writing code. Meanwhile, another of our recent reports found that 72% of enterprise technology leaders cite data privacy and compliance as the biggest risk associated with AI-based development tools.
More code, more compliance risk, and test suites already struggling to keep up. That's the environment compliance as code was built for. The pipelines that used to have a person check each change against company policy now handle a volume of code no one could check in time, even if they wanted to.
Large engineering organizations have had a method for making delivery more manageable from a compliance perspective for years: defining policy as version-controlled rules that run automatically within the pipeline, rather than relying on someone to review each release by hand.
At first, teams implemented compliance as code because they were releasing too often or facing too many audit requirements to keep up with manually. Now, with AI pushing code volume past what any team can review by hand, it's becoming the most practical way to enforce policy consistently at enterprise scale.
What manual compliance review used to look like
Before compliance as code, proving a release was compliant meant assembling evidence after the fact. Someone pulled screenshots of approvals, exported logs from three different systems, and matched them against a checklist a few weeks before the auditor showed up. The work happened in spreadsheets and email threads, not in the pipeline.
It worked when releases were infrequent. The evidence pile stayed small enough for someone to assemble it by hand. Audit prep was a known, scheduled event, not a constant condition, so a team could afford to scramble for two weeks once or twice a year.
Large teams replaced that scramble with compliance as code. Rules built into the automated sequence that takes code from a developer's machine to production ran automatically every time code shipped:
- Access controls checked at deploy: Before a release goes out, the pipeline confirms that only approved people touched the code that's shipping, and blocks the release if someone outside that list made a change.
- Logging requirements enforced by the pipeline itself: The pipeline records who approved the release, when it shipped, and what changed, automatically, instead of relying on someone to write that down afterward.
- Evidence generated as a byproduct of releasing: The record of approvals and changes is already there when an audit happens, rather than someone having to reconstruct it from memory and old emails.
Put simply, compliance as code is policy and audit controls written as automated rules that replace manual checklists.
Enforcement is what makes compliance as code work
Our 2026 State of Code Abundance report found that 92% of organizations say they’re confident in AI-generated code’s production readiness before it ships. But 81% of those organizations also saw an increase in production issues linked to AI-generated code, indicating a gap between the process organizations believe they have and what actually happens.
A likely culprit is lack of follow-through. The data shows that 93% of organizations have a formal process for reviewing and releasing AI-generated code, but only 56% say it's always enforced.
Some teams assume the fix is a platform migration, consolidating delivery onto fewer tools so there's less to coordinate, but the data says otherwise. Consolidating tools doesn't automatically consolidate enforcement. It just moves the gap to a new platform.
Why automating compliance in one tool doesn't close the gap
Automating compliance inside a DevSecOps pipeline usually means adding policy checks at specific points: a gate before merge, a scan before deploy, an approval step tied to a ticket. Most CI tools and scanners now support this natively. That part isn't hard anymore.
The gap is what happens between those checks. A CI tool can confirm its own gate passed. It has no way of knowing whether the security scanner's gate also passed, or whether the deploy tool's approval step ran.
Three systems, each reporting green. But the scanner only checked what it was pointed at. A library that two other services depend on never made it into the scan. The flaw sitting inside it went undetected. Every tool did what it was built to do, but because none of them could see past their own slice of the pipeline, they couldn’t tell you whether the release as a whole was compliant.
The compliance layer that sits above the tools
A team can automate policy checks in every tool they run and still ship something that violates policy, because automating compliance per tool only guarantees enforcement within that tool. It doesn't guarantee enforcement across the release the tools are all contributing to.
What's missing is a layer that sits above all those tools, reads their signals together, and catches what none of them could see on their own.
CloudBees Unify connects whatever combination of CI/CD pipelines, ticketing systems, and security scanners you already run without replacing any of them, and reads their signals against one shared policy.
CloudBees Unify correlates security findings, delivery data, and release context across connected tools so policy decisions can be made using a complete picture rather than isolated signals.
So when you're thinking about compliance as code, the question isn't which CI/CD tool is best for SOC 2 compliance. Instead, ask what tool enforces policy consistently across the CI/CD tools you already have, since SOC 2 controls like access, change management, and monitoring span multiple tools anyway. That's how Unify works: it’s not a CI/CD platform, but the policy and audit layer above it.
And while agentic coding causes these code volume and policy enforcement problems, CloudBees Unify's AI features are built to counter them. Its AI Assistant draws on the full delivery record to investigate failures and answer questions about what's blocking a release. Today, the AI Assistant helps teams investigate delivery issues, answer questions, and navigate release context using information already available in CloudBees Unify.
As CloudBees expands its agentic capabilities, the vision is to automate more governance and compliance workflows while maintaining auditability. That's the compliance layer manual, tool-by-tool checks can't provide. See how CloudBees Unify enforces policy across every tool you already run.
FAQs about compliance as code
What is compliance as code?
Compliance as code means enforcing policy and generating audit evidence automatically within the pipeline, instead of relying on someone to check each release by hand. Rules that used to live in a checklist get written directly into the release process, so evidence exists the moment code ships rather than being reconstructed afterward.
How is compliance as code different from a compliance audit checklist?
A checklist is something a person completes, usually right before an audit. Compliance as code moves those same checks into the pipeline so they run on every release, not just the ones scheduled for review. The output is closer to a continuous record than a one-time inspection.
Does automating compliance checks in each individual tool make a release compliant?
Not on its own. A CI tool, a scanner, and a deploy tool can each confirm their own gate passed without any of them knowing whether the others' gates passed too. Compliance depends on what happens across those tools, not just inside each one.
Can compliance as code keep pace with AI-generated code?
It's positioned well for it. Manual review assumed a volume of code a person could reasonably check by hand. As AI pushes that volume higher, automated, pipeline-enforced policy is one of the few approaches that scales with it.
How does CloudBees Unify fit into a compliance as code approach?
CloudBees Unify connects the CI/CD pipelines, ticketing systems, and security scanners already in use and reads their signals against one shared policy, without replacing any of those tools. That gives teams a compliance view across the release rather than a set of separate, tool-by-tool checks.
