All articlesFR

Human in the Loop: Advisor Approval, Data Residency and Audit Trails for AI Planning Tools in Canada

Compliance conversations about AI tend to start in the wrong place. They start with the technology: which model, how accurate, how new. The questions that matter to an advisory practice are older than any of that. Who is responsible for the recommendation? Where is the client's information? Can you show what happened?

Those three questions map onto three safeguards that any AI planning tool used in a Canadian practice should be able to demonstrate: advisor approval, data residency, and an audit trail. This article looks at what each one means in practice and what to ask for.

A note before starting: this is a practical overview, not legal advice. Your obligations depend on your registration, your dealer or firm, and your province. Federal and provincial privacy law and the guidance of bodies such as CIRO, FSRA and the AMF are the right places to confirm specifics, ideally with your compliance team.

Why "Human in the Loop" Is More Than a Slogan

"Human in the loop" has become a stock phrase in AI marketing, and it is used loosely. Sometimes it means a person can see what the AI did. Sometimes it means a person could intervene if they noticed something. Neither is the same as a person approving each change before it takes effect.

For financial planning, the distinction is the whole point. Your existing obligations do not change because a tool is involved: you are expected to know your client, have a reasonable basis for what you recommend, and be able to explain it. A tool that edits a client's plan on its own, even accurately, puts a recommendation in the file that you did not make.

A meaningful human-in-the-loop design has three characteristics.

Proposals, not edits. The AI can draft a scenario, propose a mapping of figures from a document, or suggest a recommendation. It does not change the plan.

Explicit approval. A change reaches the plan only when the advisor accepts it. Ignoring a suggestion leaves the plan as it was.

Visible provenance. Once approved, it is clear which figures came from the advisor, which from documents the AI read, and which the advisor accepted from an AI proposal.

Approval in Practice

Consider what this looks like on a real file.

A new client brings in two years of T1 returns, a CPP Statement of Contributions, a group RRSP statement, a term life policy and the T2 for their operating company. An AI planning tool reads all of it and proposes values for perhaps a hundred fields: income history, contribution room, account balances, coverage amounts, retained earnings.

Under a human-in-the-loop design, the advisor sees those proposals before they become part of the plan. They notice that the AI read the opco's retained earnings correctly but did not know about the holding company, because the client did not bring that T2. They add it. Only then does the plan move forward.

The same applies in a meeting. When a client asks what happens if they start CPP at 70 instead of 65, the AI can answer from the plan's own figures and draft the question as a new scenario. The scenario sits as a draft until the advisor decides to keep it.

The approval step is short. It is also the moment the advisor takes ownership of what is in the file.

Data Residency: Where Client Information Lives

Planning files hold some of the most sensitive information clients ever share: income, health, family relationships, estate wishes, business ownership. When an AI tool reads that information, it matters where the data goes and what is done with it.

Privacy rules on where client data can be processed vary, and your compliance team is the right place to confirm what applies to your practice. In practice, many firms, and many clients, simply prefer that their data stay in Canada.

For AI tools, three questions are worth asking in writing.

Where is client data stored? Including the AI conversation history, not only the plan.

Is client data used to train AI models? Either the vendor's or a third party's. The answer should be a clear no, in the contract or privacy policy.

Which subprocessors handle the data? If the AI relies on a third-party model provider, what are the terms of that relationship?

A vendor that can answer these cleanly has thought about the issue. One that answers vaguely probably has not.

The Audit Trail: Showing What Happened

The third safeguard is the one most often missing.

When a person in your practice works on a plan, the file usually shows it: notes, emails, version history. When an AI tool works on a plan, that record can disappear unless the tool is designed to keep it. The conversation happened, suggestions were made, some were accepted, and nothing in the file says so.

That gap matters for three audiences.

Your team. An assistant preparing for a follow-up, or a colleague covering a vacation, needs to know what was discussed and decided.

Compliance. A file review asks how a recommendation was reached. "The AI suggested it and I agreed" is not an answer unless you can show what it suggested and why.

You, later. A year from now, when the client asks why the plan assumed QPP at 65 rather than 70, the record should answer.

The practical form of an audit trail for AI is a thread per client: every question asked, every proposal made, every approval or rejection, in order, attached to the client file and readable by the people who need it.

Numbers You Can Reproduce

There is a fourth safeguard underneath the other three. Approval and audit trails are only meaningful if the figures themselves are stable.

If an AI tool generates projections directly from a language model, the same inputs may produce different outputs on different days. An audit trail of figures that cannot be reproduced does not help much. The safer design is for a deterministic engine to compute every number, and for the AI to cite that engine's output rather than produce its own. Then the trail points to figures anyone can regenerate.

A Short Checklist

When evaluating an AI planning tool for a Canadian practice, ask the vendor to show you, not tell you:

  • A proposed change that does not reach the plan until you approve it
  • Where client data and AI conversation history are stored
  • The written commitment that client data is not used to train models
  • The full history of AI activity on one client file
  • The same scenario run twice, producing the same figures

Where This Leaves Advisors

None of these safeguards is exotic. They are what you already expect of a person working in your practice: do the work, bring it to me before it goes to the client, keep a record, and handle client information properly. The test for an AI planning tool is whether it meets the same standard.

Finn, PlanBase's financial planning associate, was designed around these safeguards. The advisor approves every change before it reaches the plan, every number comes from the deterministic engine, client data is stored in Canada and never used to train AI models, and each client has one reviewable thread for the advisor's team and compliance. Details on data handling are on our security page.


This article is general information and not legal or compliance advice. Confirm your obligations with your compliance team and the guidance that applies to your registration.

All articles