Why General-Purpose LLMs Are the Wrong Tool for Regulated Financial Advice
Financial firms are pasting client data into Copilot, ChatGPT and Claude to draft Advice Statements and DDQs, workflows these tools were never designed to perform. Why regulated advice needs data custody, auditability, deterministic source-grounded outputs, and clear accountability, none of which a general-purpose model can add after the fact.

Large language models are extraordinary writers, which is exactly why so many financial firms are adopting them. The problem is that they're now being used for regulated advice workflows they were never designed to perform, in ways that likely fall outside the regulator's expectations for how AI should be deployed in the advice market.
Walk into any advice practice, licensee office or fund manager today and you'll probably find someone pasting client details into Copilot, ChatGPT or Claude, to help draft Advice Statements or Due Diligence Questionnaires (DDQs). Nobody formally decided this was how regulated client advice would be produced. It simply happened, much as spreadsheets and email happened: the tool is good at language, the deadline is real, and the alternative is another hour of manual drafting. This isn't a story about carelessness or malfeasance; it's a story about architectural mismatch.
General-purpose language models are designed to be broadly useful across an almost limitless range of tasks. That breadth is genuinely impressive, but it's largely beside the point. Regulated financial advice demands four things that consumer AI tools were never designed around:
- Data custody
- Auditability
- Deterministic, source-grounded outputs
- Clear accountability
None of these can be bolted on afterwards. They need to shape the system from the very beginning.
Where the Data Actually Goes
When someone pastes a client's fee structure, fact-find notes or recordings into a public AI, that information mostly leaves the firm's controlled technology and data environments, and is processed under privacy policies, contractual arrangements and infrastructure the firm doesn't control. For an AFSL holder, that raises legitimate questions around privacy, security, outsourcing and the firm's continuing ability to demonstrate appropriate control over client information. A compliance review should be able to answer some straightforward questions:
- Where's this data processed?
- Who can access it?
- Is it retained?
- Is it used to improve future models?
- What contractual protections does the firm truly have?
For staff using public AI services outside an approved enterprise deployment, the answers may be unclear. This is one of the biggest gaps between frontier AI models and regulated environments, and one of the hardest to retrofit later. The model doesn't necessarily need to become smarter. The architecture around it needs to change, in ways that public AI likely never will.
A Transcript Isn't an Audit Trail
If ASIC asks how an advice document came to contain a particular recommendation, answering "we used an AI" won't be sufficient. A chat transcript records a conversation, it doesn't necessarily show:
- which source documents were used
- where each figure originated
- which version of the data applied
- what edits were made
- who reviewed the document
- who approved it before it was sent
Regulated work requires something very different. It should be possible to trace every material statement backwards:
- this figure came from this client record
- this document was generated on this date
- these sources were used
- this authorised person reviewed and approved it
That's an audit trail. A conversation log was never designed to be one.
Fluency Isn't the Same as Consistency
Ask a general-purpose model to describe the same fee arrangement twice and you could receive different wording, different emphasis or, occasionally, different numbers. For most everyday writing, that variability is a strength: it makes the writing feel natural. For an Advice Statement, it's a risk. Regulated documents need to communicate the same verified information repeatedly and consistently. Every figure should be traceable to an authoritative source rather than reconstructed from statistical probability. This isn't a prompting problem. It's an architecture problem.
Whose Problem Is the Hallucination?
If an AI-generated fee figure is wrong and reaches a client, whose liability is that?
- The adviser who signed the document? Almost certainly.
- The licensee responsible for supervision? Quite possibly.
- The AI vendor whose terms typically disclaim responsibility for output accuracy? Almost certainly not.
That allocation of responsibility isn't a reflection of how capable the model is. It's simply how general-purpose AI products are designed. They're built to be broadly useful while placing responsibility for verification on the user. That's entirely reasonable when drafting an email or summarising a meeting. It's much harder to justify when producing documents that carry regulatory obligations and could materially affect a client's financial future.
What Regulated-Grade AI Actually Requires
This is not an argument against AI. The administrative burden facing advisers, paraplanners and compliance teams is real, and AI should absolutely reduce it. But success depends on the architecture, not simply the model. A system designed for regulated work should:
- Keep client information within the firm's controlled environment
- Support appropriate data residency and data sovereignty requirements
- Generate a complete, signed audit trail rather than simply preserving conversations
- Ground every material output in verified source data
- Include structured review and approval workflows before documents leave the organisation
Those principles provide a useful framework for evaluating any regulated AI platform, including BackPro:
- Where does the data go?
- What's the audit trail?
- Are outputs consistently grounded in verified information?
- Who's accountable before anything reaches a client?
How BackPro Addresses the Consistency Problem
BackPro uses Retrieval-Augmented Generation (RAG), meaning every figure, clause and factual statement is retrieved directly from the firm's own approved knowledge base at the time a document is generated, rather than reconstructed from the model's training data.
If supporting information can't be found, the system flags the gap for human review rather than inventing a plausible answer. Outputs are also produced within structured workflows and approved templates, reducing unnecessary variability while ensuring every document remains grounded in authoritative source material. Consistency and hallucinations aren't solved by asking a model to "be more careful." You can't prompt your way out of an architectural problem.
Combined with tenancy-isolated data handling and a signed audit trail covering generation, review and approval, the result addresses the four requirements regulated firms actually care about: the data stays under organisational control, every output is traceable, documents are consistently grounded in approved information, and a human remains accountable before anything reaches a client.
The Real Choice
Most firms have already decided to adopt AI. The question remaining is which architecture they choose. One path starts with broad consumer AI designed for general usefulness, then attempts to add governance afterwards. The other starts with governance itself, data custody, auditability, accountability and source-grounded outputs, and uses AI within that framework.
The future of AI in regulated industries won't be determined by which model is the best writer. It'll be determined by which architecture best satisfies the obligations regulated firms already have. In financial services, governance isn't another feature, it's the product.
