AI for regulated firms: governance from day one

In a regulated firm, AI has to be governed from the first day of the build, because a regulator, an auditor or the board will eventually ask for evidence of every step. In practice that means the controls are designed before the system goes live: human approval on consequential actions, a log of every action with its basis, monitoring for drift, a data protection impact assessment completed before any higher-risk processing starts, and reporting written in terms an auditor accepts. This guide sets out what each of those looks like in operation.

What do the controls look like in practice?

Approval points are placed wherever an action is consequential: money leaving the business, a message going to a client, anything near a regulated boundary such as advice or a suitability statement. The system prepares the action and a named person approves it, and that gate stays in place until the error-rate record justifies relaxing it.

Logging is per action. Each entry records what the system received, what it decided, the basis for the decision such as the source document or the rule applied, who approved it, when, and what happened next. The test of the log is whether a decision can be reconstructed months later from the record alone.

Monitoring runs on a fixed cadence. Early in a system's life the operating review is weekly: volumes, exceptions, approvals, error rates and any sign of drift as inputs change. Once behaviour is stable the cadence can lengthen, with automatic alerts covering the gap between reviews.

The board reporting pack pulls this together: which systems are live and what each is permitted to do, error rates against agreed thresholds, incidents and their resolution, changes to autonomy settings, and the data each system touches. Written that way, the pack is readable by a non-technical director and usable by an auditor.

When is a DPIA required and what should it cover?

Under UK GDPR, a data protection impact assessment is required before any processing that is likely to result in a high risk to individuals, and AI systems handling personal data often meet that bar because they apply new technology to personal data at scale. The safe operating assumption for a regulated firm is that an AI workflow touching personal data needs a DPIA, completed and signed off before the processing goes live.

The assessment describes the processing and its purpose, the data involved and where it flows, the lawful basis, the risks to individuals, and the measures that reduce those risks, which in an AI build are largely the controls described above. The ICO publishes guidance on AI and data protection, and the DPIA is a living document: a material change to what the system does or the data it uses means the assessment is revisited before the change ships.

Does the EU AI Act affect a UK firm?

A UK firm with EMEA exposure should be aware of the EU AI Act, which applies on a risk basis: obligations scale with the risk category of the use, and they can reach providers and deployers outside the EU where a system is placed on the EU market or its output is used there. Most back-office automation of the kind described in this guide falls into the minimal or limited risk categories, where obligations are light and centre on transparency. Obligations increase substantially for uses the Act classes as high risk, and a firm whose use case might sit near those categories should take specific advice rather than rely on a general guide.

What security baseline should be in place?

The National Cyber Security Centre's guidance sets the baseline any supplier should work to: multi-factor authentication on the accounts the system uses, role-based access so each person and each component holds only the permissions it needs, protected and tested backups, and least privilege as the default posture.

The purpose of the baseline is containment. A single compromised credential or a single mistaken action should be limited in what it can reach, and the per-action logging means anything that does happen is visible and attributable rather than silent.

Which five questions should you ask any AI supplier?

First, where is our data processed? The strong answer is inside your own accounts and tools, so the data stays where it already lives. Second, is our data used to train models? The answer should be that model providers are used under commercial API terms that exclude training on your data, and the supplier should show you those terms.

Third, who owns the code and the prompts? You should, with the repository and documentation handed over, because a system you cannot inspect is a system you cannot audit. Fourth, what happens when the model is wrong? The answer should describe an exception queue and human approval gates, with the error visible in the log rather than silently absorbed. Fifth, what does the auditor see? The answer should be the per-action log and the reporting pack, and a supplier who hesitates on this question is telling you something.

None of this slows the work once it is in place, and for a regulated firm it is the enabling layer: the controls are what let the business use AI near money, clients and regulated data at all. Governance built into the first day of the build costs a fraction of governance retrofitted after a question from a regulator.