Compliance as Executable Policy

Most organizations treat compliance as a document. A policy is written, reviewed, signed, and filed. The system is built separately, and somewhere in between a control owner attests that the two are aligned. For deterministic software, updated on a release schedule, that arrangement mostly works.

However, an agent does not read your policy PDF, and it does not pause for your quarterly control review. It acts on live context, probabilistically, potentially thousands of times a day, and it may behave differently after an overnight model update that no one filed a change request for. A compliance regime that lives in a document beside the system cannot govern a system that moves that fast. The obligation has to run inside the system, or it does not run at all.

This is the shift the EU AI Act, DORA, and GDPR quietly force on regulated enterprises: compliance stops being a PDF and becomes code that executes, emits verdicts the workflow must obey, and leaves evidence a regulator can reconstruct.

Policy is code your compliance team owns

The instinct is for engineers to embed compliance logic in the agent's code. That is the wrong owner. The people accountable to the regulator are your compliance team, so they have to own the rules, and be able to prove it.

In practice that means policy-as-code: a policy decision point, an OPA or Rego engine, that your compliance team versions, tests, cryptographically signs, and approves before deployment. Mechanism is cleanly separated from decision. The engineers build the machinery that asks the policy engine "may this proceed?" The compliance team owns the rules that answer. Neither can quietly overrule the other, and the separation is itself auditable.

The dividend is that a compliance rule is now a testable, versioned artifact with a signature and an owner, not an interpretation living in someone's head or buried in application code. When a regulator asks "who decided this was allowed, and when?", the answer is a signed policy version, not a meeting no one minuted.

Policies also expire by time-to-live. Every rule must be reviewed, re-approved, and re-signed on schedule, which makes staleness visible and governable instead of silent. A rule that has quietly aged out of relevance stops being invisible risk and becomes a flagged item someone has to sign again.

Every gate resolves to one of four verdicts

For the workflow to obey the policy, the policy has to speak in verdicts the workflow can act on. Every compliance gate resolves to one of four.

• ALLOW. All conditions satisfied. The agent proceeds without human intervention.
• ALLOW-WITH-CONDITIONS. Partially met. The agent proceeds under documented constraints, such as extra logging, a scope limit, or a review flag.
• DENY. A hard condition fails. The transaction is blocked, with no exception path.
• REQUIRE-HUMAN. The call carries regulatory weight that cannot be delegated. The agent only analyses; a human decides.

The four verdicts are what convert "the system is compliant" from an assurance into a mechanism. An assurance cannot be tested. A verdict can: you can point at any transaction and see which verdict fired, under which policy version, and why.

REQUIRE-HUMAN is the load-bearing verdict for regulated work

Of the four, one carries the weight of the regulated use case, and it is worth connecting directly to the law.

Under GDPR Article 22, a person has the right not to be subject to a decision based solely on automated processing where it produces legal or similarly significant effects. The credit decision, the claim denial, the compliance sign-off: these cannot be fully delegated to a machine. In this architecture, they resolve to REQUIRE-HUMAN by policy. The agent prepares, verifies, and orchestrates. The regulated decision stays with a person.

This is easy to misread as a limitation bolted on to satisfy a lawyer. It is the opposite. It is the design that lets the whole system be lawful. An agent that made the consequential call itself would be faster and illegal. An agent that does all the work up to the decision and hands a human a complete, evidenced dossier is both fast and lawful. REQUIRE-HUMAN is not the agent's weakness. It is the boundary that makes autonomy defensible everywhere else.

No evidence, no decision

A policy that runs is only half the obligation. The other half is proving, after the fact, what happened. Under EU AI Act record-keeping expectations (Article 12), you have to be able to reconstruct why a decision was made.

So every agent decision leaves an append-only, hash-chained evidence trail on a write-once store, written before the decision commits. The order matters: the record is written first, and only then does the decision take effect. If the evidence cannot be written, the decision does not happen. The system fails closed.

That single rule, no evidence, no decision, is what makes an agent inspectable rather than a black box. The record for any decision captures who acted, under what authority, on which inputs, against which signed policy version, at what autonomy level, and with what evidence. The hash-chaining means the trail cannot be quietly edited after the fact: tampering breaks the chain. When your auditors point at a transaction, you hand them a record, not a reconstruction.

This is also the answer to the question a risk committee actually asks: how do we sign off on a black box? The honest answer is that it is not a black box to the committee. It is a system where every decision arrives pre-evidenced, against a policy the compliance team signed, with consequential calls reserved for humans. The committee signs off on a documented, testable control, not a promise.

Built for the regulatory horizon, not just today's rule

The regulations are not standing still, and that is the final argument for making compliance executable rather than documentary.

EU AI Act Article 4 is already in force: since February 2025, organizations deploying AI must ensure their operators have sufficient AI literacy, and national authorities began overseeing it from August 2025. The high-risk obligations, the operational-resilience rules under DORA, the right-to-explanation, and data-residency requirements are arriving on their own schedules. A compliance regime encoded as signed, versioned, expiring policy adapts as the rules evolve, because changing a control means changing a policy artifact, not rebuilding the system. A compliance regime living in PDFs adapts at the speed of a document review cycle, which is to say, too slowly.

So the reframe worth carrying into your next audit is not "are we compliant with the current rule?" It is can we execute our obligations as signed, testable policy, prove every decision with evidence written before it commits, and change a control without rebuilding the system? If compliance still lives in a document beside the system, you are attesting to alignment you cannot demonstrate on demand.

If you want to see one obligation turned into a running control on a real process, book a meeting.