What the AI Act Actually Is

The EU AI Act is a regulation that sorts uses of artificial intelligence by the risk they pose to people, and attaches obligations to the riskier ones. The key point — and the one most easily lost in the coverage — is that it regulates how AI is used, not AI as a technology. The same language model can sit inside a harmless internal search tool or a system that decides who gets hired. The Act treats those two situations completely differently, because the risk to a person is completely different.

It applies to two roles. If you build or brand an AI system, you are a provider. If you put someone else’s AI system to use in your business, you are a deployer. Most mid-sized companies are deployers — you buy a tool, or you have one built, and you run it. That role carries lighter duties than being a provider, and for the majority of everyday uses those duties are modest or nonexistent.

Here is the reassuring reality that rarely makes the headlines: the overwhelming majority of Mittelstand AI use — document search, drafting assistance, internal process automation, summarising reports, answering routine questions — sits in the lowest risk tiers, where the Act asks little or nothing of you. The strict rules exist, but they are aimed at a narrow set of genuinely sensitive applications. Knowing which bucket you are in is most of the work.

The Four Risk Categories

The Act builds everything on a simple ladder of four risk levels. Understanding the ladder is the single most useful thing you can take away from this article.

Unacceptable banned outright High risk strict duties — docs, oversight, records Limited risk transparency only — say it’s AI Minimal risk no obligations — most business AI is here
The AI Act’s risk ladder. Most business automation sits at the wide base — minimal or limited risk; the strict, high-risk tier is a narrow, well-defined shortlist.

Unacceptable risk — banned outright

A small number of AI practices are prohibited entirely because they are considered a clear threat to people’s rights. This includes things like social scoring of citizens, manipulative systems that exploit vulnerabilities, and certain forms of biometric surveillance. For a normal business, this category is almost never relevant — you would have to be deliberately building something abusive to fall into it. It is worth knowing the line exists, but you are extremely unlikely to be anywhere near it.

High risk — strict duties

This is the category that carries real obligations, and it is defined narrowly. High-risk uses are those where an AI system materially affects someone’s safety, livelihood, or fundamental rights. Concrete Mittelstand examples: AI that screens job applicants or ranks CVs, AI that scores creditworthiness, AI embedded in safety components of machinery, or AI used in access to essential services. If you operate in one of these areas, the Act expects documentation, risk management, human oversight, data quality controls, and record-keeping.

Limited risk — transparency only

Here the only real obligation is honesty. If people interact with an AI system, they should know it. A customer-facing chatbot, an AI voice assistant, or AI-generated content generally falls here. You do not need a compliance apparatus — you need a clear notice that the person is dealing with AI.

Minimal risk — no obligations

Everything else. AI-assisted spam filters, internal document search, summarising your own reports, drafting an email that a human then reviews, forecasting inventory — none of it carries specific AI Act obligations. This is where most internal automation lives.

The takeaway. Most internal automation is minimal or limited risk. High risk is a specific, well-defined shortlist — not a catch-all. If your AI is not deciding something significant about a person, you are almost certainly not in the strict tier.

What Applies to You

The fastest way to reduce anxiety is to locate each of your AI uses on the ladder. Most companies find, once they actually list what they run, that the strict rules touch little or nothing.

Customer-facing chatbots and assistants

If you run a chatbot on your website, an AI email responder, or a voice assistant, you are almost always in limited risk. The obligation is transparency: tell people they are talking to an AI, and label AI-generated content where relevant. That is a sentence in your interface and a line in your terms — not a project.

HR, credit, and safety uses

The moment AI helps decide who gets hired, who gets a loan, who gets access to an essential service, or how a safety-critical machine behaves, you are likely in high risk. Here the duties are real: keep documentation, ensure a human stays meaningfully in the loop, manage the data quality behind the decision, and be able to show how the system works. If any of your uses fall here, this is where to concentrate your effort.

Internal document and process automation

Search across your own files, summarising contracts for your own team, routing tickets, extracting data from invoices, drafting text a human reviews — this is nearly always minimal risk. No specific AI Act obligations attach. This is exactly the kind of high-value, low-risk work where mid-sized companies get the most benefit with the least regulatory friction.

Which bucket am I in? Ask one question: does this AI make or materially shape a decision about a specific person — their job, money, safety, or access to something essential? If yes, treat it as high risk and get advice. If it merely talks to people, add a transparency notice. If it just helps your own team work faster, it is almost certainly minimal risk.

The Timeline

The Act does not switch on all at once. It applies in phases, which gives everyone time to prepare — and means the parts most likely to affect you arrive later, not sooner.

The bans on unacceptable-risk uses came into force first, in early 2025. These are the prohibited practices — the ones a normal business is never doing anyway — so for most companies this milestone passed without any action required.

The rules for general-purpose AI models (the large foundation models themselves) began applying in the course of 2025. These obligations largely fall on the companies that build and provide those big models, not on you as someone using a tool built on top of one. Your provider carries most of this weight.

The high-risk obligations — the substantial ones around documentation, oversight, and data quality — phase in across 2026 and 2027. This is the part to watch if any of your uses fall into the high-risk category. If they do not, these dates are largely academic for you. The staggered schedule is deliberate: it gives companies that do operate high-risk systems time to build the necessary processes rather than scramble.

The practical message: there is no cliff edge you have already fallen off. There is a phased ramp, and where you sit on the risk ladder determines whether any of it lands on your desk at all.

How It Relates to GDPR

A common worry is that the AI Act replaces or contradicts the GDPR. It does neither. The two regulations stack. They govern different things and apply at the same time.

The GDPR governs personal data: what you may collect, why, how long you keep it, and on what legal basis. It does not care whether AI is involved — it cares about the data. The AI Act governs the AI system itself: how the model is used, what risk category it falls into, and what safeguards that demands. If your AI processes personal data — which many systems do — both apply. You still need a lawful basis under the GDPR and you still classify the use under the AI Act. Neither excuses you from the other.

The good news is that the same architectural choices that satisfy one tend to satisfy the other. When your AI runs on infrastructure you control — on-premise or in a data-sovereign setup where your data never leaves your boundary — you address the GDPR’s data-residency and processing concerns and you make the AI Act’s documentation and oversight duties far easier to meet at the same time. Control over where data lives and how the system behaves is the common foundation for both regimes. This is a core part of how we design systems — you can read more on our services page.

They complement, they don’t collide. GDPR asks “are you allowed to use this data?” The AI Act asks “is this AI use safe and transparent?” A data-sovereign architecture is a strong answer to both questions at once.

Practical Steps to Take Now

You do not need a compliance department to get ahead of this. For most mid-sized companies, a focused afternoon of honest inventory covers the bulk of it. The steps are concrete and finite.

1. Inventory your AI uses. Write down every place AI is actually in play — the website chatbot, the document search, the drafting assistant, the analytics tool that quietly added an AI feature. You cannot classify what you have not listed, and most companies are surprised by how short the real list is.

2. Classify each use on the ladder. For every item, decide: unacceptable, high, limited, or minimal. Use the one-question heuristic above. This single step tells you where to spend attention and, more often, where you can relax.

3. Add transparency notices where needed. For anything customer-facing, make sure people know they are dealing with AI. This is quick and cheap, and it covers the most common obligation a normal business actually has.

4. Keep documentation. For any high-risk use — and it is good practice everywhere — record what the system does, what data it uses, and who is accountable. Documentation is not bureaucracy for its own sake; it is what turns an audit from a crisis into a filing exercise.

5. Choose an architecture that keeps data controllable. The more control you retain over where your data lives and how the system behaves, the easier every obligation becomes — under both the AI Act and the GDPR. Data sovereignty is not just a compliance box; it is what makes compliance cheap.

If you would rather have this done properly and get a clear read on where you stand, our AI Readiness Check assesses exactly this: what AI you use, which risk tier each use sits in, and what — if anything — you need to do about it.

Where Tippel Fits

Compliance is far easier when it is designed in rather than bolted on. The reason the AI Act unsettles some companies is that AI was often adopted quickly, with little documentation, on infrastructure nobody controlled — so when the rules arrived, so did the scramble.

The way we build avoids that scramble by default. Every system is documented as it is built, every consequential action is auditable, and data sovereignty is the starting assumption, not an upgrade you pay extra for. When a project already carries its own documentation, keeps its data inside your boundary, and logs what it does, meeting the AI Act stops being a project of its own. Compliance becomes a byproduct of building the system properly — a checkbox you can tick, not a crisis you have to manage.

That is the whole idea: the same engineering discipline that makes AI reliable and secure is the discipline the regulation is asking for. Do the first well, and the second largely takes care of itself.