EU AI Act Compliance for SMBs: The Practical 2025–2028 Guide

Your obligations under the EU AI Act depend on your role in the AI supply chain — whether you develop, deploy, import, or distribute AI systems — and on where your systems land in the Act's four risk tiers. Regulation (EU) 2024/1689 assigns distinct legal duties to each actor, with some obligations already in force and others phased in through 2028. This guide maps your specific requirements by role, risk tier, and deadline so you can build a compliance roadmap without the ambiguity.

After reading this, you will know: which articles apply to your business, what documentation you must produce before each enforcement date, how to classify systems under Article 6 and Annex III, and what the fine ceilings actually are (including the proportionality protection that genuinely matters for SMBs). You will also identify the gaps that most small businesses miss — misclassifying systems, delaying risk documentation, or assuming their vendor handles everything.

The EU AI Act applies to any organisation offering AI systems in the EU market, regardless of where your company is registered. Company size does not reduce your legal obligations, but the Act does contain a specific financial protection for SMEs and start-ups that affects how fines are calculated.

---

What the EU AI Act Is and Why It Applies to Your Business

The EU AI Act (Regulation (EU) 2024/1689) is a binding legal framework that classifies AI systems by risk level and attaches compliance obligations to the top two tiers. Unlike voluntary standards, it creates enforceable duties with penalties reaching €35 million or 7% of global annual turnover for the most serious violations.

Scope: Who Must Comply

Article 2 establishes that the regulation applies to:

• Providers placing AI systems on the EU market or putting them into service in the EU — regardless of where the provider is based
• Deployers (organisations using AI systems in a professional capacity) established or located in the EU
• Importers and distributors of AI systems when those systems are used by EU residents
• Third-country providers whose AI system outputs are used in the Union

A small German logistics company using a chatbot from a US vendor, or a Polish recruitment firm deploying CV-screening software, must ensure compliance. The obligation is territorial, not jurisdictional.

The Four Actor Roles

One organisation can hold multiple roles simultaneously. A SaaS company that builds a CV-screening tool and uses it internally to hire its own staff is both provider and deployer — obligations stack.

Article 25 contains a critical trap for SMBs: a deployer, distributor, or importer becomes a provider (and inherits the full provider obligation set) if it puts its own name on a high-risk system, substantially modifies it, or changes its intended purpose. Rebranding a third-party model as your own product triggers this shift immediately.

Most SMBs are deployers of third-party AI tools. The deployer obligations are lighter than most founders fear — but the parts that actually bite are human oversight (Article 14), monitoring, and the Fundamental Rights Impact Assessment (Article 27) for certain use cases.

The Phased Compliance Timeline

Compliance is not simultaneous. The Act phases in obligations by risk tier:

• 2 February 2025 — Article 5 prohibited practices apply. Also Article 4 AI literacy — providers and deployers must ensure staff working with AI have adequate understanding of the systems and the Act's requirements. Both are already in force.
• 2 August 2025 — General-Purpose AI (GPAI) model obligations (Chapter V, Articles 51–56), governance, AI Office, and the penalties regime (Article 99) apply.
• 2 August 2026 — General application of the Act, including limited-risk transparency obligations under Article 50.
• 2 December 2027 — High-risk AI systems listed in Annex III (stand-alone: recruitment tools, credit scoring, biometrics, etc.) must meet the full high-risk stack.
• 2 August 2028 — High-risk AI that functions as a safety component of products covered by EU harmonisation law (Annex I: machinery, lifts, medical devices, etc.) must comply.

The original Annex III deadline was 2 August 2026. Under the Digital Omnibus — a Commission proposal of November 2025, politically agreed by Parliament and Council on 7 May 2026 — that date is now 2 December 2027 for stand-alone systems and 2 August 2028 for product-embedded systems. Formal adoption is expected before the original 2 August 2026 date.

The extension is breathing room, not a reprieve. Technical documentation, risk management systems, and conformity assessments take months to assemble properly. Organisations that start in 2027 will be scrambling.

---

Your Role in the AI Supply Chain: Getting Classification Right

Misclassifying your role is one of the most common enforcement gaps. Get this wrong and you either over-invest in obligations you don't have, or — more likely — you miss the ones you do.

Providers: The Heaviest Obligation Set

You are a provider if you develop, train, or place an AI system on the EU market under your own name or trademark. This covers SaaS companies shipping AI features, AI-native startups, and any business that fine-tunes or substantially adapts a foundation model and releases it to customers.

Under Article 16, providers of high-risk AI must: implement a risk management system (Article 9), compile and maintain technical documentation (Article 11), ensure human oversight by design (Article 14), conduct a conformity assessment (Article 43), register the system (Article 49), and establish post-market monitoring (Article 72). That is the full stack — and each item has sub-requirements.

For high-risk violations, the fine ceiling is €15 million or 3% of worldwide annual turnover. For Article 5 prohibited practices, it is €35 million or 7%.

The SME proportionality protection (Article 99(6)): For SMEs and start-ups, fines are capped at the lower of the fixed amount or the percentage of turnover — not the higher, as for large companies. For a startup with €800,000 turnover, the effective ceiling for a high-risk violation is €24,000 (3%), not €15,000,000. This does not reduce the legal obligation, but it significantly changes the financial risk calculation for early-stage companies. Know it exists.

Deployers: Lighter but Not Trivial

You are a deployer if you use a high-risk AI system in your professional operations. Under Article 26, deployers must: use the system according to the provider's instructions, ensure the humans overseeing it have the competence and authority to understand and override its outputs, monitor real-world performance, and keep records.

The obligation that trips up most SMB deployers is Article 14 human oversight — not because it is onerous, but because it requires genuine design choices. Your oversight person must be able to understand why the system produced a given output, not just that it did. Assigning oversight to someone without the background to interrogate the model's reasoning violates the requirement.

Article 27 FRIA: If you are a public body, a private entity providing public services, or a private entity deploying high-risk AI in employment, credit scoring, insurance, essential services, law enforcement, border management, justice administration, or democratic processes, you must conduct a Fundamental Rights Impact Assessment before first deployment. This is not optional and not a formality — it must document how the system could affect fundamental rights, what mitigation measures apply, and how you will monitor ongoing impact.

SMBs in Multiple Roles

A fintech startup building and deploying its own credit-scoring AI is simultaneously a provider (Articles 9–17, 43, 47–49, 72) and a deployer (Article 26, and Article 27 FRIA). Compliance costs compound. Plan for both tracks from the start rather than discovering the second one mid-audit.

---

The Four Risk Tiers: What They Are and What Each Costs You

The Act sorts every AI system into one of four tiers. The tier determines whether you can deploy at all, what documentation you must maintain, and your financial exposure. Classification is not optional — you must document your assessment of where each system lands.

Tier 1: Prohibited Practices (Article 5)

These practices are banned outright. No exceptions for SMBs, no proportionality argument, no grace period. They have been illegal since 2 February 2025.

Article 5 prohibits:

• Subliminal or manipulative techniques that distort behaviour and are likely to cause significant harm
• Exploitation of vulnerabilities — targeting children, elderly people, people with disabilities, or those in economically precarious positions — in ways likely to cause significant harm
• Social scoring by public authorities based on social or economic status that leads to discriminatory treatment
• Real-time remote biometric identification in publicly accessible spaces by law enforcement, except in narrow, strictly regulated circumstances
• Retrospective remote biometric identification in public spaces (except for serious crime investigation with judicial authorisation)
• Biometric categorisation of individuals based on sensitive attributes (political opinion, religious belief, race, sexual orientation) to infer those characteristics
• Emotion recognition in the workplace or educational institutions
• AI systems used to compile facial recognition databases by untargeted scraping of images
• Predictive policing based solely on profiling without objective, verifiable facts

The fine for any Article 5 breach is up to €35 million or 7% of worldwide annual turnover — whichever is higher. For an SME, the Art 99(6) cap means the percentage applies if it results in a lower number than the fixed sum. At low turnover levels the fixed sum remains the ceiling; at higher turnover levels the percentage bites harder.

Practical check for SMBs: A recruitment firm using AI that proxies age through CV date ranges and filters candidates as a result is likely in Article 5(b) territory (exploiting implied vulnerability to cause harm in an employment context). A warehouse operator using emotion recognition cameras violates Article 5 outright. Audit these use cases now — they have been illegal for over a year.

Tier 2: High-Risk AI (Article 6, Annex III, Annex I)

High-risk AI systems attract the full compliance stack: risk management system, technical documentation, data governance, human oversight by design, conformity assessment before market placement, registration, and post-market monitoring. They also trigger deployer obligations including FRIA in certain contexts.

Article 6 defines high-risk in two tracks:

Track A — Annex I product-embedded systems: AI functioning as a safety component in products governed by EU harmonisation law (machinery, lifts, personal protective equipment, toys, medical devices, radio equipment, etc.). These require third-party conformity assessment through a notified body. Deadline: 2 August 2028.

Track B — Annex III stand-alone systems: AI systems listed in eight categories (see below). Internal conformity assessment permitted for most. Deadline: 2 December 2027.

The Article 6(3) filter: A system that falls within an Annex III heading is not high-risk if it does not pose a significant risk of harm to health, safety, or fundamental rights. This applies where the system performs a narrow procedural task, improves the result of a previously completed human activity, detects decision patterns without replacing or influencing human assessment, or does preparatory work only. However, any system that profiles natural persons is always high-risk — the filter does not apply. Providers claiming this exemption must document their assessment and register it in the EU database.

The eight Annex III categories:

1. Biometrics — remote biometric identification systems; biometric categorisation inferring sensitive attributes; emotion recognition (where permitted)
2. Critical infrastructure — safety components in digital infrastructure, road traffic management, utility supply
3. Education and vocational training — admission decisions, student evaluation, exam-cheating detection
4. Employment and workers management — recruitment and selection, task allocation, promotion and termination, monitoring of employees' performance and behaviour
5. Access to essential services — creditworthiness and credit scoring (excluding fraud detection); health and life insurance risk assessment and pricing; emergency dispatch prioritisation; public-benefit eligibility
6. Law enforcement — risk-of-offending assessment, polygraphs, evidence reliability evaluation, criminal profiling
7. Migration, asylum, border control — risk assessment, application examination, document verification
8. Administration of justice and democratic processes — assisting judicial decision-making; influencing elections or referenda

Fine ceiling for high-risk violations: €15 million or 3% of worldwide annual turnover — whichever is higher; lower figure for SMEs and start-ups per Art 99(6).

Tier 3: Limited-Risk (Article 50)

Article 50 imposes transparency obligations — disclosure duties only, no conformity assessment required. These apply when an AI system:

• Interacts with humans in ways that could be mistaken for human interaction (chatbots, virtual assistants) — users must be informed they are interacting with AI, unless this is obvious from context
• Generates synthetic audio, images, or video (deepfakes, AI-generated marketing content) — the synthetic nature must be labelled
• Detects emotions or classifies persons based on biometric features
• Generates text for public dissemination on matters of public interest (AI-generated content labelling)

Article 50 obligations apply from 2 August 2026. Fine ceiling: €15 million or 3% for most violations; the misinfo/misleading-information category is €7.5 million or 1%.

For SMBs: A customer-service chatbot, an AI email assistant, or a social media tool using generative content generation all land here. The compliance burden is low — a disclosure statement at the point of interaction — but it must exist and be accurate.

Tier 4: Minimal Risk

Everything else. No mandatory AI Act obligations beyond general EU law (GDPR, consumer protection). Recommendation engines, spam filters, demand forecasting, route optimisation, and most document classification tools sit here. Voluntary codes of conduct are encouraged but not required.

---

High-Risk Compliance in Detail: The Seven-Obligation Stack

If your system is high-risk, seven interconnected obligations apply before you can place it on the market. Each has its own Article reference and specific sub-requirements. Missing any one of them creates a compliance gap that regulators will find.

1. Risk Management System (Article 9)

A continuous, iterative process running for the entire lifecycle of the system — not a one-time assessment. Article 9 requires you to identify and analyse all known and reasonably foreseeable risks to health, safety, or fundamental rights, estimate and evaluate those risks (including under foreseeable misuse conditions), and adopt suitable risk mitigation measures proportionate to what you found.

The common mistake is treating Article 9 as a document rather than a process. When post-market monitoring reveals a new failure mode, you must update the risk analysis. A recruitment AI that was tested for gender bias but later shows age-correlated disparate impact needs a new Article 9 cycle.

Practical minimum for a 20-person HR-tech firm: a risk register that names each identified harm, its likelihood and severity, the mitigation applied, and the residual risk accepted. Version-controlled, not sitting in someone's inbox.

2. Technical Documentation (Article 11, Annex IV)

Providers must compile and maintain technical documentation before market placement. The documentation must be kept for the system's operational lifetime plus at least ten years (the Act sets a minimum of ten years for most high-risk systems; check sector-specific rules for longer requirements).

Annex IV specifies the minimum content:

• General description of the system, its intended purpose, version history, hardware and deployment environment
• Development methodology: training data sources, preprocessing, labelling protocols, known data gaps
• System architecture: model type, algorithms, input/output specifications, integration dependencies
• Performance testing results: accuracy metrics, robustness testing, performance across demographic groups and edge cases
• Instructions for use and documented limitations
• Post-market monitoring procedures

Practical example: A credit-scoring SaaS for regional lenders must document that its model was trained on 200,000 loan applications from 2018–2024, that applicants under 25 were under-represented in training data (and what was done about it), and that the model achieves 88% accuracy overall but 81% for self-employed applicants. That specificity is what regulators expect — not a generic description.

3. Data Governance (Article 10)

Training, validation, and testing datasets must be relevant, representative of the real-world conditions where the system operates, free of errors to the extent practicable, and assessed for biases that could affect health, safety, or fundamental rights. Article 10 also requires appropriate data governance practices: version control, access restrictions, audit trails.

Where bias cannot be fully eliminated in training data, the risk management system (Article 9) must document this as a residual risk and specify ongoing monitoring measures.

4. Human Oversight (Article 14)

High-risk AI systems must be designed and built — not just operated — in ways that enable effective human oversight. Article 14 is a design obligation on providers and an operational obligation on deployers.

The system must:

• Allow the persons overseeing it to understand its capabilities and limitations
• Enable monitoring for anomalies, failures, and unexpected outputs
• Allow intervention and override without requiring multilayered approval
• Include a stop function where necessary

For deployers: the oversight person must have the competence to understand why the system produced a given output, the training to recognise failures, and the authority to act on what they find. Assigning AI oversight to a junior employee with no briefing and no override authority does not satisfy Article 14.

5. Conformity Assessment (Article 43)

Before placing a high-risk AI system on the market, you must complete a conformity assessment that verifies compliance with the Chapter III requirements (Articles 9–15). For most Annex III systems, this is an internal conformity assessment — you conduct it yourself, document it, and sign an EU Declaration of Conformity under Article 47. For Annex I product-embedded systems, a notified body must be involved.

The assessment does not disappear after market placement. Article 43(4) requires a new conformity assessment when you make a substantial modification to a high-risk system already on the market.

Internal assessment is less expensive than third-party audit, but it demands rigour. Regulators can — and will — scrutinise the methodology and findings.

6. Registration (Article 49)

Before placing a high-risk AI system on the EU market (or for deployers, before deploying a high-risk system from a non-EU provider that has not registered), the system must be registered in the EU AI database. The database is a public register of high-risk AI systems and their providers.

Providers who invoke the Article 6(3) filter (claiming their Annex III system is not actually high-risk) must also register their assessment of why the system falls outside the high-risk tier.

7. Post-Market Monitoring (Article 72)

Providers must establish and maintain a post-market monitoring system that actively collects and analyses data on system performance after deployment. This feeds back into the Article 9 risk management cycle. Where post-market data reveals a serious risk, Article 73 requires notification to competent authorities.

Post-market monitoring is not passive logging. It requires defining in advance what metrics you will track, at what frequency, and what thresholds trigger remedial action or a new risk assessment cycle.

---

Deployer Obligations: What You Must Do When You Use a High-Risk AI System

Most SMBs are deployers — they use AI systems built by someone else. The deployer obligation set under Article 26 is lighter than the provider stack, but it has genuine teeth.

Use the System as Instructed

Article 26 requires deployers to use the system strictly in accordance with the provider's instructions for use. Repurposing a recruitment AI (designed to screen CVs) to evaluate existing employees' performance without the provider's authorisation violates this obligation and may trigger the Article 25 role-shift: if you modify the system's intended purpose, you become the provider for that new use case and inherit the full provider stack.

Ensure Human Oversight Is Genuine

The AI literacy requirement under Article 4 (already in force since 2 February 2025) requires providers and deployers to take measures to ensure relevant staff have sufficient AI literacy — an understanding of the AI systems they work with and the Act's requirements. Article 4 is not aspirational; it is a live obligation.

Under Article 26, the person(s) overseeing a high-risk AI system must have documented competence and explicit authority to override the system's outputs. This means: specific training records, written delegation of authority, and a process for escalation when the system produces anomalous results. Generic "AI awareness" training does not satisfy the requirement for systems making decisions about individuals' rights.

Monitor Performance and Report Incidents

Article 26 requires deployers to monitor system performance in real-world conditions and report serious risks or malfunctions to the provider. Where the incident constitutes a serious incident (as defined in Article 3), the deployer may also need to notify competent authorities. Maintain logs of anomalous outputs, user complaints, and override decisions — these are the evidence base for any enforcement inquiry.

Fundamental Rights Impact Assessment (Article 27)

If you are a public body, a private entity providing public services, or a private entity deploying high-risk AI in any of the following areas — employment, credit and insurance, essential services, law enforcement, border management, justice, or democratic processes — you must complete a FRIA before first deployment.

The FRIA must document: how the system could affect fundamental rights (privacy, non-discrimination, access to justice, freedom of expression); what mitigation measures are in place; who was consulted; and how you will monitor ongoing impact. It is a living document — update it if the use case changes or new risks emerge.

An SMB running a payroll platform and using AI to flag anomalous payment patterns (adjacent to employment monitoring) should assess whether Article 27 applies to their deployment. When in doubt, document the assessment either way.

Record-Keeping: Minimum Three Years

Article 26 requires deployers to keep records of their use of the high-risk system. The minimum retention period under the Act is three years, though sector-specific law (data protection, financial services) may impose longer requirements.

Records that regulators will request: deployment decisions and their rationale, human oversight logs (including overrides), incident reports and corrective actions, FRIA documentation and updates, and training records for oversight personnel. Store these centrally with access controls and version history — not scattered across email threads.

---

Transparency Obligations for Limited-Risk and High-Risk Systems (Article 50)

Transparency under Article 50 operates at two levels depending on your system's risk tier.

For limited-risk systems (chatbots, synthetic media, emotion recognition, AI-generated content): disclosure is the full obligation. Users must be informed they are interacting with AI before the interaction begins, unless this is obvious from context. AI-generated synthetic audio, images, or video must be labelled as machine-generated. This is not a vague requirement — it means a disclosure statement at the point of engagement, not buried in a footer.

For high-risk systems (Annex III): transparency obligations are more substantive. Under Article 13, providers must ensure the system's outputs are interpretable by deployers. Under Article 26, deployers must inform individuals when a high-risk AI system has materially contributed to a decision that affects them. In employment screening, this means informing candidates that AI was used in evaluating their application — before the process concludes, not after.

The right to an explanation of an individual decision under Article 86 adds a further dimension: individuals affected by high-risk AI decisions in areas such as employment, credit, insurance, and essential services can request a meaningful explanation of the logic behind the decision. Your system design and documentation must be capable of supporting that explanation.

Common mistake: A generic disclosure — "This decision involved AI" — does not satisfy the requirement. Regulators expect context-specific information calibrated to the decision's impact on the individual and their actual ability to understand it.

---

General-Purpose AI Models: What SMBs Need to Know (Articles 51–55)

Most SMBs do not develop GPAI models — they use them via API. But the obligations are worth understanding because they affect what your GPAI provider must give you.

All GPAI model providers (Article 53) must maintain technical documentation, provide downstream information to deployers, publish a copyright policy, and make available a summary of training data. If you build on top of a GPAI model (embedding it in a product), your provider should be giving you the documentation you need to satisfy your own obligations.

GPAI models with systemic risk (Article 51 — those trained with more than 10^25 floating-point operations, or designated by the AI Office) must also conduct model evaluations, implement risk mitigation, and report serious incidents (Article 55). The fine for non-compliance with GPAI obligations is up to €15 million or 3% of worldwide turnover, imposed by the Commission (Article 101).

As a deployer or downstream builder: verify that your GPAI provider has met its Article 53 obligations before building on their model. If they cannot produce technical documentation and a training-data summary, that is a supply chain risk.

---

Technical Documentation and Record-Keeping: A Practical Five-Step Process

Step 1: Inventory Your AI Systems

Before any documentation work, list every AI system your organisation develops or uses. Include: vendor-supplied tools, embedded features in SaaS products you purchase, custom-built models, and anything using machine learning for automated decision-making. Classify each one using Article 6 and Annex III. Document the classification rationale in writing — including where you conclude a system is not high-risk and why.

Step 2: Build the Annex IV Technical File for Each High-Risk System

Annex IV specifies the minimum content that providers must document. The file is the evidence that your system meets the Chapter III requirements. For a 40-person HR-tech firm with a CV-screening tool, the technical file should include: the intended purpose statement, training data description (volume, sources, known gaps and how they were addressed), validation and testing results with demographic breakdowns, bias assessment methodology and findings, model architecture description, and the Article 9 risk register with mitigation evidence.

This is not a marketing document. Write it for a regulator who is actively looking for gaps.

Step 3: Compile the Article 9 Risk Register

Separate from (but cross-referenced with) the technical file, maintain a risk register that tracks each identified harm, its likelihood and severity rating, the mitigation applied, and the residual risk. Version-control it. When post-market monitoring surfaces new failure modes, update the register and document the date and trigger.

Step 4: Document Human Oversight Arrangements

For each high-risk system, record: who is responsible for oversight, what training they have received, what authority they hold, and how override decisions are logged. This is the deployer's primary documentation obligation and the first thing an authority will ask for in an investigation involving a disputed AI decision.

Step 5: Establish a Retention and Access Schedule

Technical documentation: retain for the system's operational life plus ten years. Risk assessments: same. Incident logs and oversight records: three years minimum; longer where sector law requires. FRIA: three years minimum from last update.

All records must be retrievable on short notice. Organise them as a single auditable package, not scattered across personal drives. Regulatory requests come with short deadlines.

---

Industry Compliance Snapshots

Different sectors face different Annex III exposure. These sketches illustrate where the obligations bite hardest.

Fintech: Credit Scoring and Loan Decisions

Credit scoring and creditworthiness assessment is explicitly listed in Annex III, Section 5. If your fintech uses AI to contribute to lending decisions, you are high-risk. The human oversight requirement under Article 14 means your compliance officer must be able to interrogate why the model assigned a given score — not just review the output number. Build the explanation capability into the model before deployment; retrofitting is expensive.

Affected individuals have a right under Article 86 to request an explanation of the specific decision. Design your appeal workflow before launch.

Healthcare: AI-Supported Diagnosis

AI systems supporting clinical diagnosis are high-risk under Annex III, Section 2 (critical infrastructure) and may also intersect with medical device regulation (Annex I, MDR). Clinical validation is a prerequisite — statistical accuracy on a held-out dataset is not the same as validated performance in real clinical workflows. Clinicians must retain full authority to override the system; document this explicitly in both the technical file and the oversight arrangements.

Recruitment: CV Screening and Candidate Ranking

Automated CV screening is Annex III Section 4 high-risk. Candidates must be informed that AI is used in their evaluation (Article 13 / Article 26). Under Article 14, your HR team must have the competence and authority to override shortlists. Under Article 27, if your organisation deploys this tool rather than builds it, you likely need a FRIA. Log which candidates were processed by the system and maintain those records for at least three years.

The specific risk to watch: proxy discrimination. A model trained on historical hiring data from a male-dominated organisation will encode historical bias unless this is explicitly addressed in the Article 10 data governance assessment.

EdTech: Automated Assessment and Grading

Automated grading and student assessment falls under Annex III Section 3. For high-stakes assessments (final exams, degree classifications), educators must have the competence and authority to verify and override AI-generated grades before they are finalised. Students and parents are entitled to understand how AI contributed to the assessment. Document your validation study and human review workflow before deploying.

Law Enforcement and Security: Where Smaller Businesses Intersect

Most SMBs do not operate in law enforcement. But two situations create unexpected exposure: premises security using biometric identification (Annex III Section 1), and predictive analytics tools sold to or used by law enforcement (Annex III Section 6). Emotion recognition in the workplace is prohibited under Article 5 regardless of the size of the organisation deploying it. Audit your physical security and HR monitoring tools against this list.

---

Penalties: What the Fines Actually Are

The old articles circulating online often misstate the penalty figures. Here are the correct numbers from Article 99.

Three tiers, "whichever is higher" of the fixed sum or the percentage of worldwide annual turnover:

The SME/start-up protection (Article 99(6)): For SMEs and start-ups, the fine is capped at the lower of the percentage and the fixed sum, rather than the higher. For a startup with €1.5 million turnover, the effective ceiling for a high-risk violation is €45,000 (3% × €1.5M), not €15 million. This is a genuine proportionality measure — not an exemption from the law, but a significant constraint on the fine calculation. Note it in your risk register when assessing compliance investment decisions.

GPAI-specific fines (Article 101): the Commission can impose fines of up to €15 million or 3% on GPAI model providers.

What regulators can do beyond fines: National competent authorities can order suspension of a system from the EU market, require immediate corrective action, and refer cases for criminal investigation where member state law provides for it. Non-cooperation — refusing to provide documentation or obstructing an inspection — is itself a violation carrying fines up to €15 million or 3%.

---

Compliance Roadmap for SMBs: Six Practical Steps

Step 1: AI Literacy and Prohibited Practices Audit (Do This Now — Already Overdue)

Both Article 4 (AI literacy) and Article 5 (prohibited practices) have been in force since 2 February 2025. If you have not done these, you are currently non-compliant.

AI literacy: identify every role in your organisation that works with AI systems and document what training they have received on those systems' capabilities, limitations, and the Act's requirements. This does not need to be expensive — a structured internal briefing with records is a starting point.

Prohibited practices: audit every AI system you develop or deploy against the Article 5 list. Any system that performs real-time biometric identification in public spaces, uses emotion recognition in the workplace, or applies subliminal manipulation techniques must be discontinued immediately. Document your assessment for any system that was reviewed and cleared.

Step 2: Build Your AI Inventory

List every AI system your organisation develops or uses. For each one: name it, describe its function, identify the vendor or internal team, note the data it processes, and record your initial view of its risk tier. This inventory is the foundation for everything that follows and is itself evidence of compliance due diligence.

Step 3: Classify Each System Under Article 6

For each system in your inventory, work through the Article 6 classification: does it function as a safety component in an Annex I product? Does it fall within any of the eight Annex III headings? If it falls within an Annex III heading, does it pass the Article 6(3) filter (is there no significant risk of harm)? Does it profile natural persons? Document the classification and the reasoning in writing.

If you are a deployer using a third-party high-risk tool, your provider should have classified it and can provide documentation. Verify this before deployment — you cannot outsource the compliance obligation, only the classification work.

Step 4: Determine Your Role

For each high-risk system, determine whether you are the provider, deployer, both, or whether Article 25 role-shift applies. If you are the provider, begin the Article 11 technical documentation file and the Article 9 risk register. If you are the deployer, begin documenting your oversight arrangements and assess whether Article 27 FRIA applies.

Step 5: Build Documentation for High-Risk Systems (Target: 2027, but Start Now)

The Annex III deadline is 2 December 2027, but technical documentation, risk management systems, bias testing, and conformity assessments take time. A realistic minimum for a stand-alone Annex III system is 4–6 months of structured work for a small team. For product-embedded systems (Annex I), budget 9–12 months and a notified body engagement.

Confir provides a self-serve, rule-based compliance workflow that classifies your systems under Articles 5 and 6 using Annex III logic, generates the Annex IV technical documentation pack, runs the Article 27 FRIA for deployers, and maintains the risk register — from €600/year. The logic is deterministic and reproducible: the same inputs produce the same classification, every time, without relying on AI inference. For SMBs without a dedicated compliance team, this closes the gap between knowing what is required and having the documentation to prove it.

Step 6: Implement Article 50 Transparency Before August 2026

For any chatbot, synthetic media tool, or AI-generated content system you deploy or build, implement the Article 50 disclosure requirement before 2 August 2026. This is typically a low-cost change — a disclosure statement before interaction begins and a labelling convention for AI-generated content. Do not defer it to the last month.

---

Common SMB Compliance Mistakes

Assuming your vendor handles compliance. Under Article 25, responsibility follows the system. If you deploy a high-risk system, you have deployer obligations regardless of what your vendor promises in their terms of service.

Treating AI literacy (Article 4) as optional. It has been in force since February 2025. Your oversight staff must have documented AI literacy appropriate to the systems they work with.

Using the Article 6(3) filter without documenting it. Claiming a system is not high-risk under the filter requires a documented assessment and registration. The exemption is not self-executing.

Treating technical documentation as a one-off project. Article 11 documentation and the Article 9 risk register must be updated when the system is modified, when post-market monitoring reveals new risks, and when the use case changes. Build a review cycle into your operational calendar.

Misreading the FRIA trigger. Article 27 applies to private-sector deployers in specific areas — not just public bodies. If you deploy AI in employment, credit, insurance, or essential services, assess whether Article 27 applies before your first live deployment.

Ignoring the Art 25 role-shift. Rebranding, fine-tuning, or repurposing a third-party high-risk system can make you the provider. Review your contracts and deployment configurations before making changes.

---

How Confir Supports SMB Compliance

Most SMBs do not have a dedicated compliance team, and the documentation requirements under Articles 9, 11, 14, and 27 are not light. Confir is a self-serve EU AI Act compliance tool built specifically for SMB legal, compliance, and IT teams.

The classification workflow uses rule-based, deterministic logic — not AI inference — to work through Articles 5 and 6, applying Annex III criteria via plain-English questions. The same intake produces the same finding every time, which makes it audit-defensible. Outputs include the Annex IV technical documentation pack, the Article 47 Declaration of Conformity, the Article 27 FRIA, and an organisation-wide risk register with an immutable audit log. It maps to ISO/IEC 42001 and GDPR where relevant. Pricing starts at €600/year with no enterprise sales cycle.

---

Frequently Asked Questions

Does the EU AI Act apply to my SMB if we're not based in the EU?

Yes. Article 2 establishes extraterritorial scope: the Act applies to any organisation placing AI systems on the EU market or using them to serve EU residents, regardless of where the company is registered. A US-based HR-tech startup selling a CV-screening tool to European employers is subject to the same Article 16 provider obligations as an equivalent firm in Berlin. There is no exemption for foreign entities. If your system affects even one EU resident's rights or safety in a regulated context, full compliance is required.

How do I know if my AI system is high-risk under Annex III?

Work through Article 6 methodically. First: does your system function as a safety component in an Annex I product (machinery, medical devices, lifts, etc.)? If yes — Annex I track, deadline 2 August 2028. Second: does the system fall within any of the eight Annex III categories (biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, justice)? If yes — check the Article 6(3) filter. If the system profiles natural persons, the filter does not apply and it is high-risk. If it falls within Annex III but does not pose a significant risk of harm and does not profile individuals, document the assessment and register it. Automated CV screening, credit scoring, and biometric identification are high-risk without exception.

What is the difference between a provider and a deployer, and which obligations apply to me?

A provider (Article 16) develops or places the system on the market under its own name. A deployer (Article 26) uses a high-risk system in professional operations. Providers carry the heavier load: risk management system (Article 9), technical documentation (Article 11), human oversight by design (Article 14), conformity assessment (Article 43), registration (Article 49), and post-market monitoring (Article 72). Deployers must ensure human oversight is genuine, monitor real-world performance, keep records, and in specific contexts run a FRIA (Article 27). Many SMBs are both simultaneously — a fintech building and deploying its own credit-scoring model must satisfy both tracks. Article 25 means role boundaries are not fixed: modify a third-party system's intended purpose and you become its provider.

When do the key deadlines apply?

Article 5 prohibited practices and Article 4 AI literacy have been in force since 2 February 2025 — if you have not addressed these, you are already overdue. Article 50 limited-risk transparency obligations apply from 2 August 2026. Under the Digital Omnibus agreed May 2026, the Annex III high-risk deadline is now 2 December 2027 for stand-alone systems (previously 2 August 2026), and 2 August 2028 for high-risk AI embedded in Annex I products. The extension does not reduce documentation requirements — it gives you more time to meet them properly.

What are the actual fine amounts, and does the SME cap apply to my business?

Article 99 sets three tiers: €35 million or 7% of worldwide annual turnover for Article 5 violations; €15 million or 3% for most other obligations including high-risk requirements; €7.5 million or 1% for supplying incorrect information to authorities. In each tier, the applicable fine is whichever of the fixed sum or the percentage is higher — except for SMEs and start-ups, where Article 99(6) applies the lower figure. For a company with €2 million annual turnover, the effective ceiling for a high-risk violation is €60,000 (3%), not €15 million. This is the single most misunderstood provision in the Act for SMB audiences.

What documentation do I need to maintain?

Providers of high-risk systems must maintain an Annex IV technical documentation file (Article 11) covering system design, training data, testing results, and limitations — retained for the system's lifetime plus ten years. Article 9 requires a live risk register with documented mitigation measures. Article 72 requires post-market monitoring records. Deployers must maintain oversight logs, incident records, corrective action records, and FRIA documentation (Article 26) for a minimum of three years. All records must be retrievable on short notice; regulatory requests come with tight deadlines.

What happens if I don't comply?

Beyond the fine ceilings listed above, competent authorities can order your system removed from the EU market immediately and require corrective action. Affected individuals can pursue civil claims under Article 82. Refusing to cooperate with an investigation — failing to produce documentation, obstructing an inspection — is itself a separate violation. Non-compliance is not a business risk to be managed financially; at the high-risk tier, it can mean being locked out of the EU market entirely.

---

Related guides

• compliance software comparison
• Article 17 quality management requirements
• Article 16 provider obligations
• AI governance software solutions