AI governance for regulated industries: a practical baseline

Governance conversations in regulated industries usually stall in the same place. Legal asks what the framework is, engineering asks what they’re allowed to ship, and six months later there’s a policy document nobody has read and no systems in production.

The way out isn’t a bigger framework. It’s a small one you can actually apply, built on obligations you already carry.

Start from the obligations you already have

Most organisations write AI governance from a blank page, as if none of it were covered. It largely is. If you’re in finance, healthcare or the public sector you already have model risk management, data protection obligations, records retention, access control and audit requirements.

AI doesn’t replace those — it inherits them. Start by mapping what already applies, then write policy only for the genuine gaps. That’s usually a much shorter list than expected, and it has the advantage of being defensible: you’re extending controls your regulator already recognises rather than inventing a parallel regime.

Classify by decision, not by technology

The most common mistake is tiering systems by how the AI works — model size, whether it’s generative, whether it’s third-party. None of that predicts risk.

What predicts risk is the decision the output touches:

• Assistive — a person reads the output and decides. Drafting, summarising, search.
• Consequential — the output materially shapes a decision about a person. Eligibility, triage, prioritisation, risk scoring.
• Autonomous — the system acts without a human in the loop.

Assistive systems need light-touch controls. Consequential ones need real scrutiny. Autonomous ones in a regulated context need a very good reason to exist at all. This tiering is one sentence per system, and it’s the decision that determines everything downstream.

The five controls that carry most of the weight

You can write fifty controls. Five of them do most of the work, and a baseline that stops there will pass more scrutiny than a comprehensive framework nobody follows.

• A named owner. Every system has one person accountable for it — not a committee, not a team. If nobody’s name is on it, nobody reviews it.
• Data boundaries in writing. What can be sent, what must never be, and where it goes. Recorded once, enforced in code rather than in a policy PDF.
• Human review proportionate to tier. Consequential systems get a person in the loop before the decision lands, and that person needs enough context to actually disagree.
• Logging you could hand to an auditor. Input, output, model version, timestamp, who acted. Decide the retention period with legal before launch, not after a request.
• A defined failure path. What happens when the system is unavailable or wrong. Every regulated process needs one, and “the team will work it out” isn’t it.

Documentation is the deliverable

In a regulated environment, a system you cannot explain is a system you cannot defend. The explanation has to exist before anyone asks for it — written after the fact, it reads exactly like what it is.

Keep it to one page per system: what it does, what data it touches, which tier, who owns it, what happens when it fails, and what was tested before launch. If that page can’t be written, the system isn’t ready — and that’s a more useful gate than any approval workflow.

Who signs off

Governance fails on process more often than on principle. If every AI change needs a committee, teams route around the committee.

Tie approval to the tier. Assistive systems are signed off by the owning team. Consequential ones need risk and legal. Autonomous ones go to whoever signs off material operational risk today. Then publish the turnaround time you’ll hold yourself to — governance that takes six weeks produces shadow AI, which is the outcome it was meant to prevent.

A baseline you can ship this quarter

If you have nothing today, this is a defensible starting position:

• An inventory of every AI system in use, including the ones bought without IT’s involvement
• A tier assigned to each, using the three-way split above
• A named owner per system
• The one-page description, for consequential and autonomous systems first
• Logging and retention agreed with legal
• A published approval path with a committed turnaround

Six items. None of them require a new tool, and together they answer most of what a regulator will ask first.

Governance that slows teams down doesn’t reduce risk. It relocates it somewhere you can’t see.

The organisations that handle this well aren’t the ones with the longest policy. They’re the ones where an engineer can tell you, without checking, what tier their system is and who owns it.

If you’re building this baseline in a regulated environment, start a conversation. You’ll be talking to the people who do the work.