Getting started with AI is not a technology decision. It is a business decision that happens to involve technology. Most organizations in Canadian financial services have this backwards.
They pick the tool before they define the problem. They assume the data is clean because nobody has checked it properly yet. They rush the requirements and skip the foundation.
Then six months later the implementation is stalled, the budget is stretched, and the board is asking questions nobody wants to answer.
Getting started with AI is not a technology decision. It is a business decision that happens to involve technology.
The organizations that treat it as a technology decision start by selecting tools. They evaluate vendors. They run proofs of concept on curated datasets that look nothing like their production data. They build excitement in the boardroom based on demos that do not reflect the actual complexity of their environment.
Then the real work begins. And the gap between the demo and the delivery is where programs go to die.
It starts with the right questions. Not what AI can do. What your organization is actually trying to solve.
What are we trying to solve? Not at the technology level. At the business level. What decision is being made today manually that AI could support? What process is consuming resources in a way that pattern recognition could reduce? What outcome are we trying to change and how will we know if it changed?
What does our data look like today, honestly? Not what the data dictionary says it looks like. What it actually looks like when someone pulls it and examines it. The completeness, the consistency, the coverage across the years and the systems that matter for this problem.
What does success look like in six months, not six years? AI programs that are defined by long-term outcomes with no near-term checkpoints are programs that lose organizational support before they produce anything. Six-month success needs to be specific, measurable, and achievable with the data and capability you actually have right now.
Who owns this when the project ends? The model, the monitoring, the governance, the retraining cycle. If there is no answer to that question before the program starts, there will be no answer when it ends either. The program will produce a model that nobody maintains, running on data that nobody is accountable for, producing outputs that nobody trusts.
The organizations that get AI right get the foundation right first. That is not a constraint. That is the work.
In Canadian financial services, the foundation that gets skipped most often is data governance. Organizations arrive at AI programs with years of accumulated data that has never been examined for the specific purpose of training a model. The data exists. The quality is unknown. The ownership is unclear. The lineage is undocumented.
A model trained on that data will learn whatever patterns are in it, including the errors, the gaps, the inconsistencies, and the historical decisions that no longer reflect current business intent. The model will perform well on the training data. It will not perform well in production. The difference between those two things is where the confidence of the original business case meets the reality of the deployment environment.
The requirements that get skipped most often are the ones nobody wants to write: the edge cases, the exceptions, the failure modes. What happens when the AI output is wrong? Who reviews it? What is the process for a human to override it? What gets logged? These questions are not interesting to answer before deployment. They are critical to answer before deployment. After deployment it is too late to design them properly.
At JK Advisory we work with financial services organizations at exactly this stage. Before the tools. Before the vendor. Before the model.
We help organizations define the problem clearly enough that the technology selection becomes straightforward. We assess the data honestly enough that the scope reflects reality rather than optimism. We structure the governance before it is needed rather than after it is overdue. We write the requirements for the hard parts, not just the happy path.
That work is not glamorous. It does not generate the kind of boardroom excitement that a vendor demo produces. But it is the work that determines whether the program is still running eighteen months later or has quietly been deprioritized while the team moves on to the next initiative.
Because the organizations that get AI right get the foundation right first.
If that is the conversation your organization needs to have, we have had it before.