How to Comply With the EU AI Act: Step-by-Step Guide

Most organisations approach the EU AI Act by asking "what do we need to do." That cannot be answered until two earlier questions are settled: does the Act apply to us, and in which role. Obligations under Regulation (EU) 2024/1689 differ sharply by whether an organisation is a provider, a deployer, or another type of operator, and by how each AI system is classified. Skipping straight to controls or documentation produces checklists that miss obligations that genuinely apply and impose burdens that do not.

This guide sets out a sequential workflow: scope and role, AI inventory, classification, applicable obligations, risk assessment, controls, vendor review, AI literacy, documentation, and ongoing audit. It reflects the Digital Omnibus on AI, Regulation (EU) 2026/1744, in force since 27 July 2026, which changed several dates and obligations organisations had been planning around.

EU AI Act Compliance: What Applies Now?

In short: as of September 2026, prohibited AI practices, AI literacy measures under Article 4, most general-purpose AI (GPAI) obligations, and Article 50 transparency obligations already apply. Core obligations for standalone high-risk AI systems (Annex III) do not apply until 2 December 2027, and obligations for high-risk AI embedded in regulated products (Annex I) do not apply until 2 August 2028, following the deferral introduced by the Digital Omnibus.

As the European Commission has confirmed, the Digital Omnibus left the 2025 dates unchanged, deferred the Annex III and Annex I timelines, and made targeted changes to Article 4, Article 5, Article 27, and the AI Office's supervisory powers; the Council of the EU's announcement of 29 June 2026 confirms the same final application dates.

Enforcement follows the same logic: the AI Office and national competent authorities take on supervisory powers progressively, tied to each provision's own application date, and the AI Office's oversight of general-purpose AI models has been expanded under the Digital Omnibus. This guide does not address penalty amounts; verify current figures against the consolidated Regulation directly.

Step 1: Determine the AI Act's Scope and Your Role

Whether the AI Act applies is not decided by whether a company has an EU office. As the consolidated text of the Regulation on EUR-Lex sets out, it applies based on territorial and material scope factors: providers established in the EU, deployers located in the EU, AI systems placed on or put into service in the EU market, and, in defined circumstances, non-EU providers and deployers whose system's output is used in the EU. Not every company anywhere that uses AI is automatically in scope; genuinely unclear scope questions deserve dedicated legal review.

It is also worth separating EU AI Act compliance from overall AI legal compliance. Data protection law (GDPR), consumer protection, product safety, employment law, cybersecurity rules, and sector-specific or national legislation can apply independently and in parallel. The AI Act does not replace the GDPR, and AI Act compliance does not automatically establish compliance with those other frameworks.

Identify Your Role Under the AI Act

The roles below are not interchangeable:

• Provider: develops an AI system, or has one developed, and places it on the market or puts it into service under its own name.

• Deployer: uses an AI system under its own authority, other than for personal non-professional use.

• Importer / distributor: brings a provider's system to the EU market or makes it available there, without being the original provider.

• Product manufacturer: places a product on the market with an embedded AI system under its own name.

• Authorised representative: acts on behalf of a non-EU provider for AI Act purposes.

• Downstream provider: integrates a GPAI model, or another provider's system, into its own AI system.

• GPAI model provider: develops, or has developed, a general-purpose AI model and places it on the market.

GPAI model provider obligations are distinct from AI-system provider or deployer obligations. An organisation deploying a chatbot built on a GPAI model is typically a deployer, not a GPAI model provider, even though the underlying model carries its own separate rules.

Create a Role-and-System Compliance Matrix

A practical governance tool, not a statutory requirement, is a matrix recording, per AI system: system name, use case, organisation's role, provider or vendor, preliminary classification, applicable obligations, and an owner. Building this early supports EU AI Act compliance  throughout the rest of the process.

Step 2: Create an AI System Inventory

AI arrives through several routes at once: internally developed models, third-party AI products, AI embedded inside existing software, and departmental tools adopted without central visibility. An inventory is the foundation for everything that follows, since classification and obligation-mapping can only be done system by system.

What to Record in an AI Inventory

Recommended fields, distinct from anything the Act itself requires in this format, typically include: system or model name, provider, business purpose, intended use, department, users, data involved, organisation's role, preliminary classification, applicable obligations, owner, and review status. Some overlap with documentation that is legally required for specific systems (Step 9); the inventory helps locate and maintain that evidence.

Step 3: Classify Each AI System

Classification follows a decision sequence, applied per system:

1. Is the system or activity within scope at all?

2. Does the system involve a prohibited AI practice?

3. Is the system high-risk under the applicable Article 6 pathway?

4. Do Article 6(3) conditions or exceptions affect that classification?

5. Do Article 50 transparency obligations apply?

6. Is GPAI relevant, as a model the organisation provides or one it builds on?

7. What other obligations, if any, apply as a result?

Check for Prohibited AI Practices

Article 5 of the consolidated Regulation prohibits specific unacceptable-risk practices, applicable since 2 February 2025. The Digital Omnibus added two further prohibitions, on AI systems used to generate or manipulate non-consensual intimate material and child sexual abuse material, applying from 2 December 2026 rather than from the original date. This guide does not reproduce the full list; check the current Article 5 text for any practice that may be relevant.

Determine Whether High-Risk Rules Apply

As EUR-Lex's consolidated text of Article 6 shows, the Article sets out two principal pathways, and sector names are not a substitute for applying them.

Article 6(1) covers systems that are safety components of, or are themselves, products already covered by Union harmonisation legislation in Annex I (for example certain machinery, medical device, or toy safety legislation), where that product requires third-party conformity assessment. The Digital Omnibus clarified that a component only counts as a safety component where its intended purpose is to prevent or mitigate risks to health and safety, narrowing this pathway.

Article 6(2) covers systems corresponding to the use cases in Annex III, such as certain systems used in employment, education, credit assessment, law enforcement, and critical infrastructure. Not every Annex III use case results in automatic high-risk status.

Article 6(3) sets out conditions that can take a system otherwise falling under an Annex III use case out of high-risk classification, generally where it performs a narrow procedural task, improves a previously completed human activity's result, detects patterns without influencing human decisions, or performs limited preparatory work. Whether these apply is case-specific, not a default assumption. High-risk obligations apply from 2 December 2027 (Annex III) and 2 August 2028 (Annex I); high-risk classification does not mean every associated obligation is already in force.

Check Transparency Obligations

Article 50 requires, among other things, informing individuals when they interact with certain AI systems and, in defined circumstances, disclosing or marking AI-generated content, as the European Commission's guidance on Article 50 transparency explains. It does not apply identically to every system. These obligations have applied since 2 August 2026, except that Article 50(2) marking for generative systems already on the market before that date applies from 2 December 2026.

Check Whether GPAI Rules Are Relevant

If the organisation develops and places a general-purpose AI model on the market, separate GPAI model provider obligations apply, as the European Commission sets out for GPAI providers. These have applied since 2 August 2025, with different transition treatment for models already on the market before that date and additional obligations for models presenting systemic risk. This is not a GPAI compliance guide; where relevant, GPAI obligations warrant dedicated review.

Step 4: Map the Obligations That Apply to Each System and Role

Classification produces an obligation map, not a single risk label. The categories below are illustrative; whether each applies depends on classification, role, and application date, and should be verified individually rather than treated as a universal list.

Provider obligations where applicable can include risk management, data governance, technical documentation, logging, transparency information for deployers, human oversight design, accuracy and robustness, cybersecurity, conformity assessment, quality management, post-market monitoring, and serious incident reporting.

Deployer obligations where applicable can include using the system per the provider's instructions, human oversight during use, monitoring, logging where required, transparency toward affected individuals, escalating incidents, and completing an impact assessment where legally required. Not every deployer carries every item on this list.

Importers, distributors, and authorised representatives have narrower, role-specific obligations, generally concerned with verifying a provider has met its own duties before making a system available. GPAI model providers have the separate obligations noted in Step 3.

Step 5: Assess AI Risks and Required Impacts

A practical risk assessment, independent of high-risk classification, generally involves identifying risks and foreseeable misuse, considering affected people or groups, identifying mitigations, assigning responsibility, documenting residual risk, and setting review points.

Where Annex III or Annex I high-risk obligations apply, the Regulation requires a risk-management process specific to high-risk systems in the applicable Articles; this guide does not reproduce that process, and organisations with high-risk systems should review the provisions directly ahead of the 2027 and 2028 dates.

Fundamental Rights Impact Assessment Where Article 27 Applies

A general risk assessment, a high-risk risk-management process, and an Article 27 Fundamental Rights Impact Assessment (FRIA) are three distinct things. Article 27 requires a FRIA only from specific deployers, including certain public bodies, private providers of certain public services, and deployers of certain credit-scoring or insurance-pricing systems, and only in the circumstances the Article defines. Not every organisation using AI must conduct a FRIA, and not every high-risk deployment automatically triggers one. Under the Digital Omnibus's amendments to the Regulation, a FRIA may now cross-reference a data protection impact assessment already completed under GDPR Article 35 for the same system; the FRIA obligation follows the Annex III timeline, applying from 2 December 2027 where the underlying conditions are met.

Step 6: Implement Required Controls and Governance

Applicable requirements translate into operational governance: accountability, internal policies, human oversight, documentation practices, ongoing monitoring, incident escalation, transparency measures, and coordination with privacy and cybersecurity functions. Some are statutory controls tied to a specific classification; others are recommended practices that support compliance without being independently mandated. Keeping that distinction visible avoids overstating what the law requires.

A usable evidence trail typically includes each system's classification rationale, completed risk assessments, applicable policies, vendor information, records of AI literacy measures, required technical documentation, monitoring records, incident records, and impact assessments where completed.

Step 7: Review AI Vendors and Third Parties

Most organisations rely on third-party AI to some extent, and vendor review is central to EU AI Act vendor due diligence. A practical review covers the vendor's identity and role, how roles are allocated between organisation and vendor, the system's intended purpose, available documentation, transparency information provided, contractual allocation of responsibilities, incident notification arrangements, how material changes are communicated, downstream-provider information where relevant, and periodic reassessment.

Vendor compliance does not transfer an organisation's own legal responsibilities as a deployer or downstream provider. Contractual assurances from a vendor are useful evidence but do not, by themselves, satisfy the organisation's own obligations under the Regulation.

Step 8: Implement AI Literacy and Role-Appropriate Training

Article 4 requires providers and deployers to take measures supporting the development of AI literacy among staff and others dealing with AI systems on their behalf, taking into account technical knowledge, experience, education, training, the context of use, and the people affected. The Digital Omnibus rewrote Article 4, as reflected in the current consolidated text of the Regulation, into an obligation of effort rather than guaranteed outcome: providers and deployers need not guarantee any individual's specific literacy level, and the Commission and Member States are separately tasked with supporting these efforts.

The Act does not require every employee to complete a specific course or certificate, does not mandate one universal programme or fixed number of hours, and does not treat any single commercial course as automatically sufficient for Article 4. What is appropriate depends on role, systems, and people affected, which is why AI literacy measures, organisation-specific training, and commercial AI education remain related but distinct.

A structured course such as EU AI Act compliance training can help staff build the underlying knowledge of roles, classification, and obligations that supports an organisation's own Article 4 measures. Completing it does not itself guarantee compliance, does not automatically satisfy Article 4, does not replace measures tailored to the organisation's own systems and staff, is not a legal certification, and does not guarantee audit outcomes. It is best positioned as one educational input into a broader, organisation-specific AI literacy programme.

Step 9: Document and Maintain Compliance Evidence

Evidence should be created and kept through each system's lifecycle, not assembled retroactively: the inventory, classification rationale, risk assessments, technical documentation where required, logs, vendor due diligence records, AI literacy evidence, impact assessments where completed, incident records, and records of system changes.

Nothing should be labelled a legal requirement without verifying the specific provision that creates it.

Step 10: Audit and Monitor EU AI Act Compliance

An EU AI Act compliance audit here means a structured internal review, not an official or universal audit under the Regulation itself. A periodic review should cover the inventory, role determinations, classification decisions, the obligation map, documentation, controls, vendors, AI literacy measures, transparency compliance, incidents, and changes to systems, vendors, or the regulatory framework since the last review.

This checklist is a practical internal tool, not an official Commission checklist, and passing an internal review of this kind does not by itself guarantee regulatory compliance.

Build practical EU AI Act knowledge

Working through roles, risk categories and application dates is easier when a team shares the same vocabulary. AI Governance Courses offers EU AI Act compliance training designed to help professionals understand how the Act's roles, risk classifications and obligations fit together, and to strengthen the foundation for internal governance work.

The course is educational. It does not constitute legal advice, and completing it does not by itself make an organisation compliant with the AI Act.

How SMEs Can Approach EU AI Act Compliance

EU AI Act compliance for SMEs follows the same sequence above, applied proportionately: build an inventory even if small, identify roles clearly, prioritise systems most likely to be high-risk or subject to transparency obligations, map only the obligations that actually apply, apply governance proportionate to size and risk, still review third-party vendors, still implement appropriate AI literacy measures, keep documentation proportionate but real, and build in recurring review even if informal.

As the European Commission explains, the Digital Omnibus introduced a defined small mid-cap (SMC) category, companies above SME thresholds but with fewer than 750 employees and turnover or balance-sheet figures below specified limits, and extended SME-style simplifications, such as simplified technical documentation and more proportionate conformity assessment and quality management routes, to that category for high-risk systems. These are simplifications, not exemptions: SMEs and SMCs are not exempt, do not all share identical obligations, and the changes reduce administrative burden without eliminating substantive responsibility.

EU AI Act Compliance Checklist

Part A: Determine What the Law Requires

• Determine whether the activity or system falls within scope

• Identify the organisation's role

• Identify the relevant AI system or model

• Check for prohibited AI practices

• Assess the applicable Article 6 pathway

• Consider Article 6(3) conditions and exceptions

• Check Article 50 transparency obligations where applicable

• Determine whether GPAI rules are relevant

• Map the obligations that actually apply

Part B: Practical Compliance Management

• Assess relevant risks

• Complete an Article 27 FRIA where legally applicable

• Implement required controls

• Establish proportionate governance measures

• Review AI vendors

• Implement appropriate AI literacy measures

• Maintain required documentation

• Maintain useful governance evidence

• Conduct periodic internal reviews

• Monitor AI-system and regulatory changes

This EU AI Act compliance checklist is a planning aid. Completing every item in Part B does not itself guarantee compliance, and several Part B items are recommended practices rather than standalone statutory requirements.