Essay

Policy-as-Code Still Doesn't Solve This

Sam Carter16 Apr 2026 · 3 min read

A tier-one investment bank that takes AI governance seriously ends up in the same place.

The team moves from documents to code. Policies become rules. Rules become services. Decisions are evaluated programmatically. This is a real step forward.

It is still not enough.

The promise

Policy-as-code solves a clear problem. Instead of interpreting a document, the rules engine evaluates a rule. Instead of relying on human judgement alone, decisions are checked against defined criteria. Procurement gains consistency, repeatability, and speed.

A decision is no longer arbitrary. It is evaluated.

The assumption

Once policies are expressed in code, the system is governed. If every decision is evaluated against policy, then governance is enforced. If governance is enforced, it can be demonstrated.

Where it breaks

A policy engine evaluates a decision at a point in time. The engine does not preserve that moment.

The gap

Take a vendor approval workflow at a UK investment bank.

On Monday, March 4th, a Cyprus-based payment processor is submitted as a Tier-2 supplier with a £1.2m three-year contract value. The procurement system runs Vendor Policy v2.3 against the application: financial thresholds (debt-to-equity below 1.8), jurisdictional risk rating (Cyprus rated medium under the bank's geopolitical schedule), and internal exposure limits (less than 4% of single-vendor concentration in the payments segment).

All criteria pass. The decision is recorded: approved. The supplier is onboarded into the AP system within seventy-two hours.

Six months later

The policy has changed. Thresholds have tightened — debt-to-equity is now 1.5. Jurisdiction risk ratings have been updated; Cyprus has moved from medium to medium-high. Exposure limits have shifted under the new third-party risk framework.

Policy v2.3 is no longer active. Policy v2.6 is now in force.

The question

A PRA review asks why was this supplier approved.

The rules engine can re-evaluate the supplier today. It can run the same input through Policy v2.6. It can show what would happen now. What it cannot show, with certainty, is the exact rule set that was in force at the moment of approval, the precise thresholds that were applied, the context that surrounded the decision, or whether the decision complied with governance at that time.

The evaluation happened.

The evidence did not persist.

The time problem

These engines are designed to evaluate, not to preserve. Rules change. Versions move. Services are redeployed. The system optimises for the next decision, not for proving the last one.

The independence problem

Even when versioning exists, it remains internal. The same policy engine that evaluated the decision is responsible for reconstructing it. A system describing its own behaviour is not independent proof — it is procedural reconstruction.

The illusion of control

From the outside, the system looks governed. Policies exist in code. Evaluations are consistent. Decisions are traceable.

Traceability is not proof. Traceability shows that something happened; it does not prove why it happened under the conditions that existed at the time.

The moment of scrutiny

The gap only appears when a specific decision is questioned. Not the policy in general. Not the system in aggregate.

One decision. One moment. One policy version.

The shift

A governed system does not just evaluate decisions. It captures them. At the moment they are made, the input, the policy, the context, the outcome, the version, the timestamp, and the signature are bound together as a single artefact.

What changes

When the PRA letter arrives — why was this supplier approved? — the procurement system does not re-evaluate. It retrieves.

No reconstruction. No re-running of rules. No dependency on what the system looks like today.

The decision stands on its own.

Closing

Policy-as-code enforces decisions.

It does not prove them.

When a decision needs to defend itself — in front of a regulator, a court, or an internal risk committee — enforcement is not enough.

You need evidence. You need proof.