EU AI Act: what mid-sized companies must do

The regulation looks at use, not technology

The EU AI Act, Regulation (EU) 2024/1689, has been in force since 1 August 2024. It does not regulate language models as such, but what a company does with them. The same model can be entirely unproblematic in one workflow and trigger heavy obligations in another. A language model that writes product texts and the same model ranking job applications are two levels apart in the regulation.

Four levels and one obligation that applies to everyone are enough for classification:

Prohibited practices under Article 5: for example emotion recognition in the workplace, social scoring of people or manipulative techniques that deliberately undermine people's decisions. Prohibited since 2 February 2025.
High-risk systems under Article 6 in conjunction with Annex III: among others, AI in the employment context, in assessing the creditworthiness of private individuals and in critical infrastructure. This is where the real obligations lie.
Transparency obligations under Article 50: anyone who lets people interact with an AI or generates certain content must disclose it.
Minimal risk: everything else. No special obligations under the regulation; voluntary codes of conduct are possible.
For everyone: AI literacy under Article 4. Anyone who provides or deploys AI systems ensures that the people working with them sufficiently understand what they are doing. Has applied since 2 February 2025.

The good news first: most workflows that save work at mid-sized companies are at the minimal risk level. Anyone who produces texts at scale, cleans data or sorts enquiries has little to do with the regulation. The exceptions, however, are exactly the workflows that are often first on the wish list: applications and personnel.

The timetable, as of October 2026

The regulation applies in stages. Since February 2025 the prohibitions and AI literacy have applied, and since August 2025 the obligations for providers of large general-purpose models, which do not directly affect your company as a user of such models. Since 2 August 2026 the transparency obligations under Article 50 have applied. The EU postponed the obligations for high-risk systems with the Digital Omnibus (Regulation (EU) 2026/1744, in force since 27 July 2026): for stand-alone systems under Annex III to 2 December 2027, and for AI in products already subject to product regulation (Article 6(1)) to 2 August 2028. The postponement does not change how your workflows are classified, only the date from which non-compliance becomes costly. Check the current position before any decision; the timetables have been adjusted several times recently.

Provider or deployer: the question that is often overlooked

The obligations also depend on your role. In Article 3 the regulation distinguishes between the provider, who develops an AI system or has it developed and puts it into service under its own name, and the deployer, who uses a system under its own authority. Anyone who buys and uses finished software is a deployer. Anyone who has a custom workflow built and runs it under their own name may be a provider themselves, even if a service provider wrote the code.

For workflows with minimal risk this hardly matters. For high-risk systems it does: under Article 16 the provider bears the heavy obligations (quality management, technical documentation, conformity assessment, registration). Article 25 also provides that a deployer becomes a provider if it substantially modifies a system or uses it for a high-risk purpose for which it was not intended. So anyone who later points a general tool at job applications may change role without noticing.

Classification table: typical workflows at mid-sized companies

The following table classifies workflows that we see regularly in analyses. It is no substitute for a case-by-case assessment, but it shows where you need to look more closely and where you do not.

Classification table: typical workflows at mid-sized companies
Workflow	Classification	What follows
Producing product texts from data sheets, with human approval	Minimal risk	Article 4. The disclosure obligation for AI texts in Article 50(4) concerns texts published to inform the public on matters of public interest, and even then not where there is editorial control. Product texts are not covered.
Checking a text inventory against rules and rewording it (for example environmental claims)	Minimal risk	Article 4. The obligations arise from the law being checked against, not from the EU AI Act.
Translation with a specialist glossary	Minimal risk	Article 4.
Cleaning up CRM duplicates, enriching company data	Minimal risk	Article 4. Data protection under the GDPR still applies, for example a data processing agreement under Article 28.
Reading incoming enquiries, classifying them, passing them to the sales team	Minimal risk	Article 4. If processing times per employee are evaluated, an issue arises under the German Works Constitution Act (BetrVG), not under the EU AI Act.
Chatbot or product adviser on the website	Transparency under Article 50(1)	Visitors must be able to recognise that they are talking to an AI, unless this is obvious. A clear notice in the chat window is sufficient.
Reply emails that the workflow sends itself without human review	Minimal risk or transparency	Whether Article 50(1) applies has not been conclusively settled. We recommend a short notice in the email.
Reading applications from the mailbox and filing them in a structured way, without assessment	Borderline case, Annex III, point 4	May fall outside the high-risk level as a narrow procedural task under Article 6(3). This assessment must be documented.
Assessing, filtering or ranking applications	High risk, Annex III, point 4(a)	Full deployer obligations under Article 26, plus GDPR Article 22 and Article 35, and co-determination under section 95 of the Works Constitution Act.
Allocating tasks based on individual behaviour, assessing performance	High risk, Annex III, point 4(b)	As above, plus co-determination under section 87(1) no. 6 of the Works Constitution Act.
Recognising employees' mood from voice or face	Prohibited under Article 5(1)(f)	Do not build. Exceptions only for medical or safety reasons.
Recognising the tone of incoming customer emails	Minimal risk	Not emotion recognition within the meaning of the regulation, because it is not based on biometric data.
Assessing the creditworthiness of private customers	High risk, Annex III, point 5(b)	Credit checks on business customers do not concern natural persons and do not fall under this point.
Internal knowledge assistant covering manuals and policies	Minimal risk	Article 4, internal rules of use.

Two patterns stand out. First: where the AI works with factual data, such as texts, product data or company data, it almost always remains at minimal risk. Second: as soon as it judges people, whether applicants, employees or private customers, the level rises. That is the simplest rule of thumb for a first classification.

The exception in Article 6(3)

Not every system that works in an area listed in Annex III is automatically high-risk. Article 6(3) exempts systems that pose no significant risk, for instance because they only perform a narrow procedural task, improve the result of a previously completed human activity or merely prepare an assessment by people. A workflow that reads attachments from application emails and transfers name, position and documents into the applicant tool may fall under this.

Two restrictions are important. The exception never applies if the system profiles people. And anyone relying on it must document the assessment before putting the system into service and present it on request. In practice this means: the line between "sorting documents" and "pre-sorting applicants" must be set down in writing in the workflow description, and the workflow must be technically built so that it does not cross it.

What high-risk workflows mean for the deployer

If you use a high-risk system, such as bought-in software for pre-selecting applicants, Article 26 governs your obligations as a deployer. The most important ones, in the order in which they arise in operation:

Use the system in accordance with the provider's instructions for use and not for other purposes.
Assign human oversight to people who are competent, trained and authorised for it.
Insofar as you control the input data: ensure that it is relevant to the purpose and representative.
Monitor operation and inform the provider and the authority of risks or serious incidents.
Keep the automatically generated logs for at least six months, insofar as they are under your control.
Before putting the system into service in the workplace, inform the workers' representatives and the employees concerned (Article 26(7)).
Use the provider's information for your data protection impact assessment under Article 35 GDPR.

Article 99 provides for fines for infringements; they are highest for prohibited practices, at up to €35 million or seven percent of worldwide annual turnover. More important than the maximum amounts: without this structure in place, a high-risk workflow rarely survives scrutiny by the works council and the data protection officer.

AI literacy under Article 4: what is enough in practice

Article 4 does not require certificates or a particular course. It requires measures that fit the use, the employees' prior knowledge and the people affected. For a mid-sized company, the following has proven effective:

An overview of who uses which AI systems, including the chat windows that individual departments use on their own initiative.
A short training session per role: anyone who approves a workflow's outputs must know which errors are typical and what to look out for. Anyone who only sees the result needs less.
A rule of use for general chat tools: which data may go in and which may not.
A record of who was trained and when. It costs little and is the first thing asked for when something goes wrong.

Handing over a workflow is the natural moment for this. The people who will check and adapt the workflow in future learn, in the process, exactly what Article 4 is about.

The GDPR continues to apply alongside it

The EU AI Act does not replace data protection law; it applies in addition. For most workflows the GDPR is in fact the stricter test. Three provisions are regularly decisive: Article 28 requires a data processing agreement with every service provider and model provider that processes personal data on your behalf. Article 35 requires a data protection impact assessment where processing is likely to result in a high risk for data subjects, which almost always needs to be examined for AI in HR. And Article 22 gives people the right not to be subject to a decision based solely on automated processing that has legal or similarly significant effects. An automatic rejection of applicants is an example of this.

Where the data is processed, whether on your own servers, in an EU data centre or via a cloud model under contract, is, however, not a matter for the EU AI Act. You decide this for each workflow according to the sensitivity of the data; how is explained on our data sovereignty page and in the article On your own servers, in Europe or in the cloud.

How a workflow fulfils the obligations instead of getting round them

The obligations of the regulation come down to three things: you have to know what the system does, a person must be able to intervene, and it must be possible to trace what happened. These are exactly the components that a properly built workflow has anyway. Every workflow we build has a rulebook that defines what it may do and what it puts before a person, a check that tests outputs against these rules, and a log for each task. Approval of texts, data and customer contacts stays with you.

An example from sales advice: at a technology distributor, a chatbot with its own knowledge base answers product questions in five languages, with references to sources, and hands over to human experts when things get specific. The notice that visitors are talking to an AI is one line of text there; the handover to people is the part that takes work. How we build such workflows is described under Sales and communication.

This article reflects the position as of October 2026 and is not legal advice. For a binding classification of a workflow, involve your legal department or a law firm; the table keeps that conversation short.

What this means for you

For most workflows that save work at mid-sized companies, the EU AI Act gives rise to few obligations: AI literacy for those involved, a notice in the chat window, clean documentation. It only becomes demanding when an AI judges applicants, employees or private customers. You should approach these workflows deliberately, with the works council and the data protection officer at the table from the start, or design them so that the decision stays with a person. The most sensible first step is a list: which AI systems are already running in your company today, and in which row of the table does each of them belong? Our checklist takes you through these and the other questions involved in introducing AI, in six sections: checklist for introducing AI on a sound legal footing.

The EU AI Act for mid-sized companies: which obligations arise for which workflows