How to Run an EU AI Act Readiness Assessment: A Step-by-Step Method for SMEs

An EU AI Act readiness assessment is an internal diagnostic under Regulation (EU) 2024/1689: you inventory every AI system you build or use, classify each by risk tier under Articles 5, 6 and 50, assign your legal role as provider or deployer, and gap-check the current state against the obligations that attach. The output is a scored remediation plan — what to fix, and by when.

It is not the same thing as a conformity assessment. A readiness assessment is the diagnostic you run yourself; the Article 43 conformity assessment is the regulated pre-market procedure for high-risk systems. Readiness tells you whether you even need conformity assessment, and what else applies.

The method below runs in six steps and produces three artefacts: an AI system register, a per-system classification record with role assignment, and a scored gap analysis tied to deadlines. You can run it without a legal team. Start here for the orientation layer: where to start with EU AI Act compliance.

---

What an EU AI Act Readiness Assessment Actually Is

Readiness assessment vs conformity assessment

The two are easy to confuse, and the confusion costs time. A readiness assessment is an evidence-gathering exercise across your whole AI estate; a conformity assessment is a regulated procedure for one high-risk system. The table below draws the line.

Why an SME needs one now, not in 2027

The stand-alone high-risk obligations were deferred, but three obligation sets are already enforceable: the Article 5 prohibitions (in force since 2 February 2025), the GPAI duties for general-purpose model providers (Articles 51-55, in force since 2 August 2025), and the Article 4 AI-literacy duty (in force since 2 February 2025). A high-risk technical file also takes months to assemble. Waiting until 2027 means discovering your gaps too late to close them.

What a finished assessment produces

The assessment is the bridge between "we use AI somewhere" and a defensible compliance position. When it is done you hold: (1) an AI system register, (2) a per-system classification and role record, and (3) a scored gap analysis sequenced against the timeline. Everything downstream — remediation, documentation, budget — flows from those three artefacts.

---

Step 1: Build an AI System Register

You cannot classify what you have not inventoried. The register is the foundation, and a missing register is the single most common gap in SME assessments.

What counts as an AI system

Use the Article 3(1) definition to decide what belongs in the register and what is ordinary deterministic software that does not. The definition turns on a machine-based system that infers, from input, how to generate outputs such as predictions, content, recommendations or decisions. A fixed rules engine with no inference is out of scope; a model that adapts or infers is in.

Fields every register row needs

Each row should capture, at minimum:

1. System name and short description
2. Purpose and the business function it touches
3. Where it sits — internal tool, feature inside your own product, or third-party/vendor AI
4. Who supplies it
5. Whether personal data is processed
6. The team or owner accountable for it

Don't forget embedded and third-party AI

List everything: internal tools, AI features inside your own product, and third-party AI — chatbots, CV-screening tools, analytics, code assistants. SMEs routinely miss two categories: embedded AI bundled inside a SaaS subscription, and shadow AI adopted by an individual team without procurement sign-off. The register is also a living document — Article 72 post-market monitoring and ongoing procurement mean it needs an owner and a review cadence, not a one-off spreadsheet.

---

Step 2: Classify Each System by Risk Tier

Run each system through four tiers, in order. Stop at the first that fits.

Prohibited practices - Article 5

Article 5 bans specific practices outright: social scoring, untargeted scraping of facial images, manipulative or exploitative techniques, certain biometric categorisation, and real-time remote biometric identification in public spaces. These have been prohibited since 2 February 2025. If a system matches a prohibition, the answer is not remediation — it is to stop.

High-risk: Article 6 plus Annex III

A system is high-risk if it is a safety component of, or itself is, a product covered by Annex I harmonisation legislation (Article 6(1)), or if it falls within a use case listed in Annex III (Article 6(2)) — for example employment and worker management, creditworthiness, or education.

The Article 6(3) significant-risk filter

Article 6(3) lets a system inside an Annex III category escape high-risk status if it does not pose a significant risk of harm to health, safety or fundamental rights — narrow procedural tasks, for instance. But any system that profiles natural persons is always high-risk. Document the assessment either way; the exemption is a finding you must be able to defend, not a silence.

Limited-risk transparency - Article 50 - and minimal risk

Most SME systems land here. Article 50 attaches transparency disclosures to systems that interact with people, generate synthetic content, or perform emotion/biometric categorisation. Everything else is minimal risk with no specific obligation. Record the reasoning for each classification so the result is auditable. Confir can classify each AI system by risk tier deterministically.

---

Step 3: Determine Your Role for Each System

Assign a role per system, not per company. You can be a provider of one system and a deployer of another at the same time. Misassigned roles are a top source of under-compliance.

Provider obligations - Article 16

A provider develops a system or places it on the market under its own name or trademark, and carries the heavy obligation set in Article 16 — including conformity assessment and technical documentation.

Deployer obligations - Article 26

A deployer uses a system under its own authority in a professional context, and carries the lighter Article 26 duties: follow the instructions for use, ensure human oversight, keep logs, monitor operation, and report serious incidents.

The Article 25 role-shift trap

Watch Article 25. A deployer who puts their own name or trademark on a high-risk system, makes a substantial modification, or changes its intended purpose becomes a provider — and inherits the full provider obligation set. A vendor relationship can quietly turn you into a provider if you rebrand or materially alter the tool. The table below summarises the split.

---

Step 4: Gap-Check the High-Risk Requirements

For each system classified high-risk in Step 2, gap-check the seven core obligations and mark the current state. This is where the readiness score comes from.

Risk and data foundations - Articles 9, 10

Article 9 requires a continuous risk management system that runs across the lifecycle. Article 10 requires data and data governance practices covering the training, validation and testing data sets.

Documentation and logging - Articles 11, 12 and Annex IV

Article 11 requires technical documentation whose minimum content is set out in Annex IV. Article 12 requires the system to technically allow automatic recording of events — logging — over its lifetime.

Transparency, oversight, robustness - Articles 13, 14, 15

Article 13 requires transparency and instructions for use that let deployers interpret the output. Article 14 requires the system to be designed for effective human oversight. Article 15 requires appropriate accuracy, robustness and cybersecurity.

Deployers of high-risk systems do not gap-check all seven themselves, but they must confirm the provider has met them and satisfy their own Article 26 duties — keep the role from Step 3 in view throughout.

---

Step 5: Check AI Literacy — Article 4 Is Already in Force

What Article 4 requires

Article 4 has applied to every organisation that provides or deploys AI since 2 February 2025. It is not a future deadline, and it is not limited to high-risk systems. It requires measures to ensure that staff who use or oversee AI systems have a sufficient level of AI literacy, proportionate to the organisation's context and the systems involved.

Proportionate measures for a small team

No certification standard is mandated. For an SME, documented briefings — who was trained, on what, and when — plus a short internal note on the tools in use and their limitations will satisfy proportionality. The bar is proportionate effort, not a formal qualification.

The audit footprint

Treat literacy as an audit footprint. If an incident occurs, a regulator will ask whether the staff operating the system understood what it does and when to escalate. Because Article 4 is live and low-effort, it is the quickest "Ready" status you can earn on the scorecard — close it first.

---

Step 6: Score Readiness and Plan Remediation Against the Timeline

A readiness scoring table

Score each obligation domain per system as Not started / In progress / Ready. That turns the gap-check into a prioritised plan. A worked template:

Sequencing fixes by deadline

Sequence remediation by what bites first. Article 5 prohibitions, GPAI (Articles 51-55) and Article 4 literacy are enforceable now. Article 50 content-marking and watermarking, plus the new CSAM and "nudifier" provisions, land on 2 December 2026 — a fixed calendar date.

What is live now vs deferred

The Digital Omnibus, agreed politically on 6-7 May 2026 and confirmed at COREPER around 13 May 2026, agreed to move stand-alone high-risk Annex III obligations (Article 6(2)) from 2 August 2026 to 2 December 2027, and Annex I product-embedded high-risk (Article 6(1)) from 2 August 2027 to 2 August 2028. As of June 2026 this is agreed but not yet law — it still needs the European Parliament plenary vote, formal Council adoption, and Official Journal publication. The statute still reads 2 August 2026, so plan against the earlier date until the deferral is formally enacted. These are fixed calendar dates: the standards-contingent "stop-the-clock" proposal was rejected, so do not treat the timeline as conditional on harmonised standards. See the EU AI Act deadline timeline and what the Digital Omnibus delay changes.

---

What Non-Compliance Costs

Tie the readiness score to exposure: the higher the unmet obligation tier, the higher the fine ceiling.

The Article 99 penalty tiers

• Article 99(3): up to EUR 35 million or 7% of total worldwide annual turnover, whichever is higher, for breaching the Article 5 prohibitions.
• Article 99(4): up to EUR 15 million or 3% of worldwide annual turnover, whichever is higher, for most other obligations, including the high-risk requirements and deployer duties.
• Article 99(5): up to EUR 7.5 million or 1% of turnover, whichever is higher, for supplying incorrect, incomplete or misleading information to authorities.

The SME proportional cap - Article 99(6)

Article 99(6) flips the formula for SMEs and start-ups: the ceiling becomes the lower of the two figures rather than the higher. That is relief on the cap, not immunity from a fine. For the full breakdown, see the Article 99 penalty tiers.

---

How Confir helps

Confir's Risk Classification & Compliance module runs the readiness assessment as a guided, structured intake rather than a consultant engagement. The classification engine is deterministic and rule-based: the same intake answers always produce the same finding, using the same logic every time — no model inference, no hallucination — and the rule that fired is human-readable, so the result is defensible in an audit.

It assigns role (provider, deployer, or both under Article 25), classifies against Article 6 and Annex III, and produces the documented finding that becomes the register and gap-analysis evidence. For high-risk systems it scaffolds the Article 11 / Annex IV technical documentation; for limited-risk systems the documented classification itself is the primary artefact. It is the fast, repeatable way for an SME without a legal team to complete Steps 1-4 and produce the scorecard — then action the findings with the full compliance checklist.

---

Frequently Asked Questions

What is an EU AI Act readiness assessment? It is an internal diagnostic that inventories every AI system you build or use, classifies each by risk tier under Articles 5, 6 and 50, assigns your legal role as provider or deployer, and gap-checks current state against the obligations that apply. The output is a scored remediation plan showing exactly what to fix and by when.

How do I do an EU AI Act readiness assessment for a small company? Follow six steps: build an AI system register, classify each system by risk tier, determine your role per system (provider or deployer), gap-check the high-risk requirements in Articles 9 to 15, confirm Article 4 AI literacy, then score each domain and plan remediation against the deadlines. An SME can run this without a legal team using structured tooling.

Is the EU AI Act readiness deadline still 2 August 2026? As of June 2026, the statute still reads 2 August 2026 for stand-alone high-risk Annex III systems. The Digital Omnibus agreed in May 2026 to defer that to 2 December 2027, but it is not yet law — it still needs the Parliament vote, Council adoption and Official Journal publication. Plan against the earlier date until the deferral is formally enacted.

Which EU AI Act obligations apply right now? The Article 5 prohibited-practice bans have applied since 2 February 2025, the same date the Article 4 AI literacy duty took effect. GPAI model-provider obligations under Articles 51 to 55 have applied since 2 August 2025. These are enforceable now regardless of the high-risk deferral, so readiness work cannot wait for 2027.

How do I classify whether my AI system is high-risk? Check Article 5 first to rule out a prohibited practice, then test Article 6 with Annex III: a system is high-risk if it is a safety component of an Annex I product or falls within an Annex III use case such as employment, creditworthiness or education. The Article 6(3) filter can exempt narrow procedural uses, but any system that profiles people is always high-risk.

What is the difference between a provider and a deployer under the EU AI Act? A provider develops an AI system or places it on the market under its own name and carries the full Article 16 obligations. A deployer uses a system under its own authority in a professional context and carries the lighter Article 26 duties. Beware Article 25: rebranding, substantially modifying, or changing the purpose of a high-risk system turns a deployer into a provider.

What are the EU AI Act fines for non-compliance? Article 99 sets three tiers: up to EUR 35 million or 7% of worldwide turnover for breaching the Article 5 prohibitions; up to EUR 15 million or 3% for most other obligations including high-risk requirements; and up to EUR 7.5 million or 1% for giving authorities incorrect information. For SMEs and start-ups, Article 99(6) caps the fine at the lower figure rather than the higher.

---

Related guides

• Where to start with EU AI Act compliance
• Classify each AI system by risk tier
• The full compliance checklist
• The EU AI Act deadline timeline
• What the Digital Omnibus delay changes
• The Article 99 penalty tiers