Can a compliance policy be a skill file?

Most organisations trying to adopt agents have to invent their procedures from scratch. Banks, insurers and hospitals do not. They have spent two decades writing them down, because a regulator asked them to.

That is a genuine head start, and it is routinely wasted — because the documents were written to be audited, not executed.

The gap between a policy and a procedure

A control framework says what must be true. ISO/IEC 27001 Annex A.5.15 requires access to information to be controlled on the basis of business and security requirements. That is a statement of intent, and it is correct, and no system can act on it.

The operational form of the same clause looks different:

• Which systems are in scope, by name.
• What evidence proves a request is legitimate.
• Who approves, and who may not approve their own request.
• What is recorded, where, and for how long.
• What happens when the evidence is incomplete — which is the interesting case, and usually the undocumented one.

That is a skill. It is the same clause, rewritten so that the next step is unambiguous. Nothing about it is AI-specific; it is what you would have to write anyway to onboard a new analyst properly.

A worked example with a real deadline

Payments gives the cleanest illustration, because the standard is precise and the clock is public. Under CBPR+, cross-border payment messages must carry structured addresses — country, town, and street as discrete fields — rather than free text, from 14 November 2026.

Written as policy, that is a paragraph in a programme plan. Written as a skill, it is executable:

• The field-level rules for a pacs.008 — which elements are mandatory, which are conditional on the corridor.
• The mapping from your legacy free-text address block to the structured elements.
• The validation that runs before send, and what a rejection actually means.
• The exceptions — markets where the address data has never been captured cleanly, and what to do about them.

An agent holding that skill can be pointed at a book of standing instructions and tell you, by Friday, how many will fail and why. The same question asked without the skill produces a workshop.

The step that must stay human

This is where the honest version of the argument matters, and where most vendor material goes quiet.

A procedure can be delegated. Accountability cannot. In a customer onboarding file, intake, completeness, screening and risk rating are all procedure — rule-following at volume, which is precisely what a machine does better than a tired human at 4pm on a Friday. But a politically exposed person hit, an opaque ownership chain, a jurisdiction that just moved onto a grey list: those are judgements a named officer signs, and no framework in the world lets you delegate that signature to a system.

The failure mode is not automating too little. It is automating the five procedural steps, discovering it works, and quietly letting the sixth slide in with them because the boundary was never drawn in writing.

So draw it in writing. A good compliance skill says, explicitly, where it stops.

The by-product nobody expects

Teams that do this report the same surprise: the exercise finds gaps in the policy itself. Writing a clause as executable steps forces you to answer questions the prose let you avoid — what counts as sufficient evidence, who decides when two rules conflict, what the fallback is when a data source is unavailable.

Those gaps existed before. They were being filled, inconsistently, by whichever experienced person happened to handle the case. That is not a controls posture; it is a dependency on individuals, and it is exactly what an auditor is trying to find.

The executive framing

The pitch to a board is not “we are adopting AI in compliance.” It is narrower and much easier to defend:

We are writing our controls down in a form that can be executed and tested, rather than only asserted. The immediate benefit is consistency and evidence. The second benefit is that any capable system — this year's or next year's — can run them.

That is a governance improvement that happens to unlock automation, rather than an automation project that hopes governance keeps up. In a regulated institution, the order of those two clauses is the whole argument.