EU AI Act Explained: What Your System Must Actually Do

TL;DR

• The EU AI Act (Regulation 2024/1689) entered into force in August 2024. The most consequential compliance deadlines fall in August 2026 (for Annex III use cases, including HR tools, credit systems, and education platforms) and August 2027 (for Annex I regulated products).

• High-risk AI systems must meet core compliance obligations under Articles 9–15 — including pre-deployment technical documentation, automatic event logging, functioning human oversight, and EU database registration — before they can legally go to market.

• Companies that treat compliance as an architecture constraint from the start avoid costly rebuilds later. Those that don’t are accumulating technical debt that surfaces at exactly the wrong moment.

The EU AI Act is not a proposal anymore. It entered into force in August 2024, and for most companies building or deploying AI systems, the hardest deadlines hit in 2026 and 2027. That’s closer than it sounds — especially if your architecture wasn’t designed with compliance in mind from the start.

This article is for founders, executives, and product leaders who are building and running AI-powered systems and need to understand, in plain terms, what the EU AI Act actually requires — not at a theoretical level, but at the level of architectural decisions, documentation, and operational processes.

We’ll cover how the risk classification works, which systems trigger full compliance obligations, what those obligations actually are (not just in summary). Also, we’ll consider what the compliance timeline means for your roadmap today. All referenced regulation text comes from the official EU AI Act source.

What the EU AI Act is — and what it isn’t

The EU AI Act (Regulation 2024/1689) is a behavioral regulation. It governs how AI systems function in deployment — not how data is collected or stored. That’s GDPR’s (General Data Protection Regulation) job. Both can apply to the same system at the same time, and often do.

The Act runs on a risk-based model. Obligations scale with the realistic harm a system could cause to individuals or society. The full classification framework is defined in Chapters II and III of the regulation.

Four categories of market participants carry obligations under the Act:

• Providers — companies that develop or bring AI systems to market under their own name
• Deployers — companies that put AI systems to work in a professional context
• Importers — entities that bring non-EU providers’ systems into the EU market
• Distributors — entities that make systems available without modifying them

Each role carries different obligations. Many companies are both providers and deployers — they build AI internally and operate it themselves — which means both obligation sets apply simultaneously.

On extraterritorial reach: if your AI system is placed on the EU market or its outputs affect people in the EU, you’re in scope — regardless of where your company is incorporated. A US startup with EU users faces the same regulatory requirements as a company headquartered in Berlin. There is no headquarters exemption, and no minimum-user-count threshold.

The Act also covers more than machine learning. Under Article 3(1), any system using statistical methods, logic-based approaches, or search algorithms to produce outputs that influence real-world decisions may qualify as an AI system. If you’re not certain whether your product qualifies, the answer is probably yes.

EU AI Act risk categories explained: where does your system actually land?

The risk model has four tiers. Where your system lands determines your documentation requirements, deployment checklist, ongoing obligations, and exposure to penalties.

Unacceptable risk: practices the Act bans outright

These prohibitions are already law — they took effect February 2, 2025. There was no transition period. Source: Article 5, EU AI Act. 

The banned practices include:

• Social scoring of individuals by public authorities
• Subliminal manipulation that bypasses conscious awareness to alter behavior
• Exploitation of vulnerabilities based on age, disability, or social situation
• Real-time remote biometric surveillance in public spaces for law enforcement (with narrow, court-authorized exceptions)
• Individual predictive policing based purely on profiling, without an objective factual basis
• Emotion recognition in workplace and educational settings — except for medical or safety purposes

If your system touches any of these use cases, that is the starting point for your compliance review.

High-risk AI — the category that changes everything

High-risk systems must meet the full compliance framework defined in Articles 9–15 of the Act. That framework covers eight specific EU AI Act requirements for high-risk AI systems: data governance documentation, pre-deployment technical documentation, automatic event logging, transparency to users and deployers, human oversight mechanisms, accuracy and robustness standards, cybersecurity controls, and registration in the EU AI database.

Two annexes define which systems qualify as high-risk.

Annex I covers AI integrated into regulated products: medical devices, machinery, aviation components, vehicles, toys, lifts, and personal protective equipment.

Annex III covers specific, named use cases across eight categories. The table below maps them directly from the regulation:

If your system touches hiring, credit, education outcomes, or any public-sector decision-making, treat it as high-risk until you have documented evidence to the contrary. Most teams that go through this exercise find they’ve been underestimating their exposure.

Limited risk — transparency without the full compliance stack

Limited-risk systems don’t face the full compliance framework, but the obligations they carry are functional requirements — they affect how you build the product interface, not just what you document.

The three key transparency obligations:

1. Chatbots and conversational AI must disclose to users that they are interacting with a machine — at the start of each interaction, not buried in terms of service.
2. Deepfakes and synthetic media (video, audio, image, text) must be labeled as AI-generated or AI-manipulated — with exceptions for clearly artistic or satirical content.
3. Emotion recognition and biometric categorization systems must notify individuals being assessed.

This is a design requirement. Your system’s interface must make disclosure unavoidable — not optional for the user to find.

Minimal risk — the space where most consumer AI lives

Spam filters, AI-powered game characters, content recommendation engines — most deployed AI falls here. No mandatory obligations apply under the Act. The European AI Office is developing voluntary codes of conduct for this category, and adoption signals good-faith AI governance. For companies building across multiple product lines, some systems may be low-risk, while others may be high-risk — so a full inventory still matters.

EU AI Act compliance timeline: every deadline that changes your roadmap

The Act phases in across three years. The EU AI Act compliance deadlines 2026 and 2027 are not filing dates — they are dates by which compliant systems must already be in operation.

The full phase-in schedule:

These dates should be on your engineering roadmap today — not your legal team’s calendar for 2026.

EU AI Act compliance deadline 2026: what “ready” means in practice

Being compliant by the deadline means your system was designed, documented, and operating in a compliant state before deployment — not that you completed a checklist on August 2nd.

The Act requires high-risk AI systems to undergo a conformity assessment before being placed on the market. For most Annex III systems, this is a self-assessment. But it requires complete technical documentation, validated training datasets, human oversight procedures, and logging infrastructure to already exist and be functioning. “Planned” does not satisfy the requirement.

Companies that start embedding EU AI Act compliance requirements into their systems now avoid an architectural re-do at the worst possible moment: when they’re scaling into new markets and enterprise deals. Those that wait face both a compressed timeline and the harder engineering problem of retrofitting auditability into a system that was never built for it.

AI and GDPR compliance: where the two frameworks intersect

GDPR governs how you collect and process personal data. The EU AI Act governs how your AI system behaves. When a system uses personal data to make decisions about individuals — which most high-risk AI does — both frameworks apply simultaneously. AI and GDPR compliance are not separate workstreams.

The most consequential intersection points:

• Article 22 GDPR (automated decision-making): Individuals have the right not to be subject to purely automated decisions that significantly affect them, unless they have given explicit consent, a contract exists, or a legal basis applies. The EU AI Act’s human oversight requirements for high-risk systems directly reinforce this.
• Right to explanation: GDPR Articles 13–14 require individuals to be informed about the logic involved in automated processing. EU AI Act Article 13 requires high-risk systems to provide sufficient transparency for deployers to interpret outputs — and affected individuals to understand decisions.
• Lawful basis for training data: If your AI was trained on personal data, that data must have been collected under a valid GDPR lawful basis. Using data collected for one purpose to train an AI system for another may require a new legal basis or fresh consent.

For teams already managing GDPR compliance, your existing data governance infrastructure is a starting point — not a complete answer — for what the AI Act now requires. We cover the GDPR side of AI in a separate article. For the AI data governance layer that both frameworks depend on, the structural requirements overlap significantly.

EU AI Act fines for non-compliance: the penalty structure

Three tiers define the enforcement architecture. In each case, the higher of the two amounts — the fixed maximum or the percentage of turnover — is the one that applies.

For context: the EU AI Act’s maximum fines for non-compliance at the top tier are 7% of global annual turnover, exceeding GDPR’s 4% ceiling.

For SMEs (small and medium enterprises) and startups: the fixed-cap amounts may appear manageable. The percentage-of-turnover calculation is what matters for growing companies — particularly those with significant enterprise contracts or EU market exposure. Enforcement falls to national supervisory authorities in each EU member state. The European AI Office oversees enforcement for GPAI (General-Purpose AI) model providers.

The architecture problem nobody talks about

The EU AI Act’s obligations reveal a deeper issue that deadlines alone don’t capture. Most AI systems deployed today were built to perform — to optimize a metric, automate a workflow, or generate a prediction. Logging, explainability, versioning, and human intervention interfaces were afterthoughts. For systems built that way, adding compliance later means rebuilding core components.

Companies entering EU AI Act readiness processes with the most difficulty tend to share a common profile:

• Models built in notebooks that were never productionized properly
• No version control on trained models, only on source code
• No ability to trace a specific prediction back to the training data that influenced it
• Logging infrastructure that lives inside application logs rather than at the model layer
• Human review interfaces built as optional UI elements, not required workflow gates

These are normal outputs of teams focused on getting to production quickly. Under the EU AI Act, they represent AI compliance risks — and those risks compound as you scale. The practical read: if you can’t answer “what model produced this decision, on what data, and why” within 24 hours, your architecture has a gap.

AI compliance strategy: four principles for building it in from the start

A compliance-aware architecture treats regulatory requirements as design constraints alongside performance, latency, and cost. The four principles that matter most in practice:

1. Model governance from day one. Every trained model is versioned, reproducible, and linked to the dataset version it was trained on. This is what the Act requires you to demonstrate — not just that a model exists, but that you can account for its lineage. For a structured approach to this, see our guide on AI data governance for enterprise AI.
2. Logging at the model layer. Inference logs, input data summaries, confidence scores, and decision outputs must be captured at the model serving layer — not reconstructed from application logs after the fact. Reconstructed logs do not satisfy Article 12 requirements.
3. Human oversight as a system component. The human review step is a required gate in the workflow. The system cannot proceed without human sign-off in designated decision classes. This is an architecture decision that must be made before you build the interface, not after.
4. Explanation interfaces built alongside prediction interfaces. If a deployer or affected individual asks why the system produced a particular output, the answer must be retrievable — not reconstructed. For many ML (machine learning) architectures, meeting this standard for explainable AI requires deliberate choices from the start. A post-hoc explanation layer on an opaque model is not a substitute.

For teams in the early stages of this work, our industry-specific AI governance guide explains how these principles apply across regulated sectors.

How Corpsoft Solutions approaches EU AI Act compliance

Corpsoft Solutions has been designing AI systems for regulated environments before the EU AI Act was finalized. The compliance requirements described in this article are not new additions to our process — they are part of how we design production-grade AI from the start.

Our AI development practice is built on three principles that map directly to what the Act requires.

1. Auditability by design. Every model we build has version control, reproducibility guarantees, and inference logging built into the infrastructure. When a regulator asks which model produced a given decision on a given date, the answer is retrievable — not approximated from incomplete logs.
2. Explainability as a product feature. We build explanation interfaces alongside prediction interfaces — not as a layer added after deployment. This matters for EU AI Act compliance, and equally for enterprise deals: regulated-industry buyers require explainable AI before they’ll sign a contract.
3. Human oversight that actually works. We design human-in-the-loop workflows as required gates, not optional review steps. The interface surfaces the inputs, confidence levels, and model reasoning a human needs to make a real override decision — not just the prediction.

We work across AI consulting, AI solutions for businesses, and AI integration into existing systems for companies preparing for the EU AI Act. Our AI governance and compliance approach covers the regulatory environment across sectors. For companies starting from a gap assessment, AI compliance for business is a practical starting point.

If you’re evaluating whether your current architecture can support compliance without a full rebuild — that conversation starts with understanding where you are today.

Start with clarity on where you stand

The EU AI Act is specific about what’s required — but it doesn’t tell you what any of it means for your system in your context. That’s your work to do, and the earlier you do it, the more options you have.

A useful first step: work through the risk classification approach, and be honest about your current state of logging and documentation. Many companies discover they’re two or three architectural decisions away from compliance readiness — and knowing that now makes the difference between a manageable remediation and a full rebuild under deadline pressure.

The EU AI Act is specific and structured. For teams that start treating compliance as an architectural constraint, the cost is manageable. For those who wait, it compounds.

Share this post: