EU AI Act: Top 5 SME Use Cases 2026

The assessment path: first the role, then the prohibition, then the risk class

Each of the five use cases is classified in three steps: determine the role per system, rule out prohibited practices, establish the risk class. Only then is it clear which obligations apply at all.

The starting point is the definition in Art. 3 no. 1 AI Act: a machine-based system that is designed to operate with varying levels of autonomy and that infers, from the input it receives, how to generate outputs such as predictions, content, recommendations or decisions. In doing so, the Regulation follows a risk-based approach: the type and content of the rules are tailored to the intensity and scope of the risk (recital 26 AI Act).

Step 1 — role. A provider is whoever develops an AI system or places it on the market (Art. 3 no. 3 AI Act); a deployer is whoever uses an AI system under its own authority (Art. 3 no. 4 AI Act). As a rule, SMEs are pure deployers. The role has to be determined per system, not per company, and it can change: under Art. 25 AI Act a deployer becomes a provider where it substantially modifies the purpose or functionality or places the system on the market under its own name.

Step 2 — prohibitions. Art. 5(1) AI Act prohibits, among other things, social scoring ((c)), emotion recognition in the workplace and in education institutions ((f)), biometric categorisation to infer sensitive attributes ((g)) as well as the untargeted scraping of facial images from the internet or from CCTV footage ((e)). These prohibitions have applied since 2 February 2025 (Art. 113 AI Act).

Step 3 — risk class. The AI systems listed in Annex III are considered high risk (Art. 6(2) AI Act); for SMEs, no. 4 (employment, workers management) is primarily relevant. The exception in Art. 6(3) AI Act applies only where the system does not pose a significant risk to health, safety or fundamental rights — and it is ruled out as soon as the system performs profiling of natural persons. Where a system stays below that threshold, Art. 50 AI Act determines the transparency obligations.

Also widespread are code assistance, marketing automation and OCR/document AI (qualitative classification, as at the first version of 2 May 2026). Code assistance: deployer (Art. 3 no. 4 AI Act); no Annex III area applies as long as the system does not evaluate natural persons — the obligation is training under Art. 4 AI Act, inclusion in the AI inventory is a practical recommendation. Marketing automation: likewise no Annex III area as long as no natural persons are evaluated; where the system generates synthetic content, the machine-readable marking under Art. 50(2) AI Act falls on the provider of the generating system, and personal data of target groups require a legal basis under Art. 6(1) GDPR. OCR/document AI: minimal, as long as only document content is extracted; the classification flips into Annex III no. 4 as soon as evaluations of employees or applicants arise from it (Art. 6(2) AI Act in conjunction with Annex III).

1. ChatGPT for text creation (marketing, email)

Risk: limited (Art. 50 transparency). Obligations and practical recommendations: acceptable use policy, AI literacy training, output quality control, no auto-posting of personal data.

Whoever buys and uses ChatGPT is a deployer (Art. 3 no. 4 AI Act). The obligations for providers of general-purpose AI models — technical documentation under Annex XI, information for downstream providers, a policy to comply with copyright law and the published summary of the training content (Art. 53(1) AI Act) — fall on the model provider, not on the SME using it. Even a custom GPT of your own on a cloud platform does not make an SME a provider, according to the classification in our GPAI article; provider status only arises under the conditions set out in step 1 of the assessment path (Art. 25 AI Act).

On transparency, it is worth looking at who the rule addresses: the machine-readable marking of synthetic audio, image, video and text content is required by Art. 50(2) AI Act from the providers of the generating system. Deployer obligations under Art. 50 AI Act concern emotion recognition and biometric categorisation (paragraph 3) and deep fakes (paragraph 4). Practical recommendation: set out in the acceptable use policy which types of text are published externally and who checks the output before publication.

Independently of that, the AI literacy obligation under Art. 4 AI Act has applied since 2 February 2025 to the persons who come into contact with AI; as a practical recommendation, its content covers the definition of AI, risk classes, prohibited practices, transparency obligations and human oversight. Where personal data go into the prompts, the processing needs a legal basis under Art. 6(1) GDPR; for special categories of data — health data, for example — the general prohibition on processing in Art. 9(1) GDPR applies, with the narrow exceptions of paragraph 2.

2. Microsoft Copilot for office assistance

Risk: limited. Obligations and practical recommendations: check tenant isolation, data classification, AUP, training. Caution: before switching the tool on, clarify which tenant data the assistant can reach — check permissions and sensitivity labels (see below).

With the office assistant, too, the SME is a deployer (Art. 3 no. 4 AI Act); the GPAI provider obligations under Art. 53 AI Act lie with the model provider. The difference from use case 1 is the data access — and it shifts the centre of gravity from the AI Act to the GDPR.

Before switching the tool on, it must be clarified which data holdings the assistant can reach. Where a type of processing, in particular using new technologies, and taking into account the nature, scope, context and purposes of the processing, is likely to result in a high risk to the rights and freedoms of natural persons, a data protection impact assessment must be carried out beforehand (Art. 35(1) GDPR); as a standard example, Art. 35(3) GDPR names, among other things, processing on a large scale of special categories of data under Art. 9 GDPR. Where the service provider processes personal data on your behalf, Art. 28(1) and (3) GDPR require sufficient guarantees and a contract with the minimum content set out there.

Practical recommendation: carry out a threshold assessment under Art. 35 GDPR before switching the tool on and record the result per tenant; you should check permissions and the classification of the storage locations beforehand, not afterwards, and keep them in the same file as the AI inventory (see immediate to-dos). In concrete terms, this means two things: first, check the reach — which SharePoint, OneDrive and mailbox locations a user account can reach through the assistant. Second, check the classification — mark storage locations holding special categories of data under Art. 9 GDPR before switching the tool on and take them out of scope of access. The AI literacy obligation under Art. 4 AI Act and the acceptable use policy from use case 1 apply to this tool unchanged.

3. AI recruiting tool

Risk: HIGH (Annex III, 4). Obligations: for private SMEs as deployers, the deployer obligations under Art. 26 apply from 2 December 2027 (human oversight by competent persons, relevant and sufficiently representative input data, retention of the logs for at least six months, information of the affected employees and workers' representatives) — as set by Art. 113(3)(c)(i) AI Act in the version under Regulation (EU) 2026/1744, in force since 27 July 2026.

No FRIA for private SMEs: a fundamental rights impact assessment (FRIA) does not apply to a private SME for the recruiting tool: Art. 27(1) imposes it only on deployers "that are bodies governed by public law, or are private entities providing public services", as well as on deployers of high-risk AI systems under Annex III no. 5 (b) and (c) (creditworthiness, life/health insurance).

In addition, and independently of the AI Act: bias testing as a practical recommendation (see below; the reversal of the burden of proof under § 22 AGG already applies in Germany NOW; Austria: the lowered standard of proof under § 12(12) and § 26(12) GlBG — affected persons must establish the discrimination as credible; the contact points are the Equal Treatment Commission and the Ombud for Equal Treatment), privacy notice, transparency, applicants' right to object.

Whether an HR tool falls under Annex III no. 4 is not decided by the product name but by the question of whether it evaluates people:

The allocation is a practical classification based on the references given in the table. The exception in Art. 6(3) AI Act is to be interpreted narrowly and is ruled out as soon as the system performs profiling of natural persons; where a system generates evaluations or recommendations capable of materially influencing human decisions, it remains high risk.

Two limits belong before the rollout: systems that analyse the emotions of employees run into the prohibition of emotion recognition in the workplace (Art. 5(1)(f) AI Act). And in data protection terms, a systematic and extensive evaluation of personal aspects (profiling) on which decisions producing legal effects are based is the standard example for a data protection impact assessment under Art. 35(3) GDPR. Access requests from rejected applicants must be answered without undue delay and in any event within one month; the period may be extended by two months where requests are complex and numerous (Art. 12(3) GDPR). Practical recommendation: align log retention and deletion periods for applicant data with one another before going live.

Practical recommendation on bias testing: check the system's hit rates separately for the characteristics listed in § 1 AGG, document the date, the data basis and the result for each test run, and repeat the test after every change to the model or the criteria — the documentation is what you produce in a § 22 AGG case. For applicants' right to object, the response period is the same as for access requests (Art. 12(3) GDPR).

4. AI chatbot for customer support

Risk: limited. Obligations and practical recommendations: bot notice 'you are chatting with AI' (Art. 50), escalation to a human, data protection information, AUP.

The notice has a clear addressee: under Art. 50(1) AI Act, providers must ensure that AI systems intended to interact directly with natural persons inform those persons that they are interacting with an AI system. The obligation has applied since 2 August 2026 (Art. 113 AI Act). Practical recommendation for deployers: check whether the notice actually appears in the delivered interface, and regulate it in the contract with the chatbot supplier — it is displayed on your side.

Where the chatbot analyses emotions, deployers must inform the persons concerned of the operation of the system (Art. 50(3) AI Act); towards employees, the prohibition in Art. 5(1)(f) AI Act applies in addition. In data protection terms: in so far as chat histories contain personal data, the processing needs a legal basis under Art. 6(1) GDPR; where a service provider processes those data on your behalf, a contract under Art. 28(1) and (3) GDPR is required, and requests from data subjects must be answered within one month (Art. 12(3) GDPR). Where the chat widget stores information on the terminal equipment or accesses stored information, in Germany this is permissible only with prior, informed consent — unless the sole purpose is carrying out the transmission of a message or the access is strictly necessary in order to provide the digital service expressly requested by the user (§ 25(1) and (2) TDDDG).

Practical recommendation on escalation: define from which type of request the chat is handed over to a competent person, and record that rule where the support team reads it — in the service process, not only in the policy.

5. AI-supported anomaly detection in accounting

Risk: minimal. Obligations and practical recommendations: documentation in the AI inventory, AI literacy training. No high-risk classification.

Anomaly detection in accounting is minimal risk because it checks booking data and does not evaluate natural persons: none of the eight areas of Annex III therefore applies (Art. 6(2) AI Act in conjunction with Annex III). The AI literacy obligation under Art. 4 AI Act and inclusion in the AI inventory remain unaffected by this.

The classification flips as soon as the same analysis evaluates the behaviour or performance of employees — for example, who recorded or approved which booking. Annex III no. 4 (employment, workers management) then comes into view — as with performance scoring in the table for use case 3. Emotion recognition in the workplace is prohibited in any event (Art. 5(1)(f) AI Act).

In data protection terms: as soon as the analysis captures personal data, it needs a legal basis under Art. 6(1) GDPR. Practical recommendation: record in the inventory which fields are personal and who reviews hits — that is exactly where the line runs between minimal risk and Annex III no. 4.

Obligations and deadlines: what has applied to these five use cases since when

Five sets of obligations are decisive for the five use cases: AI literacy, prohibitions, GPAI provider obligations, transparency and the high-risk deployer obligations. The last two rows of the table are included for delimitation: they apply to none of the five use cases. Each row of the table names a set of obligations under the AI Act and the date on which it starts to apply under Art. 113 AI Act; where the rule itself names the addressee, it is stated in the row.

On the legal status: the Digital Omnibus has been adopted as Regulation (EU) 2026/1744 and has been in force since 27 July 2026. As a result, the high-risk obligations in Chapter III Sections 1–3 apply to Annex III systems from 2 December 2027 and to Annex I systems from 2 August 2028 (Art. 113(3)(c) AI Act as amended); not covered by the postponement are Art. 4, Art. 5, the GPAI obligations and Art. 50, and the general date of application of 2 August 2026 remains in place. You will find the references for this in the sources block.

Data protection runs in parallel: what the GDPR additionally requires

As soon as a use case processes personal data, the AI Act and the GDPR apply side by side — with their own legal bases, their own deadlines and their own supervision. Each row of the following table names an obligation under the GDPR; the trigger is in each case the situation named in the reference.

Practical recommendation: keep both strands of evidence per system in one file — the AI Act asks about role, classification and oversight, the GDPR about legal basis, contracts and data subject rights. Separate filing creates double work as soon as a request comes in.

Germany and Austria: where the obligations differ

As an EU regulation, the AI Act applies directly and in identical wording in both countries — Annex III, the roles, the deployer obligations and the deadlines are identical. The differences lie in national law; the following table covers three areas: protection against discrimination, the data protection officer and the authorities. All rows of the table name national provisions, not obligations under the AI Act.

For the AI Act itself, each Member State designates at least one notifying authority and at least one market surveillance authority; one market surveillance authority acts as the single point of contact, and the contact details had to be made publicly available by 2 August 2025 (Art. 70(1) and (2) AI Act). In Germany, the market surveillance authority has been the Federal Network Agency (Bundesnetzagentur) since 29 July 2026 (§ 2(1) KI-MIG), in so far as sectoral authorities — such as BaFin — are not competent; it is at the same time the single point of contact under Art. 70(2) AI Act (§ 6(1) KI-MIG). As at the date of this article (17 August 2026), Austria has not designated a market surveillance authority under Art. 70 AI Act; the AI service point at RTR is an information and advisory body without supervisory powers. One point helps twice in the recruiting use case: in Germany, under § 12(1) to (3) AGG, suitable training of employees counts as fulfilment of the duty to take measures to protect against less favourable treatment — the AI literacy training under Art. 4 AI Act and the AGG training can therefore be planned as one session (practical recommendation for Germany).

Fine framework: which tier applies to which infringement

The AI Act tiers the upper limits according to the seriousness of the infringement (Art. 99(3) to (5) AI Act); where personal data are affected, the GDPR frameworks run alongside. All rows name statutory upper limits, not standard amounts.

Two points belong with this: for SMEs and start-ups, Art. 99(6) AI Act provides a privilege — the lower of the two values applies. And infringements of the AI literacy obligation in Art. 4 do not fall under the framework of Art. 99(4); penalties in that respect follow national law within the scope of Art. 99(1) AI Act.

Immediate to-dos: inventory, training record, clarification of roles

Three steps carry all five use cases: build an AI inventory, document training, clarify provider or deployer status per system. The order and the intervals below are practical recommendations, not deadlines under the AI Act.

1. AI inventory. Record six fields per system: name and provider, use case, role (provider, deployer or both), risk class (prohibited under Art. 5, high risk under Annex III, GPAI or minimal), the types of data processed including special categories under Art. 9 GDPR, and the persons responsible for oversight and escalation. The inventory is the basis on which all further evidence builds.

2. Document training. The obligation under Art. 4 AI Act has applied since 2 February 2025. On the content, see use case 1. Art. 4 AI Act does not prescribe a particular form of record and does not require providers or deployers to guarantee any specific level of AI literacy (paragraph 1 in the version under Regulation (EU) 2026/1744). Practical recommendation: record the group of participants, the date and the content for each session and schedule new employees in at onboarding.

3. Clarify the role. Confirm the role per system following the assessment path (Art. 3 no. 4, Art. 25 AI Act). Practical rhythm, not a statutory deadline: check the inventory and the allocation of roles with every new tool and additionally review them once a year.