Most internal AI projects at advice firms stall at the same point, and it’s rarely the build or the budget. It’s the conversation with compliance. The tool works and the demos look promising, then someone asks where the data goes, who checks the outputs and what happens when it gets something wrong. Without good answers, the project sits on hold indefinitely.

These problems can be solved, and solving them doesn’t need a six-figure technology programme. It needs the assistant built properly from the start, with the compliance questions designed in rather than added afterwards.

What makes an internal AI assistant “compliant enough” to deploy

Compliance sign-off for an internal AI assistant in a regulated advice firm comes down to four things: where the data lives, what the system is allowed to say, who reviews its outputs, and what happens when something goes wrong. A system that gives clear, auditable answers to all four is one a compliance officer can work with.

The FCA and the Bank of England issued a joint statement in 2026 signalling that AI governance for UK-regulated firms is moving from voluntary best practice towards explicit regulatory expectation[1]. Firms that haven’t thought through how they govern AI will be asked to. The answer is to build it so it holds up when they are.

Architecture first: why “grounded” AI is the right starting point

Whether the assistant is grounded is the most important design choice you’ll make. A grounded AI system only answers from a specific knowledge base your firm owns, rather than from its general training data.

For an advice firm, that means the assistant only draws on documents you’ve uploaded and approved: your internal procedures, product lists, suitability framework and compliance manual. It can’t speculate, and it can’t bring in information from outside that set.

That helps compliance in three ways. Made-up answers drop sharply, because the model is finding and summarising rather than writing from scratch. The regulatory scope narrows, because the system isn’t advising or recommending products; it’s a structured search tool over your own documents. The audit trail also becomes manageable, because every answer can be traced to a source document.

This is where most firms go wrong. They take a general-purpose AI tool, connect it to their internal files and assume that’s the same as a grounded system. It isn’t. A grounded setup stops the model going beyond its knowledge base. A general tool with access to your documents can still answer from its training data, and most of them do.

Data residency and deletion: what compliance will actually ask

Before an internal AI assistant goes live at a regulated firm, someone needs clear answers to four questions:

  • Where does data go when a staff member types a query? With many consumer AI tools, queries go to third-party servers, may be logged, and in some cases may be used to improve the model. For a firm handling client data, that’s a UK GDPR problem[2].
  • What’s in the knowledge base, and has it been checked? Your compliance manual is fine. A file with client names and portfolio details needs a different conversation.
  • Can data be deleted on request, and is there a documented process? UK GDPR requires that personal data can be identified and erased[2]. If the deployment involves personal data and there’s no way to delete it, it isn’t deployable as it stands.
  • What happens when a staff member leaves? Query logs, if there are any, may need reviewing and clearing.

These are reasonable questions, and they’re the ones your Data Protection Officer will ask. Having good answers ready before the conversation is what moves a project from “pending review” to “approved”. On my own builds, a data protection agreement is signed before I touch any client data, and each client’s data sits on its own isolated server, because those are the first two things a DPO asks about.

What the assistant should and should not do

Defining what the assistant is for matters as much as the technical setup. An assistant that replaces regulated judgement is a problem. One that supports it isn’t.

Here’s a scope most compliance teams can accept.

An internal AI assistant for an advice firm can reasonably: search and summarise internal procedure documents, answer questions about your firm’s own processes, draft internal notes and meeting summaries for review, point staff to the relevant section of your compliance manual, and produce first drafts (report sections, client letter templates) that an adviser then reviews and approves.

It shouldn’t: make suitability recommendations, produce client-facing content without a review step, classify clients for regulatory purposes, or make any decision that would normally need regulated judgement. Any output that feeds a regulated document or decision needs a sign-off step built into the workflow, not added informally.

The short version: the system drafts, the adviser decides.

A practical build sequence

Firms that succeed with this start small and expand. This order works:

  1. Define the knowledge base. Pick two or three internal documents the team refers to all the time, such as your suitability framework, your complaints procedure and your Consumer Duty file. Digitise and tidy them if needed. They become the first version of the assistant’s knowledge.
  2. Choose a deployment that keeps data in your control. For most firms in 2026, that means a tool with confirmed UK or EU data residency and no training on your queries, or an on-premise or private cloud deployment. Several providers now offer managed deployments designed for regulated firms. Get written confirmation of how data is handled from any vendor before you sign.
  3. Define the review step before you deploy. For every type of output the assistant can produce, decide in advance who reviews it, what they’re checking for and how the review is recorded. Have this in place before staff start using it.
  4. Test it properly before calling it live. Something that looks promising in a demo hasn’t yet shown it works in your day-to-day operation. Run a structured test with real questions from real staff, check the answers against your source documents, and measure accuracy before treating it as reliable.
  5. Document everything. Your AI governance record doesn’t need to be elaborate, but it does need to exist: what the system is, what it’s allowed to do, who approved it, what data it touches and how you tested it. That’s the file you hand the FCA if they ask.

What good governance looks like in practice

Once the assistant is running, three habits keep it trustworthy:

  • Review the knowledge base quarterly. Procedures change and so do regulatory requirements. An assistant working from a document that was accurate eighteen months ago may now give answers that don’t reflect your current obligations. Give someone the job of checking and updating the source documents on a schedule.
  • Log and spot-check outputs. You don’t need to review every answer, but you do need a way of sampling them and catching repeated errors. If the assistant keeps misreading one section of your compliance manual, you want to know before someone relies on it.
  • Keep the scope visible. Staff will naturally push at the edges of what the tool is for. That’s fine if the boundary is clear and enforced. Brief the team on what the assistant is for, what it isn’t for, and what to do when they’re unsure.

Getting an internal assistant approved is mostly a governance job rather than a technology one, and governance problems are solved with clear thinking and decisions written down. The UK AI governance guide covers the wider obligations around it.

UK regulatory note. Cordrey Consulting is not authorised or regulated by the Financial Conduct Authority. Nothing in this article constitutes regulated financial advice, a formal compliance opinion, or legal advice. The discussion of FCA expectations is based on publicly available regulatory communications and is intended for general information only. Firms should take independent legal and compliance advice before deploying AI systems in regulated contexts.

Data protection note. Nothing here constitutes legal advice on GDPR compliance. Data protection obligations vary by circumstance and jurisdiction. UK firms should consult a qualified Data Protection Officer or legal adviser before deploying AI tools that process personal data. The Information Commissioner’s Office (ICO) is the relevant supervisory authority for UK data protection matters.

Sources

[1] FCA and Bank of England, joint statement on AI in financial services, 2026. Cited for the regulatory signal that AI governance is moving from voluntary to expected. https://www.fca.org.uk

[2] UK Government, UK GDPR (retained from EU GDPR, as amended), Article 17 (right to erasure) and Articles 44, 49 (international transfers). https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/