What Is the EU AI Act? Plain-English Guide for SMBs

The EU AI Act (Regulation (EU) 2024/1689) is the world's first legally binding, cross-sectoral law on artificial intelligence. It entered into force on 1 August 2024. It does not ban AI. It sorts AI systems into four risk tiers and attaches obligations to the top two. If your system lands in the right tier — or if you simply use a third-party AI tool in a professional context inside the EU — this regulation applies to you directly.

This guide covers what the Act is, who it catches, how the four tiers work, what the full high-risk obligation set requires article by article, which role you hold in the supply chain, the corrected compliance timeline (including the Digital Omnibus deferral agreed in May 2026), how fines are calculated, and a five-step starter for getting compliant.

---

What the Act Actually Is

Most new AI governance frameworks are either voluntary codes or sector-specific guidance. The EU AI Act is neither. It is a directly applicable EU Regulation — meaning it has the same legal force as a statute in every EU member state, without needing domestic implementation. There is no German version, no French transposition. One text, 27 jurisdictions, the same obligations.

The regulation's formal citation is Regulation (EU) 2024/1689 of the European Parliament and of the Council. It was published in the EU Official Journal on 12 July 2024 and entered into force twenty days later, on 1 August 2024. The obligations then rolled in over a phased schedule (covered below).

The core design logic is risk-based: the heavier the potential harm, the heavier the obligation. A spam filter faces no mandatory obligations. A CV-screening tool for a 300-person company faces the same high-risk stack as a large bank's credit-scoring model. The Act does not distinguish by company size at the classification level — it distinguishes by what the system does and what could go wrong.

How the Act fits alongside existing EU law

The EU AI Act is not the only regulation that touches AI. Understanding where it sits relative to GDPR, the product liability framework, and sectoral rules prevents gaps and duplication.

GDPR remains fully in force. The two regulations overlap significantly for high-risk AI systems that process personal data — which is most of them. GDPR governs the data; the AI Act governs the system. Providers building a recruitment AI must satisfy both the Article 10 data governance requirements under the AI Act and the lawful-basis and data-minimisation obligations under GDPR. Compliance with one does not discharge the other.

The AI Liability Directive (still in progress as of June 2026) is designed to sit alongside the AI Act, making it easier for individuals harmed by AI systems to pursue civil claims. The AI Act establishes the public-law obligations; the liability directive addresses private-law redress.

Sector-specific rules — the Medical Devices Regulation, the financial services framework under MiFID II and the EBA guidelines, the DORA regulation for financial digital resilience — continue to apply to AI in those sectors. The AI Act layers on top of, and coordinates with, those frameworks. A medical AI device is simultaneously subject to the Medical Devices Regulation (CE mark via the MDR) and to the AI Act's high-risk tier via Annex I.

ISO/IEC 42001 (the AI management system standard) is not part of the regulatory framework but provides a useful operational structure. Confir cross-maps its assessments to ISO/IEC 42001, NIST AI RMF, and GDPR where relevant.

---

Who the Act Applies To

Extraterritorial scope (Article 2)

The Act applies to:

• Providers placing an AI system on the EU market or putting it into service in the EU — regardless of where the provider is established. A US startup selling an AI recruitment tool to German firms is a provider under the Act.
• Deployers of AI systems located within the EU, or whose use affects persons in the EU.
• Importers and distributors in the EU supply chain.
• Providers and deployers established outside the EU when the output of their AI system is used in the EU.

The territorial reach is broader than GDPR. You do not need a European office, a European server, or a European data subject to fall in scope. If your system's output lands in front of EU users, the Act applies.

Key exclusions

The Act carves out four areas:

1. Military, defence, and national security — these are outside EU competence and expressly excluded.
2. Pure scientific research and development — AI developed and tested solely for R&D purposes, not yet placed on the market, is not covered. Once you move toward deployment, the exclusion lapses.
3. Purely personal, non-professional use — running an AI tool for your own private purposes, with no professional or commercial context, sits outside scope.
4. Open-source models — the treatment is limited, not blanket. Open-source GPAI model providers are partially exempt from some Chapter V obligations (technical documentation, downstream disclosure) unless their model is released with a systemic-risk designation (10^25 FLOP threshold) or is used in prohibited/high-risk contexts. Open-source does not exempt a deployer who uses the model in a high-risk application.

---

The Four Risk Tiers

The Act classifies every AI system into one of four tiers. Your tier determines which obligations apply.

Tier 1 — Unacceptable risk (prohibited)

Article 5 lists practices that are banned outright. They have been prohibited since 2 February 2025. No compliance pathway exists; you cannot deploy these systems in the EU under any circumstances.

The banned categories include:

• Real-time remote biometric identification in publicly accessible spaces (with a narrow law-enforcement exception requiring prior judicial or equivalent authorisation).
• AI systems that use subliminal techniques operating below conscious perception, or that exploit vulnerabilities of specific groups, to distort behaviour in harmful ways.
• Social scoring by public authorities — assigning scores to natural persons based on social behaviour, leading to detrimental treatment.
• Predictive policing based solely on profiling, without objective evidence tied to an individual.
• Emotion recognition systems in workplace and educational institution contexts.
• Biometric categorisation systems inferring sensitive attributes (political opinions, race, sexual orientation) from biometric data.
• Untargeted scraping of facial images from the internet or CCTV to build facial recognition databases.

If you recognise your product in any of those descriptions, stop and get legal advice. The fine ceiling is €35 million or 7% of global annual turnover — whichever is higher.

A few of the prohibitions are worth elaborating because they generate the most confusion in practice.

The workplace emotion recognition ban catches more products than founders expect. If your HR software analyses video of job interviews to infer candidate emotional states, that is prohibited — regardless of whether your marketing describes it as "engagement measurement" or "candidate experience scoring." The label does not matter; the function does.

The biometric categorisation ban for sensitive attributes applies to inferring political opinions, religious or philosophical beliefs, race, sexual orientation, or trade union membership from biometric data. A security camera system that categorises people by apparent ethnicity to generate statistics falls here, even if no individual identification is intended.

The predictive policing ban is narrow. It targets systems that predict an individual's likelihood of offending solely on the basis of profiling, without objective, individually verifiable evidence. AI that analyses historical crime data to predict where offences are likely to occur (hotspot analysis) is different from AI that predicts which specific individuals are likely to offend based on social or demographic data alone.

Tier 2 — High risk

High-risk systems carry the full obligation stack. There are two pathways to the high-risk tier.

Annex I pathway: AI systems that are safety components of products already governed by EU product safety law — machinery, medical devices, civil aviation, cars, toys, and similar regulated-product categories. If your AI sits inside one of these products and affects the product's safety, you are in the high-risk tier via Annex I.

Annex III pathway: Stand-alone AI systems in eight specific areas:

1. Biometrics — remote biometric identification, biometric categorisation, and emotion recognition where not already prohibited.
2. Critical infrastructure — safety components in digital infrastructure, road traffic management, electricity, water, gas.
3. Education and vocational training — admission decisions, evaluating students and exam-cheating monitoring, assessment of learning outcomes affecting access to education.
4. Employment, workers management, and access to self-employment — recruitment and CV screening, task allocation, promotion and termination decisions, performance monitoring.
5. Access to essential private and public services — creditworthiness assessment and credit scoring (fraud detection is out), health and life insurance risk and pricing, emergency dispatch prioritisation, public-benefit eligibility.
6. Law enforcement — risk-of-offending or re-offending assessments, AI used in polygraph-like systems, evidence reliability scoring, suspect profiling.
7. Migration, asylum, and border control — risk assessments for asylum seekers, examination of visa and residence permit applications, document authenticity verification.
8. Administration of justice and democratic processes — AI assisting judicial authorities in researching or applying law; systems used to influence elections or referenda.

The Article 6(3) filter. Being in an Annex III area does not automatically make a system high-risk. Article 6(3) provides that a system is not high-risk if it does not pose a significant risk of harm to health, safety, or fundamental rights — for instance if it performs a narrow procedural task, improves the result of a previously completed human activity, or does preparatory work without influencing human assessments. But any system that profiles natural persons remains high-risk regardless. Providers claiming the Article 6(3) filter must document the assessment and register the system.

Most SMBs building AI products fall somewhere in Annex III. An HR-tech startup with 40 employees whose product screens CVs is in the employment bucket. A fintech whose model prices insurance policies is in essential services. Classification is not a judgment call you make loosely — the obligations that follow are substantial.

Two areas generate the most classification disputes among SMBs.

Credit scoring versus fraud detection. The Act explicitly excludes fraud detection from Annex III's essential-services bucket. A system that flags transactions as potentially fraudulent is outside Annex III (and likely minimal risk). A system that assesses whether a customer is creditworthy, or that produces a score used in a lending decision, is in Annex III regardless of how the provider labels it. If your model is downstream of a credit decision — even if a human makes the final call — examine carefully whether you are within scope.

Performance monitoring versus task allocation. Article 6 and Annex III catch AI used in "workers management" broadly, including monitoring of working performance. A productivity dashboard that tracks employee output metrics and is used by managers to decide on performance reviews or terminations is likely high-risk. A simple time-tracking tool that records hours worked, without AI-generated assessments or recommendations, is not.

Tier 3 — Limited risk (transparency obligations)

Article 50 covers systems where the main concern is deception, not harm. The obligations are narrow: disclose.

• Chatbots and conversational AI must inform users they are interacting with an AI system, not a human.
• Deepfakes and synthetic media — AI-generated or manipulated video, audio, or images — must be labelled as artificially generated or manipulated. An exception applies where the disclosure would be obviously unnecessary (e.g. AI in a clearly satirical context).
• Emotion recognition and biometric categorisation systems (where permitted) must inform exposed natural persons.
• AI-generated text on matters of public interest must be labelled when published.

Article 50 applies from 2 August 2026 (the general application date). A customer-service chatbot deployed by a French telecoms company must disclose its AI nature — but it does not need a conformity assessment, a risk management system, or technical documentation.

Tier 4 — Minimal risk

Everything else. The vast majority of AI systems in use today — recommendation engines, spam filters, fraud detection outside the essential-services bucket, content moderation tools, image enhancement, product search — fall here. No mandatory obligations. The Commission encourages voluntary codes of conduct, but the Act imposes nothing.

The practical takeaway: classify first. Most anxiety about the EU AI Act is misplaced because most AI deployments are minimal risk. The regulation is genuinely burdensome only for the top tier.

---

GPAI Models: A Separate, Cross-Cutting Category

General-purpose AI (GPAI) models — meaning models trained on broad data, capable of a wide range of tasks, and typically integrated into downstream applications — are governed by Chapter V (Articles 51–56). They are not a fifth risk tier. A GPAI model can also be deployed in a high-risk application, in which case both sets of obligations apply.

All GPAI model providers (regardless of systemic-risk status) must under Article 53:

• Prepare and maintain technical documentation.
• Provide downstream providers with information to enable their own compliance.
• Have a copyright policy complying with EU law.
• Publish a summary of training data.

Models that cross the 10^25 FLOP computational threshold during training are presumed to carry systemic risk and face additional obligations under Article 55: model evaluation (including adversarial testing), risk mitigation, incident reporting to the AI Office, and cybersecurity measures. Article 51 defines the classification; Article 52 sets the notification procedure.

If you are deploying a third-party GPAI model (GPT-4-class, Gemini, Claude, and similar) into an Annex III application, the downstream provider obligations on you remain. The GPAI provider's Chapter V obligations do not discharge your own high-risk duties under Articles 9–17.

---

The High-Risk Obligation Set, Article by Article

For systems that land in the high-risk tier, these are the mandatory requirements. They are not optional and they are not aspirational. Each article represents a distinct legal obligation.

Article 9 — Risk management system. Providers must establish, implement, document, and maintain a risk management system throughout the AI system's lifecycle. This means identifying foreseeable risks, estimating and evaluating them, adopting suitable risk control measures, and testing that the measures work. The system must be updated as the AI evolves or as new risks emerge.

Article 10 — Data and data governance. Training, validation, and test datasets must be subject to appropriate data governance practices: relevant, representative, free of errors, and complete for the intended purpose. Providers must examine data for possible biases that could lead to prohibited outcomes. For a recruitment tool, this means demographic analysis of the training corpus and documented bias testing before any deployment.

Article 11 — Technical documentation. Before placing a high-risk system on the market, providers must prepare documentation per Annex IV. The required elements include: a general system description, a description of its components and development process, information on training and testing, performance metrics, the risk management system outcomes, human oversight measures, and cybersecurity details. This is the dossier a regulator would review.

Article 12 — Record-keeping and logging. High-risk systems must be capable of automatically recording logs — events relevant to identifying risks and incidents, and to monitoring. Logging granularity must be sufficient to trace the system's operation over its active life. Deployers must retain logs for at least six months (or longer if sector regulation requires it).

Article 13 — Transparency and information to deployers. AI systems must be transparent enough for deployers to understand what the system does, its capabilities and limitations, performance metrics, and what human oversight is required. Instructions for use must accompany each system. A deployer cannot legitimately run a high-risk system without this information; a provider who fails to supply it has breached Article 13.

Article 14 — Human oversight. High-risk systems must be designed and built so that natural persons can effectively oversee them during use. This means: humans can understand system outputs, they can detect and address failures, they can choose not to use the system in a given case, and they can override or disregard outputs. "Human in the loop" is not enough if the human is rubber-stamping outputs they cannot meaningfully evaluate.

Article 15 — Accuracy, robustness, and cybersecurity. High-risk systems must achieve appropriate levels of accuracy and perform consistently throughout their lifecycle. They must be resilient against errors, faults, and adversarial attempts to alter outputs. Accuracy levels and the relevant metrics must be declared in the technical documentation.

Article 17 — Quality management system (QMS). Providers must put in place a quality management system covering policies, procedures, instructions, and resources. The QMS addresses the system's design, testing, deployment, post-market monitoring, and corrective actions. For a 15-person SaaS company, this is not necessarily a heavyweight ISO-certified programme — but it must be documented, functional, and auditable.

Article 43 — Conformity assessment. Before placing a high-risk system on the market, providers must carry out a conformity assessment demonstrating compliance with the high-risk requirements. For most Annex III systems, self-assessment (internal review against the Act's requirements) is permitted unless a harmonised standard has been replaced by a mandatory third-party check. Biometric identification systems are subject to mandatory third-party (notified body) assessment. The assessment is documented; it does not expire, but must be updated when the system is substantially modified.

Articles 47–49 — Declaration of conformity, CE marking, and registration. After passing conformity assessment, providers draw up an EU declaration of conformity (Article 47), affix CE marking where applicable (Article 48), and register the system in the EU database before placing it on the market (Article 49). The database is publicly accessible (with some sensitive elements redacted). Non-EU providers must appoint an authorised representative established in the EU (Article 22).

Article 72 — Post-market monitoring. Providers must actively monitor high-risk systems after deployment, collect data on performance, identify any emergent risks, and act on findings. The post-market monitoring plan is part of the quality management system. This is ongoing — not a one-time deployment check.

Article 73 — Serious incident reporting. Providers must report serious incidents — those resulting in death, serious health harm, serious breaches of fundamental rights, or significant disruptions to critical infrastructure — to the relevant national market surveillance authority without undue delay, and in any case within 15 days of becoming aware of a direct causal link between the system and the incident.

The obligation set in aggregate

Taken together, Articles 9–17, 43, 47–49, 72, and 73 constitute a significant compliance programme. For a SaaS provider building its first Annex III product, a reasonable estimate is three to six months of dedicated work before the system can be placed on the market — less if the team is experienced and has already built the QMS bones, more if documentation is starting from scratch.

The documents interact. The risk management system (Article 9) informs the technical documentation (Article 11). The data governance assessment (Article 10) feeds into both. The conformity assessment (Article 43) draws on all of them and cannot happen until they exist. Treating these as sequential, independent tasks misunderstands the structure: they are a system.

One common error is confusing the Article 11 technical documentation with the Article 47 declaration of conformity. The technical documentation is the evidence — the full dossier showing how the system was designed, tested, and assessed. The declaration of conformity is the formal statement — the document signed by the provider asserting that the system meets the requirements. You write the declaration on the basis of the technical documentation, not instead of it.

---

Roles in the Supply Chain

Who holds which obligation depends on the role you hold in relation to the AI system.

Provider (Article 16): Develops an AI system or a GPAI model and places it on the EU market, or puts it into service under its own name or trademark. Carries the heaviest obligations: the full Articles 9–17 stack, conformity assessment, declaration of conformity, CE marking, registration, post-market monitoring, and incident reporting. A Berlin-based startup that builds a CV-screening product and sells it to HR teams is a provider.

Deployer (Article 26): Uses a high-risk AI system in a professional capacity, under its authority, for purposes and in contexts it determines. Must follow the provider's instructions, assign human oversight to competent persons, monitor performance, and log relevant events. Some deployers must also run a Fundamental Rights Impact Assessment (FRIA) under Article 27 — specifically, deployers of high-risk systems used by or on behalf of public authorities (or private entities providing public services such as banks, insurers, utilities). A regional bank deploying a third-party credit-scoring model is a deployer.

Importer (Article 23): Places a high-risk AI system on the EU market on behalf of a non-EU provider. Must verify that conformity assessment has been completed, that technical documentation exists, that CE marking is in place, and that the provider has an authorised representative. Carries liability if the provider is unreachable.

Distributor (Article 24): Supplies a high-risk system that is already on the EU market, without modifying it. Must verify that CE marking and documentation are present and that the system is not supplied to known non-compliant users.

Article 25 — Role shifts. A deployer, distributor, or importer becomes a provider — and inherits the full provider obligation stack — if it: (a) puts its name or trademark on a high-risk system, (b) substantially modifies a high-risk system, or (c) modifies the intended purpose of a non-high-risk system into a high-risk one.

In practice, most SMBs are deployers of third-party AI tools. Deployer obligations are lighter than provider obligations, but they are real. If you use an AI system to make decisions about your employees, customers, or benefit recipients, the Article 26 and Article 27 obligations sit with you directly.

The FRIA in practice

The Article 27 Fundamental Rights Impact Assessment deserves specific attention for deployers. Not all deployers must run one — it applies to deployers using high-risk systems who are, or are acting on behalf of, public bodies, or who are private entities providing public-interest services (credit institutions, insurance companies, water/energy/transport operators, healthcare providers, and similar). If you are a regional insurer deploying a third-party AI pricing model, you are in scope.

The FRIA requires the deployer to assess, before deployment, the potential impact of the system on fundamental rights: privacy, non-discrimination, dignity, data protection, and others. It is not an audit of the technical system — the provider's conformity assessment covers that — but an assessment of the specific deployment context. A credit-scoring model deployed by a German regional bank to assess mortgage applications triggers a different FRIA than the same model deployed by a consumer lender in a higher-risk demographic. The context changes the rights impact; the FRIA must reflect that.

The assessment must be notified to the relevant market surveillance authority if requested, and the deployer must log outputs of the high-risk system for at least six months and make them available to that authority on request.

---

The Compliance Timeline (Corrected for Digital Omnibus)

The Act's obligations came into force in phases. Get these dates right — they matter for planning:

The last two dates reflect the Digital Omnibus deferral. The original Act applied all high-risk obligations from 2 August 2026. Following the Commission's proposal of 19 November 2025 and the political agreement between Parliament and Council on 7 May 2026, the high-risk application dates were separated and pushed back: to 2 December 2027 for stand-alone Annex III systems, and to 2 August 2028 for Annex I product-embedded systems. Formal adoption was expected before August 2026.

The deferral is real, but the window is not as long as it looks. Article 11 technical documentation alone takes months to assemble properly. Risk management systems need to be built and validated before the assessment, not the night before the deadline. Companies that wait until mid-2027 to start will not have enough time.

What "general application" in August 2026 means for you

The 2 August 2026 date — general application — is sometimes misread as the main compliance deadline. It is not. What it triggers is:

• The Article 50 transparency obligations for limited-risk systems (chatbot disclosure, deepfake labelling, AI-generated content marking).
• The AI Office and governance structure becomes fully operational.
• Market surveillance authorities begin exercising their full inspection and enforcement powers across all parts of the Act that have applied since 2025.

If you deploy a chatbot or any AI that generates synthetic media, 2 August 2026 is your deadline for the disclosure obligations. For everything else that is already in force (Article 5, Article 4 literacy, Article 99 penalties), August 2026 adds the infrastructure for enforcement — which means the risk of acting on a prohibited or non-compliant system goes up, not that a new obligation suddenly appears.

The practical read: if your system is prohibited, you are already non-compliant and have been since February 2025. If your system is high-risk, you have until December 2027 — but every month spent not building the documentation is a month of risk accumulation, not a month of permitted non-compliance.

---

Penalties (Article 99)

Fines are the higher of a fixed ceiling or a percentage of total worldwide annual turnover for the preceding financial year:

• €35,000,000 or 7% — breach of the Article 5 prohibitions (deploying a banned AI system).
• €15,000,000 or 3% — most other violations, including non-compliance with high-risk requirements, provider and deployer obligations under Articles 16, 26, 50, and similar.
• €7,500,000 or 1% — supplying incorrect, incomplete, or misleading information to a notified body or competent authority.

SME protection (Article 99(6)): For SMEs and start-ups, fines are capped at the lower of the percentage figure and the fixed ceiling. A small company's fine cannot exceed what the percentage would yield, even if that is below the fixed maximum. This is meaningful: a startup with €2 million in annual turnover facing a 3% fine pays €60,000, not €15 million. The proportionality protection is real, though it does not reduce the compliance obligation itself.

GPAI-specific fines are handled separately under Article 101 — up to €15 million or 3% of worldwide turnover, imposed by the Commission rather than national authorities.

Note: the figures €30 million/6% and €20 million/4% that appeared in early summaries of the Act do not reflect the final text. The correct figures are as above.

---

What to Do Now: A Five-Step Starter

If you have not yet mapped your AI exposure against the Act, here is where to begin.

Step 1 — Take inventory. List every AI system your organisation builds or deploys, including AI features embedded in SaaS tools you subscribe to. Include both internal-use systems (HR, finance, operations) and customer-facing products. You cannot classify what you have not listed.

Step 2 — Classify each system. For each item in the inventory, determine whether it falls into Article 5 (prohibited), Annex III (high-risk), Article 50 (limited-risk transparency), or minimal risk. Work through the Article 6 logic carefully: check whether an Annex III category applies, then check whether the Article 6(3) filter exempts it. Document your reasoning — this assessment is itself an auditable record.

Step 3 — Assign roles. For each high-risk system, determine whether you are a provider, deployer, importer, or distributor. If you have modified a third-party system or relabelled it, you may be a provider under Article 25. Role determines which Article stack applies to you.

Step 4 — Gap-assess against the obligation set. For each high-risk system where you are a provider, work through Articles 9–17, 43, and 47–49 and identify what you have versus what you need. For deployer-role systems, work through Articles 26–27. The gap list becomes your compliance project plan.

Step 5 — Build the documentation. Technical documentation (Annex IV), risk management system records, data governance documentation, and the declaration of conformity cannot be retrofitted quickly. Start with the systems that are furthest along toward deployment or that handle the most sensitive decisions. Treat the 2 December 2027 deadline as the latest acceptable completion date, not the start date.

---

How Confir Helps

Confir is EU AI Act compliance software built for SMB compliance, legal, and IT teams. It runs every step above through a structured workflow: AI inventory and registration, Article 5/6 classification using Annex III logic, role derivation, and a structured assessment across risk management, data governance, transparency, and oversight. The engine is rule-based and deterministic — the same inputs produce the same finding every time, with the specific rule that fired shown in plain language. This matters for audit: an explainable output is defensible; a black-box one is not.

At the end of the assessment, Confir generates the Article 11/Annex IV technical documentation pack, the Article 47 EU Declaration of Conformity, and (for relevant deployers) the Article 27 Fundamental Rights Impact Assessment. Pricing starts at €600 per year; no consultants, no enterprise sales cycle.

---

FAQ

What is the EU AI Act in one sentence? It is Regulation (EU) 2024/1689 — the EU's legally binding, risk-based framework for AI systems, which prohibits the most harmful applications, attaches a full compliance stack to high-risk systems in eight defined areas, and requires transparency disclosures for limited-risk AI such as chatbots and deepfakes.

Does the EU AI Act apply to us if we are not based in the EU? Yes, if your system is placed on the EU market or if its output is used in the EU (Article 2). Location of the provider is irrelevant. A company in Singapore selling an AI recruitment tool to Dutch firms must comply with the same obligations as a Dutch provider. Non-EU providers must appoint an authorised representative in the EU under Article 22.

When does the high-risk deadline actually apply? For stand-alone Annex III systems (recruitment, credit-scoring, biometrics, etc.), the date is 2 December 2027 — deferred from the original August 2026 date under the Digital Omnibus political agreement of May 2026. For high-risk AI embedded as safety components in regulated products (machinery, medical devices, vehicles), it is 2 August 2028. The prohibitions (Article 5) have applied since 2 February 2025.

What is the difference between a provider and a deployer under the Act? A provider develops or markets the AI system; a deployer uses it in a professional context. Providers carry the heaviest burden — conformity assessment, technical documentation, QMS, CE marking, registration. Deployers must follow instructions, maintain logs, ensure human oversight (Article 14), and in some cases run a Fundamental Rights Impact Assessment (Article 27). Under Article 25, a deployer who substantially modifies a system or changes its intended purpose becomes a provider.

Is our chatbot high-risk? Almost certainly not. A standard customer-service or sales chatbot falls under Article 50 (limited-risk) and requires only disclosure: users must be told they are speaking with an AI system. A chatbot becomes high-risk only if it performs an Annex III function — for example, if it makes or informs creditworthiness decisions, recruitment screening, or benefit-eligibility determinations. Classify by what the system does, not what it looks like.

What are the fines for non-compliance? Violating Article 5 (deploying a prohibited AI system) carries up to €35 million or 7% of global annual turnover, whichever is higher. Most other violations — failing to meet high-risk requirements, provider/deployer obligations — carry up to €15 million or 3%. Supplying false information to authorities is up to €7.5 million or 1%. For SMEs and start-ups, Art 99(6) caps fines at the lower of the percentage or fixed ceiling. There is no €30 million/6% tier — that figure does not exist in the final Act.

Do we need a notified body for the conformity assessment? For most Annex III systems, self-assessment is permitted. Third-party assessment by a designated notified body is mandatory for AI systems intended for remote biometric identification. The conformity assessment must be documented, and the system must then be registered in the EU database (Article 49) before going to market.

---

Related guides

• compliance software comparison tools
• deployer obligations and requirements
• AI governance software solutions
• Article 16 provider obligations