Does the EU AI Act reach a Canadian supplier?
A European customer has sent an AI Act clause and asked you to confirm compliance. You are in British Columbia, your servers are in Canada, and nobody in the company has read a European regulation before. The first question is not what to do — it is whether the thing reaches you at all, and that question has a real answer.
Published 22 September 2026. Written by the SecHB practice, Greater Vancouver, British Columbia.
The short version
A supplier outside the European Union can be reached by this Regulation, because its scope provisions are written to follow the market and the output rather than the establishment of the company. Establishment outside the Union is expressly not a defence, and the output of a system used in the Union is a separate hook again.
Whether it reaches your organization, and in which role, is a legal determination and belongs with your counsel. What follows is what the instrument says, so that the conversation with counsel starts from the text rather than from a summary of a summary.
Identifying the instrument correctly
The document people mean by “the EU AI Act” is Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence … (Artificial Intelligence Act), published in the Official Journal. Cite it by number. Newsletters and vendor pages paraphrase it heavily, and the paraphrases have drifted.
It is a Regulation, not a Directive, which in European law means it applies as written rather than through a national transposing statute in each member state.
Why a supplier outside the EU can be caught
Two limbs of the scope provision do the work, and they are short enough to quote. The Regulation applies to providers placing on the market or putting into service AI systems or placing on the market general-purpose AI models in the Union, irrespective of whether those providers are established or located within the Union or in a third country
.
And separately, to providers and deployers of AI systems that have their place of establishment or are located in a third country, where the output produced by the AI system is used in the Union
.
The second limb is the one Canadian suppliers underestimate. It does not require you to sell in Europe, to have a European entity, or to host anything there. It attaches to where the output is used. A recital makes the intent explicit: the purpose is to prevent circumvention and to protect people located in the Union, including where a European operator contracts work out to an operator in a third country.
Why no timeline appears on this page
The Regulation applies in stages rather than all at once, and the staged dates have been the subject of amendment. A date published on a consultancy page is exactly the kind of fact that is true when written, false eighteen months later, and quoted by somebody making a plan in between.
No date is published on this page. The Regulation applies in stages and the timetable has been amended, so the only safe answer is the one read from the consolidated text on EUR-Lex at the time the question is asked — and whether it reaches your organization at all is a question for your counsel. The consolidated text on EUR-Lex is the source that is current by construction; nothing here is a substitute for reading it, and the timing question is checked there at engagement time.
What the Regulation says about the cybersecurity of AI systems
This is the part a security practice can speak to directly, and it is unusually concrete. The recitals state that cyberattacks against AI systems can leverage AI specific assets, such as training data sets (e.g. data poisoning) or trained models (e.g. adversarial attacks or membership inference), or exploit vulnerabilities in the AI system’s digital assets or the underlying ICT infrastructure
.
That is a threat model written into a legal instrument, and it maps onto ordinary engineering work.
| What the text names | What it means in a system you run |
|---|---|
| Training data | The recitals name data poisoning as an attack on an AI-specific asset. In a shipping product the asset that matters is usually the retrieval corpus rather than the pre-training set, because that is the one an outsider can write into. |
| Trained models | Named alongside adversarial attacks and membership inference. The practical questions are who can reach the weights, what integrity evidence exists for each artifact, and what an output reveals about the data behind it. |
| Model leakage and theft | The recitals on general-purpose models with systemic risk reach accidental leakage, unauthorised release, circumvention of safety measures, unauthorised access and model theft — which in engineering terms is access control, egress control and artifact integrity around the weights and the serving infrastructure. |
| Adversarial testing | Named for providers of general-purpose AI models with systemic risk, with internal or independent external testing both contemplated. Testing is carried out only with signed authorization, to a scope agreed in writing. |
Adversarial testing and model protection for general-purpose models
For providers of general-purpose AI models with systemic risk, the recitals contemplate model evaluations before first placing on the market, including conducting and documenting adversarial testing of models, also, as appropriate, through internal or independent external testing
.
On the protection side, the same material states that cybersecurity protection should consider accidental model leakage, unauthorised releases, circumvention of safety measures, and defence against cyberattacks, unauthorised access or model theft
, and suggests securing model weights, algorithms, servers and data sets through operational security measures, cybersecurity policies and access controls.
Most Canadian suppliers are not providers of general-purpose models with systemic risk, and should not assume these obligations reach them. They are worth reading anyway, because they are a clear statement of what a regulator considers reasonable care around a model — and customers increasingly write that expectation into contracts regardless of whether the Regulation compels it.
What a Canadian supplier can usefully do now
None of this depends on a date, and none of it is wasted if the answer turns out to be that the Regulation does not reach you.
- Know what you run and what it is used for. An inventory of AI systems and features, with the purpose of each and whether any output reaches a user in Europe. This single artifact answers the scope question and is the thing most organizations cannot produce.
- Know which role you are in per system. Built it, or use somebody else’s? Rebranded it? Modified it substantially? Record the answer per system and let counsel classify.
- Provenance for every model artifact. Where it came from, what verified it, what version is pinned.
- Protect the assets the text names. Access control and integrity evidence around weights, training and retrieval corpora, and the serving infrastructure.
- Keep the records. Evaluations, test results, incidents and decisions, in a form a third party can read.
- Read your provider contracts. If a European obligation lands on you and the model is somebody else’s, what you can promise is bounded by what they promised you.
Where this hands off to counsel
Four questions are legal, not technical, and a security practice that answers them is doing something it should not. Does the Regulation reach this organization. Which role applies per system. How a given system is classified. And what may be represented in a contract. The engineering work described above supports all four by producing the facts; the determinations belong with qualified counsel.
Roughly: a provider develops an AI system or a general-purpose AI model and puts it on the market under its own name, while a deployer uses one under its own authority. The distinction carries different obligations, it can change when you rebrand or substantially modify someone else’s system, and it is a determination for counsel rather than for a security review.
How the work is bounded
The scope is agreed in writing before work starts, and the engagement is quoted in writing with it.
Testing and adversary simulation are carried out only with signed authorization, to a scope agreed in writing.
SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs. The work here is what an organization does to be ready for them.
Nothing here is legal advice. Where a question turns on the law, the work is done alongside the client’s counsel, not instead of them.
Questions we are asked
When does the EU AI Act apply to us?
No date is published on this page. The Regulation applies in stages and the timetable has been amended, so the only safe answer is the one read from the consolidated text on EUR-Lex at the time the question is asked — and whether it reaches your organization at all is a question for your counsel.
Are we a provider or a deployer?
Roughly: a provider develops an AI system or a general-purpose AI model and puts it on the market under its own name, while a deployer uses one under its own authority. The distinction carries different obligations, it can change when you rebrand or substantially modify someone else’s system, and it is a determination for counsel rather than for a security review.
Does readiness work here overlap with ISO/IEC 42001?
Substantially, on the evidence side. An inventory of AI in use, named ownership, a risk method applied per system, provenance for every model artifact and records that survive someone else reading them are wanted by both, which is why the work is usually done once and presented twice.
Can an instrument written in Brussels reach a Canadian company?
A supplier outside the European Union can be reached by this Regulation, because its scope provisions are written to follow the market and the output rather than the establishment of the company.
Where to go from here
The inventory, ownership and records work is AI governance readiness. If a customer is also asking which framework you follow, ISO/IEC 42001 and NIST AI RMF compared sets out what exists at the end of each path. For the provenance and artifact-integrity side, AI supply chain security is the engagement. And if somebody has told you a Canadian statute obliges you too, AIDA did not pass has the parliamentary record. Other pieces are indexed under Writing.
Send the customer’s clause and a description of the system behind it, and the reply will say what evidence the conversation needs.