EU AI Act: A Practical Implementation Guide for CTOs

The EU AI Act is the world's first comprehensive legal framework for artificial intelligence. It came into force in August 2024. The main high-risk obligations apply from 2 December 2027. Most CTOs in Germany, Austria, and Switzerland know they are coming. What they have not done is the unglamorous work those obligations depend on: building the AI inventory, classifying the systems, and documenting the oversight. And most have also missed the obligation that has been active since February 2025 - AI literacy training for every employee whose work is affected by AI. That one is not coming. It is already overdue.

This guide is not another overview of what the regulation says. There are hundreds of those. This is a working document for CTOs who need to know what practical compliance looks like now that the timeline has shifted - what is already enforceable, what the extra fifteen months actually buy you, and where most advisory frameworks leave you on your own.

The Obligation You Are Already Late On (Article 4)

Article 4 of the EU AI Act requires organisations deploying or using AI systems to ensure "AI literacy" - sufficient understanding of AI systems' capabilities, limitations, and impacts - for all relevant staff. This is not a future obligation. The literacy requirement became effective on 2 February 2025, six months ahead of the main risk-classification provisions.

Most organisations have not completed this. Many have not started. For over a year, the common response was: "We'll handle it with the rest of the compliance work in 2026." We are now in 2026, and the main high-risk obligations apply from 2 December 2027. If Article 4 training has not happened yet, it is not a planning item - it is an overdue obligation that needs to be closed before anything else.

What counts as "AI literacy" under Article 4? The Act is deliberately non-prescriptive. It does not specify a curriculum, a duration, or a certification. It requires that staff have sufficient understanding proportionate to the AI systems they work with. In practice:

• Staff using AI tools - including general-purpose tools like Microsoft Copilot, ChatGPT, or Gemini - need to understand what these systems can and cannot do reliably.
• Staff making decisions influenced by AI outputs need to understand how to critically evaluate those outputs.
• Technical staff deploying or maintaining AI systems need deeper understanding of the systems' limitations and known failure modes.

The proportionality principle matters - and it also means the barrier is lower than most organisations assume. A documented team briefing explaining what ChatGPT gets wrong, how to sanity-check AI outputs, and what not to use AI for unilaterally qualifies as literacy for general users. You do not need a formal e-learning platform or external trainer. You need a record that training happened, what it covered, and who attended. That is achievable in days.

The AI You Do Not Know You Have

Before you can classify AI systems under the Act, you need to know what AI systems you actually have. For most organisations, this is harder than it sounds.

The obvious inventory - internally built ML models, AI-powered products you developed - is manageable. The invisible inventory is the problem. AI has been embedded into standard enterprise software so thoroughly that most technology stacks contain AI systems nobody explicitly chose to deploy.

Common examples that appear in German Mittelstand technology stacks:

• CRM and sales platforms with lead scoring, churn prediction, or next-best-action recommendations - Salesforce Einstein, HubSpot AI, Microsoft Dynamics Copilot.
• HR platforms that screen CVs, rank applicants, or flag retention risks - SAP SuccessFactors, Workday, Personio with AI add-ons.
• Finance tools with anomaly detection, fraud scoring, or automated approval workflows.
• ERP systems with demand forecasting, procurement optimisation, or predictive maintenance modules.
• Communication platforms with real-time transcription, sentiment analysis, or meeting summaries - Teams, Zoom, Slack AI.

Each of these may constitute an AI system under the Act's definition - which is deliberately broad: "a machine-based system that generates outputs such as predictions, recommendations, decisions, or content." Most ML-powered software features meet this threshold.

A practical starting point: ask your IT procurement team to pull every vendor contract signed in the last three years and identify which ones include any form of automated scoring, recommendation, prediction, or decision-making. Then ask department heads the same question directly - they often know about AI tool usage that was never formally procured through IT.

One useful shortcut now available: since August 2025, providers of general-purpose AI models - Microsoft, Google, SAP, and others - have been under their own EU AI Act obligations to publish model capability and limitation documentation, and a year on that documentation is far more complete than it was at first. If you are using AI features embedded in their platforms, you can request this documentation directly. It will not map perfectly to your deployment context, but it gives you a foundation for your own inventory and classification work rather than starting from scratch.

The Classification Trap

The EU AI Act divides AI systems into risk tiers: unacceptable risk (banned), high risk (strict obligations), limited risk (transparency requirements), and minimal risk (no specific requirements). Most compliance coverage focuses on the high-risk categories - correctly. But the classification trap is not about which tier a system ends up in after assessment. It is about the assumption organisations make before they assess.

The trap: most organisations assume their AI is minimal risk until proven otherwise. The Act works differently. For certain categories of AI, the presumption runs in reverse. If you deploy AI in these categories, the burden is on you to demonstrate it does not fall into the high-risk tier. Silence is not compliance.

Annex III of the Act lists eight categories where AI systems are presumptively high risk:

Category 4 - employment and worker management - catches organisations by surprise with consistency. AI used in recruitment, CV screening, performance monitoring, task allocation, and HR decision support may be high-risk under the Act. If your HR platform uses ML-based ranking or scoring in any of these processes, you may already be operating a high-risk AI system without having classified it as such.

Three Gaps That Create the Most Exposure

Gap 1: No documented AI inventory

The Act requires organisations to maintain records of AI systems they deploy. Without an inventory, you cannot classify, you cannot assess conformity, and you cannot respond to a regulatory inquiry. Most organisations have no systematic AI inventory. What they have: spreadsheets maintained by individual teams, SaaS subscriptions managed outside IT procurement, and AI embedded in vendor software that was never flagged as AI during onboarding. This is the starting condition for most companies we assess - and it is not a comfortable one.

Gap 2: No process for evaluating AI before deployment

The Act requires conformity assessment for high-risk AI before deployment. Most organisations have no procurement or IT governance process that asks "does this tool or feature involve AI?" before a purchase is approved. AI gets deployed because a team needed a feature, because the vendor included it in a platform update, or because someone bought a SaaS tool that happened to use ML. The gap is structural: procurement was not designed with AI classification in mind. Fixing it requires adding one question - "does this involve automated scoring, recommendation, or decision-making?" - to your procurement checklist. It is genuinely that simple to start.

Gap 3: No demonstrable human oversight for automated decisions

High-risk AI systems under the Act require "appropriate human oversight" - mechanisms that allow humans to monitor the system, intervene, and override outputs. Many organisations have oversight in principle ("a manager reviews all AI recommendations") but cannot demonstrate it in practice ("we have no audit log showing that review occurred"). A review process that exists in policy but generates no evidence is not demonstrable oversight. This gap is harder to close than the first two because it may require changes to application logging, workflow design, or the systems themselves.

The Betriebsrat Factor

German companies operating under the Betriebsverfassungsgesetz face an additional compliance dimension that international AI Act guidance almost never addresses. This omission is significant for Mittelstand companies.

Any AI system that monitors employee performance, allocates work, or influences employment decisions may be subject to works council co-determination rights under §87 and §90 BetrVG. This is not a future risk created by the EU AI Act - it is current German employment law, predating the Act by decades. What the EU AI Act does is expand the scope of what constitutes an AI-based employment system, making the interaction between these two frameworks more consequential.

The practical implication: before deploying AI systems in employment contexts, Mittelstand companies need to consider not only EU AI Act classification but works council consultation requirements. These are not parallel, independent processes. They interact. An AI system that clears EU AI Act conformity requirements may still require a Betriebsvereinbarung before deployment - and a Betriebsvereinbarung negotiation can take months.

This layer of compliance complexity is specific to German companies and is largely absent from Brussels-centric advisory frameworks. CTOs in German companies should ensure their legal counsel understands both frameworks and specifically how they interact in the context of AI-supported HR and workforce management tools. International law firms without strong German employment law expertise are often poorly positioned here.

The Compliance Timeline: What Hits When

The EU AI Act has a phased implementation timeline, and the Digital Omnibus rearranged the back half of it. Not everything applies at once, and the deferral did not apply evenly. The confusion around what moved and what did not is now the single biggest source of misplaced confidence we see - organisations hear "delayed to 2027" and quietly stop work on obligations that are already enforceable.

The deferral to December 2027 changes the arithmetic in one specific way: a complex high-risk system discovered in your inventory today can now realistically be remediated before the obligations bite. A thorough conformity assessment - covering technical documentation, accuracy testing, bias evaluation, and oversight mechanism design - takes two to four months for a system of any real complexity, and architectural remediation on top of that can take a further two quarters. Fifteen months absorbs that. Six months would not have. This is the first point in the Act's rollout where a Mittelstand organisation starting from scratch can finish without cutting corners.

What the extra time does not do is remove anything from the list. The obligations themselves - risk management, data governance, technical documentation, logging, human oversight, accuracy and robustness - are unchanged. Only the date moved. The organisations that treat December 2027 as permission to pause will arrive in the same position they were in this year, with the same inventory gap, and without the excuse. The ones that use it properly will finish the inventory and classification work in 2026, and spend 2027 on documentation and oversight design rather than on discovery.

Where Most Guidance Falls Short

The market for EU AI Act advisory services has grown rapidly. Most of what is being sold has two consistent weaknesses.

First: it is designed for the text of the regulation, not for the reality of how AI is deployed in organisations. Guidance that says "maintain technical documentation for high-risk AI systems" is correct. It does not help you understand that the AI in your SAP HR module was deployed by a consultant three years ago, nobody has the original model card, and the vendor's documentation refers to a version that has since been updated. The gap between regulatory requirement and operational reality is where most organisations are stuck - and where most advisory frameworks offer the least help.

Second: it treats the EU AI Act as a standalone compliance exercise rather than an integration with existing governance processes. Organisations that already have mature data governance - GDPR compliance processes, data quality frameworks, audit trails - have a significant head start on EU AI Act compliance. Many of the documentation and oversight requirements the Act demands are things mature GDPR-compliant organisations already do for data processing. Those organisations should not be starting from scratch; they should be extending existing governance processes to cover AI-specific requirements.

Third: it is written for AI providers, not AI deployers. The Act distinguishes between providers (organisations that develop and place AI systems on the market) and deployers (organisations that use AI systems in their operations). Most compliance guidance - and most of the high-profile enforcement commentary - focuses on provider obligations (Articles 16–27). But most Mittelstand companies are deployers, not providers. Your obligations under Article 26 as a deployer are different: you are responsible for your deployment context, your use case, your human oversight mechanisms, and your staff training. You are not responsible for the system's underlying technical conformity - that is the provider's obligation. Many organisations are doing provider-level compliance work when they only need deployer-level compliance, and vice versa.

The advisory support worth paying for starts with your actual AI systems - not the regulation's structure - identifies whether you are acting as a provider, a deployer, or both for each system, and maps compliance requirements to what you actually owe. If a compliance project generates a framework document but no AI inventory and no provider/deployer distinction, it has not delivered compliance. It has delivered paper.

Five Questions for Your Next Leadership Meeting

These are the five questions that, in our experience across European compliance assessments, most consistently reveal the real state of EU AI Act readiness. They work as a leadership conversation starter and as a rough readiness diagnostic.

1. Do we have a complete inventory of AI systems we currently operate - including AI embedded in vendor platforms we did not explicitly select? If the answer is "we have a partial list" or "we're working on it," you do not have one.
2. Have we completed AI literacy training for all staff whose work is affected by AI systems? Article 4 is already active. A planned program counts for nothing against the February 2025 obligation.
3. For each AI system we operate, do we know whether it falls into one of the eight Annex III high-risk categories? An answer of "our AI is not high-risk" without documented assessment is not a compliance answer.
4. For AI systems in HR, recruitment, or performance management contexts, have we consulted with our works council? This is not a future question. If those systems are already in operation, the consultation should already have happened.
5. For high-risk AI systems, do we have documented evidence of human oversight - not just a policy, but audit trails showing that review occurred? Documentation that oversight is supposed to happen is categorically different from evidence that it does.

What Comes Next

The high-risk obligations for stand-alone Annex III systems apply from 2 December 2027; for AI embedded in regulated products under Annex I, from 2 August 2028. That is roughly fifteen months of runway - enough to do this properly, and enough to waste. The organisations that get it right will treat 2026 as the year the discovery work gets finished, not the year it gets postponed again.

A realistic plan for the remainder of 2026 has three phases. Weeks one to three: close the two obligations that are already enforceable - Article 4 literacy training, and an Article 50 transparency audit of every customer-facing AI touchpoint and content pipeline. These are parallel tracks and neither requires external help. Weeks four to ten: complete your AI inventory and classify every system in it. Use the Annex III categories as your first filter. For systems in employment, HR, or credit contexts, prioritise them - these are where enforcement attention will focus first. The remainder of the year: for any confirmed high-risk systems, scope the technical documentation and oversight design work, and put it in the 2027 budget while there is still a budget cycle to put it in.

If you discover a high-risk system that requires significant architectural remediation - new logging infrastructure, workflow redesign, third-party audit - December 2027 is now enough time to do it, provided the discovery happens in 2026 rather than in the final quarter. The failure mode has changed shape: it is no longer running out of clock, it is starting the inventory so late that the clock runs out anyway. Where a gap genuinely cannot be closed, document your findings, your assessment, and your remediation plan with a realistic timeline. Regulators in the early enforcement period are more likely to treat a documented remediation commitment favourably than an organisation with no evidence of awareness at all. This is not a legal opinion - consult your counsel - but it reflects how early-stage regulatory enforcement typically works in practice.

How ProDataAI Can Help

We have been working on EU AI Act readiness with Mittelstand companies since 2024. What we have found consistently: the challenge is not understanding the regulation - it is translating the regulation into what it means for specific systems, specific teams, and your actual governance context. That translation work is what we do.

AI Inventory & Classification Assessment

We map every AI system in your organisation - including AI embedded in vendor platforms your IT register may not reflect - and classify each one against the EU AI Act's risk tiers. We distinguish your deployer obligations from provider obligations (most Mittelstand companies are deployers, not providers, and conflating the two wastes significant compliance effort). Most organisations spend weeks building their inventory; our structured discovery process produces a documented, classified inventory in two to four weeks.

Article 4 AI Literacy Program

We design and deliver proportionate literacy training for your teams - from general staff using productivity AI daily to technical staff deploying and maintaining AI systems. Proportionate means the training content and depth match the AI each role actually works with. We produce the attendance records and coverage documentation you need to demonstrate compliance to a regulator. This is typically a one- to two-week engagement and does not require an external e-learning platform.

Governance Integration - GDPR to AI Act

If you have mature data governance infrastructure - GDPR processing registers, accountability frameworks, audit trails - we extend it to cover AI-specific obligations rather than building parallel compliance processes. This is the most efficient path for organisations with existing governance maturity. The organisations that arrive in December 2027 most prepared are almost always the ones that treated EU AI Act as an extension of existing governance, not a separate project.

Betriebsrat Coordination

We work alongside your employment law counsel to address the intersection of EU AI Act compliance and works council co-determination requirements under BetrVG. We produce the technical documentation that satisfies both frameworks - the conformity evidence the Act requires and the transparency documentation that accelerates Betriebsvereinbarung negotiations. International compliance frameworks ignore this layer entirely; we have built it in from the start.

High-Risk Documentation & Oversight Design

For confirmed high-risk systems, we produce the technical documentation, accuracy assessments, and oversight mechanism design required under Article 26. We also design the audit logging and workflow changes needed to make human oversight demonstrable - not just stated in policy. If a high-risk system cannot be fully remediated in time, we help you build a documented risk acceptance and remediation timeline that demonstrates awareness and a credible compliance path.