The EU AI Act is no longer a proposal. It entered into force on 1 August 2024, and its obligations are arriving in phases — but the phases themselves have moved. In November 2025 the European Commission proposed a Digital Omnibus that pushes the heaviest deadlines back, and EU legislators reached a provisional agreement on it in May 2026. If you are deploying AI in a DACH enterprise, the regulation still shapes what you can build, how you must document it, and what happens if you get it wrong. What has changed is the calendar — and the smart response to a moving calendar is not to relax, but to use the breathing room deliberately.
Most coverage of the AI Act reads like a legal seminar. This guide is not that. It is a practical walkthrough for the people who actually have to act on it: Geschäftsführung, Head of IT, and the compliance leads who need to know which parts apply to them and what to do about it, starting now.
The core message is simple. If you build compliance into your AI initiatives from the outset, it costs a fraction of retrofitting it later. If you wait for enforcement to catch up, you are looking at project delays, architectural rework, and — for the worst category of violation — fines of up to €35 million or 7% of total worldwide annual turnover, whichever is higher.
What the AI Act actually regulates
The AI Act is the world's first comprehensive legal framework for artificial intelligence. Unlike the DSGVO, which governs how you process personal data regardless of the technology, the AI Act regulates the technology itself: AI systems and general-purpose AI models.
The definition of an "AI system" is deliberately broad — a machine-based system that, from the input it receives, infers how to generate outputs such as predictions, recommendations, decisions, or content that can influence physical or virtual environments. That covers a predictive-maintenance model on a factory floor, a chatbot handling customer enquiries, and an automated claims-triage system alike. For most DACH enterprises, this means the question is not whether the Act applies to your production AI, but how — and that turns entirely on risk classification.
The risk classification system
The Act sorts AI into four tiers. Everything else flows from where a system lands.
Unacceptable risk is banned outright. This covers social scoring, untargeted scraping of facial images to build recognition databases, manipulation that exploits the vulnerabilities of specific groups, and — directly relevant to employers — emotion recognition in the workplace and in educational settings. For most Mittelstand companies this category is a quick sanity check rather than a project: you are almost certainly not building these systems. But check anyway. A tool that infers employee emotional states during video calls would fall here, and the prohibitions have applied since 2 February 2025.
High-risk is the tier that drives real work. It captures AI used in employment and worker management (CV screening, performance scoring, task allocation), access to essential services (creditworthiness assessment, life and health insurance risk pricing), critical infrastructure, education, and biometric identification. High-risk classification triggers the full stack: a risk-management system, technical documentation, data governance, logging, human oversight, accuracy and robustness requirements, and a conformity assessment. For a DACH enterprise in insurance, lending, or HR tech, at least some workflows will likely land here — and the practical consequence is that you must be able to explain what the system does and how it reaches its outputs, not merely that it works.
Limited risk carries a single core duty: transparency. Users must be told they are interacting with an AI system, and AI-generated or manipulated content must be labelled. If you are running a customer-facing chatbot or an AI writing assistant, this is your category, and the burden is manageable.
Minimal risk — spam filters, AI-enhanced internal search, most document classification and process automation — carries no specific AI Act obligations, though general product-safety and DSGVO duties still apply. For most Mittelstand companies taking their first AI steps, this is genuinely good news: the typical first portfolio is dominated by minimal- and limited-risk workflows. But you need to know that, documented, with a written classification rationale, before you proceed. For a system-by-system walkthrough, see EU AI Act Risk Classification.
Provider or deployer: which role are you?
The obligations differ sharply depending on your role, and most DACH enterprises misjudge it at first.
Providers develop an AI system, or have one developed, and place it on the market or put it into service under their own name. Deployers use an AI system under the authority of a provider. If you run a foundation model through Azure OpenAI for internal document processing, you are the deployer and the model provider is the provider. The overwhelming majority of Mittelstand companies are deployers — they integrate third-party models and vendor solutions rather than training their own.
Deployer obligations are lighter than provider obligations, but they are not nothing. You must use the system in line with its intended purpose, implement the human-oversight measures the provider specifies, monitor operation and keep the automatically generated logs, and inform affected people where automated decision-making touches them. There is one trap worth flagging early: if you fine-tune a model, bolt on a substantial custom layer, or repurpose a system beyond its intended use, you can cross the line from deployer to provider — and inherit the far heavier provider obligations. Get this classification right before you build, not after.
A common misconception is worth correcting: the fundamental rights impact assessment under Article 27 is not a universal deployer duty. It binds public bodies, private entities delivering public services, and deployers of the specific high-risk systems that assess creditworthiness or price life and health insurance. If you are a private manufacturer running an internal high-risk workflow outside those categories, the FRIA may not apply to you at all — though a DSGVO Data Protection Impact Assessment often still will.
How the AI Act meets the DSGVO
If you operate in the DACH region you already live with the DSGVO, and the AI Act layers on top of it rather than replacing it. The two reinforce each other where it matters: both demand impact assessments for higher-risk processing, both require transparency about automated decisions, and both rest on documentation and accountability. If your data-protection programme is solid, you have a real head start.
The AI Act then goes further than the DSGVO ever did — risk-management systems, technical documentation of the AI system itself rather than just the data flow, conformity assessments, and ongoing performance monitoring. And the two regimes can pull against each other: the DSGVO's data-minimisation principle sits awkwardly beside the Act's demand for sufficiently representative training data. Reconciling that takes deliberate legal and technical planning, which is why we run a DPIA designed specifically for AI use cases as part of every engagement. The practical implication is that AI compliance cannot be a standalone workstream bolted onto an existing programme. Your Datenschutzbeauftragter belongs in the room from day one, not after the model is built.
The timeline that actually applies now
This is where most published guides are now wrong, because the deadlines moved after they were written. Here is the current picture.
The prohibitions on unacceptable-risk systems and the AI-literacy obligations have applied since 2 February 2025. The obligations for general-purpose AI models, the governance structures, and the penalty provisions took effect on 2 August 2025 — and the Commission's voluntary General-Purpose AI Code of Practice, published in July 2025, gives providers a route to demonstrate compliance. Major model providers including Anthropic, Google, Microsoft, and OpenAI signed on as early signatories.
The pivotal change concerns high-risk systems. The original Act put most high-risk obligations at 2 August 2026. The Digital Omnibus, proposed by the Commission on 19 November 2025 and agreed provisionally by Parliament and Council in May 2026, defers them: standalone high-risk systems (Annex III) now move to 2 December 2027, and high-risk systems embedded in already-regulated products (Annex I — medical devices, machinery, vehicles) to 2 August 2028. The Omnibus also replaces the originally proposed "trigger when the standards are ready" mechanism with these fixed calendar dates.
One critical caveat: as of mid-2026 the Omnibus is a provisional agreement, not yet formally adopted or published in the Official Journal. Until it is, the legally binding date remains 2 August 2026, and the transparency obligations that take effect then are not in question. The honest read for a Geschäftsführer is this — plan against the new 2027 and 2028 dates for the bulk of high-risk work, but do not treat August 2026 as cancelled until the amended text is law. For a deadline-by-deadline breakdown, see the EU AI Act timeline.
There is a second reason not to exhale. Germany was late designating its enforcement machinery. The Bundesnetzagentur is set to act as the central market-surveillance authority, notifying authority, and single point of contact, but the implementing law — the KI-Marktüberwachungs- und Innovationsförderungsgesetz, or KI-MIG — was only adopted as a Federal Cabinet draft on 11 February 2026, after Germany missed the EU's August 2025 deadline for naming competent authorities. A delayed enforcer is not a permanent one. The structures are arriving; the extra months are runway, not reprieve.
What compliance looks like in practice
Theory keeps you informed. Practice keeps you out of enforcement actions. For a typical DACH enterprise running a handful of AI workflows in production, the path is concrete.
It starts with an inventory, because you cannot comply for systems you do not know exist. That includes shadow AI — the marketing team drafting campaigns in a public chatbot, the sales team pushing leads through a third-party scoring API. For each system, record what it does, who uses it, what data it touches, who the provider is, and which risk tier it falls into. Classification comes next: apply the four tiers to every entry. Most will be minimal or limited; some may be high-risk; none should be unacceptable — and if one is, that is a problem to solve this week, not this quarter.
Then comes closing the documentation gap, which is usually where reality bites. Most companies find they already have the components — a model card here, a risk note in a project repository, a data-flow diagram in a wiki — scattered across tools and teams. The Act requires that material consolidated, maintained, and audit-ready, which is a different discipline from having written it down once. For high-risk systems that means technical documentation, a living risk-management system, data-governance procedures, and recorded accuracy and robustness testing; for limited-risk systems it means transparency disclosures; for minimal-risk systems, basic records.
Human oversight is the requirement most often misread. The Act does not mean "a human sees the output somewhere downstream." It means a named person with the competence, training, and actual authority to understand the system, override its decisions, and intervene. For many enterprises that forces a genuine redesign of the workflow, because an AI step can no longer simply feed the next process stage unchecked. Alongside it sits monitoring and incident reporting — watching high-risk systems for performance degradation and drift, with duties to report serious issues to the supervisory authority. This is precisely where compliance by design earns its keep: if audit logging and drift detection are in the architecture from the start, monitoring is a feature; if they are not, it is a rebuild. And where the FRIA applies, it should be run as one combined assessment with the DSGVO DPIA rather than two overlapping exercises.
How the AI Operating System methodology handles compliance
At Remote Native, compliance is not a phase tacked onto the end. It is a design constraint that shapes the build from Discovery onward. The AI Operating System methodology assumes it by default.
In Discovery we classify each use case against the Act's risk tiers before a line of code is written, so that where a workflow is high-risk, the compliance requirements shape the architecture rather than fighting it afterwards. Deployments run on EU-resident infrastructure — data does not leave the EU, which removes an entire category of risk before it can arise. We design for data minimisation by architecture, processing only what a workflow needs, because the DSGVO and the AI Act both require it and because it cuts attack surface, cost, and complexity at the same time. Audit logging is present from day one — structured records of inputs, outputs, model versions, and human-override decisions — so that when an auditor asks what a system decided on a given case on a given date, and why, there is an answer. A DPIA template tailored to each workflow ships with the engagement and is walked through with your DSB and legal team rather than produced under pressure later. And human oversight is built into the workflow design through explicit checkpoints, override mechanisms, and escalation paths.
The point of all this is not virtue. It is economics. Retrofitting logging, documentation, and oversight into a system that was built without them is markedly more expensive than designing them in — in our experience by a multiple, not a margin — because it means architectural rework rather than configuration. Treating compliance as a design choice rather than a legal afterthought is simply the cheaper way to build.
What DACH enterprises should do now
The deferral to 2027 and 2028 is real, and it is tempting to read it as permission to wait. That would be the wrong lesson. The work that takes the longest — building the inventory, classifying systems, consolidating documentation, redesigning workflows for genuine human oversight — is exactly the work the extra time is meant for, and it does not get easier by starting later.
So start the inventory now, shadow AI included, and put a single named owner on AI Act compliance — your DSB, your Head of IT, or a dedicated lead, but one person accountable. Classify every system against the four tiers, using the classification guide as the on-ramp, and brief leadership on what the portfolio actually contains rather than what it is assumed to contain. For anything high-risk, begin documentation and monitoring now against the 2027 date; for limited-risk systems, implement the transparency disclosures, which are not deferred; and for every new initiative, write the compliance requirements into the project brief from the outset. Run a DPIA for each workflow that touches personal data. Then keep watching the regulatory ground move — the Bundesnetzagentur's guidance as the KI-MIG is finalised, and the Omnibus text as it passes into law.
The Mittelstand advantage
Here is the part large corporates will not enjoy hearing. The Mittelstand is better positioned for AI Act compliance than most assume, for three structural reasons. A company running five AI workflows has a manageable task; a corporate running five hundred has a programme. When the Geschäftsführer decides to invest in compliance, it happens — no steering committee, no half-year procurement cycle. And the typical mid-market portfolio is dominated by minimal- and limited-risk systems, which means the heaviest requirements may not apply to a single workflow in the business. For more on how the Act lands specifically on mid-market companies, see What the EU AI Act Means for Mittelstand Companies.
The companies that come out ahead will not be the ones that waited for certainty. They will be the ones that treated compliance as a design constraint, built AI that is transparent, documented, and human-supervised because that is how good systems are built anyway, and were therefore ready to answer "yes, here is our documentation" the first time a regulated buyer asked. The deadlines moved. The advantage of moving first did not.
A Fit Call maps your AI portfolio against the AI Act's risk tiers and gives you a clear-eyed view of where you stand — before the deferred deadlines become the next scramble.
References: European Commission, "AI Act — Regulatory framework for AI"; EU Artificial Intelligence Act, "Implementation Timeline" and "Article 99: Penalties" and "Article 27: Fundamental Rights Impact Assessment"; European Commission, "The General-Purpose AI Code of Practice," 2025; Gibson Dunn, "EU AI Act Omnibus Agreement — Postponed High-Risk Deadlines," 2026; Pinsent Masons, "AI Act: Germany consults on implementation law," 2026; Bundesnetzagentur, "Artificial Intelligence — Market Surveillance."