What Is EU AI Act? A Plain-Language Guide

The EU AI Act is the European Union's law regulating artificial intelligence systems based on the risk they pose to people, and it applies to any company, including Canadian ones, whose AI system is used by people in the EU or affects EU residents, regardless of where the company is headquartered.

What Is the EU AI Act, in Plain Language

The EU AI Act is the first comprehensive law anywhere that regulates AI by risk level rather than by technology type. Instead of writing rules for "machine learning" or "generative AI" as categories, it sorts AI systems into four buckets, unacceptable risk, high risk, limited risk, and minimal risk, and attaches obligations to each bucket. The higher the risk to health, safety, or fundamental rights, the heavier the compliance burden.

If you have already gone through a SOC 2 audit or ISO 27001 certification, the shape of this will feel familiar: documented controls, risk assessments, human oversight, and an audit trail. The difference is that the EU AI Act regulates the AI system itself, not just the organization's security posture around it.

Who Actually Needs to Comply with the EU AI Act

The law casts a wide net. It applies to:

• Providers who build or place an AI system on the EU market, even if the company is based in Toronto or Vancouver and never opens an EU office.
• Deployers who use an AI system in their operations if the output affects people in the EU, for example a Montreal fintech using an AI model to score EU-based loan applicants.
• Importers and distributors who bring AI products into the EU market.

The trigger is not where your servers sit or where your company is incorporated. It is whether the AI system's output is used in the EU or affects people there. A SaaS company in Waterloo selling to customers in Germany or France is in scope the same way a Berlin startup would be.

The Four Risk Categories, Explained

Understanding which bucket your AI system falls into is the first real decision point, because it determines everything downstream.

• Unacceptable risk: banned outright. This covers things like social scoring by governments and certain manipulative or exploitative AI practices.
• High risk: allowed, but heavily regulated. This includes AI used in hiring, credit scoring, insurance underwriting, critical infrastructure, education, law enforcement, and medical devices.
• Limited risk: transparency obligations only, mainly disclosure that a person is interacting with AI (chatbots, deepfakes, AI-generated content).
• Minimal risk: the vast majority of AI systems, spam filters, recommendation engines, inventory tools, fall here with no new legal obligations.

Most of the compliance conversation, and most of the cost, concentrates in that second bucket: high risk.

What High-Risk AI Obligations Actually Require

If your AI system lands in the high-risk category, the EU AI Act requires a documented program, not a one-time checklist. In practice that means:

• A risk management system covering the AI system's full lifecycle, updated continuously, not filed once.
• Data governance controls proving your training and testing data is relevant, representative, and checked for bias.
• Technical documentation detailed enough that a regulator or auditor can reconstruct how the system works and why it made a given decision.
• Human oversight built into the system design, so a person can intervene, override, or shut down an automated decision.
• Accuracy, robustness, and cybersecurity testing with results documented and retained.
• A conformity assessment before the system goes to market, plus registration in an EU database for many high-risk categories.

None of this replaces your existing security or compliance work. It sits alongside SOC 2, ISO 27001, or ISO 42001 as an additional, AI-specific layer of controls and evidence.

EU AI Act Timeline: Key Compliance Deadlines

The law entered into force on August 1, 2024, but obligations phase in over several years rather than landing all at once:

• February 2, 2025: bans on unacceptable-risk AI practices took effect, along with AI literacy requirements for staff.
• August 2, 2025: obligations for general-purpose AI model providers (the large foundation model builders) became applicable, along with rules on governance and penalties.
• August 2, 2026: the Article 50 transparency duties become applicable. Label your chatbot, mark synthetic content, disclose deepfakes. For most SaaS companies this is now the date that matters.
• December 2, 2027: the bulk of high-risk AI system obligations become applicable for stand-alone Annex III systems. Regulation (EU) 2026/1744 moved this back from August 2, 2026 because the harmonised standards and national authorities were not ready.
• August 2, 2028: an extended deadline applies to high-risk AI embedded in already-regulated products, like certain medical devices and machinery.

The practical takeaway: if your product touches hiring, lending, insurance, or another high-risk category and reaches EU users, the window to build the required documentation and controls is now. The high-risk deadline moved to December 2027, but the transparency duties land in August 2026 and did not move.

Common Misconceptions About the EU AI Act

A few myths come up constantly with clients working through this:

• "We're a Canadian company, it doesn't apply to us." Location of incorporation is irrelevant. What matters is whether EU-based people are affected by the AI system's output.
• "We just use OpenAI's API, so we're not a provider." You can still be a deployer with obligations, particularly if you fine-tune, customize, or apply the model to a high-risk use case like credit decisions.
• "It's basically GDPR for AI." Related in spirit, both are EU rights-protection laws, but the EU AI Act regulates system design and risk, not just data processing. Compliance with one does not satisfy the other.
• "This is a legal problem, not a security or engineering problem." The bulk of the actual work, documentation, testing, data governance, human oversight design, sits with security and engineering teams, not just legal.

Does the EU AI Act Apply to Companies Outside the EU, Including Canada

Yes, and this is where Canadian founders get caught off guard. The extraterritorial reach mirrors GDPR: if a company anywhere, Toronto, Ottawa, Calgary, has an AI system whose output is used by or affects people in the EU, the Act applies. Canadian companies also have to keep an eye on how this interacts with domestic obligations, PIPEDA at the federal level and Quebec's Law 25 for provincial coverage. Neither substitutes for EU AI Act compliance, but a company that has already built disciplined data governance and risk management for PIPEDA or Law 25 has a real head start on the documentation the EU AI Act demands.

Where to Start If You Think You're in Scope

The first step is not a compliance program, it's a scoping exercise: which of your AI systems touch the EU, and which risk category do they fall into. From there, the work looks like EU AI Act readiness work generally does: gap assessment against the high-risk obligations, building the technical documentation and risk management system, and designing human oversight into the product before a regulator or a customer's procurement team asks for it. Companies already pursuing ISO 42001 readiness for AI management systems will find significant overlap in the underlying controls, which is worth sequencing deliberately rather than duplicating effort across two separate programs.

Get Help Scoping Your EU AI Act Exposure

traztech works with Canadian tech companies, from Toronto and Waterloo to Vancouver and Montreal, that sell into or serve EU users and need a straight answer on what the EU AI Act actually requires of them. If you are not sure whether your AI system is high risk, or you know it is and need the documentation and controls built before the August 2026 deadline, contact traztech to scope the work.

How you accidentally become a provider

The most expensive mistake in scoping is assuming that buying a model keeps you in the lighter deployer category. Article 25 turns a deployer into a provider in three situations, and small product decisions trip all of them. You become the provider by putting your own name or trademark on a high-risk system, by substantially modifying one, or by repurposing a system so that it becomes high risk, which is what happens when someone wires a general-purpose assistant into a candidate screening flow.

That matters because the obligations diverge sharply. A deployer has to use the system according to instructions, assign competent human oversight, keep the generated logs, and inform affected people in certain cases. A provider owns the risk management system, the technical documentation, the conformity assessment, the registration entry, and post-market monitoring. A product manager who adds a fine-tuned scoring model to an HR feature has, in an afternoon, moved the company across that line without anyone raising a ticket.

The Annex III filter almost nobody uses correctly

Article 6(3) lets you conclude that a system listed in Annex III is not in fact high risk when it performs a narrow procedural task, improves the result of a previously completed human activity, detects decision patterns without replacing human judgement, or does preparatory work only. This is a genuine and useful off-ramp. It is also conditional: it does not apply where the system profiles individuals, and you must document the assessment before placing the system on the market and register it anyway.

So the exemption is not a shrug in a meeting. It is a written analysis that a regulator or an enterprise buyer can read, and it is the highest-value document a mid-sized SaaS company can produce here, because it either takes the whole program off the table or tells you early that it will not.

Enforcement and who comes knocking

Penalties run in tiers. Prohibited practices carry the top band, up to 35 million euro or seven percent of global annual turnover, whichever is higher. Most other breaches, including the high-risk obligations, sit at up to 15 million euro or three percent. Supplying incorrect or misleading information to authorities carries up to 7.5 million euro or one percent. Enforcement is national, through market surveillance authorities in each member state.

Realistically, the first party to test your compliance will not be a regulator. It will be a European customer's procurement team inserting AI Act warranties into a renewal, or a distributor asking for your declaration of conformity. That happens well ahead of the statutory deadlines, which is the reason to write the scoping memo now even if your obligations land in 2027.

When you should not start a program

Most software companies are not in scope for anything beyond transparency, and buying an AI governance program to prove it is a waste of money. If your AI features are recommendation, search ranking, summarization of your own content, or internal productivity tooling, the honest answer is a labelled chatbot, a short scoping memo, and the staff literacy obligation handled through an hour of training. Revisit it when the product roadmap touches hiring, credit, insurance, education, or biometrics.

If you do sit in a high-risk category, do the work in the order that reduces risk fastest: scoping first, then data governance and evaluation records, then documentation. Companies already running ISO 27001 have much of the risk management scaffolding and should extend it rather than start a second parallel program. If you want a straight read on which side of the line you are on, tell us what the system does and who uses it.