The EU AI Act is no longer a proposal. It entered into force in August 2024, and its obligations are rolling out in phases through 2027. If you are deploying AI in a DACH enterprise — or planning to — this regulation shapes what you can build, how you must document it, and what happens if you get it wrong.

Most coverage of the AI Act reads like a legal seminar. This guide is not that. It is a practical walkthrough for enterprise practitioners: CTOs, compliance officers, and business leaders who need to understand what the regulation requires, 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 day one, it costs a fraction of retrofitting it later. If you wait until enforcement catches up, you are looking at project delays, architectural rework, and fines that can reach €35 million or 7% of global annual turnover.

What the EU AI Act actually regulates

The AI Act is the world's first comprehensive legal framework for artificial intelligence. Unlike DSGVO, which regulates data processing regardless of the technology used, the AI Act regulates the technology itself — specifically, AI systems and general-purpose AI models.

An "AI system" under the regulation is broadly defined: a machine-based system that generates outputs such as predictions, recommendations, decisions, or content that can influence physical or virtual environments. That definition covers everything from a predictive maintenance model on a factory floor to a chatbot handling customer enquiries to an automated claims triage system.

For DACH enterprises, this means most production AI workflows fall within the Act's scope. The question is not whether the regulation applies, but how — and that depends on the risk classification.

The risk classification system

The AI Act creates four risk tiers. Everything flows from where your AI system lands on this scale.

Unacceptable risk — banned outright

Certain AI applications are prohibited entirely. These include social scoring systems, real-time biometric identification in public spaces (with narrow law-enforcement exceptions), manipulation of vulnerable groups, and emotion recognition in workplaces and schools.

For most DACH enterprises, this category is straightforward: you are almost certainly not building these systems. But it is worth a sanity check. An AI system that monitors employee emotions during video calls, for example, would fall here. So would a customer scoring system that uses behavioural data to exploit psychological vulnerabilities.

High-risk — the heaviest obligations

This is the category that matters most for enterprise AI. High-risk systems include AI used in:

  • Employment and worker management: automated CV screening, interview scoring, performance monitoring, task allocation
  • Access to essential services: credit scoring, insurance risk assessment, social benefit eligibility
  • Critical infrastructure: energy, transport, water, digital infrastructure management
  • Education and vocational training: automated grading, exam proctoring, student assessment
  • Law enforcement and border control: risk assessments, evidence evaluation
  • Biometric identification and categorisation

High-risk systems trigger the full compliance stack: conformity assessments, technical documentation, risk management systems, data governance, human oversight, accuracy and robustness requirements, and registration in the EU database.

For a DACH enterprise in insurance, financial services, or HR tech, high-risk classification is likely for at least some workflows. The practical impact is significant: you need documented risk management, ongoing monitoring, audit trails, and — critically — the ability to explain what the system does and how it reaches its outputs.

Limited risk — transparency obligations

Limited-risk systems have one primary obligation: transparency. Users must be informed that they are interacting with an AI system. This covers chatbots, AI-generated content, emotion recognition systems (where permitted), and biometric categorisation.

If you are deploying a customer-facing chatbot or an AI writing assistant, this is your category. The compliance burden is manageable: disclose that the system is AI, label AI-generated content, and maintain basic records.

Minimal risk — no specific obligations

AI systems that do not fall into the above categories — spam filters, AI-enhanced search, recommendation engines for internal use, most process automation — are minimal risk. No specific obligations under the AI Act, though general product safety and DSGVO requirements still apply.

For most Mittelstand companies deploying their first AI workflows, this is actually good news. Document classification, internal knowledge retrieval, and process automation typically fall here. The regulation's heaviest requirements do not apply. But you need to know that — documented, with a clear classification rationale — before you proceed.

For a detailed walkthrough of how to classify your specific AI systems, see EU AI Act Risk Classification.

Provider vs. deployer: which role are you?

The AI Act distinguishes between two key roles, and the obligations differ substantially.

Providers are organisations that develop or commission an AI system and place it on the market or put it into service under their own name. If you build a custom AI model or significantly modify an existing one, you are likely a provider.

Deployers are organisations that use an AI system under the authority of a provider. If you deploy GPT-4 via Azure OpenAI for internal document processing, you are a deployer. Microsoft is the provider.

Most DACH enterprises are deployers. They use third-party foundation models, cloud AI services, or vendor solutions and integrate them into their workflows. Deployer obligations are lighter than provider obligations, but they are not zero:

  • Ensure the AI system is used in accordance with its intended purpose
  • Implement human oversight measures
  • Monitor the system's operation and report incidents
  • Conduct a fundamental rights impact assessment for high-risk systems
  • Maintain logs and cooperate with authorities
  • Inform affected individuals about automated decision-making

The critical nuance: if you fine-tune a model, add a custom layer, or modify the system's intended purpose, you may shift from deployer to provider. This is not academic — it changes your compliance burden significantly. Get this classification right early.

How the AI Act interacts with DSGVO

If you are operating in the DACH region, you are already navigating DSGVO. The AI Act adds a layer on top — but it also overlaps in important ways.

Where they reinforce each other: Both require Data Protection Impact Assessments (DPIAs) for high-risk processing. Both require transparency about automated decision-making. Both require documentation and accountability. If your DSGVO compliance is solid, you have a head start.

Where the AI Act goes further: The AI Act requires risk management systems, technical documentation of the AI system itself (not just the data processing), conformity assessments, and ongoing monitoring of AI system performance — none of which DSGVO mandates.

Where they create tension: DSGVO's data minimisation principle can conflict with AI training requirements. The AI Act's demand for representative training data can conflict with DSGVO's purpose limitation. Navigating this requires careful legal and technical planning — which is why we run a DPIA specifically designed for AI use cases as part of every engagement.

For DACH enterprises, the practical implication is that AI compliance is not a standalone workstream. It must be integrated with your existing data protection programme. Your DSB (Datenschutzbeauftragter) needs to be involved from day one, not brought in after the model is built.

The implementation timeline

The AI Act rolls out in phases. Understanding the timeline is essential for planning — and for not panicking about the wrong deadlines.

February 2025: Prohibitions on unacceptable-risk AI systems take effect. If you have any AI applications that fall into the banned category, they must be decommissioned.

August 2025: Obligations for general-purpose AI (GPAI) models take effect. This primarily impacts providers of foundation models, but deployers should understand how their GPAI providers are handling compliance.

August 2026: Most obligations for high-risk AI systems take effect. This is the critical deadline for enterprises deploying AI in HR, finance, insurance, or critical infrastructure. Conformity assessments, technical documentation, risk management systems, and human oversight must be in place.

August 2027: Extended deadline for high-risk AI systems embedded in products already regulated under EU sectoral legislation (medical devices, aviation, automotive, etc.).

For a detailed breakdown of each deadline and what actions to take before each one, see EU AI Act Timeline.

The August 2026 deadline is the one most DACH enterprises should be planning against right now. That gives you just over a year — which sounds comfortable until you account for the time required to classify systems, update documentation, implement monitoring, and run conformity assessments across multiple AI workflows.

What compliance actually looks like in practice

Theory is useful. Practice is what keeps you out of enforcement actions. Here is what AI Act compliance looks like for a typical DACH enterprise running 3–10 AI workflows in production.

1. Build an AI system inventory

You cannot comply with regulation for systems you do not know about. Step one is an inventory of every AI system in use — including shadow AI. That marketing team using ChatGPT to draft campaigns? That counts. The sales team running leads through a third-party scoring API? That counts too.

For each system, document: what it does, who uses it, what data it processes, who the provider is, and what risk category it falls into.

2. Classify each system by risk level

Apply the AI Act's risk classification to every system in your inventory. Most will be minimal or limited risk. Some will be high-risk. None should be unacceptable risk — and if any are, you have an immediate problem to solve.

3. Close the documentation gap

For high-risk systems, you need: technical documentation, a risk management system, data governance procedures, accuracy metrics, robustness testing, and human oversight protocols. For limited-risk systems, you need transparency disclosures. For minimal-risk systems, basic records suffice.

Most companies discover they have the components of this documentation scattered across project repositories, Confluence pages, and Slack threads. The AI Act requires it consolidated, maintained, and audit-ready.

4. Implement human oversight

Every high-risk AI system must have human oversight — a person who can understand the system's outputs, override decisions, and intervene when needed. This is not "a human sees the output somewhere in the process." It means a specific person with the training, authority, and tools to supervise the AI system's operation in real time.

For many DACH enterprises, this requires rethinking workflow design. The AI cannot simply run autonomously and produce outputs that flow into the next process step unchecked. Someone must be in the loop — and that someone must be empowered and equipped to act.

5. Set up monitoring and incident reporting

High-risk AI systems must be monitored for performance degradation, bias drift, and safety issues. When things go wrong, there are reporting obligations to national supervisory authorities.

This is where compliance by design pays dividends. If your AI architecture includes audit logging, performance dashboards, and automated drift detection from day one, monitoring is a feature, not a retrofit. If you built the system without these capabilities, you are looking at an architectural rework.

6. Conduct impact assessments

For high-risk systems, deployers must conduct a fundamental rights impact assessment. This is distinct from, but complementary to, a DSGVO DPIA. In practice, we combine both into a single assessment that covers data protection and fundamental rights in one pass.

How the AI Operating System methodology handles compliance

At Remote Native, compliance is not a phase. It is a design constraint that shapes every decision from Discovery through to Production.

The AI Operating System methodology bakes compliance in by default:

  • Discovery phase: We classify AI use cases against the AI Act's risk categories before any development begins. If a workflow is high-risk, the compliance requirements shape the technical architecture — not the other way around.
  • EU-resident infrastructure: All deployments run on EU-resident infrastructure. Data does not leave the EU. This is non-negotiable and removes an entire category of compliance risk.
  • Data minimisation by architecture: We design AI workflows to process only the data they need. Not because it is nice — because DSGVO and the AI Act both require it, and because it reduces attack surface, cost, and complexity simultaneously.
  • Audit logging from day one: Every AI workflow includes structured logging of inputs, outputs, model versions, and human override decisions. This is not added later. It is part of the initial architecture. When an auditor asks "what did this system decide on case X on date Y, and why?" — we can answer that question.
  • DPIA template included: Every engagement includes a pre-built DPIA template tailored to the specific AI workflow. We walk through it with your DSB and legal team as part of the process, not as an afterthought.
  • Human oversight by design: We design workflows with explicit human checkpoints, override mechanisms, and escalation paths. The AI Act requires it. Good engineering demands it. The result is a system that is both compliant and trustworthy.

This approach means compliance is not a cost centre that slows down delivery. It is a design choice that prevents expensive rework later. Based on our engagements, retrofitting compliance into an existing AI system typically costs 3–5x more than building it in from the start.

What DACH enterprises should do right now

If you are reading this in mid-2026, the August 2026 deadline for high-risk systems is approaching fast. Here is the minimum viable compliance path:

This week:

  • Start an AI system inventory. Include shadow AI.
  • Assign someone to own AI Act compliance — this could be your DSB, your CTO, or a dedicated compliance lead.

This month:

  • Classify every AI system by risk level. Use the classification guide as a starting point.
  • Brief your leadership team on the AI Act's implications for your specific AI portfolio.

This quarter:

  • For high-risk systems: begin conformity assessment preparation, update documentation, implement monitoring.
  • For limited-risk systems: implement transparency disclosures.
  • For all new AI initiatives: embed compliance requirements into the project brief from day one.
  • Run a DPIA for every AI workflow that processes personal data.

Ongoing:

  • Monitor regulatory guidance from national supervisory authorities (in Germany, the Bundesnetzagentur for the AI Act, Datenschutzaufsichtsbehörden for DSGVO).
  • Review and update your AI system documentation with every significant change.
  • Train your teams on AI Act obligations relevant to their roles.

The Mittelstand advantage

Here is an uncomfortable truth for large corporates and a reassuring one for mid-market companies: the Mittelstand is better positioned for AI Act compliance than most people assume.

Why? Three reasons:

  1. Fewer AI systems to classify and document. A company running 5 AI workflows has a manageable compliance task. A DAX-40 company running 500 has a programme.
  2. Shorter decision chains. When the Geschäftsführer decides to invest in compliance, it happens. No steering committee, no six-month procurement cycle.
  3. Most use cases are low-risk. Document classification, process automation, internal knowledge retrieval — the typical Mittelstand AI portfolio is dominated by minimal and limited-risk systems. The heavy compliance requirements for high-risk systems may not apply to a single workflow in your organisation.

For more on how the AI Act specifically impacts mid-market companies, see What the EU AI Act Means for Mittelstand Companies.

The cost of waiting

The temptation is to wait — to see how enforcement plays out, to let the large companies go first, to treat compliance as a problem for later.

This is a mistake, for three reasons:

  1. Retroactive compliance is expensive. AI systems built without audit logging, documentation, and human oversight need architectural rework. Based on our engagements, the cost typically runs 3–5x what it would have been to build it in from the start.
  2. The market will reward early movers. Enterprise buyers — especially in regulated industries — are already asking vendors about AI Act compliance. Being able to answer "yes, we are compliant, here is our documentation" is a competitive advantage.
  3. Enforcement is not a future event. The first prohibitions took effect in February 2025. National supervisory authorities are standing up. Penalties are real: up to €35 million or 7% of global annual turnover for prohibited practices.

Start with a conversation

AI Act compliance is not a checkbox exercise. It is an opportunity to build AI the right way — transparent, documented, human-supervised, and architecturally sound. The companies that treat compliance as a design constraint rather than a legal burden will build better AI systems and deploy them faster.

If you are navigating the AI Act for your organisation and want a clear-eyed assessment of where you stand and what to do next, book a Fit Call. We will review your AI portfolio, classify your systems, and outline a practical compliance path — in 30 minutes, no slides.

Further reading: