Compliance as Code

In regulated industries, compliance is checked at the end today: before going live, projects collect documents, fill in checklists, and wait for approvals from security, data protection, and internal audit. In the agentic Software Development Lifecycle, this pattern no longer holds, because agents produce more changes in less time than any downstream review could ever handle. This article describes how we move regulation into the pipeline: policies are written as machine-readable rules, checked automatically at every gate, and backed by a complete audit trail, so that evidence emerges as a by-product of the work.

Why downstream review no longer holds

The first three articles in this series covered the division of labor between people and agents, quality gates at which people decide, and measuring maturity. The fourth building block is governance, and in regulated organizations it decides whether an agentic pilot ever reaches production. Of the four reasons agentic transformations fail, "governance too late" is, in my view, the most treacherous: supervisors, internal audit, data protection, and the works council only come to the table shortly before go-live, and the rollout stops on the last mile.

The problem is structural, not organizational. A downstream compliance review assumes that there are few, large releases that can be examined individually. Agentic cells, however, deliver in cycles of days, in mature cells of hours. If each of these changes has to pass through a compliance review lasting several weeks, the time gained is lost before it reaches the business. If the review is reduced to spot checks instead, the organization loses precisely the traceability that regulation demands. Neither is an option.

There is a second problem: a language model does not know your organization's security policies, nor its architecture guidelines, data classification, or the retention periods from sector-specific law, unless someone provides them as a verifiable rule. A policy that exists only in a document is neither read nor followed by an agent. For the agent, it does not exist.

A policy that lives in a document is remembered. A policy that lives in the pipeline is followed.

What Compliance as Code means

Compliance as Code means treating policies the way you treat software: they are written in machine-readable form, versioned, tested, and enforced in the delivery pipeline as gate criteria. Three properties distinguish this from the classic policy on the intranet.

• Verifiable. Every rule has an automated check that runs at a defined gate. A rule that cannot be checked is not yet a rule but an intention, and it is refined until it becomes verifiable.
• Versioned. Rules have owners, a history, and an approval process. Whoever changes a rule leaves a traceable record, exactly as with a code change.
• Enforced. A violation blocks the gate. Exceptions are possible, but they are documented, time-limited, and personally accountable decisions, not silent workarounds under deadline pressure.

In our projects, the rules fall into four classes. Security rules cover, for example, dependencies with known vulnerabilities, impermissible licenses, secrets in code, or encryption standards. Architecture rules define which technologies, interface standards, and layer boundaries are permitted and where data may reside, for instance exclusively in European data centers. Data protection rules describe which data classes may be processed in which environments, which deletion periods apply, and what must be logged. Finally, business-regulatory rules are requirements from laws and supervisory guidance that the system itself must meet: a four-eyes principle above a certain amount, a retention period, a reporting obligation.

The fourth class shows that Compliance as Code has two levels. The first is compliance of the process: how is the software created, who is accountable for which change, what is logged? The second is compliance of the product: does the software demonstrably meet the regulations that apply to its use? Both levels belong in the pipeline, but they are checked at different gates and with different means.

Three principles carry governance

In our operating model, oversight of agentic delivery rests on three principles. First, a person is accountable for every change an agent makes; accountability toward supervisors, internal audit, and partners remains clearly personalized. Second, policies are enforced in pipelines as Compliance as Code instead of being remembered in documents. Third, a complete audit trail makes every agent action, every context used, and every approval reconstructible.

European regulation demands exactly these building blocks. The AI Act, Regulation (EU) 2024/1689, in force since August 2024, requires for high-risk AI systems, among other things, a risk management system, technical documentation, record-keeping, and human oversight (Articles 9, 11, 12, and 14). DORA, Regulation (EU) 2022/2554, has applied to financial entities since January 2025 and requires robust ICT risk management, the management of ICT-related incidents, digital operational resilience testing, and the management of third-party providers. And internal audit has always required that every production change be traceable.

A note on classification: whether an AI system counts as high-risk depends on its intended purpose, not on the technology. That is why Compliance as Code also includes classifying and documenting the intended purpose of every agent. And if the software the agents build itself falls under the regulation, its requirements become requirements in the specification, with test cases like any other requirement.

Where the rules take effect in the pipeline

The four gates from the second article in this series are also the places where Compliance as Code takes effect. The same division of labor applies at every gate: agents generate, agents verify, people decide.

1. Definition of Ready. Regulatory requirements are part of the specification as verifiable requirements, each with a reference to the regulation it stems from. With reqChecker, we check whether they are unambiguous, verifiable, and singular; only then do they become the basis for test cases and machine-readable build orders. The knowledge graph links regulation and requirement, so the origin of every rule is documented.
2. Definition of Done. Before every merge, the process-compliance checks run: security scans, dependency and license checks, architecture rules, secret detection in code, test coverage. Independent verification agents run them; no agent verifies its own work. A violation blocks the gate, and what reaches the person is a verified result with a test log.
3. Definition of Deploy. Before go-live, product compliance is demonstrated: acceptance tests against the specification with Signoff, including the regulatory requirements, a security review by our experts, and a tested rollback. The go/no-go decision is made by a person, based on an audit-proof acceptance report.
4. Definition of Operability. In operations, observability, logging, and incident accountability take over. Incidents are detected, documented, and reported, as DORA requires for the financial sector, and the lessons flow back into the backlog and the specification.

The decisive side effect arises in the knowledge graph: because regulation, requirement, code, test case, and release are connected through typed, evidenced relationships, the chain of evidence is not produced as a separate project before the audit but continuously. When a regulation changes, an impact analysis shows within minutes which requirements, modules, and tests are affected. Until now, that question took weeks in grown landscapes.

What this demands in practice

Compliance as Code is not a tooling decision but an organizational one. Five consequences can be drawn from our projects.

• Start small, but binding. Not all policies are codified at once. We start with the rules that most often delay approvals today, usually security and dependencies, and expand domain by domain along the pilot cells. In our approach, quality gates and Compliance as Code are already in production during piloting; they become organization-wide in the second horizon of the maturity path, when agents execute multi-step orders across business units.
• Internal audit, data protection, and security become authors. The specialists who check at the end today write the rules at the beginning. This shifts their role from control at the end to source of the rule at the start, and brings exactly those stakeholders to the table early whose late arrival stops rollouts.
• Every rule needs an owner. A rule without accountability goes stale, and a stale rule that keeps blocking gates undermines acceptance of the whole approach. Exceptions are time-limited and documented with a rationale.
• The chain of evidence belongs to the organization. Rules, check results, and the audit trail live in your own platform and your own knowledge graph, not with the model provider. You will change models several times in the coming years; the evidence stays.
• Measure the guardrails. Alongside delivery efficiency, the share of rules checked automatically, the time from change to approval, and the four metrics of delivery research (Forsgren, Humble, Kim 2018) belong in management reporting. Efficiency gains only count if change failure rate, production incidents, defect rate, and test coverage do not deteriorate.

That this path is viable even in strictly regulated organizations is shown by a program at a large European bank that we support: under banking supervision, DORA, and the AI Act, a capability model with 41 capabilities in nine domains across six maturity levels was built, mapped to regulation, with "security, risk, and compliance" as a domain of its own. In the portfolio logic we use to prioritize such programs, Compliance as Code counts as a strategic bet, alongside agentic pilot cells and the knowledge graph for legacy code: with a business case, board sponsorship, and staged funding, not as a quick win (program figures anonymized and rounded, project status first quarter of 2026).

The economics are clear: the up to 5x faster delivery in the agentically orchestrated implementation model and the 20 to 45 percent efficiency gain across full projects (experience values from ReqPOOL projects 2023 to 2026, verifiable per project) are achievable in regulated industries only if compliance checking keeps pace with delivery. Compliance as Code is the condition for that, not the price.

How we do it ourselves: reqCoder

In reqCoder, ReqPOOL's complete, fully automated agentic Software Development Lifecycle, which is already in internal use at ReqPOOL, these principles are hard-wired. The chain of evidence across the four stages includes the reqChecker check and security scan in the beta, Signoff acceptance and audit trail in the deployment stage, and the complete transfer of intellectual property in production. Every agent action, every context used, and every approval is logged and can be reconstructed. The models are connected through EU data centers, and there is no training on client data. Every approval at a gate remains a human decision.

Built correctly, the agentic Software Development Lifecycle is therefore not the compliance risk it is taken for in many organizations, but the first form of delivery in which evidence emerges as a by-product of the work. That, in my assessment after the four articles of this series, is the real reason why regulated industries should not be the last but the first to shape the transition.

The next step

How we anchor governance, quality gates, and Compliance as Code in your delivery organization is described on the Agentic Software Development Lifecycle page. What the chain of evidence and the audit trail look like in our own agentic pipeline is described on the reqCoder page. In an expert meeting, we jointly examine which of your policies can already be written in machine-readable form today and at which gate they should take effect first.