EU AI Act Requirements: A Practical Checklist

The EU AI Act requires providers and deployers of high-risk AI systems to complete a risk management system, data governance review, technical documentation, human oversight design, and conformity assessment before the system reaches an EU market, with obligations phasing in between February 2025 and August 2027. Below is a practical, checklist-style breakdown of what actually needs to get done, in the order most compliance teams tackle it.

Who the EU AI Act Actually Applies To

The Act applies to any organization that places an AI system on the EU market or whose AI system's output is used in the EU, regardless of where the company is headquartered. That means a SaaS company in Toronto or Waterloo selling into European enterprise accounts is in scope the moment its product touches an EU user, even without an EU office. Canadian tech companies expanding into Europe often discover this obligation only after a prospect's procurement team asks for it during due diligence, which is too late to start from zero.

Three roles carry distinct duties: providers (who build or substantially modify the system), deployers (who use it under their own authority), and importers or distributors. Most Canadian SaaS vendors are providers. If you also use third-party AI internally for hiring, credit decisions, or fraud detection, you may simultaneously be a deployer with a separate set of obligations.

Step One: Classify Your AI System's Risk Tier

Everything downstream depends on this classification, so it belongs first on the checklist.

• Unacceptable risk: social scoring, manipulative or subliminal techniques, and most real-time biometric identification in public spaces are banned outright as of February 2025.
• High-risk: systems used in employment, credit scoring, insurance underwriting, education admissions, critical infrastructure, law enforcement, and medical devices carry the full obligation set described below.
• Limited risk: chatbots, deepfake generators, and emotion-recognition tools mainly require transparency, telling the user they are interacting with AI.
• Minimal risk: spam filters, recommendation engines, and most internal productivity tools have no new obligations.

Get this classification wrong and you either over-invest in controls a minimal-risk tool doesn't need, or under-invest and miss a conformity assessment a high-risk system requires. This is exactly the gap our EU AI Act readiness engagement starts by closing, before any documentation work begins.

Core Checklist for High-Risk AI Systems

If your classification lands in the high-risk tier, the Act requires the following, in roughly the order auditors expect to see them built.

1. Risk Management System

A documented, continuous process that identifies, evaluates, and mitigates risks across the AI system's lifecycle, not a one-time assessment filed away after launch.

2. Data Governance and Quality

Training, validation, and testing datasets must be relevant, representative, and checked for bias. You need to document data provenance and be able to explain why a dataset is fit for the system's intended purpose.

3. Technical Documentation

A file (the Act's Annex IV documentation) covering the system's design, capabilities, limitations, and performance metrics. This is the artifact regulators and enterprise customers will ask to see first.

4. Record-Keeping and Logging

Automatic logging of events throughout the system's operation, retained long enough to allow traceability and post-incident investigation.

5. Transparency to Deployers

Clear instructions for use, so the organization deploying your AI understands its capabilities, limitations, and appropriate human oversight measures.

6. Human Oversight

Design controls that let a human intervene, override, or halt the system's output. This can't be bolted on after the fact, it needs to be part of the system architecture.

7. Accuracy, Robustness, and Cybersecurity

Testing that demonstrates the system performs consistently and resists adversarial manipulation, tampering, and unauthorized access.

8. Conformity Assessment and CE Marking

Before market placement, high-risk systems must pass a conformity assessment, either self-assessed against harmonized standards or reviewed by a notified body, and carry the CE marking.

9. Registration in the EU Database

Most high-risk systems must be registered in the publicly accessible EU database before deployment.

10. Post-Market Monitoring

An ongoing plan to track performance in production and report serious incidents to the relevant authority.

The Compliance Timeline You Need to Plan Against

• February 2025: prohibitions on unacceptable-risk practices and AI literacy obligations took effect.
• August 2025: governance rules and obligations for general-purpose AI model providers began applying.
• August 2026: the bulk of high-risk system obligations become enforceable, including the checklist items above.
• August 2027: obligations extend to high-risk AI embedded in already-regulated products, such as medical devices and machinery.

Twelve months sounds like runway, but conformity assessment, documentation, and human oversight redesign are not fast work when they're layered on top of an existing product roadmap. Teams that start scoping now avoid a compressed rebuild in mid-2026.

Why This Matters for Canadian Companies Specifically

Canadian obligations don't disappear because the EU AI Act exists, they stack. PIPEDA still governs personal data handling nationally, and Quebec's Law 25 imposes its own automated decision-making disclosure requirements for Quebec residents. A company selling AI-driven products from Ottawa or Montreal into both the EU and Canada needs a control set that satisfies each regime without building separate programs. We map this overlap directly for clients, so evidence gets reused rather than duplicated.

Vancouver and Calgary AI startups selling into European insurance and fintech buyers face a similar pattern: the deal doesn't close until legal or procurement sees evidence of AI Act readiness, not just a promise to comply later. Building the documentation trail before it's requested, rather than scrambling during a due diligence deadline, is the difference between a smooth close and a stalled one.

Common Mistakes That Slow Down Readiness

• Treating the risk classification as a one-time exercise instead of revisiting it every time the system's use case expands.
• Writing technical documentation after the system ships instead of building it alongside development, which turns a documentation task into an archaeology project.
• Assuming a SOC 2 report covers AI-specific obligations. It doesn't, human oversight design and conformity assessment fall outside a typical SOC 2 scope.
• Underestimating how long conformity assessment takes when a notified body review is required rather than self-assessment.

Getting Started

The fastest path is a scoping call that classifies your system's risk tier, maps what you already have against the checklist above, and flags the gaps that need the most lead time before August 2026. TrazTech runs this as part of its EU AI Act readiness service, working alongside Canadian tech companies from Toronto to Vancouver that need to satisfy European regulators without losing months to a compliance program built from scratch. If your AI system also touches employment, credit, or fraud decisions, it's worth reviewing alongside our broader ISO 42001 readiness work, since the two frameworks share significant control overlap.

If you're not sure which tier your AI system falls into, or you know it's high-risk and need a realistic timeline to August 2026, get in touch and we'll walk through where you stand.

The Annex III exemption most teams miss

Article 6(3) contains a carve-out that a lot of Canadian vendors qualify for and never claim. A system that falls under one of the Annex III high-risk use cases is not treated as high-risk if it performs only a narrow procedural task, improves the result of a previously completed human activity, detects decision patterns without replacing or influencing the human assessment, or performs preparatory work for an assessment. Profiling of natural persons is excluded from the carve-out entirely, so if your system profiles, you are high-risk regardless.

The catch is that claiming the exemption is not passive. You have to document the assessment before you place the system on the market, keep that documentation available to national authorities on request, and still register the system in the EU database. So the exemption does not remove your paperwork, it removes the conformity assessment, the risk management system, the Annex IV technical file, and the rest of the heavy obligations. That is a very large saving in exchange for a short, well-argued memo. Write it carefully, because a regulator reading it later will be checking whether "does not influence the human assessment" was true in practice or only in the design document.

What happens when you fine-tune somebody else's model

The word to watch in the Act is "substantial modification". If you take a third-party model or system and change it enough that its intended purpose or its compliance position shifts, you become the provider of the modified system and inherit the provider obligations. Putting your own trademark on a high-risk system supplied by someone else does the same thing.

This bites in a specific way for the teams we work with. A company buys an API from a large model provider, builds a resume-screening feature on top, ships it into an EU customer, and assumes the model provider carries the regulatory weight. It does not work that way. The model provider has general-purpose AI model obligations, which are about the model. You have provider obligations for the high-risk system, which are about the deployed use. The model card you were handed is not your Annex IV technical documentation, and the model provider's evaluations are not your accuracy and robustness testing against your own intended purpose.

Practically, this means your contract with the upstream provider needs to give you what you need to build your own file: information on training data characteristics, known limitations, evaluation results, and a commitment to notify you of material model changes. Ask for it during procurement. Asking after your customer's legal team has requested your technical documentation is a bad time to discover the vendor will not provide it.

Deployer obligations, which are lighter but not nothing

If you use a high-risk system under your own authority, Article 26 applies to you even though you built nothing. You have to use the system according to the provider's instructions, assign human oversight to people with the competence, training, and authority to actually intervene, ensure input data is relevant and sufficiently representative for your intended use, monitor operation and suspend use plus inform the provider if you suspect a risk, and keep the automatically generated logs for at least six months where those logs are under your control.

Two extras catch employers. If you deploy a high-risk system at the workplace, you have to inform affected workers and their representatives before you put it into service. And where an individual is subject to a decision produced or assisted by a high-risk system, they have a right to a clear explanation of the role the system played. A Canadian company running an AI-assisted hiring tool over EU applicants is a deployer with all of this on its plate, separately from whatever it owes as a provider of its own product.

The fundamental rights impact assessment under Article 27 is narrower than people fear. It applies to bodies governed by public law, private entities providing public services, and deployers of the creditworthiness and life or health insurance pricing use cases. Most B2B SaaS deployers are outside it. Confirm which side of that line you are on rather than assuming.

Non-EU providers need an authorised representative

Article 22 requires providers established outside the EU to appoint, by written mandate, an authorised representative established in the Union before making a high-risk system available. The representative holds a copy of the technical documentation, the EU declaration of conformity, and the conformity assessment certificate, keeps them available to authorities for ten years, and cooperates with market surveillance. They can terminate the mandate if they believe you are acting contrary to your obligations, and they have to tell the authority when they do.

For a Toronto or Vancouver company with no EU entity, this is a real procurement task with a real cost and a lead time measured in weeks, and it is easy to leave until last because it feels administrative. Start it early, because the representative will want to see the documentation before accepting the mandate, and a good one will refuse a mandate over an incomplete file.

Penalties, incident reporting, and the clocks that run

The penalty tiers are worth knowing precisely, because they change how a board reacts to the topic. Up to 35 million euro or 7 percent of worldwide annual turnover for engaging in a prohibited practice, whichever is higher. Up to 15 million euro or 3 percent for breaching most other obligations, including the high-risk provider and deployer duties. Up to 7.5 million euro or 1 percent for supplying incorrect, incomplete, or misleading information to notified bodies or authorities. That last tier is the one that punishes a rushed, inaccurate technical file rather than an absent one.

Serious incident reporting under Article 73 runs on tight clocks. The general obligation is to report immediately after establishing a causal link, and no later than fifteen days after becoming aware. A widespread infringement or a serious incident involving critical infrastructure disruption compresses that to two days. Death of a person compresses it to ten days from the date you establish or suspect the link. You cannot meet a two-day clock with an incident process that has never been rehearsed against an AI failure mode, which is why we fold this into incident response work rather than treating it as a documentation item. Our retained engagements exist partly for this: the reporting clock is not something a project-based readiness push leaves behind.

Building the file while the harmonized standards are still moving

The Act lets you presume conformity by following harmonized standards, and CEN-CENELEC JTC 21 is still producing several of them. That leaves teams asking whether to wait. Do not wait. Build against ISO/IEC 42001 for the management system, ISO/IEC 23894 for AI risk management, and ISO/IEC 5259 for data quality, then map to the harmonized standards when they publish. The underlying evidence, a risk register that is reviewed rather than filed, dataset provenance records, evaluation results tied to your stated intended purpose, logging that survives an investigation, does not change when the standard number does.

Reuse what you have. If you already hold ISO 27001, your access control, change management, supplier, and incident evidence carries directly into the cybersecurity limb of Article 15 and into large parts of the management system. What it does not cover is data governance for training sets, human oversight design, or conformity assessment. Mapping the overlap first is the cheapest hour you will spend, and it is where our compliance advisory work usually starts on these engagements.

When you should not buy AI Act readiness

Most products marketed as AI-powered are minimal or limited risk, and for those the correct deliverable is a short classification memo, a transparency notice telling users they are interacting with an AI system, and a diary note to revisit the classification when the use case expands. That is a few hours of work. If a consultancy responds to a recommendation engine or an internal drafting copilot with a proposal for a full risk management system and a conformity assessment, they are selling you the high-risk programme for a minimal-risk product, and you should decline.

You should also decline if you have no EU market exposure and no realistic plan to acquire it in the next year. Output used in the EU is the trigger, and a handful of EU-resident users on a self-serve plan is worth a considered look, but building a conformity file against a market you have not entered is premature. Note the date, revisit it when the pipeline changes.

If your obligation is genuinely limited to transparency, your own counsel and product team can execute it without us. We would rather tell you that on the scoping call than take the engagement. Where we do add something is on the high-risk path, where the accuracy, robustness, and cybersecurity testing under Article 15 needs someone who has attacked systems rather than only documented them. If you are unsure which of these describes you, talk to us and the classification conversation costs you nothing.