Menu
08 Jun 2026 · Industry Insights · 5 min read

EU AI Act for SMEs: What Shipping AI Features Actually Requires.

The August 2026 high-risk deadline decoded for product teams: which AI features are out of scope, which need transparency, which are genuinely high-risk — and the SME carve-outs nobody mentions.

I ship LLM features for EU clients, which means I get asked about the AI Act in almost every kickoff call now. The questions usually come loaded with anxiety — "do we need a compliance officer before we can add a chatbot?" — and the honest answer is that for most SME products, the Act asks far less of you than the headlines suggest. But "less than you feared" is not "nothing", and the 2 August 2026 deadline makes this the year to sort out which bucket your features fall into.

The timeline in one paragraph

The AI Act entered into force in August 2024 and phases in over three years. The bans on prohibited practices (social scoring, manipulative systems, most real-time biometric identification) have applied since February 2025, together with an AI literacy duty for staff working with AI. Obligations for general-purpose AI model providers started in August 2025 — that one mostly concerns OpenAI, Anthropic, Mistral and friends, not you. The big date for product teams is 2 August 2026: from then, the full obligations for high-risk systems listed in Annex III apply, along with the transparency rules and the enforcement machinery with real fines.

The three buckets your features fall into

Almost every SME feature I have assessed lands in one of three buckets. Walk your feature list through this in order:

  1. Is it a prohibited practice? Emotion recognition at work, social scoring, exploitative manipulation. If yes, stop — but in five years of client work I have never seen an SME feature genuinely land here.
  2. Is it high-risk under Annex III? The list is specific: AI used in recruitment and worker management (CV screening, promotion decisions), credit scoring, insurance pricing for life and health, education admission and exam scoring, essential services eligibility, and a few public-sector categories. If your feature decides or materially influences one of these outcomes about a person, you are high-risk. A recruitment SaaS ranking applicants: high-risk. A recruitment SaaS where AI drafts the job ad: not.
  3. Does it interact with people or generate content? Then you have limited-risk transparency duties, and this is where most SME LLM features live. Users must know they are talking to an AI, not a human. AI-generated content that could mislead (synthetic media) must be disclosed and machine-readably marked. That is largely it.

Everything else — recommendation logic, internal tooling, spam filtering, code assistants, forecasting dashboards — is minimal risk. The Act imposes no obligations there beyond the general AI literacy duty.

The SME carve-outs nobody mentions

The Act was written with explicit proportionality for small companies, and if you are an SME you should actually use these:

  • Regulatory sandboxes. Every member state must run at least one AI regulatory sandbox, with priority and free access for SMEs. If you are building something genuinely close to the high-risk line, a sandbox gives you supervised testing and written guidance instead of guesswork. Finland's sandbox work sits under Traficom — worth knowing for Nordic teams.
  • Simplified technical documentation. SMEs may provide the Annex IV technical documentation for high-risk systems in a simplified form the Commission publishes as a template — you do not need a hundred-page dossier written by lawyers.
  • Proportionate fines. Penalty caps for SMEs are the lower of the percentage or the absolute amount, explicitly to avoid existential fines for small companies.

What I actually document per project

For the ordinary case — an SME product with LLM features that are limited or minimal risk — heavyweight compliance tooling is overkill. What I produce for clients is a short, living document per AI feature, versioned in the repo next to the code, typically one to two pages:

  • Purpose and classification. What the feature does, which Annex III categories were checked, and the one-paragraph reasoning for why it is or is not high-risk. This is the paragraph a regulator or enterprise customer will ask for first.
  • Model and provider chain. Which model, which API, which version pinning strategy, where inference runs (EU region or not), and a link to the provider's own AI Act documentation.
  • Transparency implementation. Where in the UI the AI disclosure lives, and how generated content is labelled — with a screenshot, because "we told users" needs evidence.
  • Human oversight points. What a human can review, override, or turn off. Even for minimal-risk features this is one honest paragraph, and it doubles as good product design.
  • Data flows and logging. What user data reaches the model, retention on both sides, and what gets logged for incident reconstruction. This section is shared with the GDPR records, which you already keep — the two regimes overlap more than they conflict.

The pattern matters more than the template: classification reasoning written down before launch is cheap; reconstructing it eighteen months later under a customer's due-diligence questionnaire is not. The community-maintained AI Act Explorer is the fastest way to check the actual article text when a question comes up.

Most SME AI features are minimal or limited risk: your obligations are honest disclosure and a page of documentation, not a compliance department. The real work is classifying each feature deliberately — once, in writing — before August 2026.

Where this bites in practice

The teams that struggle are not the ones with genuinely high-risk systems — those know who they are. It is the products drifting into Annex III territory feature by feature: the HR tool that adds "AI fit scoring", the fintech that lets the model nudge credit limits. My rule with clients: any feature that touches employment, credit, insurance or education outcomes gets classified before it is built, not after. It changes the design conversation in useful ways — often the same value ships as a decision-support feature with a human in the loop, well clear of the high-risk line. That assessment habit is now a standard part of my AI development work, the same way migrations and tests are part of my Laravel work.

Shipping AI features for EU users and unsure which bucket they fall into? I help product teams classify, document and build them properly — get in touch.

#eu ai act sme compliance #ai regulation #compliance #llm features #eu
Keep reading more from the notebook
20 May 2026 Industry Insights Interview the engineer before you sign Most agencies will never let you interview the engineer who will build your product. Here is why that matters, what to ask in 45 minutes, and the code test I would happily take myself. 16 May 2026 Industry Insights Working across a 10-hour time difference, honestly The time difference is the first question US clients ask me. The honest answer: it breaks some workflows, quietly improves others, and lives or dies on async discipline. 09 May 2026 Industry Insights What "dedicated developer" actually means when you buy it "Dedicated developer" can mean one engineer on your backlog — or a rotating seat shared across three accounts. How to tell which one you are actually buying, before you sign.

Planning something like this?

In my work I build exactly the kind of systems this post is about — Laravel, AI, and software that has to hold up in production. Tell me what you're building and I'll tell you honestly how I'd approach it.

Let's talk

Dealing with this yourself?

I have done this end to end. Tell me what is slow, broken, or blocked and I will give you an honest read on it — including if the answer is that you do not need me.

Get in touch ↗ WhatsApp +91 91175 22222 ↗ LinkedIn ↗