The gap between what's legal and what's safe
A Canadian organization deploying AI today can be fully compliant with every law on the books and still have no idea what its AI systems are actually doing. That's not a contradiction. It's the current state of Canadian AI regulation, and it's the reason "control plane" has to mean something more specific than "wait for the law to catch up."
There is no general law in Canada that governs AI models and systems. The Artificial Intelligence and Data Act — the federal government's attempt at exactly that framework — has been sitting in Parliament since 2022 and is unlikely to receive Royal Assent this year, if it survives in its current form at all. What exists instead is a patchwork: privacy law, sector-specific rules, and a scattering of provincial moves like Ontario's requirement that employers disclose when AI is used in hiring decisions. Exporters serving EU markets face a different pressure entirely, since the EU AI Act's high-risk obligations phase in through 2026 and 2027 regardless of what Ottawa does.
The practical consequence for a security or technology leader is this: nobody is coming to tell you what's mandatory. The Canadian Centre for Cyber Security has published detailed guidance on AI security actions, and it's worth taking seriously precisely because it's one of the few concrete, Canada-specific reference points available — but it's guidance, not law. A control plane built only to satisfy eventual legislation will be built too late and probably built wrong, because it will be designed around compliance categories that don't yet exist instead of around the operational reality of what your AI systems can already reach.
What a control plane actually has to do
Strip away the framework language and a control plane is answering three questions continuously, not once: what can this AI system do, who is accountable when it does something unexpected, and how quickly can someone find out and intervene. Every other component — logging, approval workflows, risk scoring — exists in service of those three questions.
Consider how this plays out at a mid-sized firm that deploys an AI agent to handle routine customer account inquiries and process low-value transfers. The pilot works. Over six months, the agent gets connected to three adjacent systems, one expansion at a time, because each connection solved a real operational problem and nobody wanted to be the person who slowed down a project that was clearly working. At no point did anyone sit down and decide, formally, that the agent should have this scope. Each step was locally reasonable. The aggregate is a system with access nobody signed off on and a change history nobody can reconstruct.
This is the pattern the Five Eyes' joint guidance on agentic AI security calls out directly: agentic systems inherit every weakness of the underlying language model, then add a wider attack surface, more autonomy, and accountability that gets harder to trace with each expansion. The guidance's recommendation is blunt — never grant broad or unrestricted access, and limit agentic AI to low-risk, non-sensitive tasks until oversight and evaluation methods mature. That's a narrower mandate than most pilots end up with in practice, which is exactly the gap a control plane is meant to close.
Accountability has to be a name, not a policy
The single most common failure in AI governance isn't a missing technical control. It's the absence of a person who can be asked, on short notice, "what is this system allowed to do, and who approved the last change to that scope?" Policy documents don't answer that question under time pressure. A named owner does.
For every AI deployment — not just the ones that feel high-stakes at launch, since scope creep is exactly how low-stakes deployments become high-stakes ones — someone specific needs to own the answer to what it can access, why, and since when. That ownership has to survive personnel changes and reorganizations, which means it belongs in deployment documentation, not in one person's institutional memory. This sounds obvious stated plainly and is nonetheless the control most organizations skip, because assigning a name creates accountability that's uncomfortable to assign and easy to defer.
Where NIST's framework earns its keep — and where it doesn't
The NIST AI Risk Management Framework is the closest thing available to a structured methodology for this problem: it walks organizations through identifying risks, scoring their potential impact, and selecting controls proportionate to that impact. Used well, it forces a discipline that ad hoc governance rarely achieves — someone has to actually articulate what could go wrong before deciding whether the current controls are adequate.
It's worth being honest about its limits, too. NIST's own guidance on monitoring deployed AI systems acknowledges that while pre-deployment evaluation is well understood, post-deployment monitoring — the ongoing work of watching what a system does once it's live, in production, interacting with real data — has no widely validated methodology yet. Terminology isn't even standardized across the field. That's not a reason to skip monitoring. It's a reason to treat any vendor claim of "continuous AI monitoring" with the same skepticism a security team would apply to a vendor claiming "unbreakable encryption." The framework tells you what questions to ask. It does not yet tell you, with confidence, how to verify the answers.
The urgency argument, and why it's not manufactured
It would be easy to treat all of this as hypothetical risk management — the kind of governance advice that sounds responsible but describes a threat that hasn't materialized yet. The Canadian Centre for Cyber Security's own statement on frontier AI models argues otherwise. Its assessment is that frontier models can now help threat actors find and exploit vulnerabilities significantly faster than before, compressing the window defenders have to respond from days or weeks down to hours in some cases. That's not a claim about AI agents misbehaving inside your organization. It's a claim about the speed of the external threat environment your control plane has to operate in. A governance structure that takes weeks to detect an unauthorized access expansion is being built for a threat landscape that no longer exists.
The honest tradeoff
None of this is free, and pretending otherwise would undercut the case for doing it. A named owner for every deployment, documented access boundaries, logging detailed enough to reconstruct a decision after the fact, tested fallback processes — every one of these adds friction and cost to systems whose main selling point is speed. An organization that builds this well will deploy AI more cautiously, and probably more slowly, than a competitor that doesn't bother. That is a real cost, not a rhetorical one, and any leader proposing a control plane to their board should say so plainly rather than pretending governance is free.
The counterargument that it's not worth it — that Canada's absence of a general AI law means organizations have room to move fast now and formalize later — has a real weakness, though: "later" is when the incident already happened. The gap between AIDA's uncertain future and the Cyber Centre's current guidance isn't a gap in urgency. It's a gap in what's mandatory versus what's prudent, and for the systems already touching customer data, financial transactions, or health records, prudent is the only bar that matters right now.
The decision this actually comes down to
Canadian organizations don't get to wait for AIDA, and they shouldn't want to. Legislation, when it arrives, will codify a floor — a minimum standard applied after the fact to systems already deployed. The organizations in the best position when that happens will be the ones that treated the Cyber Centre's guidance as an operational baseline now, not a compliance milestone to hit later. The ones caught flat-footed won't be caught by the law. They'll be caught by an AI system that expanded its own reach three approvals ago, with no one able to say when, why, or who signed off.