How to Get EU AI Act: A Step-by-Step Guide

Getting ready for the EU AI Act means classifying your AI system's risk tier, building the technical documentation and risk management file the regulation requires, then proving conformity before you sell or deploy in the EU market. For most Canadian companies with a high-risk AI system, this is a six-to-twelve month project, not a weekend compliance checkbox.

What the EU AI Act Actually Requires (and Who It Applies To)

The EU AI Act is extraterritorial. If your AI system's output is used in the EU, whether you are a Toronto SaaS company selling into Germany or an Ottawa fintech serving French banks, the regulation can reach you even without a European office. It classifies AI systems into four tiers: unacceptable risk (banned outright), high-risk, limited risk, and minimal risk. Most of the compliance burden sits with high-risk systems, things like AI used in hiring, credit scoring, insurance underwriting, biometric identification, or critical infrastructure.

If your system lands in the high-risk category, the Act requires a risk management system, data governance controls, technical documentation, logging, human oversight mechanisms, and a conformity assessment before market entry. General-purpose AI models carry their own separate transparency and documentation obligations, layered on top.

Step 1: Classify Your AI System's Risk Tier

Before anything else, you need a defensible classification. This is where a lot of teams stall, because the classification isn't always obvious. A recommendation engine might be minimal risk. The same architecture used to screen job applicants is high-risk. We walk this classification against Annex III use cases and the actual data flows in the product, not just the marketing description of what it does.

• Map every AI feature to its use case, not its underlying model
• Determine if you are a provider, deployer, importer, or distributor under the Act (each has different obligations)
• Document the classification decision itself, since regulators and enterprise procurement teams will ask for the reasoning, not just the conclusion

Step 2: Build the Risk Management System

High-risk systems require a continuous risk management process across the entire AI lifecycle, from design through decommissioning. This isn't a one-time risk assessment you file and forget. It has to identify foreseeable misuse, evaluate risks to health, safety, and fundamental rights, and show mitigation measures with evidence they were tested. If your team has already been through ISO 27001 or SOC 2, the muscle memory transfers, but the AI Act adds fairness, bias, and human-rights dimensions that a standard security risk register doesn't cover.

Step 3: Assemble Technical Documentation and Data Governance

The Act requires a technical file that reads almost like an engineering audit trail: system architecture, training and validation data provenance, performance metrics, known limitations, and version history. Data governance obligations require you to show your training and testing data is relevant, representative, and checked for bias. For Canadian companies, this dovetails with existing PIPEDA obligations around personal data, but the AI Act's data governance bar is more prescriptive and specific to model training.

Step 4: Implement Human Oversight and Logging

High-risk systems need built-in human oversight, meaning a person can meaningfully intervene, override, or stop the system, not just a rubber-stamp review step. You also need automatic logging (traceability of the system's operation) retained for a set period. These aren't abstract requirements. They usually mean actual engineering work: adding override controls to a product that may never have had them, and building audit logs that capture model decisions in a form a human, or a regulator, can actually review.

Step 5: Run the Conformity Assessment

Most high-risk systems under the Act use a self-assessment conformity procedure against harmonized standards, though some categories (like biometric identification) require third-party notified body involvement. Either path ends with a declaration of conformity and CE marking before the system enters the EU market. This is the step where gaps in documentation from earlier phases surface, which is why we push teams to treat steps 1 through 4 as evidence-gathering for this assessment, not separate exercises.

Realistic Timeline: What EU AI Act Readiness Actually Takes

Ask three vendors for a timeline and you'll get three different answers, mostly because "readiness" means different things. A realistic breakdown for a mid-market high-risk system:

• Weeks 1-3: Risk classification and gap assessment against current documentation
• Weeks 4-12: Building the risk management system, data governance controls, and technical file
• Weeks 10-16: Human oversight and logging implementation (runs partially in parallel with documentation)
• Weeks 16-24: Conformity assessment, declaration of conformity, and remediation of any gaps found during review

Companies that already hold SOC 2 or ISO 27001 tend to move faster through the risk management and documentation phases, since the governance habits and evidence discipline already exist. Teams starting from zero should plan closer to nine or twelve months, especially if the AI system touches EU personal data and needs to reconcile with GDPR obligations at the same time.

Where Canadian Companies Get Tripped Up

Two patterns show up repeatedly with Canadian tech companies expanding into the EU, whether they're based in Waterloo, Vancouver, or Montreal. First, teams treat the AI Act as a legal document to hand to outside counsel, when most of the actual work, the technical documentation, the logging, the risk testing, is engineering and product work that counsel can't build. Second, companies underestimate how much of this maps onto obligations they'll eventually face at home too. Quebec's Law 25 already imposes automated decision-making transparency requirements, and Canada's own AI governance direction is trending toward similar high-risk classifications. Building the AI Act file properly now means less duplicated work later.

Where a Compliance Partner Helps

The EU AI Act rewards teams that treat compliance as a system, not a document. A partner earns its keep in three places: translating the regulation's language into the actual engineering backlog, keeping the risk management process alive after the initial file is built (an outdated risk register is worse than no risk register in an audit), and catching the classification errors that turn a minimal-risk assumption into a high-risk surprise six months before a launch date. We built our EU AI Act readiness program around exactly this gap, working through classification, documentation, and conformity assessment as one continuous process rather than three disconnected deliverables.

For companies also carrying AI governance obligations tied to model risk management more broadly, it's worth pairing this work with an ISO 42001 AI management system build, since the two frameworks overlap heavily on risk management and documentation structure and doing them together avoids rebuilding the same evidence twice.

Get Started

If your product touches the EU market and you're not sure whether it lands in the high-risk tier, that uncertainty itself is the first thing to resolve, before a customer contract or a regulator forces the question. Talk to traztech about a classification review and a realistic path to conformity.

The Obligations Phase In on Different Dates

The Act did not switch on all at once, and teams that treat it as a single deadline either panic early or miss something. The staging runs roughly like this: the prohibited practices and the AI literacy duty came into application first, general-purpose AI model obligations and the governance and penalty machinery followed, the bulk of the Annex III high-risk obligations came next, and high-risk AI embedded in products already covered by EU product safety legislation sits furthest out on the calendar. Models and systems already on the market before their relevant date generally get transitional treatment rather than immediate retrofit.

Two practical consequences. First, your obligation date depends on which bucket you are in, so the classification work in step one is also the work that tells you how much time you have. Second, these dates have been politically contested since the text was finalized, and adjustments to the high-risk timing have been proposed more than once. Confirm the current position with counsel or the official text before you build a plan around a date you read in an article, including this one. What does not change is the order of work, which is why we put classification first regardless of what the calendar says.

The Penalty Structure, and Why It Is Not the Main Risk

The headline numbers are tiered. Prohibited practices carry the highest exposure, capped at a percentage of worldwide annual turnover or a fixed ceiling, whichever is greater. Breaching the substantive obligations for high-risk systems sits at a lower tier, and supplying incorrect or misleading information to authorities sits lower again. For SMEs, the caps are applied at the lower of the two figures rather than the higher, which softens the absolute exposure but does not remove it.

For most Canadian companies, though, regulatory fines are not the risk that arrives first. Commercial pressure is. European enterprise buyers began putting AI Act language into procurement questionnaires and contract addenda well ahead of the compliance dates, because their own obligations as deployers depend on what you can tell them about your system. The practical failure mode is not an inspector at your door. It is a deal held in security and legal review for eleven weeks because you cannot produce a classification rationale, a data provenance statement, or a description of your human oversight design. That is the same failure mode that stalls audits, and the fix is the same: have the document ready before someone asks for it.

Provider or Deployer: the Role Question That Catches Canadian Teams

The obligations attach to roles, not to companies, and one company can hold different roles for different systems. The two situations that surprise teams:

You can become a provider without building a model. If you put your name or trademark on a high-risk AI system, if you substantially modify one, or if you change the intended purpose of an existing system so that it becomes high-risk, you take on provider obligations. A Canadian SaaS company that fine-tunes a third-party foundation model, brands the result, and sells it into an Annex III use case has almost certainly become a provider. The original model developer's documentation does not transfer your obligations to them, although the Act does require upstream suppliers to give you what you reasonably need.

You can be a deployer of someone else's system inside your own company. If you use a high-risk AI system for recruitment, promotion decisions, or worker management affecting people in the EU, you carry deployer duties: assigning competent human oversight, making sure input data is relevant to the intended purpose, keeping the automatically generated logs, and informing affected workers and their representatives. Companies preparing hard for their product obligations routinely miss that their own HR stack put them in scope on a second front.

Write the role determination down per system, with the reasoning. It is the first thing a knowledgeable counterparty asks for, and it is the cheapest document in the whole file to produce early and the most expensive to reconstruct late.

The Requirements Nobody Budgets For

An EU authorised representative. A provider established outside the Union that places a high-risk system on the EU market generally has to appoint, by written mandate, an authorised representative established in the EU before doing so. That representative holds the technical documentation, cooperates with authorities, and can terminate the mandate if they believe you are not compliant. This is a real contract with a real party and a real annual cost, and it is invisible on most readiness plans until someone reads Article 22 properly.

Registration in the EU database. Annex III high-risk systems are registered in an EU-level database before being placed on the market, with information that is publicly visible. Plan for the fact that your classification and intended purpose become a published statement rather than an internal note.

Post-market monitoring and incident reporting. You need a documented post-market monitoring plan, and serious incidents have to be reported to the relevant market surveillance authority on short clocks, tighter still where there is death or widespread infringement. If you already run an incident response process for security events, this is an extension of it rather than a parallel one, and the sensible move is to widen the existing runbook and the existing on-call rotation rather than stand up a second process that nobody rehearses.

AI literacy. There is a standing obligation to ensure a sufficient level of AI literacy among staff dealing with the systems. It is not onerous, but it is evidence-generating: it means training records, and training records mean someone owns the roster.

The Transparency Tier Most Canadian SaaS Companies Actually Land In

A lot of the anxiety in this market is misplaced. If your product includes a support chatbot, a summarization feature, or generative content tooling, and none of it makes or materially informs decisions in an Annex III domain, you are most likely in the transparency tier rather than the high-risk one. The obligations there are comparatively light: tell people they are interacting with an AI system where it would not be obvious, mark synthetic audio, image, video and text in a machine-readable format, and disclose deepfake content where the exception for artistic or satirical work does not apply.

That is engineering and copy work measured in weeks, not a conformity assessment measured in quarters. The mistake is not under-scoping, it is over-scoping: teams read the high-risk chapter, assume it applies, and commission a program they do not need. Classify honestly and against the actual use case, and if the honest answer is limited risk, do the transparency work properly and spend the rest of the budget somewhere it changes your risk position. Our EU AI Act requirements checklist is a reasonable place to sanity-check which tier you are arguing for.

Where This Overlaps With Work You Are Already Doing

The AI Act does not exist in isolation, and treating it as a standalone project is how companies pay twice. Data governance obligations around training data provenance and bias checking sit directly alongside the lawful-basis and minimization analysis you owe under GDPR for the same data. The fundamental rights impact assessment required of certain deployers is a different instrument from a data protection impact assessment, but they share inputs and should be built from one source of truth about your data flows. Logging and traceability obligations overlap with the audit logging you already need for security frameworks. Post-market monitoring overlaps with incident response.

Companies holding SOC 2 or ISO 27001 tend to move through this faster, and the reason is not the controls. It is that they already have the habit of producing evidence on request, a document that says who approved what, and a calendar of recurring obligations that someone owns. If your organization has never had that discipline, the AI Act will be the thing that teaches it, expensively. Building the governance layer once and mapping it across frameworks is the point of how we run compliance work, and keeping the risk file alive after the initial build is what a retainer is for, because a risk management system that has not been touched in eight months is a finding rather than a defence.

When Not to Start This Work Yet

Several situations where paying anyone for EU AI Act readiness right now is premature.

You have no EU exposure and no EU pipeline. The Act reaches you when output is used in the Union, not when a European reads your website. If you have no EU customers, no EU users, and no near-term plan to sell there, do the classification exercise so you know where you would land, then stop. That is a short piece of work, not a program.

Your system is clearly limited risk. Do the transparency work and move on. Buying a full conformity build for a system that is not high-risk is the most common way money gets wasted in this category.

The real requirement is a customer's AI addendum. If what triggered this is one enterprise buyer sending an AI governance questionnaire, answer the questionnaire properly with a documented classification, a data provenance statement and an oversight description. That is days of work. Reach for the full technical file when your own obligations require it, not when a procurement form does.

You are mid-rebuild of the model or the product. Technical documentation describes a specific system version. Documenting an architecture you are about to replace means writing the file twice. Wait until the design settles, but do the classification and the role determination now, because those change what you are allowed to ship and they should be inputs to the rebuild rather than a review of it.