What Financial Institutions Need to Know About AI Security Frameworks

Tae Yeon Eom21 min read·Just now

From global standards to Canada’s post-AIDA governance vacuum — and what the most advanced institutions are doing about it

Here is a productive way to think about where AI in financial services currently stands: the technology has outpaced the institutions built to govern it, the laws built to regulate it, and the risk frameworks built to contain it — in that order. The distance between those three layers is where most of the real danger lives, and also where most of the competitive advantage is available to institutions that close it first.

The global AI market is on track to reach approximately CAD $1.2 trillion by 2026. The financial sector is among the most aggressive adopters. But adoption has outrun confidence in governance. A major survey published earlier this year found that while Canadian financial executives are experimenting with AI at high rates, they are deploying it at enterprise scale at a notably lower rate than their global counterparts — even though the technology available to them is identical.

This piece maps that divide across three layers. First, the global security frameworks converging into a common compliance baseline. Second, the distinctive — and, following the collapse of Canada’s first federal AI bill in early 2025, considerably more complex — Canadian regulatory situation. Third, the specific technical and organizational disciplines that separate institutions successfully deploying AI from those still running indefinite pilots.

Canada’s most advanced financial institutions have taken meaningfully different approaches to closing that divide. Each tells us something useful. This piece examines what those approaches reveal.

I. The Converging Global Baseline

No single jurisdiction has enacted a binding, comprehensive AI security standard for financial services. What exists instead is a body of authoritative frameworks hardening into regulatory expectations — and, in some jurisdictions, into statutory obligations. Understanding how these frameworks relate to each other is the starting point for any serious governance conversation.

NIST AI RMF: The Organizing Logic

The NIST AI Risk Management Framework (AI RMF) has become the closest thing to a universal governance operating system for AI. Its four core functions — Govern, Map, Measure, and Manage — are technology-neutral by design, which is their primary strength for institutions running multiple model types simultaneously.

A bank deploying an LLM for client service, a time-series model for credit risk, and a reinforcement-learning engine for trading runs fundamentally different risk profiles across three systems. The NIST AI RMF provides a single taxonomy and accountability structure that applies across all three, integrating AI risk into an institution’s existing enterprise risk management (ERM) framework rather than isolating it inside IT.

ISO/IEC 42001: The Certification Layer

Where NIST provides the organizing logic, ISO/IEC 42001 provides an auditable certification layer. By standardizing terminology and process controls across the AI model lifecycle, ISO 42001 enables a multinational institution to build its compliance architecture once — to the most demanding standard — and map downward to local requirements, rather than redesigning separate programs jurisdiction by jurisdiction. For large Canadian banks operating across North America, Europe, and Asia-Pacific, that efficiency is real.

OWASP LLM Top 10 and MITRE ATLAS: The Engineering Reality Check

Policy frameworks cannot substitute for the engineering specificity that OWASP’s LLM Top 10 and MITRE ATLAS provide. OWASP catalogs vulnerabilities specific to large language model architectures — prompt injection, training data poisoning, insecure output handling — with the rigor previously applied to web application security. MITRE ATLAS maps adversarial tactics, techniques, and procedures (TTPs) against AI systems in a format that security operations teams already know from MITRE ATT&CK.

Together, they eliminate the translation friction between a board-level AI policy and a security engineer’s threat model. Without them, governance documentation and engineering practice tend to diverge — and the divergence is where exposure accumulates.

The FS AI RMF: When Generic Principles Meet Banking Operations

Recognizing that general frameworks do not capture the regulatory scrutiny, consumer protection obligations, and operational complexity specific to banking, the U.S. Department of the Treasury released the Financial Services AI Risk Management Framework (FS AI RMF). Its most practically useful contribution is the ‘AI Lexicon’ — a standardized vocabulary designed to resolve the communication failures that occur when legal, technology, and business teams use the same words to mean entirely different things. Left unaddressed, that vocabulary disconnect creates compliance blindspots at exactly the boundaries where oversight matters most.

Four Frameworks: Roles and Strategic Value

Press enter or click to view image in full size

II. Canada’s Governance Vacuum — and How OSFI Filled It

To understand what Canadian financial institutions are actually navigating in 2026, one fact matters above all others: Canada’s only attempt at federal AI legislation is dead. Everything else in the domestic regulatory environment follows from that.

The End of AIDA — and What Comes Next

The Artificial Intelligence and Data Act (AIDA), introduced as part of Bill C-27, was Canada’s first attempt at a comprehensive federal AI framework. It was effectively shelved in early 2025 when a change in government and a subsequent election wiped the Order Paper clean.

That does not mean the regulatory landscape is static. Canada’s AI Minister, Evan Solomon, confirmed on May 4, 2026 that a new national AI strategy is coming “very soon,” following consultations that drew more than 11,000 submissions. The government’s spring economic statement has already outlined six pillars for the forthcoming strategy: new privacy and online safety laws, sovereign compute infrastructure, support for Canadian AI companies, international coordination, AI education and training, and pro-worker AI development. The direction is becoming clear — even if the binding text has not yet arrived.

For financial institutions, the practical calculus has not changed: there is no enacted statute to wait for. But the vacuum is not permanent. Institutions building OSFI-aligned governance now are not just managing current risk — they are positioning themselves to map downward to federal requirements when they crystallize, rather than rebuilding upward from compliance minimums.

The absence of federal legislation does not mean lighter regulation. It means heavier self-imposed accountability. Without a checklist-style statutory minimum to satisfy, institutions must now interpret and demonstrate compliance with OSFI’s principles-based guidelines on their own terms — a far more demanding governance challenge than ticking statutory boxes. This is precisely why the 29% enterprise deployment rate makes sense: the institutions that have scaled AI are those that resolved the governance ambiguity themselves, rather than waiting for a law to resolve it for them.

CAISI: The Government’s Alternative Mechanism

In the absence of legislation, the federal government moved through a different channel. In November 2024, the Canadian Artificial Intelligence Safety Institute (CAISI) launched with a CAD $50 million, five-year commitment as part of the broader $2.4 billion AI investment in Budget 2024. It is led by ISED, with research streams through CIFAR and the National Research Council, and is a founding member of the International Network of AI Safety Institutes alongside counterparts in the US, UK, Japan, and Singapore.

CAISI does not create compliance obligations. It is not a substitute for OSFI guidance. But it signals that frontier model evaluation, interpretability research, and adversarial robustness testing are government priorities — not only academic ones. Institutions already building those capabilities internally are better positioned to engage with CAISI’s outputs as they develop.

OSFI Guideline E-23: The Governing Standard

OSFI’s revised Guideline E-23 — Model Risk Management is the most consequential piece of AI governance that Canadian FRFIs must act on. Published in final form September 11, 2025 and effective May 1, 2027 — with an 18-month transition period already underway — it marks the most significant update to model risk management expectations since the original 2017 guideline.

Four provisions carry the most weight:

• Scope expansion. The revised guideline applies to all FRFIs — banks, foreign bank branches, life insurance, property and casualty, and trust and loan companies. Federally Regulated Pension Plans (FRPPs) are explicitly excluded. AI and ML models are expressly included in the definition of ‘model’ the guideline governs.

• Qualitative risk tiering. Institutions must rate model risk using both quantitative factors (financial impact) and qualitative ones: model complexity, level of autonomous decision-making, input data reliability, customer impact, and regulatory risk. A small-balance credit model with high automation and limited override may warrant higher-tier governance than a much larger but manually reviewed model.

• Self-learning model governance. Institutions must define what constitutes a ‘material change’ in models that update their own parameters — and when such changes trigger mandatory re-validation. Gradual, silent model drift in production is harder to govern than an overt failure, and E-23 makes that challenge explicit.

• Third- and fourth-party accountability. Deploying a vendor’s black-box model does not transfer institutional liability to the vendor. FRFIs remain responsible for understanding and controlling externally sourced model behavior, including due diligence on training data and architecture where IP restrictions limit full disclosure.

Guidelines B-13 and B-10: Infrastructure and Supply Chain

OSFI’s Guideline B-13 (effective January 2024) requires FRFIs to align cybersecurity strategy with overall business strategy and to build governance capable of defending against AI-augmented threats. Revised Guideline B-10 addresses the AI supply chain — requiring a Third-Party Risk Management Framework covering the full lifecycle of external AI relationships from sourcing to exit. The concentration risk created by dependence on a small number of foundation model providers is treated in B-10 as a systemic concern, not merely a vendor management question.

FIFAI II and the AGILE Framework

The AGILE Framework provides the most operationally useful synthesis of Canadian regulatory expectations. It was developed through the Financial Industry Forum on AI (FIFAI II) by OSFI, the Global Risk Institute, the Bank of Canada, and FCAC, in collaboration with industry practitioners:

III. The Adoption Hurdle: Why Experimentation Is Not Deployment

The regulatory architecture described above is designed to enable something that most Canadian financial institutions have not yet achieved: enterprise-scale AI deployment that delivers measurable business value without introducing unacceptable risk. Understanding why that hurdle persists is as important as understanding the frameworks designed to lower it.

The numbers are specific. PwC Canada’s 29th Annual CEO Survey (January 2026, 133 Canadian CEOs) found that 94% of Canadian CEOs use AI in some form — but only 29% have scaled it enterprise-wide, compared to 43% globally. At the global level, PwC’s broader survey of 4,454 CEOs across 95 countries found that 56% report no revenue or cost benefit from AI investments, and only one in eight say AI has delivered both cost and revenue gains.

94% experimenting. 29% deployed at scale. That 65-point divide is not a technology problem. It is a governance confidence deficit — and it is costing Canadian financial institutions a measurable competitive position relative to global peers.

The underlying constraint is institutional confidence. Banks must prove — to themselves, to regulators, and to their boards — that AI can be deployed in high-stakes, customer-facing contexts like credit adjudication or fraud detection without creating uncontrollable liability. Currently, the fear of unexplainable model behavior, adversarial exposure, or regulatory challenge keeps most AI use cases confined to internal productivity tools. That is where the risk is lowest. It is also where the value is smallest.

Part of that caution is architecturally justified. Generative AI systems are, at their foundation, language models: they predict the most probable next token in a sequence, not the mathematically correct answer to a numerical problem. Analysis of the Canadian financial sector consistently finds that generative AI is well-suited to customer interaction, document synthesis, and internal knowledge retrieval — but is architecturally unsuited to the kind of precise numerical computation that underpins credit pricing, regulatory capital calculations, and trading risk. The institutions that are deploying AI successfully have been deliberate about this boundary: language models for language tasks, purpose-built quantitative models for numeracy. Ignoring that boundary is one of the most reliable ways to create model risk exposure that neither the NIST AI RMF nor OSFI E-23 will excuse.

Several Canadian institutions are navigating this more deliberately. Scotiabank’s AI and Data Ethics approach integrates governance into a three-lines-of-defence structure, separating business deployment, risk oversight, and internal audit. TD’s Trustworthy AI team, built around its Layer 6 acquisition, focuses on fairness testing across demographic groups alongside predictive performance. Both approaches share the same recognition: governance cannot be a gate inserted at the deployment approval stage. It has to be present from the beginning of the research and engineering process.

IV. The Technical Requirements: What Governance Looks Like at the Engineering Layer

Translating governance frameworks into production security requires confronting technical realities that policy documents cannot address in sufficient detail. The most fundamental vulnerability of modern LLMs and deep learning architectures is structural: the control plane and the data plane are not separated. Instructions and user input traverse the same neural pathways. That makes these systems susceptible to manipulation through their inputs in ways that conventional software is not.

The Canadian Centre for Cyber Security has explicitly stated that financial institutions must implement proactive AI security measures to counter data theft, reputational damage, and financial loss from AI misuse — and that reactive approaches applied after deployment are insufficient.

The Adversarial Threat Surface

Security and engineering teams must now defend against four distinct categories of adversarial attacks that traditional IT security was never designed to handle:

• Prompt injection: malicious instructions embedded in what appears to be ordinary user input, causing the model to execute unauthorized commands or disclose confidential data to a third party.

• Jailbreaking: inputs framed in ways that the model’s alignment training fails to recognize as policy violations, bypassing safety filters to produce restricted behavior or content.

• Data extraction: forcing models into repetition loops or other error states that cause them to output fragments of training data — potentially exposing sensitive customer records present during training.

• Model inversion: reconstructing sensitive attributes from training data by systematically analyzing model outputs, without direct access to the training dataset.

Layered Defense: What Works in Practice

The most effective institutional responses combine multiple defense mechanisms, each operating at a different layer of the model stack:

Model guardrailing. Frameworks like NeMo Guardrails impose deterministic constraints around probabilistic generative models. Regardless of how a prompt is constructed, the model cannot act or access data outside explicitly permitted parameters. Think of it as a hardware security module, applied to LLM behavior.

Dual LLM architecture — and the case for non-agentic oversight. A secondary model evaluates both the inputs to and outputs from the primary model in real time, flagging adversarial intent or policy violations before any response reaches a user. Critically, this secondary model must itself be designed as a non-agentic system — one with no independent goals, no capacity for autonomous action, and no channel through which it can be manipulated by the same inputs it is monitoring. This is the architectural principle behind Yoshua Bengio’s Scientist AI concept, developed through his LawZero nonprofit: an AI designed only to understand, predict, and flag — not to act. In his framing, “we can use those non-agentic AIs as guardrails that just need to predict whether the action of an agentic AI is dangerous.” For financial institutions deploying LLMs in regulated contexts, that design principle is not merely theoretical. It is a practical specification for what the secondary model in a dual-LLM architecture should and should not be able to do.

Defensive prompt engineering. Models designed to continuously self-check against their security constraints during generation substantially reduce jailbreak success rates without requiring external intervention at inference time.

Continuous prompt pattern monitoring. Analyzing patterns across the full population of model interactions — not just flagging individual suspicious queries — enables detection of coordinated adversarial campaigns invisible at the single-transaction level.

Privacy-Preserving Training

AI model performance scales with training data volume. That places it in direct tension with data minimization principles central to Canadian privacy law. Financial institutions hold restricted PII and transaction records that cannot be exposed in external training pipelines without categorical compliance violations.

The practical solution is differential privacy combined with synthetic data generation: producing datasets that preserve the statistical distributions and predictive value of real data while making it mathematically impossible to reverse-engineer individual customer attributes. Large-scale model training can proceed in secure internal environments without moving production data outside institutional controls.

Explainability

OSFI E-23, the AGILE framework, and the FIFAI II report all converge on the same requirement: high-impact AI systems must be explainable. For credit adjudication, fraud flagging, and trading risk, the ability to reconstruct the reasoning behind a specific output is a regulatory expectation and, in certain contexts, a consumer right. Deep learning architectures resist this natively. Three design approaches address it directly:

• Local post-hoc explanations (e.g., SHAP values) that attribute each input feature’s contribution to a specific decision

• Global interpretability techniques that characterize the model’s overall decision logic across the full input distribution

• For LLM applications: chain-of-thought output and source attribution that allow human reviewers to verify the basis for generated content in near-real time

V. The Most Demanding Test Case: What RBC Borealis Built — and What It Cost

Abstract governance principles are most useful when tested against an operational example. Among Canadian financial institutions, RBC represents the most capital-intensive and infrastructure-heavy approach to closing the governance-deployment divide — a decade-long investment that produced a proprietary answer to problems that most institutions are still solving with commercial tools. It is not the only viable approach, but it is the most fully executed at scale, and the technical choices it reveals are instructive regardless of an institution’s size.

RBC has ranked first in Canada and third globally for AI maturity in the Evident AI Index for four consecutive years — across 50 major financial institutions. The bank has committed to generating CAD $700M–$1B in enterprise value through AI-driven innovation by 2027. Reaching that target required embedding AI into core credit, trading, and client infrastructure — not running isolated pilots — and that required solving the full technical stack described in Section IV at a scale and cost that few institutions can match directly.

ATOM and Lumina: The Infrastructure-First Approach

In July 2025, RBC formally announced ATOM (Asynchronous Temporal Model) — a proprietary foundation model for financial services developed by RBC Borealis over several years of sustained research investment. The approach reflects a specific strategic judgment: that for an institution with RBC’s data volume and regulatory exposure, the most reliable way to train a high-performing and governable AI model is to build sovereign infrastructure rather than rely on third-party pipelines.

ATOM was trained on billions of RBC client financial transactions. The model addresses a technically hard problem: financial event data arrives in asynchronous, irregular patterns. A client might make three transactions in one hour, then nothing for ten days, then a cluster of activity. That non-uniform cadence is the actual structure of banking data, and it requires an architecture fundamentally different from the uniform token sequences that general-purpose LLMs process.

ATOM runs on Lumina — RBC’s internal enterprise AI platform, built on Canada’s largest private-sector GPU cluster, second only to the federal government, processing up to 10 billion transactions per minute across all business lines. Lumina is the infrastructure that allows RBC to train and serve AI models on live production data without exposing that data to external APIs or third-party pipelines — directly operationalizing the privacy-preserving training requirement described in Section IV.

That infrastructure position carries its own financial risk, and it is worth naming directly. AI hardware — GPUs in particular — depreciates substantially faster than the legacy server infrastructure it often displaces. Industry analysis increasingly notes that the capital cycle for AI compute is measured in months to a few years, not the decade-plus useful life of conventional IT assets. For institutions that have made the sovereign infrastructure bet, maintaining competitive AI capability requires ongoing capital commitment, not a one-time build. RBC’s willingness to absorb that cost is itself a strategic signal — and a structural barrier that most institutions will choose to route around rather than replicate.

ATOM is now deployed across 15 RBC products and services, including credit adjudication. The performance advantage this creates is real — but it is inseparable from the investment required to produce it. ATOM’s results depend on access to transaction data accumulated over decades and infrastructure purpose-built to use it safely. That combination is not easily replicated, which is precisely why most institutions — including well-resourced ones — are pursuing different approaches to the same underlying problem.

RESPECT AI: Governance as Engineering Specification

RBC’s RESPECT AI™ program maps directly onto the technical requirements described in Section IV. Each pillar corresponds to a specific engineering discipline, not a governance aspiration:

• Robustness. The adversarial defense mechanisms described in Section IV — guardrailing, non-agentic dual-model oversight, pattern monitoring — are operationalized here. The open-source Advertorch adversarial robustness library, published by Borealis, exposes these defenses to external peer review — strengthening RBC’s own systems while raising the sector’s collective baseline.

• Data Privacy. The differential privacy and synthetic data generation techniques described in Section IV are implemented through Lumina at the infrastructure level — allowing training on billions of real client transactions without violating the data minimization principles that external cloud pipelines would breach.

• Fairness. Continuous bias testing across demographic groups ensures models do not produce disparate outcomes — a requirement under both the AGILE framework and existing human rights obligations applicable to lending and employment decisions.

• Model Governance. OSFI E-23 compliance is integrated throughout the development lifecycle as a design input. The ‘material change’ threshold required by E-23 for self-learning models is defined in policy before training begins, not identified after deployment.

• Explainability. Ongoing research investment in decoding deep learning decision mechanisms for regulatory auditors and consumer disclosures — applied at the model design stage rather than added retroactively.

The Organizational Factor: Authority, Not Just Culture

Cultural alignment matters, but executives respond to org charts. In February 2026, RBC formalized what had previously been distributed AI activity by creating a dedicated AI Group — an internal AI accelerator reporting directly to CEO Dave McKay. The group is led by Bruce Ross, who spent 12 years as RBC’s Group Head of Technology and Operations before taking on the inaugural role. RBC spends more than CAD $5 billion annually on technology, with AI investment explicitly embedded in that figure.

Ross has framed the institutional commitment directly: “Transformation is defined by two variables: the quality and scale of the people you commit to it, and the money you put behind it.” The creation of a dedicated group with direct CEO reporting is the organizational mechanism that converts that commitment into accountability — and that prevents AI governance from becoming the responsibility of everyone in general and no one in particular. When McKay says “there isn’t a part of our business that isn’t being impacted by AI,” the organizational structure is what makes that statement operationally meaningful rather than aspirational.

The MIT CSAIL Partnership: Academic Research as Competitive Infrastructure

RBC’s partnership with MIT CSAIL’s FinTechAI initiative provides early access to foundational work in secure computation, cryptography, and adversarial defense. These are technical challenges that remain primarily academic research problems — and they take years to reach commercial markets through conventional vendor channels. Having a direct pipeline to that research before it is published is another dimension of the same infrastructure-first strategy: accumulate structural advantages that compound over time rather than competing on commercially available model capability.

VI. Five Priorities — Scaled to Your Institution

Not every institution needs to build what RBC built. OSFI’s E-23 guideline is explicit on this point: requirements apply proportionally to an institution’s size, complexity, and risk profile. A credit union or mid-size regional bank is not expected to maintain a sovereign AI infrastructure processing billions of transactions. What it is expected to do is demonstrate that its AI models — however they are sourced — are understood, governed, and controlled to a standard commensurate with the risk they create.

The five priorities below apply across institution sizes, though their implementation varies significantly between a Tier 1 global bank and a regional lender. The strategic logic is identical. The capital commitment is not.

1. Treat the Post-AIDA Period as a Build Window, Not a Waiting Room

Canada’s national AI strategy is imminent — not indefinite. When it arrives, it will set new expectations. Institutions building ISO 42001-aligned governance frameworks now will map downward to those requirements rather than rebuilding from scratch. For smaller institutions, this means establishing a documented model inventory and governance policy today — not a Lumina-scale platform, but a principled foundation that OSFI can audit and that future federal requirements can extend.

2. Standardize AI Vocabulary Across Disciplines

‘Model drift,’ ‘adversarial robustness,’ and ‘distributional shift’ must be translatable into terms that risk officers can connect to capital adequacy and regulatory reporting. Building an internal AI lexicon — consistent with the FS AI RMF’s sector-level vocabulary — eliminates the cross-functional vocabulary disconnect that creates compliance blindspots at disciplinary boundaries. This costs no capital. It costs coordination.

3. Embed Security at the Architecture Stage — Including the Oversight Model

Adding guardrails to a deployed LLM is substantially less effective than designing for security from the first architecture decision. For institutions using commercial foundation model APIs — which describes the majority — this means dual-model oversight (designed as a non-agentic monitoring system, per Bengio’s principle), defensive prompt engineering, and rigorous output monitoring built into the deployment design. The goal is the same as Lumina’s; the implementation is necessarily different in scale. And critically: define the boundary between language tasks and numerical tasks before deployment, not after a model produces a regulatory-grade calculation error.

4. Audit the Full AI Supply Chain to the Fourth-Party Level

OSFI B-10 and B-13 make clear that liability does not terminate at the vendor boundary. FRFIs must trace AI model dependencies through to the foundation model level — understanding what the external AI service is built on, what data that foundation model was trained on, and whether its known failure modes are compatible with the institution’s risk appetite. For institutions relying on third-party APIs, this is not optional due diligence. It is the primary mechanism for satisfying E-23’s third- and fourth-party accountability requirement.

5. Build AI Literacy Matched to the Actual Threat Model

Boards need sufficient understanding of agentic AI systems to govern their strategic deployment. Frontline staff need practical training to recognize deepfake-based impersonation and AI-generated social engineering attacks — now being generated by adversaries using the same model capabilities institutions are building. These require different training programs. Both are necessary, and neither depends on proprietary infrastructure to implement.

Conclusion

The competition in financial AI is not primarily a technology competition. It is a governance competition. The institutions that will generate disproportionate value over the next five years are not those with access to the most powerful commercial models — that access is available to anyone who can afford an API. They are the institutions that have built the governance infrastructure, the technical architecture, and the organizational culture that make AI deployment in regulated, high-stakes contexts actually safe.

Canada’s most advanced institutions have converged on that insight through different routes. RBC Borealis pursued the most capital-intensive path: a proprietary foundation model trained on sovereign data, governed through closed enterprise infrastructure, with a dedicated AI Group and direct CEO accountability providing the organizational authority to match the technical ambition. The approach carries real costs — including the ongoing capital commitment required to maintain competitiveness as AI hardware depreciates faster than any previous generation of compute infrastructure. TD took a different bet — acquiring Layer 6 and building a Trustworthy AI capability centered on demographic fairness and bias control across its model portfolio. Scotiabank anchored its approach in organizational design: a three-lines-of-defence structure that separates business deployment, risk oversight, and internal audit at the process level. Three different strategies. One shared recognition: the governance problem had to be solved before the deployment problem could be.

Canada’s post-AIDA regulatory environment makes this recognition more demanding, not less. A national AI strategy is imminent — but until it arrives, the absence of a statutory minimum floor means institutions must set their own standard and demonstrate it. The gap between experimentation and enterprise deployment visible across the Canadian financial sector is not evidence of technological lag. It is evidence of governance ambiguity that has not yet been resolved.

The institutions that resolve it — through sovereign infrastructure, acquired capability, or disciplined organizational design, at whatever scale fits their risk profile — will not just move AI out of pilot mode. They will build the kind of operational trust that regulators, customers, and boards extend only to institutions that have earned it. In financial services, that trust has always been the harder asset to build. It remains the more durable one.

Connect on LinkedIn: linkedin.com/in/taeyeoneom

Key References

• NIST AI Risk Management Framework

• ISO/IEC 42001 — Global AI Governance Standards

• U.S. Treasury: Financial Services AI Risk Management Framework

• OWASP / MITRE ATLAS — AI Security Frameworks

• Bill C-27 / AIDA: Timeline of Developments (Gowling WLG)

• The Demise of AIDA: 5 Key Lessons (McInnes Cooper)

• Canada’s AI Strategy: Six Pillars Outlined (CBC News, April 28, 2026)

• Solomon Says National AI Strategy Coming ‘Very Soon’ (BNN Bloomberg, May 4, 2026)

• Government of Canada Launches CAISI (November 2024)

• CAISI — Budget 2024 Announcement (CIFAR)