Only 21% of firms have mature AI agent governance, according to Gartner’s 2026 Hype Cycle for Agentic AI. So roughly four in five businesses using automation, regulated advice firms included, run live systems without the controls they’d need to show who was accountable if something went wrong. The FCA expects firms to be able to show how decisions affecting clients are made, so that gap is a problem today.
This is a practical guide to closing it: a set of steps a firm of any size can start on this week.
Why governance matters before you scale
Governance is what makes automation safe enough to rely on in the first place, so it can’t wait until the automation is bedded in.
Agentic AI systems (workflows that take actions rather than just produce text) are already used in financial services firms for client onboarding, document drafting and routing communications. They carry out work for the firm, and they should only do it within a scope a named person has approved, with a person signing off anything that leaves the firm or feeds a regulated decision. They never act for a client: the client’s decisions stay with the client. They touch client data, and some of what they produce feeds regulated decisions. That puts them under the same oversight obligations as any other process that affects clients.
The FCA has been explicit that firms are responsible for outcomes whatever mechanism produced them. Automation doesn’t pass that responsibility to a vendor. It stays with you.
Whether your automation works is only half of it. You also need to be able to prove it works, and to act when it doesn’t.
Running any AI agent with broad permissions also opens up security risks, including prompt injection, where malicious input makes the system behave in ways nobody intended. Governance that ignores this is incomplete.
The four parts of automation governance
Automation governance has four parts, and none of them is complicated to put in place.
Policy
A written document saying which processes the firm automates, what those systems may do, what they may not do, and what triggers a human review. It doesn’t need to be long. Two to four pages is enough for most firms at this stage. It has to exist, be current, and be known to the people who run the systems.
Ownership
Someone in the firm is accountable for each automated process. Not a vendor or a platform, but a named person inside the firm who can explain what the system does and how they know it’s working. In smaller firms that’s often the operations lead or the compliance officer. It doesn’t need a senior hire. It does need to be explicit.
Monitoring
Automated systems can’t be set and forgotten. At minimum, someone reviews a sample of outputs regularly: weekly for high-volume or client-facing processes, monthly for lower-stakes internal ones. The review doesn’t have to cover everything, but it has to be honest and written down.
Audit trail
For any event, you need to be able to reconstruct what an automated system did, when, and on what basis. Most integration platforms (n8n, Make, Zapier) log execution data by default. The governance job is making sure those logs are kept, can be found, and get looked at when something goes wrong, not only when someone asks for them.
Five steps to start this week
Start by mapping what you already have. Most firms underestimate how much automation is already running, from emails triggered by CRM events to document generation tools and rules-based routing in the back office.
- List every automated process. Include integrations, scheduled tasks, and anything a tool does without a person starting it each time. Be thorough, because you can’t govern a process you don’t know about.
- Rate each one by risk. High risk: processes that touch client-facing output, regulated decisions or personal data. Medium risk: internal processes that affect client records or firm reporting. Low risk: purely internal admin with no client impact. This takes an afternoon and tells you where to focus.
- Give each one an owner. One named person, recorded wherever the firm tracks responsibilities. A spreadsheet is fine for now.
- Check each high-risk process has a human review step. AI and automation output needs human review before it’s used in regulated documents or decisions. If that step isn’t there, add it. It doesn’t have to be a full audit: for most processes, a named person confirming they’ve seen and approved the output is enough. Record that it happened.
- Write a one-page policy. Cover which systems are in scope, what they may do, and how often they’re reviewed. Have compliance review it. Date it and keep it somewhere the FCA could find it if they asked.
Decisions that stay with a person
Three kinds of decision shouldn’t be fully handed to automation in a regulated firm, however capable the system looks.
The first is any output that feeds a suitability assessment or advice recommendation. The system can draft, research or flag. A qualified person reviews it and takes responsibility for what goes to the client.
The second is anything that commits the firm financially or contractually. Budget and approval authority stay with people.
The third is AI disclosure or brand communication where the firm’s regulatory obligations apply. If a client might reasonably need to know AI was involved in something they receive, a person makes that disclosure decision.
These aren’t arbitrary. They’re where the firm’s liability concentrates, and where an automation error costs most.
Keeping governance current
A framework written once and filed away doesn’t change anything. Treat your automated systems like your other operational processes: review them regularly, update the policy when something changes, and act when the monitoring shows something wrong.
A cadence that works for most firms: a short monthly review of monitoring results for high-risk processes, a quarterly review of the policy, and an annual review of every automated process in scope. Fold these into governance meetings you already hold.
Software development has a useful habit called shifting left: build the compliance and risk checks into the design and testing of a new automated process, not after it’s live. Before a new workflow goes into production, answer the governance questions first: who owns it, what it may do, and how it will be monitored. It’s the same rule I build to, where every requirement has its test written before the build starts.
Governance and client trust
Gartner’s 21% figure is part of a wider pattern: ambition and spending on agentic AI are running ahead of the organisational work needed to control it. A firm that can’t show it controls what it has already deployed isn’t ready to expand it.
For an advice firm, governance is also about client trust. Clients increasingly know that firms use technology in their processes. Being able to say clearly what your systems do, who oversees them and how you catch mistakes is a good answer to a question a client may well ask one day.
None of this is a complete compliance programme, and it isn’t legal advice. It’s a starting structure to build on, most of it can be done internally without outside help, and it’s realistic to have in place this quarter. The UK AI governance guide maps each of these controls to the rule it answers.
This article is for information only. It isn’t regulated financial advice or a compliance opinion. Consult a qualified compliance professional for advice specific to your firm.