AI coding guardrails for regulated industries: what we ship for fintech, govtech and assurance clients

Every regulated engineering organization is having the same conversation this year: the productivity case for AI coding agents is now obvious, and the compliance case is nowhere. The CTO wants the velocity; the risk function wants to know what happens at the next audit when someone asks “who wrote this code, under what controls, and where is the evidence?” — and “an AI agent, carefully” is not an answer that survives contact with a regulator.

We build for clients in regulated industries — assurance and inspection, corporate governance research, legal information systems, regulated gambling, legal technology — and this post is the concrete version of how we answer that question: which layers of our guardrail system map to which regulatory requirement, and, more importantly, what artifact each one produces. Because the thing we have learned shipping into audited environments is simple: frameworks reassure; artifacts pass audits.

The gap between policy and mechanism

The enterprise consultancies — IBM, TCS, Hexaware, and their peers — publish serious AI-coding governance frameworks, and they are worth reading as a benchmark for what the compliance conversation expects: acceptable-use policies, human-oversight requirements, review gates, risk tiers. What they have in common is that they are policy-level — they describe what people should do.

An auditor’s questions run one level lower: what does the system prevent, what does it record, and can you produce the record? A policy that says “all AI-generated code must be reviewed” is a sentence in a document. A hook that blocks un-investigated edits and logs every tool call is a mechanism — and the log is an artifact. The twelve-layer system was not designed as a compliance product; it was designed to make agent output trustworthy. But mechanisms that create trust turn out to create evidence, and evidence is what regulated engineering actually runs on.

The mapping: requirement → layer → artifact

Regime	What it effectively requires of AI-assisted development	Layer that answers	Artifact produced
GDPR / UK DPA (accountability)	Demonstrate control over how systems touching personal data are built; keep secrets out of AI context	Investigation gate + secrets policy in the spec-driven CLAUDE.md	Per-action hook log: every tool call, timestamped, with block/allow decisions
DORA (financial ICT resilience)	Change control, testing evidence, and resilience of the development process itself	PostToolUse build gate + runtime supervisor	Build/test verdict per change step; supervisor stop-events showing runaway sessions were contained
NIS2 (security by design, supply chain)	Auditable tooling, no opaque third-party dependencies in the dev loop	All hooks versioned in-repo, no phone-home	The guardrails themselves — readable scripts your security team can review line by line
SOC2 Type-II (controls operating over time)	Not “we have a control” but “the control operated, continuously, across the period”	Outcome logging + AUTO-TABLE inventories	The build-outcomes log (every task, every verdict, months deep) and per-PR architectural diffs

Two things about this table are worth saying explicitly. First, none of these artifacts is assembled for the audit — they are produced as a side effect of development running normally, which is precisely what makes them credible. Evidence gathered retrospectively smells like evidence gathered retrospectively. Second, the table claims mapping, not certification — more on that honesty below.

The four layers auditors actually ask about

In practice, regulated-client reviews converge on four mechanisms.

The investigation gate answers the provenance question. Every edit the agent made was preceded by reads the hook can prove happened — “the AI changed this authorization check” becomes “the agent read these three files, at these timestamps, then made this change, which passed these tests.” That is a chain of custody, and the full mechanism is public.

The build gate answers the testing-evidence question, per step rather than per release. DORA-style change control wants proof that changes were tested; the gate produces a verdict after every multi-file edit, logged with the change that triggered it. Ten changes, ten verdicts — not one green pipeline at the end covering ten commits of unknown intermediate state.

The runtime supervisor answers the unattended-operation question, which is the one that makes risk officers rightly nervous. If agents run overnight, what bounds them? The supervisor holds token budgets, oscillation windows, and drift thresholds, with the authority to stop a session and page a human — and its logs show every intervention and every non-intervention, which is what “the control operated across the period” means for a Type-II.

The AUTO-TABLE inventory answers the architectural-drift question. Its per-PR diff shows, in table rows, what the change did to the system’s shape — new endpoints, touched entities, affected consumers. When a reviewer asks “did the AI change anything structural?”, the answer is a diff, not an opinion. Deep-dive here.

A worked audit exchange

Abstract mappings convince engineers; auditors work in questions. Here is how a representative exchange goes when the layers are in place — four questions we have actually fielded, and the artifact that answers each.

“Show me who — or what — changed this authorization check, and under what review.” The PR’s hook log shows the agent session: the files read before the edit (investigation gate, timestamped), the edit itself, the build and test verdicts that followed (build gate), and the named engineer who approved the merge. Chain of custody, mechanical, no reconstruction required.

“How do you know AI-generated changes were tested — not just at release, but as they were made?” The outcome log: one record per task step, with build result, test result, and retry count, appended continuously since the control went live. This is the Type-II shape — not a control described, a control observed operating across the audit period.

“What prevents the AI from acting outside its mandate — say, overnight, unattended?” The supervisor configuration (versioned in the repo, so its history is itself auditable) plus its event log: every session stop, every threshold trip, and — equally important — the long stretches of nothing, which demonstrate the control was armed, not just present.

“How would you detect that AI-assisted changes altered the system’s architecture in ways nobody intended?” The AUTO-TABLE diffs, PR by PR. Structural change appears as table rows in review; the quarter’s architectural drift is the sum of visible, approved diffs rather than a surprise discovered during the next threat-modeling exercise.

None of these answers required preparing for the audit. That is the entire design goal.

Introducing this to your risk function

A practical note on rollout, because the mechanism is the easy half. What works, in our experience, is bringing the risk function a pilot with evidence attached rather than a policy proposal: one team, one repository, stage-one layers (CLAUDE.md, build gate, investigation gate), and thirty days of the resulting logs. Frame each layer in control language — objective, mechanism, evidence, owner — because that is the format their world runs on, and a hook described as “PreToolUse script” lands very differently than the same hook described as “preventive control over un-reviewed code modification, with automated evidence capture.” Add the model provider to the vendor-risk register as its own line item with its own assessment, so the tooling conversation and the data-processing conversation stay cleanly separated. Then let the thirty days of artifacts argue. Every regulated adoption we have seen succeed went policy-last, evidence-first.

Who this is for

We have shipped on this pattern for enterprise clients across assurance and inspection (DE), corporate governance research (US/UK), legal information and legal technology infrastructure (NL/IE), and regulated gambling (SE/MT) — environments where “the AI did it” is not an acceptable answer to a build-provenance question, and where the difference between a vendor you can defend to a regulator and one you cannot is decided in exactly these details. The regulated-SaaS use case covers the engagement shape; our internal template build shows the system that gets specialized to each environment.

What we deliberately do not claim

Credibility in this space is mostly a matter of respecting the limits, so here are ours, stated plainly.

Guardrails are not compliance. The twelve layers produce evidence your compliance function can use; they do not make you GDPR-compliant, DORA-ready, or SOC2-certified. Those are determinations your DPO, your risk officers, and your auditors make — our job is to ensure that when they ask for evidence, engineering has some.

The model provider is a separate assessment. What Anthropic (or any provider) does with API traffic is a data-processing question your vendor-risk process must evaluate on its own — enterprise API terms, data-retention posture, regional processing. Our layers govern what the agent does to your codebase; they do not change what your contract with the model provider says. Related but distinct: our agents work against code, not production data — personal data has no reason to be in a coding session’s context, and the secrets policy plus hooks enforce the same for credentials.

Human accountability does not transfer. A named engineer owns every PR that ships. The layers make that ownership informed — the engineer reviews evidenced, gated, annotated work instead of raw generation — but no artifact in this post moves responsibility from a person to a process.

The regulations move. DORA guidance is still maturing, NIS2 transposition varies by member state, and AI-specific supervisory expectations are actively forming. The mapping above reflects what audits ask today; the honest posture is a system that logs more than currently required, because the requirements only move in one direction.

The conversation this post is meant to start

If you are an engineering leader at a regulated firm, the practical question is not “is AI coding allowed?” — it is “what would our audit story look like if we adopted it next quarter?” That is answerable in an hour against your actual regulatory surface and your actual codebase: which layers you would need, which artifacts your auditors would ask for, and what stage one looks like.

That hour is an $80 consult — a regulated-industry guardrail review with the principal engineer who runs this system, ending with a written mapping like the table above, specific to your regime. If it turns into a Sprint Zero install, good; if it turns into your team building the layers yourselves from this cluster’s posts, that is a fine outcome too — the evidence discipline matters more than who implements it.