The SMB EU AI Act Readiness Index 2026.

The pattern. Article 4 has been enforceable since 2 February 2026: providers and deployers must ensure a sufficient level of AI literacy for staff using AI systems. The text is short, the obligation is real, and the documentation expectation is minimal — yet most SMBs cannot produce a programme, an attendance log or a refresh cadence.

What we observe. Across the EU-exposed engagements we have audited since February, the most common artefact in the literacy slot is either nothing, or a single 30-minute generic e-learning module dropped into the LMS without role-specific content or a refresh schedule. Both fail the spirit of Art. 4 and neither survives a regulator question.

Anchored against: EU AI Act Art. 4; European Commission Q&A on AI literacy (2025); ENISA 2025 SMB cyber-and-AI posture report (<20% of EU SMBs maintain a formal AI inventory, a prerequisite for targeted literacy).

So what. Stand up a role-segmented literacy programme with an attendance log and an annual refresh. The artefact does not need to be elaborate — it needs to exist, be role-relevant, and be reviewable. The 9-document SMB governance pack ships a template.

The pattern. High-risk classification under Art. 6 + Annex III triggers the bulk of the Act’s downstream work: risk-management system, data governance, technical documentation, human oversight, accuracy + robustness, post-market monitoring, conformity assessment. SMBs avoid the work by quietly classifying every system as “minimal risk” — without writing down why.

What we observe. The defensible posture is not “not high-risk” — it is “not high-risk because… [with reference to Annex III categories and the specific exclusion that applies]”. SMBs that document the rationale survive regulator and procurement questions; SMBs that don’t end up rebuilding the artefact under pressure.

Anchored against: EU AI Act Art. 6, Annex III (HR, education, credit-scoring, insurance, critical infrastructure, law enforcement, migration, justice); European Commission guidelines on prohibited practices (Feb 2026); national competent authorities now being designated under Art. 70.

So what. Write the rationale once, per AI workflow, even when the answer is “no”. Annex III is the gate — the gate must be passed and the passage logged. Treat it as a one-page artefact in the AI use register, not a 30-page bespoke memo.

The pattern. Almost every other governance obligation — literacy, Annex III rationale, FRIA, vendor DPA, post-market monitoring — depends on knowing what AI is in use, where, by whom, for what purpose. The use register is the dependency root, and it is the artefact least likely to exist on first audit.

What we observe. When we run a 30-minute Copilot Studio + Power Platform + browser-extension + shadow-SaaS sweep on a typical 100-person SMB tenant, we surface 8–15 AI-touching workflows. The buyer is usually aware of 3–5. The delta lives in connectors, browser extensions, automations and SaaS integrations that quietly call an LLM.

Anchored against: EU AI Act Art. 26 (deployer obligations); ENISA 2025 SMB report; ICO AI auditing framework (UK, an aligned reference framework for non-EU subsidiaries); CNIL “self-assessment” guidance for SMBs (FR, 2025).

So what. Build the register as a living artefact on the practice’s normal SharePoint + Power Apps stack — not a Word document. Update on every new deployment. Review quarterly. Without it, every other obligation lives on intuition.

The pattern. Article 27 requires a Fundamental Rights Impact Assessment for deployers of certain Annex III systems — most relevantly, public bodies, and private entities providing public services, when deploying high-risk AI. SMBs in education, vocational training, HR-tech, credit-scoring and insurance underwriting frequently sit in scope without realising it.

What we observe. The FRIA is short by EU-instrument standards — process description, affected categories, frequency + duration, risk-to-rights, oversight, redress. SMBs avoid it because they assume it is enterprise-scale work. It is not. But it must be done before deployment, not after.

Anchored against: EU AI Act Art. 27; European Commission template work being finalised through 2026; CNIL early guidance on FRIA scope (2025); national competent authorities expected to publish sectoral templates 2026–2027.

So what. If the workflow touches HR decisions, credit decisions, education / training access, insurance underwriting, or any public-service provision — budget a half-day FRIA per workflow at deployment, refresh annually. This is not optional for SMBs in those sectors.

The pattern. GPAI provider obligations (Art. 53) sit with the model vendor: OpenAI, Anthropic, Google, Meta, Microsoft, Mistral. Downstream obligations — transparency to users (Art. 50), human oversight (Art. 14 where applicable), use-register entry, literacy — sit with the deployer regardless of which GPAI they ride on top of. SMBs read “OpenAI is the provider” and conclude “then this isn’t my problem”.

What we observe. The cleanest test we use in audits: can the SMB show, for each GPAI-based workflow, a transparency notice to end-users where required, a use-register entry, a documented decision on Annex III applicability, and a literacy programme covering the role that uses it? If the answer is no on any of the four, the deployer obligations are not being met — irrespective of the GPAI vendor’s own compliance.

Anchored against: EU AI Act Art. 50 (transparency), Art. 53 (GPAI providers), Art. 26 (deployer obligations); European Commission GPAI Code of Practice (2025); OpenAI / Anthropic / Microsoft published transparency documentation for downstream deployers.

So what. Stop outsourcing the compliance question to the model vendor. Treat each GPAI-based workflow as your AI system, your obligation, your register entry. The vendor’s docs are a useful input, not a substitute.

The pattern. Hiring AI: AI Act (Annex III high-risk) + GDPR Art. 22 (automated decision-making) + national employment law. Credit AI: AI Act + GDPR Art. 22 + sectoral financial regulation. Healthcare AI: AI Act + GDPR + MDR (where it qualifies as a medical device). SMBs almost always engage with one regime, treating the others as someone else’s problem.

What we observe. The regimes are not contradictory but they are independently enforceable, with independent penalties and independent reporting. The practical effect: an SMB compliant with GDPR but silent on the AI Act can still be enforced against on the AI Act side, and vice versa. Documentation must address all applicable regimes, not the loudest one.

Anchored against: EU AI Act recitals on interplay with GDPR; EDPB 2025 guidance on AI Act / GDPR interaction; sectoral overlays (EBA AI guidance for credit, EIOPA for insurance, EMA + MDR for healthcare AI); ICO + CNIL coordinated statements.

So what. Run the mapping once per workflow: AI Act obligation, GDPR obligation, sectoral obligation, and the artefact that covers each. The mapping itself becomes the registrar-facing document.

The pattern. DPAs signed in 2022–2024 do not anticipate AI Act obligations. Generic “AI addenda” pasted into existing agreements rarely allocate liability between provider + deployer, rarely specify the training-data disclosure required for GPAI, and rarely commit the vendor to assist with the deployer’s Annex III rationale.

What we observe. The minimum modern clause set, in our view: provider / deployer role allocation, GPAI training-data disclosure obligation (where applicable), assistance with use-register population, assistance with FRIA, breach-and-incident notification with AI-specific triggers, sub-processor + sub-model disclosure, and right-to-audit narrowed to the AI scope.

Anchored against: EU AI Act Arts. 11–15 (provider obligations), 26 (deployer obligations); European Commission model contractual clauses for AI in public procurement (in development through 2026); BCG / EY published contract-template benchmarks.

So what. Add an AI Act clause set to the standard procurement template now. Re-paper the top five AI vendors at next renewal, not on a special project.

The pattern. Article 2 makes the Act extraterritorial. A US, UK or APAC SMB whose AI system is placed on the EU market — or whose AI output is used by recipients in the EU — is in scope. The most common surface: a SaaS product with EU customers that quietly added an AI feature in 2024–2025.

What we observe. The path-of-least-resistance fix is to designate an authorised representative under Art. 22 (for non-EU providers of high-risk systems) and complete the equivalent of the EU deployer / provider documentation. For minimal-risk systems, the obligation is lighter but the transparency + literacy provisions still bite.

Anchored against: EU AI Act Art. 2 (territorial scope), Art. 22 (authorised representative); European Commission FAQ on extraterritorial application (2025–2026); equivalent extraterritorial pattern under GDPR Art. 3.

So what. Run the territorial-scope test before assuming the Act doesn’t apply. If any meaningful EU recipient base exists, treat the workflow as in scope and document accordingly. Cheaper than discovering scope under enforcement.