← All posts

EU AI Act compliance: a practical guide for SMEs

If your business develops, deploys, or distributes an AI system that reaches the EU market, Regulation (EU) 2024/1689 — the EU AI Act — very likely applies to you, regardless of where your company is based. The single most useful thing you can do right now is run the EU AI Act Compliance Checker, the official non-binding tool from the AI Act Service Desk, and save the output. That output is your first piece of audit evidence.

The Act targets risk and market access, not geography. A UK-registered SaaS business selling an AI-powered recruitment tool to German employers is in scope. An Irish developer embedding a third-party general-purpose AI (GPAI) model into a customer-facing product is in scope. The European Commission's AI Office and national market surveillance authorities are the bodies that enforce it, and their powers include requesting datasets, source code, and training logs. The compliance checker output is informational, not legal advice, so for complex cases you should seek independent legal counsel.

Key takeaways

The EU AI Act applies based on risk and market access, not company location. If your AI system reaches the EU market, you are in scope regardless of where your business is registered.

Point Details
Scope is market-based Any AI system placed on or used in the EU market is in scope, including systems from UK-registered businesses.
Start with the official checker Run the EU AI Act Compliance Checker first and save the dated output as your initial audit evidence.
High-risk obligations are substantial Providers of high-risk systems must complete technical documentation, conformity assessment, CE marking, and EU database registration before deployment.
Staggered dates matter Most high-risk obligations apply from 2 August 2026; prohibited practices have been enforceable since 2 February 2025.
ShieldIQ automates readiness ShieldIQ's platform covers risk registers, evidence management, gap analysis, and audit-ready reporting for SMEs managing EU AI Act obligations.

Table of Contents

Your 30/60/90-day EU AI Act readiness checklist

Getting to a defensible compliance position does not require a full legal team. It requires a structured plan and consistent execution. Here is a time-bound checklist designed for small teams.

Days 1–30: discover and classify

  • Run the EU AI Act Compliance Checker for every AI system your business develops, deploys, or procures. Save each output as a dated PDF.
  • List every AI system in a central register: name, version, intended purpose, inputs, outputs, and the EU markets it touches.
  • Identify your role for each system: provider, deployer, importer, or distributor (definitions in the obligations section below).
  • Flag any system that could be high-risk or prohibited based on the checker output.
  • Designate one named person as your AI compliance lead, even if it is a part-time responsibility.

Days 31–60: document and control

  • For any high-risk system, begin drafting technical documentation using the Act's Annex IV structure.
  • Start a risk register with at minimum: system name, risk tier, identified risks, mitigations, and review date.
  • Audit vendor contracts for AI tools you procure: check for technical documentation access, incident notification obligations, and audit rights.
  • Map your AI systems to your existing GDPR data processing records. The two frameworks overlap significantly.

Days 61–90: test, monitor and iterate

  • Run a gap analysis against the obligations for your highest-risk system.
  • Establish a basic post-market monitoring process: who reviews model performance, how often, and what triggers an incident report.
  • Document your conformity assessment approach for any high-risk system.
  • Set calendar reminders for the key application dates (see the timeline section below).

Pro Tip: Document every assumption you make during the classification process, not just the final answer. If a regulator later questions your scope decision, your reasoning trail is as valuable as the checker output itself.

Your 30/60/90-day EU AI Act readiness checklist — overview diagram

How to check whether the EU AI Act applies to a specific system

The scope question is not always obvious, particularly for systems that combine AI with conventional software. Follow these steps for each system in your inventory.

  1. Define the intended purpose. Write one sentence describing what the system does and who it does it for. The Act's scope turns heavily on intended purpose and the context of use, not the underlying technology.

  2. Map inputs and outputs. Identify what data goes in (text, images, biometric data, sensor feeds) and what the system produces (decisions, recommendations, classifications, generated content). High-risk designations often hinge on output type and downstream effect.

  3. Identify EU market exposure. Ask: is this system placed on the EU market, put into service in the EU, or used by people in the EU? If yes to any of these, the Act's territorial scope is engaged regardless of where your company is registered.

  4. Run the official Compliance Checker. Go to the EU AI Act Compliance Checker and work through the guided questions. The tool classifies your system against the Act's risk tiers and flags which obligations may apply. It is non-binding and its outputs are for informational purposes only.

  5. Cross-reference with the AI Act Explorer. The Artificialintelligenceact AI Act Explorer lets you navigate the Act's text by article and search for specific use-case scenarios. Use it to verify the checker's output against the primary text.

  6. Record your answers and rationale. Save the checker output, note the version date of the tool, and write a brief rationale for any borderline decisions. This record is the foundation of your audit trail.

Pro Tip: Re-run the checker whenever you make a material change to a system's purpose, training data, or output type. A system that was minimal-risk at launch can cross into high-risk territory after an update.

What the risk categories mean and the obligations that follow

The AI Act's risk-based framework places every AI system into one of four tiers. Obligations scale sharply as risk increases.

Unacceptable risk (prohibited)

These practices are banned outright. Examples include real-time remote biometric identification in public spaces for law enforcement (with narrow exceptions), social scoring by public authorities, and AI systems that exploit psychological vulnerabilities to manipulate behaviour. If your system falls here, it cannot be placed on the EU market at all.

High risk

This is the category that demands the most preparation from SMEs. High-risk systems include AI used in recruitment and employment decisions, credit scoring, critical infrastructure management, educational assessment, and certain law enforcement applications. The obligations are substantial.

Obligation What it requires
Risk management system Documented, iterative process covering the full system lifecycle
Technical documentation Annex IV-structured record of design, training data, performance, and limitations
Data governance Controls over training and validation datasets, including provenance records
Human oversight Technical measures enabling human intervention and override
Conformity assessment Self-assessment or third-party audit confirming the system meets Act requirements
CE marking Affixing the CE mark to signal conformity before EU market placement
EU database registration Entry in the EU database for high-risk AI systems before deployment
Post-market monitoring Ongoing performance tracking and incident reporting pipeline

Transparency obligations

Systems that interact with humans (chatbots, deepfake generators, emotion-recognition tools) must disclose their AI nature to users. The obligation is relatively light but non-negotiable: users must know they are interacting with an AI system.

Minimal or no risk

The vast majority of AI applications fall here: spam filters, recommendation engines, most productivity tools. No specific obligations apply, though voluntary codes of conduct are encouraged.

A note on open-source models: exemptions for open-source AI exist under Articles 2(12) and 53(2) of the Act, but they are narrow. They do not apply where a system is high-risk, engages in a prohibited practice, or is subject to Article 50 transparency obligations. Do not assume open-source status removes your obligations without checking.

Who must do what: obligations for providers, deployers, importers and distributors

Your obligations under the Act depend entirely on your role. The same business can hold multiple roles simultaneously, which is a common trap for SMEs.

Provider means any natural or legal person that develops an AI system (or has one developed) and places it on the EU market or puts it into service under their own name or trademark. Providers of high-risk systems carry the heaviest obligations: they must implement the full risk management system, produce Annex IV technical documentation, conduct a conformity assessment, affix CE marking, and register the system in the EU database.

Deployer means any person that uses a high-risk AI system under their own authority in a professional context. They do not need to repeat the provider's conformity assessment, but they do need to keep their own operational records.

Importer means any EU-established person that places a high-risk AI system from a third country on the EU market. Importers must verify that the provider has completed the conformity assessment and that the CE marking and technical documentation are in order before placing the system on the market.

Distributor means any person in the supply chain (other than the provider or importer) that makes a high-risk AI system available on the EU market. Distributors must verify CE marking and documentation before distribution and must not make the system available if they have reason to believe it is non-compliant.

Contract clauses SMEs should request from vendors

SMEs frequently miss simple contract clauses that preserve their audit rights. When procuring AI tools from third-party vendors, request the following in writing:

  • Access to Annex IV technical documentation on request
  • Incident notification within a defined and reasonable timeframe
  • Audit rights permitting your team or a third party to inspect the system's compliance records
  • Confirmation of the vendor's role (provider or deployer) and their EU authorised representative if they are based outside the EU
  • Notification of any substantial modification that could affect the system's risk classification

Common SME role scenarios

For a SaaS provider deploying an AI-powered HR screening tool to EU clients: you are the provider. All high-risk obligations sit with you, including CE marking and EU database registration.

For a developer embedding a third-party GPAI model (such as an API-based large language model) into a customer-facing product: you are likely a deployer of the GPAI model and a provider of the downstream application. Your obligations depend on whether the downstream application is high-risk.

For an AI consultancy delivering a custom model to an EU client who then deploys it: the client becomes the provider if they place it on the market under their own name. Your contract should clarify this explicitly, including who holds the technical documentation.

Key dates, staggered application and transitional rules you must know

The Act does not apply all at once. The phasing is deliberate, and for most SMEs it is genuinely useful planning time — provided you use it.

Key application milestones:

  • 2 February 2025: Prohibited practices (unacceptable risk) became enforceable. If your system falls into this category, it should already be off the EU market.
  • 2 August 2025: GPAI obligations and governance provisions became applicable. Providers of general-purpose AI models must comply with transparency and copyright rules from this date.
  • 2 August 2026: The main body of obligations for high-risk AI systems (Annex III) and most other provisions apply from this date, per the Commission's implementation guidance.
  • 2 August 2027: High-risk AI systems that are also safety components of products covered by existing EU harmonisation legislation (Annex I) have an extended transition period.

Transitional rules under Article 111:

Article 111 provides that AI systems already placed on the market or put into service before 2 August 2026 have a transitional period running to 2 August 2027 (or 2 August 2030 for Annex I product-embedded systems). However, this protection falls away if you make a substantial modification to the system. The implementation guidance clarifies that a substantial modification is one that changes the system's intended purpose, affects its performance in a way that requires re-evaluation, or introduces new risks. Frequent release cycles are therefore a compliance trigger, not a safe harbour.

Date What becomes enforceable
2 February 2025 Prohibited AI practices
2 August 2025 GPAI model obligations; governance structures
2 August 2026 High-risk AI (Annex III); most remaining provisions
2 August 2027 Transitional period ends for most pre-existing systems; Annex I product-embedded systems
2 August 2030 Extended transition for Annex I systems under certain conditions

Pro Tip: If you are planning a significant product update, check whether it constitutes a substantial modification under Article 111 before you release it. A change-control log that records this assessment for every release is a low-cost way to protect your transitional status.

Key dates, staggered application and transitional rules you must know — overview diagram

How enforcement works and what regulators can request

The Act uses a hybrid enforcement model, and understanding it matters for cross-border businesses. The AI Office holds sole authority over GPAI model providers and can request access to models, conduct evaluations, and impose fines. National market surveillance authorities handle high-risk AI systems within their own Member States, coordinating cross-border cases through the European AI Board.

Market surveillance authorities have broad investigatory powers. They can request:

  • Technical documentation and conformity assessment records
  • Access to training datasets and validation data
  • Source code and model weights where necessary to assess compliance
  • Training logs, performance metrics, and post-market monitoring reports
  • Incident reports and corrective action records

Where a system is found non-compliant, authorities can require corrective measures, restrict or prohibit market access, and in serious cases order a recall.

National authorities can also accept complaints from any natural or legal person, which means a competitor, a user, or a civil society organisation can trigger an investigation. Transparent record-keeping and a rapid response framework are not optional extras for small teams — they are the difference between a manageable inquiry and a protracted investigation.

Audit-readiness evidence checklist

Keep the following records accessible and version-controlled:

  • Dated compliance checker outputs for each system
  • Annex IV technical documentation (current and prior versions)
  • Risk register with dated entries
  • Dataset provenance records (source, collection date, pre-processing steps)
  • Training logs and model performance metrics
  • EU declaration of conformity and CE marking records
  • EU database registration confirmation
  • Incident reports and corrective action logs
  • Post-market monitoring reports

Retain records for a minimum of ten years after the system is placed on the market, which is the period specified in the Act for high-risk systems. Store them in a centralised, access-controlled location rather than across individual team members' drives.

Practical compliance-by-design steps for small teams

Retrofitting compliance documentation after a system is deployed costs significantly more time and money than building it in from the start. The EU's regulatory framework guidance explicitly supports a compliance-by-design approach. Here is how a team of one or two people can implement it without hiring a dedicated compliance officer.

Phase 1: discovery and classification

  1. Create a central AI system register in a shared document or GRC tool. Record system name, version, purpose, inputs, outputs, EU market exposure, and initial risk classification.
  2. Run the official Compliance Checker for each entry and attach the output.
  3. Assign a risk tier to each system and flag those requiring further action.
  4. Identify your role (provider, deployer, importer, distributor) for each system.

Phase 2: implement minimal controls and documentation

  1. For high-risk systems, draft a risk management plan covering identified risks, mitigations, and review schedule.
  2. Produce a model card for each AI system: a one-to-two page summary of purpose, training data sources, known limitations, and performance benchmarks.
  3. Add dataset provenance tags to your data pipeline: who collected the data, when, from what source, and what pre-processing was applied.
  4. Implement a human oversight mechanism, even a simple one: a review step before high-stakes outputs are acted upon, with a log of who reviewed and when.
  5. Draft transparency notices for any system that interacts directly with end users.

Phase 3: test, monitor and iterate

  1. Schedule quarterly reviews of model performance against the metrics recorded at deployment.
  2. Define what constitutes a reportable incident and document the reporting path (who notifies whom, within what timeframe).
  3. Build a change-control log that captures every material update and records whether it constitutes a substantial modification under Article 111.
  4. Integrate basic compliance checks into your CI/CD pipeline: automated flags when a model update changes its intended purpose or performance profile.

For AI Act cybersecurity controls that support these phases, including technical measures for data integrity and access control, ShieldIQ's blog covers the intersection of the Act's requirements and practical security architecture.

Minimal metadata fields to capture for each model:

  • Model name and version
  • Intended purpose and use context
  • Training dataset sources and collection dates
  • Pre-processing and augmentation steps
  • Model architecture and key hyperparameters
  • Validation and test results (accuracy, fairness metrics, error rates)
  • Known limitations and failure modes
  • Responsible person and review date

Official tools and resources: what to open first

The European Commission has published several tools and guidance documents that are genuinely useful for SMEs. Here is what each one delivers and where to start.

  • EU AI Act Compliance Checker (AI Act Service Desk / European Commission): a guided questionnaire that classifies your system against the Act's risk tiers. Non-binding, but the fastest way to get an initial scope assessment. Available to any organisation, including those based outside the EU. Start here.

  • AI Act Explorer (artificialintelligenceact.eu): a searchable, article-by-article navigation tool for the Act's full text. Useful for verifying checker outputs against the primary legislation and for locating specific obligations by article number.

  • Regulation (EU) 2024/1689 (EUR-Lex): the authoritative legal text. Bookmark Annex III (high-risk system categories), Annex IV (technical documentation requirements), and Article 111 (transitional provisions).

  • AI Office pages (European Commission): covers GPAI enforcement, the AI Office's powers, and the hybrid enforcement model. Essential reading for any business working with foundation models or GPAI APIs.

  • ShieldIQ EU AI Act compliance platform: for SMEs that need automated evidence management, gap analysis, and audit-ready reporting rather than manual document management. Covers the Act alongside GDPR, NIS2, ISO 27001, and ISO 42001.

For EU organisations, all of the above are directly applicable. For businesses based in the UK or elsewhere, the official tools are equally accessible and equally relevant if your systems reach the EU market.

Research insights: where SMEs typically fall short

The most common compliance gaps are not technical. They are organisational. Based on official guidance and enforcement framework analysis, three patterns recur consistently.

Insufficient documentation at the point of audit. Regulators can request technical documentation, training logs, and dataset records at any time after a system is placed on the market. Many SMEs produce documentation reactively, after a request arrives, which is both slower and less credible than maintaining a live record. The enforcement framework makes clear that authorities expect documentation to exist, not to be created in response to their inquiry.

Decentralised evidence. Training logs stored on one engineer's laptop, dataset records in a shared drive folder with no version control, and conformity assessment notes in an email thread are not audit-ready. A centralised, access-controlled evidence store is effectively required to respond to regulator requests within a reasonable timeframe.

Underestimating the scope of regulator powers. Market surveillance authorities can request source code and model weights, not just summary documents. Businesses that have not considered this tend to discover it at the worst possible moment. Knowing what can be requested and having it organised in advance removes a significant operational risk.

Weak vendor contract clauses. SMEs frequently miss the contract clauses that preserve their audit rights when procuring AI tools. Adding mandatory vendor obligations for documentation access and incident notification is a high-leverage step that costs nothing to negotiate upfront and can be very costly to retrofit.

Practical controls that reduce enforcement risk:

  • Centralised evidence store with version control and access logs
  • Continuous post-market monitoring with documented review cycles
  • Documented risk management system updated at each release
  • Change-control log recording substantial modification assessments
  • Vendor contract clauses covering documentation access and incident notification

Pro Tip: Compliance-by-design is not just a regulatory preference. Building risk management and transparency controls into your development process from the start is materially more cost-effective than retrofitting documentation after deployment. The EU's own framework guidance supports this approach explicitly.

For guidance on agentic AI security considerations that intersect with GPAI supervision obligations, Alectura Labs' technical guide covers the emerging risk surface for enterprise teams working with autonomous AI agents.

How ShieldIQ helps SMEs meet EU AI Act obligations

ShieldIQ's EU AI Act compliance platform maps directly to the Act's mandatory requirements, giving small teams the structure they need without the overhead of building everything from scratch.

Platform capabilities mapped to Act obligations:

  • Automated risk register: captures system name, risk tier, identified risks, mitigations, and review dates in a structured, audit-ready format
  • Evidence management: centralised store for datasets, training logs, model cards, and technical documentation with version control and access logging
  • Gap analysis: automated assessment against Annex IV requirements and other high-risk obligations, flagging missing controls
  • Conformity assessment workflow support: guided process for completing and documenting conformity assessments
  • Audit-ready reporting: exportable reports formatted for regulator requests and internal governance reviews
  • Cross-framework controls: maps AI Act obligations alongside GDPR, NIS2, ISO 27001, ISO 42001, and DORA, reducing duplication for businesses managing multiple frameworks

SME use cases:

A small SaaS provider offering an AI-powered contract analysis tool to EU law firms uses ShieldIQ to maintain its Annex IV technical documentation, run scheduled gap analyses before each release, and export conformity records on demand.

An AI consultancy delivering custom models to EU clients uses the platform to document each model's training data provenance, performance benchmarks, and risk assessment, then transfers the relevant records to the client at handover.

A developer embedding a GPAI API into a customer-facing product uses ShieldIQ to track which GPAI model version is in use, log any changes, and maintain the transparency notices required under Article 50.

For complex legal questions about your specific obligations, seek independent legal advice. ShieldIQ handles the operational and evidential side of readiness; binding legal interpretation requires a qualified lawyer.

The compliance mistakes SMEs keep making

The pattern I see most often is businesses treating the EU AI Act as a documentation project rather than a process change. They spend a weekend producing a risk register, file it somewhere, and consider the job done. Six months later, the system has been updated three times, the documentation reflects none of those changes, and the risk register has not been opened since.

The Act's post-market monitoring requirement is not a formality. It is a live obligation. A conformity assessment completed at launch does not cover a system that has been substantially modified since. The implementation guidance is explicit on this point, and it is the area where I expect enforcement to bite hardest in the first wave of investigations.

The second mistake is assuming that because you are a deployer rather than a provider, your obligations are minimal. Deployers must monitor performance, implement human oversight, and report serious incidents. A business that uses an AI hiring tool without reviewing its outputs, logging its decisions, or maintaining any record of human review is exposed, even if the provider has completed a full conformity assessment.

The third is vendor contracts. Most off-the-shelf AI procurement agreements do not include the clauses the Act effectively requires: documentation access, incident notification, audit rights, and confirmation of the vendor's authorised EU representative. Negotiating these in at the point of procurement takes an hour. Negotiating them after an incident takes considerably longer.

ShieldIQ EU AI Act readiness: from gap analysis to audit-ready

Audit readiness for the EU AI Act does not have to mean months of consultant fees and manual documentation. ShieldIQ delivers a structured readiness package that gets SMEs from gap analysis to evidence-ready in weeks, not quarters.

ShieldIQ

The package covers automated gap analysis against the Act's high-risk obligations, a pre-built risk register and evidence management system, conformity assessment workflow support, and optional vCISO and consulting services for businesses that need expert guidance alongside the platform. Subscription plans scale by framework, module, and user count, so you pay for what you need. For businesses managing the Act alongside GDPR, NIS2, or ISO 27001, ShieldIQ's cross-framework controls eliminate the duplication that makes multi-framework compliance so time-consuming for small teams.

ShieldIQ handles the operational and evidential side of readiness. For binding legal interpretation of your specific obligations, seek qualified legal advice. To see where your gaps are right now, book a ShieldIQ assessment and get a clear picture of what needs to happen before your next release.

Sources

Save copies of any outputs or guidance excerpts you download from these sources, noting the date of access. Guidance documents are updated periodically and version-tracking matters for audit purposes.

This article provides general information about EU AI Act compliance obligations. It is not legal advice. For binding legal interpretation of your specific situation, consult a qualified legal professional and refer directly to the primary legislative text.

This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.

Recommended