Every planning platform now has an AI story. The pitches have converged remarkably fast: the software reads the client's situation, produces the analysis, and hands you something close to a finished plan.
The demos are impressive. They are also answering a question advisors were not really asking.
Capability is not the constraint. Language models have been able to produce fluent, plausible financial commentary for several years. The constraint is accountability. You sign the plan. You sit across from the client. If a regulator asks why you recommended a particular drawdown sequence, "the model suggested it" is not an answer.
That asymmetry should drive how advisors evaluate AI in planning software, and it mostly does not.
The Accountability Gap
When a plan goes wrong, the consequences do not distribute evenly between you and your software vendor.
The client's outcome is worse. Your relationship absorbs it. Depending on severity, your regulator and your errors and omissions carrier become involved. The vendor, in almost every case, has a limitation of liability clause and continues its quarter unaffected.
This is not a criticism of vendors. It is simply the structure of the arrangement, and it means the question "can the AI do this?" is less important than "can I defend what it produced?"
Those are different questions, and only one of them shows up in a demo.
Where AI Genuinely Helps
None of this argues against AI in planning software. Used in the right place, it does real work that nothing else does as well.
Reviewing rather than generating. A model reading a completed plan and flagging what looks inconsistent, omitted, or worth a second look is doing something valuable and low-risk. If it raises a bad flag, you dismiss it. The cost of a false positive is a few seconds. Compare that to the cost of a bad number you did not catch.
Catching what is missing. Omissions are harder to spot than errors, because nothing on the screen looks wrong. A client with a spouse and no beneficiary designation. A business owner whose succession has never been modelled. A plan that never tested an early death scenario. Systematic checking for absence is genuinely hard for humans and well suited to software.
Explaining in the client's language. Turning a projection into prose a client understands, in English or French, at a reading level that suits them, is a legitimate strength. The numbers are already fixed; the model is helping you communicate them.
Surfacing the questions worth asking. Reading a file and suggesting what you have not yet explored is useful precisely because it is advisory rather than authoritative.
Notice what these have in common. In each case, the AI operates on numbers that already exist, produced by something else, and a human decides what to do with the result.
Where It Should Not Be Trusted
The numbers themselves.
Language models are probabilistic. Run the same prompt twice and you can get different output. That property is a feature in writing and a serious defect in a projection engine, because financial planning requires the opposite guarantee: the same client data must produce the same figures every time, in the projection, in the on-screen chart, and in the printed report, this month and next year.
You cannot audit something that will not reproduce. If a client asks why last quarter's plan showed a different number than today's, "the model computed it differently" ends the conversation badly. And a compliance review is precisely an exercise in reproduction.
This is why the architecture matters more than the feature list. A deterministic engine computing the numbers, with AI reading and explaining that engine's output, gives you both things: analysis you can defend and assistance that is genuinely useful. A model generating the figures directly gives you fluency without traceability, which is the worst combination available, because it looks the most convincing.
The Regulatory Direction
Canadian regulators have not issued planning-specific AI rules, and advisors should watch that space rather than assume it stays quiet. But the existing obligations already point clearly.
You are required to know your client, to have a reasonable basis for a recommendation, and to be able to explain it. None of those obligations transfer to a vendor because a model was involved. If anything, using a tool you cannot explain makes them harder to meet.
The practical standard to hold software to is simple: can it show its work? Not "does it have AI," but "when I ask why this number is what it is, does the tool answer, and is the answer the same every time?"
Questions Worth Asking a Vendor
Five that cut through most AI demos.
Does the AI produce the numbers, or read them? This is the single most clarifying question, and vendors answer it very differently.
If I run the same client twice, do I get the same result? Ask them to demonstrate it rather than confirm it.
Can I trace any figure back to its assumptions? Pick something deep in the projection and follow it.
What happens when the AI is wrong? A tool that surfaces suggestions for your judgment fails safely. A tool that silently writes into the plan does not.
Where does my client data go, and is it used for training? For Canadian advisors this is a data residency and privacy question before it is an AI question.
The Position Worth Holding
AI belongs in planning software. Advisors who refuse it will spend time on work that could be automated, and they will communicate less clearly than colleagues who use it well.
But the value is in the assistance, not the autonomy. The category is currently marketing autonomy because it demonstrates better, and because "our AI reviews the plan you built" is a harder pitch than "our AI builds the plan."
It is also the honest one. The advisor is accountable for the recommendation, so the advisor has to remain the author of it. Software that respects that constraint is more useful than software that pretends it away, and considerably easier to defend when someone asks you to explain your work.
Finn reviews plans rather than generating them. Every figure Finn discusses comes from PlanBase's deterministic engine, so the same client data produces the same numbers every time.