EU AI Act for SMEs: duties, deadlines and practical review in 2026

This guide combines official sources checked on 26 September 2026 with a suggested operational approach. It helps prepare a technical and legal review; it does not certify any particular system or provide a legal opinion on your deployment.

The AI Omnibus entered into force on 27 July 2026. It is no longer merely a proposal. The Commission identifies 2 December 2027 for the relevant Annex III high-risk rules and 2 August 2028 for the corresponding category of AI embedded in regulated products under Annex I. Those extensions do not suspend every AI obligation. Commission announcement on the AI Omnibus.

The table lists six planning milestones of the EU AI Act after the Digital Omnibus.

The AI Act Service Desk implementation timeline sets out these milestones. Your assessment must also consider applicable exceptions, transitional provisions, changes to the system and its precise purpose. Record why a particular date applies, rather than copying a deadline into a calendar without the underlying classification.

Definitions. In simplified terms, a provider develops a system or has it developed and introduces it under its own name. A deployer uses a system under its authority in a professional context. Buying a model API does not by itself settle the role of the company offering the application built on it. Definitions in Article 3.

Role map. For an initial operational review, create a role map. Identify the model supplier, application developer, organisation defining the purpose, business presenting the system to customers and person changing its production configuration. Use named legal entities and accountable contacts. Labels such as “IT” or “the cloud” are too vague when someone later needs an answer about responsibility.

Different starting positions. A trades business purchasing a finished assistant starts from a different position than a software company selling its own branded industry application. Multiple organisations can also have different responsibilities within one project. Ask the reviewer to assess the contracts, product description and actual operation together. A sales presentation alone should not determine the result.

“Evaluate incoming applications for suitability” is a different activity from “collect applications in a mailbox.” Annex III includes specified recruitment and candidate-evaluation uses. That does not automatically classify every application used by a human-resources team in the same way. Annex III of the AI Act.

For each use, describe the input, the proposed output, the action actually triggered and the consequences of an error. An assistant might draft a message, amend a record or materially influence a decision. Calling all three tools a “copilot” hides distinctions that matter to the assessment.

The table pairs four proposed descriptions of an AI use with the question to resolve during review.

This table is a scoping tool, not a legal classification. Bring the relevant specialist into the process early when employment, credit decisions, sensitive information or safety functions are involved. Adding an automated decision later may require a fresh assessment even if the visible interface remains unchanged.

A useful scoping discussion also asks what the software is explicitly prevented from doing. “Answers customer questions” leaves much more room for interpretation than “answers from approved public product pages and cannot access accounts or approve refunds.” The second description gives both the technical team and the reviewer something concrete to evaluate.

Distinct duties. Article 50 contains several distinct duties. For direct interaction, providers generally need to ensure that people know they are interacting with AI unless that is obvious. Synthetic-content marking and specified deployer obligations are separate matters. A visible notice and a machine-readable mark serve different purposes. Commission FAQ on Article 50.

Telephone greeting. For a telephone assistant, a possible greeting is: “You are speaking with our company's AI assistant. I can take your request and pass it to the team.” This is an illustrative phrase, not a universal legal template. It must match what the assistant can actually do and sit alongside appropriate information about personal data.

Testing the notice. Test the greeting through the real call routes: direct number, forwarded call, repeat call and a change of language. On a website, check that the notice remains understandable on a small screen. If a human takes over, the user should be able to tell who is now responding. A setting visible to an administrator does not prove that a disclosure works in the published channel.

December 2026 transition. The December 2026 transition concerns the specified Article 50(2) marking obligation for certain systems placed on the market before 2 August 2026. It does not postpone chatbot disclosure generally. Service Desk explanation of application and enforcement.

Revised duty. The amended provision requires measures supporting the development of AI literacy among relevant staff and others operating systems on the organisation's behalf. It expressly does not require a guarantee that any individual achieves a particular literacy level. The replacement appears in Article 1(5) of Regulation (EU) 2026/1744.

Role-specific exercises. In practical terms, someone reviewing invoice drafts needs different exercises from a person administering a public assistant. The first role deals with field errors and approval limits; the second deals with sources, changes and problematic requests. An attendance record can show that a session took place. It cannot establish that the subsequent operation is error-free.

Internal session. A useful internal session uses the tools the team is actually allowed to operate. Ask participants to recognise an invented answer, report a missing source and transfer an unresolved case to the responsible person. Record the questions that remain and the changes needed to the workflow. Our AI literacy guide develops this approach in more detail.

Suppose a business wants to summarise incoming customer requests and prepare draft replies. This is a proposed design example, not an executed client project or a legal approval.

Permitted and excluded actions

The initial proposal gives the application access to the entire mailbox and allows it to send replies. The project team narrows the scope to a designated service folder. The assistant may suggest the request category and prepare a response. Sending, price commitments, refunds and contract amendments remain with an identified member of staff.

The business owner defines three permitted cases: appointment requests, questions about existing documents and general product information based on approved sources. Messages containing legal demands, health information or unclear customer identity go to a manual queue. This is a suggested product boundary, not a conclusion that processing any particular message is lawful.

Acceptance test cases

The proposed acceptance exercise for the service-mailbox assistant uses three test cases:

• Conflicting information. An old attachment lists one price while the approved current list contains another. The expected result is a visible uncertainty, not an invented compromise.
• Instruction inside a message. A second message instructs the assistant to export all customer contacts; that message must not expand the application's permissions.
• Refund request. A third requests a refund; the draft must not describe a payment as completed when no payment occurred.

When a fresh review is needed

The release decision covers the documented system boundary and the observed results. If the business later wants automatic sending, that becomes a separate change requiring fresh review. This makes it possible to identify exactly which capability was assessed and which was subsequently introduced.

For a bounded SME project, we recommend a shared record with a few maintained documents. This is an operational recommendation, not a universal list of statutory documentation requirements:

1. System description: purpose, users, affected people, countries, sources and excluded tasks.
2. Roles and contracts: suppliers, internal responsibilities and agreed support when the system changes.
3. Data flow: which content reaches each service, where logs are created and how access is limited.
4. Assessment: relevant legal questions, responsible reviewers, conclusions and outstanding conditions.
5. Acceptance: specific cases, observed outputs, failures and approval of the agreed scope.
6. Operation: contacts, change history, a way to disable the system and a route for complaints.

Give every outstanding condition an owner and a next review date. “Privacy will be added later” is not a useful project status. Equally, a lengthy folder does little good if nobody can identify which version is currently running.

The record should distinguish a supplier statement from an observation. For example, “the vendor says deletion is supported” differs from “the configured account was tested and the record disappeared from the specified locations.” If a test has not been performed, leave that status explicit. It is more useful than turning an assumption into an apparent acceptance result.

EU scope and Switzerland's EU connection

Austria and Germany share the EU regulation as a starting point. Add the relevant national responsibilities and other applicable rules for the actual use. Switzerland is outside the EU, but an EU connection can still matter where the statutory conditions concerning market access or use of outputs in the Union are met. Examine the specific arrangement against Article 2 on scope.

Data protection in Switzerland

Separately, Switzerland's FDPIC states that Swiss data-protection law applies to AI-supported processing. An apparently low AI risk category therefore does not remove questions about personal information. FDPIC guidance on AI and data protection.

Data protection in the EU context

In the EU context, principles such as purpose limitation, data minimisation, retention limits and security also remain relevant. Commission explanation of GDPR principles. Alongside the functional description, map the real information route: mailbox, automation service, model supplier, destination system and diagnostic logs. A hosting-country label alone cannot answer those questions.

Define the changes that trigger another specialist or legal review. Useful triggers for reassessing an AI system after launch include:

• a new affected group
• additional sources
• a different supplier
• additional countries
• a move from suggestions to autonomous actions

Changing a logo is different from allowing the application to release a payment.

For a small operational change, a clear description and relevant repeated tests may be proportionate; the formal requirements depend on the assessed arrangement. Keep rejected changes too. A future maintainer then understands why automatic refunds, for example, were intentionally excluded instead of assuming the omission was accidental.

Begin with one complete workflow description. Use the AI automation guide and the draft-and-approval approach to make the task precise. That description gives technical and legal reviewers a much firmer basis than a broad promise to introduce AI across the company.