EU AI Act for Canadian companies
The Act does not care where you are incorporated. It reaches you if your AI system is placed on the Union market, or if the output it produces is used in the Union. For a Canadian software company with European customers, that is a low bar to clear.
A Canadian company falls inside the EU AI Act if it places an AI system on the Union market, puts one into service there, or produces output with an AI system that is used in the Union. There is no establishment requirement and no revenue threshold. The obligations that already bind, as of September 2026, are the prohibitions and the AI literacy duty that applied from 2 February 2025, the general-purpose AI model obligations that applied from 2 August 2025, and the main body of high-risk obligations that applied from 2 August 2026. What is still ahead is 2 August 2027, for high-risk AI embedded in products already covered by EU product safety law.
The second thing to know is what an ISO 42001 certificate does for you here, which is less than most consultants imply. It is not a harmonised standard cited in the Official Journal, so it carries no presumption of conformity with the Act. It is still the most useful thing you can build, for reasons set out below.
Which EU AI Act dates already bind you?
| Date | What applied | Does it reach a Canadian supplier |
|---|---|---|
| 1 August 2024 | The Regulation entered into force. Nothing yet enforceable against you. | Not directly |
| 2 February 2025 | Prohibited practices, and the duty on providers and deployers to ensure AI literacy among staff dealing with AI systems. | Yes, if any EU-facing system touches a prohibited practice, and the literacy duty applies to your staff |
| 2 August 2025 | Obligations for general-purpose AI models, governance structures, notifying authorities and penalties. | Only if you place a general-purpose model on the EU market. Building on somebody else's model does not make you a GPAI provider |
| 2 August 2026 | General application, including the high-risk obligations for the use cases in Annex III and the transparency duties for systems that interact with people or generate synthetic content. | Yes. This is the date most Canadian software vendors are affected by |
| 2 August 2027 | High-risk AI that is a safety component of, or is itself, a product covered by the EU product legislation in Annex I. Also the deadline for GPAI models already on the market before 2 August 2025. | Only for regulated products, such as medical devices and machinery |
The transparency duty catches more people than the high-risk rules
Most Canadian SaaS companies are not shipping an Annex III high-risk system. Many are shipping something that talks to a person or generates content, and that carries transparency obligations: telling people they are interacting with an AI system unless it is obvious, and marking synthetic audio, image, video or text in a machine-readable way. It is a much smaller obligation than high-risk conformity and it is the one most likely to apply to you.
Are you a provider, a deployer, an importer or a distributor?
The Act assigns obligations by role, not by company, and the role is per AI system. Getting this wrong is the expensive mistake, because provider obligations for a high-risk system are an order of magnitude heavier than deployer obligations.
- Provider
- You develop an AI system, or have one developed, and place it on the market or put it into service under your own name or trade mark. A Canadian SaaS company selling its own AI feature to European customers is a provider, whether or not the model underneath is somebody else's.
- Deployer
- You use an AI system under your own authority, in a professional capacity. A company running a vendor's screening tool on its own job applicants is a deployer.
- Importer
- An entity established in the Union that places on the market an AI system bearing the name of a provider established outside it. If you sell into Europe through a reseller, that reseller may be your importer, and it will ask you for documentation it needs to meet its own obligations.
- Distributor
- Anyone else in the supply chain making the system available on the Union market. Lighter obligations, mostly verification and record keeping.
Two traps are worth naming. A deployer becomes a provider if it puts its own name on a high-risk system, substantially modifies one, or changes the intended purpose of one so that it becomes high risk. And a Canadian provider of a high-risk system has to appoint an authorised representative established in the Union, which is a contractual arrangement you have to go and buy.
What should a Canadian company actually do first?
- Inventory every AI system and name your role for each. Not one role for the company. One per system. This is the same inventory ISO 42001 clause 4 needs, which is why doing it once serves both purposes.
- Check each system against the prohibited practices. Short list, already in force, and the penalties are the highest in the Act. Emotion inference in the workplace is the one that catches ordinary business software.
- Check each system against Annex III. Employment and worker management, education, access to essential private and public services including creditworthiness, biometrics, law enforcement, migration, and administration of justice. If you sell HR or lending software into Europe, you are probably in here.
- Check the transparency triggers. Direct interaction with people, emotion recognition, biometric categorisation, and generation or manipulation of synthetic content.
- Deal with the AI literacy duty. It is the cheapest thing on this list and it applies now. Documented training for staff who build, operate or make decisions with AI systems.
- Then decide about a management system. If you are a provider of a high-risk system the Act requires a quality management system anyway, and ISO 42001 is the sensible shape for it. If you are not, certify because customers ask, not because the Act asks.
Does an ISO 42001 certificate make you compliant?
No, and the reason is specific rather than a general caution. Under EU law, presumption of conformity comes from harmonised standards whose references have been published in the Official Journal of the European Union. Those standards are being developed for the AI Act by CEN and CENELEC through their joint technical committee on artificial intelligence, JTC 21. ISO/IEC 42001 is not one of them. A certificate is evidence of governance. It is not a legal shield, and it will not be accepted by a market surveillance authority as proof of conformity with any article of the Act.
What the certificate does buy is substantial and worth being clear about. The Act requires providers of high-risk systems to operate a quality management system covering documented policies and procedures across the life cycle, a risk management system, data governance, technical documentation, record keeping, post-market monitoring and incident reporting. An honest ISO 42001 management system produces recognisable versions of all of those, and it produces them in a form an accredited auditor has already tested. Building one is the cheapest route to being ready for a conformity assessment rather than a substitute for one. The 38 Annex A controls map onto that machinery directly, and the life cycle and data groups do most of the work.
Two assessments that are not the same document
The Act's fundamental rights impact assessment, required of certain deployers of high-risk systems, is not the AI system impact assessment required by ISO 42001 clause 6.1.4, and neither is a GDPR data protection impact assessment. They overlap in analysis and differ in trigger, audience and legal effect. Which one you owe, and to whom, is set out on the AI impact assessment page.
What does Canadian law require in the meantime?
Nothing equivalent, and that gap is real rather than temporary. The Artificial Intelligence and Data Act was part of Bill C-27 and did not become law before Parliament was prorogued in early 2025, so Canada has no in-force private-sector AI statute. Any material describing AIDA as forthcoming law was written before that.
What does apply to a Canadian company running AI today is privacy law and contract. PIPEDA or the provincial statute that displaces it governs the personal information going into and coming out of a model, including the purpose it was collected for. Quebec's Law 25 requires an organization to inform an individual when a decision about them is made exclusively by automated processing, and to let them make representations to a person who can review it. That obligation is in force now, it applies to a Quebec-facing lending or hiring model regardless of anything European, and it is routinely missed by companies focused on the EU timeline. For federal buyers, the Treasury Board Directive on Automated Decision-Making and its Algorithmic Impact Assessment shape the questions in the procurement package.
Work out what the EU AI Act means for your product
Tell us what your AI does and who uses it in Europe, and we will match you with Canadian firms that do AI governance and readiness work.
Get matchedCommon questions
Does the EU AI Act apply to a Canadian company with no EU office?
Yes, if you place an AI system on the Union market, put one into service there, or the output of your AI system is used in the Union. Establishment in the EU is not required and there is no revenue threshold. A Canadian SaaS vendor with European customers using an AI feature is inside the scope.
Is our AI system high risk under the EU AI Act?
Probably not, unless it falls into one of the Annex III use cases or is a safety component of a product already regulated under EU product law. Annex III covers employment and worker management, education, access to essential services including creditworthiness and certain insurance pricing, biometrics, law enforcement, migration and justice. Most business software is outside it and lands instead in the transparency obligations.
Does ISO 42001 certification satisfy the EU AI Act?
No. ISO 42001 is not a harmonised standard cited in the Official Journal, so it gives no presumption of conformity. The harmonised standards for the Act are being developed by CEN and CENELEC JTC 21. Certification is strong evidence that you govern AI systematically, and much of the management system the Act requires of high-risk providers is the same work, but the certificate is not conformity and should never be described that way in a customer contract.
What is the AI literacy obligation and does it apply to us?
It applies from 2 February 2025 to providers and deployers of AI systems in scope of the Act, and it requires you to take measures to ensure a sufficient level of AI literacy among staff and others operating AI systems on your behalf, appropriate to their role and the context. In practice it means documented, role-appropriate training with a record of who took it. It is the cheapest obligation in the Act and one of the few already enforceable.
Do we need an EU authorised representative?
If you are a provider established outside the Union placing a high-risk AI system on the EU market, yes. You must appoint an authorised representative established in a member state by written mandate before the system is placed on the market, and that representative holds defined duties around documentation and cooperation with authorities. This is a service you contract for, and it takes time to arrange.
Is there a Canadian equivalent of the EU AI Act?
No. The Artificial Intelligence and Data Act was inside Bill C-27 and did not pass, so there is no in-force federal AI statute for the private sector. Canadian AI systems are governed by existing privacy law, contract, and for federal institutions the Treasury Board Directive on Automated Decision-Making. Quebec's Law 25 automated decision provisions are the most concrete AI-specific obligation currently in force in Canada.
We build on a third-party model. Are we a GPAI provider?
Almost certainly not. The general-purpose AI model obligations fall on whoever places the model itself on the market. Building a product on top of a commercial model API makes you a provider of an AI system, not of a general-purpose AI model, which is a lighter position. It does mean your obligations depend on documentation your model supplier gives you, which is a supplier management problem covered by the third-party controls in ISO 42001 Annex A.