The two sentences that poison almost every AI Act discussion
The first sentence is the threat of fines: penalties of up to 35 million euros or 7% of global annual turnover. The number is real – but it applies exclusively to the outright prohibited practices (more on those shortly), not to normal AI use. The second sentence is certification anxiety: "so we'll have to get everything assessed and CE-marked." That, too, doesn't hit most companies, because those duties fall almost entirely on providers of high-risk systems. Between these two exaggerated fears lies the actual, far more sober reality – and it's worth understanding before you either over-regulate out of panic or ignore the topic entirely.
First, the most important framing: the AI Act is not a second data protection law. The GDPR asks whether personal data is processed lawfully. The AI Act asks something different – whether an AI system, as a product, is safe, accountable and fair. It's product-safety law, closer in logic to a machinery or toy-safety directive than to the GDPR. The same AI system can trigger both regimes at once, but with different logic – a point we return to at the end.
The risk pyramid – and why most sit lower than they think
The AI Act grades all duties by the risk an AI system poses. Four tiers, top to bottom:
- Prohibited (unacceptable risk): social scoring by authorities, manipulative systems that deliberately exploit vulnerabilities, real-time remote biometric identification in public spaces (with narrow exceptions), emotion recognition in the workplace and in schools. These practices are simply banned – this is where the 35-million fine sits.
- High-risk: AI in clearly defined sensitive areas – recruitment and applicant screening, creditworthiness checks, insurance risk assessment, access to education, critical infrastructure. This is where the heavy duties sit (documentation, human oversight, conformity assessment).
- Limited risk (transparency duty): chatbots and generative AI. The core duty is manageable – people must be able to tell they are interacting with an AI, or that content is AI-generated (labelling of deepfakes/synthetic media).
- Minimal risk: the large remainder – spam filters, AI in games, most internal productivity tools. No specific duties under the AI Act.
The decisive, rarely spelled-out insight: the typical SME use of AI – a team uses ChatGPT, a chatbot answers standard questions, an automation sorts emails – almost always lands in the bottom two tiers. Not by luck, but because "high-risk" is defined very narrowly in the law, via a concrete list (Annex III). So the first sensible step isn't a compliance project but an honest inventory: which AI systems do we use where, and which tier does each fall into? For most companies that list is shorter and more harmless than the general nervousness suggests.
The more important question isn't "which risk", but "which role"
The workload the AI Act actually demands of you depends less on risk than on your role in the value chain. The law distinguishes two above all: the provider and the deployer. A provider develops an AI system and places it on the market under its own name – they bear the heavy duties: technical documentation, conformity assessment, CE marking, registration in an EU database. A deployer uses an AI system for its own professional purposes – its duties are far lighter even in the high-risk case: ensure human oversight, keep logs, inform affected employees, and where required carry out a fundamental-rights impact assessment.
For most companies, that's the real relief: whoever buys and uses AI is a deployer – not a provider. The CE marking that so many fear is the task of whoever builds the system, not whoever uses it.
The trap: how you silently become a "provider"
Here lies the most practically important and least-discussed insight. The line between deployer and provider is permeable – and you can cross it without noticing. The law turns a deployer into a provider (with a provider's heavy duties) when they deploy a high-risk system under their own name or brand, when they substantially modify an existing system, or when they change a system's purpose such that it becomes high-risk. Fine-tuning or deeply adapting a general-purpose AI model can also pull you into that role. For a company that doesn't just buy AI but builds its own applications on top of it, or heavily reworks existing systems, this is the decisive line – and it belongs at the start of a project, not in a later review once architecture and branding are long settled.
The one duty that already applies today – and almost nobody has done
While everyone stares at the big high-risk deadlines, one duty has long been in force and hits every single company that uses AI: the AI literacy obligation in Article 4. It has applied since 2 February 2025, regardless of the risk tier of the systems used. The core: companies must ensure that their staff – and others operating the AI systems on their behalf – have a sufficient level of AI competence. Not as a certificate, not with a mandated AI officer or governance board – but as a demonstrably taken measure. The European Commission explicitly makes clear that simply handing people the instructions for use is usually not enough.
For SMEs this is the most practically relevant part of the whole law, for two reasons. First: it applies now, while almost everything else lies in the future – and from 3 August 2026 it is enforceable by the supervisory authorities. Second: relative to its effect it's extremely cheap to implement (structured internal training, documented) and it aligns with something that makes sense anyway – that people understand what they work with. The 2026 simplification reform even softened the wording ("support the development of AI literacy" rather than guarantee a specific level) – the core remains. If you tackle only one thing in the entire AI Act, make it this one.
The moving timeline – and why "let's wait for the law" is the wrong strategy
The AI Act entered into force on 1 August 2024, but applies in stages. For planning, it's important to separate clearly what already applies from what has been postponed:
- In force since 2 February 2025: the ban on unacceptable practices and the AI literacy obligation (Art. 4).
- In force since 2 August 2025: the rules for general-purpose AI models (GPAI) and the governance structures.
- From 2 August 2026: the transparency duties (labelling of AI interaction and AI-generated content); from 3 August 2026 the supervision and enforcement rules bite.
- Postponed: the high-risk duties. For stand-alone high-risk systems (Annex III) from August 2026 to 2 December 2027; for systems embedded in regulated products (Annex I) to 2 August 2028.
This postponement is recent and was long uncertain: the European Commission tabled a simplification package ("Digital Omnibus") in November 2025, Parliament approved it on 16 June 2026, and the Council gave its green light on 29 June 2026 – only then did the new deadlines become applicable law. From this follows an uncomfortable but important insight: the legal framework for AI now iterates like software – it's adjusted while you're implementing it. Anyone who concludes "then we'll just wait until it's all final" misreads the situation: part of it already applies (see Art. 4), and the direction – simplification, but no reversal of the basic structure – is clear. The smart consequence isn't standstill but building flexibly: introducing AI systems so that role, risk classification and evidence can be retrofitted without rebuilding everything.
What this concretely means – by who's affected
The AI Act affects three groups differently, and it's worth keeping them apart:
- Companies as deployers (the normal case): inventory your AI uses and sort them into the risk pyramid, meet the AI literacy obligation now, factor in the transparency duty for chatbots/generative AI – and keep an eye on the deployer/provider line as soon as you build your own applications or heavily modify systems.
- Private users and consumers: mostly winners in rights. You get to know when you're talking to an AI rather than a human; AI-generated and manipulated content must be labelled; particularly harmful practices (social scoring, manipulative exploitation of vulnerabilities, sexual deepfakes) are banned. For end users the AI Act is less an obligation than a protection.
- AI providers and developers (the heavy end): whoever builds AI systems and provides them under their own name – all the more in the high-risk area – bears the full load: technical documentation, conformity assessment, CE marking, EU database, incident reporting. Providers of general-purpose models (GPAI) have had their own duties since August 2025; models already on the market before then must be compliant by 2 August 2027.
The AI Act and the GDPR: two laws, one system
A thinking error that regularly catches companies off guard: treating "AI compliance" as one thing. They are two regimes with different logic that hit the same system at once. The GDPR asks: is the personal data processed lawfully (legal basis, transfers, data-subject rights)? The AI Act asks: is the system, as a product, safe, transparent and fair (risk, role, oversight)? An AI-assisted applicant screening, for example, is both an automated decision under the GDPR and a high-risk system under the AI Act – and must pass both tests. Whoever thinks of only one overlooks half the duty. We covered the GDPR side of this coin in more depth in a separate article ("GDPR and AI"); this one is the other half.
What makes sense now
From all this a sober, workable path can be derived – deliberately not a definitive compliance blueprint, because that depends on the individual case, but the order of the questions that need a solid answer:
- Inventory and classification first: which AI systems do we use, and which risk tier does each fall into? The result is usually reassuring – and it shows where action is actually needed.
- Meet the AI literacy obligation now: structured, documented staff training. It already applies and is the best effort-to-benefit lever in the whole law.
- Choose your role deliberately: anyone building their own AI applications or heavily adapting systems should decide and document early whether they slip into the provider role – before architecture and branding are set.
- Build flexibly instead of freezing: introduce AI so that risk classification, oversight and evidence can be retrofitted if the framework shifts further.
None of these points can be settled with a blanket answer, and this article does not replace individual legal advice. What can be said clearly: the most expensive path is to build an AI system into production and only then discover that you've accidentally slipped into the provider role or missed a high-risk classification. Exactly those questions – which role, which risk tier, which evidence – are what we build into the architecture from the start with Custom Applications, rather than letting them become a problem after the fact.