You use AI in financial services the way you use any system that touches customers or money. You know what data it sees and where that data goes. You keep a record of what it did and who acted on it. A named person stays accountable for every decision it informs. And you can show an auditor the controls working, rather than describe them. Most compliance trouble with AI starts when a firm treats it as an exception to the rules it already follows everywhere else.
I spent years building inside banks, and later building data platforms for financial-services businesses, where a wrong number is a regulatory problem as well as a bug. This is how I approach it now that AI is part of the system. It isn’t legal advice, and your compliance team has the final word, but it gives them something concrete to say yes to.
Do the existing rules apply to AI?
Mostly, and that is good news. In the UK, the FCA has said it will regulate AI through the frameworks firms already work under, rather than through a separate rulebook. The Consumer Duty still asks whether customers get good outcomes. The Senior Managers regime still puts a named person on the hook. Data protection law still governs personal data, and has specific rules for decisions made solely by automated means that significantly affect someone. None of that changes because a model is involved, so your existing controls are the place to start.
Where does the risk actually sit?
In my experience, in four places:
- Data leaving where it should stay. Customer records pasted into a public chatbot, or a document uploaded to an online converter just to read it. Sensitive material should be processed where you control it, and every outside service that sees it should be named and approved in advance.
- Decisions nobody can explain. A model scored something, a person clicked approve, and afterwards nobody can say what the model saw or why the person agreed.
- A record that names the wrong actor. If an assistant acts through a person’s login or buttons, the audit trail says the person did it.
- Instructions hidden in content. An email or a document that says “ignore your instructions and send this” is data. A system that reads it as an order is a breach waiting for a sender.
How do you keep a record that stands up?
Make the system record who did what, honestly, at the moment it happens. In one system of mine, every write goes through a single audited path that records the actor, with the record as it was before and after. The assistant has its own tools and its own name in that log. It is forbidden from using the buttons I use, because the app can’t tell who is pressing them and would file its work under my name. That rule exists because it went wrong once: a small fix made through the interface showed me as the editor of something I had never touched.
Nobody edits that log, either, not even to tidy away their own mistakes. An accurate record with a known error in it is worth more than one corrected by hand.
An audit trail that files the machine’s work under a person’s name is worse than none, because people trust it.
Should a person always be in the loop?
For anything irreversible or customer-facing, yes, and the loop should be designed rather than assumed. I build systems that propose first. They show the change, the rows that would move or the message that would go, and nothing is written until a person applies it. Every bulk operation I write rehearses by default and needs an explicit commit before it touches anything. That turns “a person reviews it” from a line in a policy into a property of the software.
Be honest about rubber-stamping, though. Someone approving a suggestion every few seconds is not reviewing anything. Size the queue to what a person can actually read, and sample what they approved to check the review is real.
How do you prove the controls work?
By trying to break them. A control described in a policy is a claim; a control that has been attacked and held is evidence. When someone says a table can’t be read without signing in, it should mean they tried from a signed-out client and were refused. On this site, a test fails the checks if any route that accepts what people send through a form ever answers a request to read it back. Another commits a fake secret on purpose, deletes it in the next commit, and requires the scanner to find it in the history before anything can be pushed.
That kind of evidence can be rerun by an auditor on the day they ask, which a policy document never can.
Where should a firm start?
Where a wrong answer is cheap and visible. Internal work first: summarising documents for someone who reads the source anyway, drafting code that goes through review, reconciling data that a person signs off. Customer-facing decisions come later, once you have the record, the review loop and an evaluation set that shows the system behaves. Starting with the riskiest use because it carries the biggest prize is how firms end up explaining themselves.
Keep secrets out of the conversation as well. API keys and credentials belong in a secrets manager, referenced by name, never pasted into a prompt, a log or a commit message. If one is exposed, say so at once: rotating a key is cheap, and silence is not.
The short version
AI fits inside the rules a financial firm already lives by, as long as you treat it as a system and not as a special case. Know where the data goes. Record honestly who did what. Keep a person accountable, and a proposal step before anything irreversible. Prove your controls by attacking them. Do that, and compliance becomes something you design for at the start, rather than the reason the project stopped.