The Pyramid of Risk: How the EU AI Act Tames Artificial Intelligence – and Why It Concerns the Whole World

The Hook: One Piece of Code, Three Legal Realities

Imagine you build three software products. The first is a spam filter that sorts incoming email. The second is a chatbot that answers customer questions on a website. The third is a system that automatically ranks job applicants from their résumés and recommends to the HR department whom to invite. Technically, all three are "just" machine learning – models that recognize patterns in data and derive predictions from them. From an engineer's point of view, they differ in training data, architecture, and accuracy, not in their fundamental nature.

From the European legislator's point of view, however, these three systems could hardly be more different. The spam filter is essentially unregulated. The chatbot is subject to a single, mild obligation: it must make clear that you are talking to a machine. The applicant-ranking system, by contrast, falls into the strictest regulated category of all – it is a high-risk system in the sense of the EU AI Act, and its provider must establish risk management, demonstrate data governance, maintain technical documentation, enable human oversight, keep logs, and run a quality management system. Violations expose it to fines in the millions.

The same technical toolkit, three completely different legal worlds. This is exactly the core idea of the EU AI Act (officially: Regulation (EU) 2024/1689), the first comprehensive law to regulate artificial intelligence anywhere in the world. It does not regulate the technology as such, but the application context and the associated risk. And because the EU, with over 440 million consumers, represents one of the largest markets in the world, this law affects not only European firms but every company worldwide whose AI output is used in the EU – a phenomenon legal scholars call the "Brussels Effect."

For someone like Sven – a Senior AI Engineer with one foot in software architecture and one in IT security – the AI Act is not an abstract political matter but a piece of his own profession's infrastructure. It decides what documentation an AI feature needs before it goes live, which use cases are better left unbuilt, and what evidence you must produce in an audit. This article takes you the whole way: from the core idea of the risk-based approach through the four tiers of the risk pyramid, the prohibited practices, the high-risk obligations, and the special rules for "general-purpose AI," to the penalties – and ends with the single most important current development: the Digital Omnibus, which has just reshuffled the 2025/26 timeline.

Part 1: Why a Law for AI? The Risk-Based Approach

Don't Regulate the Technology – Regulate the Harm

The obvious but wrong way to regulate AI would be to target the technology itself: "Neural networks with more than X parameters require a license." Such a law would be obsolete within months and would lump harmless and dangerous applications together. The EU AI Act takes a different route, familiar from product safety law: it does not ask "How does the system work?" but "What can go wrong, and how bad would it be?"

From this follows the guiding principle: the higher the risk to health, safety, and fundamental rights, the stricter the obligations. An AI system that helps decide access to a loan, a job, or a social benefit can profoundly affect a person's life – and is treated accordingly strictly. An AI system that controls enemies in a video game cannot – and remains free. The same underlying technology, but a completely different regulatory treatment, because the potential harm differs.

The Temporal Frame and Legal Nature

The AI Act is a regulation, not a draft directive. This matters legally: an EU regulation applies directly in all member states without first having to be transposed – as a directive would – into national law. This distinguishes the AI Act from, say, the NIS2 directive, whose concrete shape varies from country to country. With the AI Act, essentially the same text applies everywhere.

The regulation entered into force on 1 August 2024, but does not apply in full immediately; instead it applies in staggered phases – more on this later. This staggering is deliberate: it gives companies time to prepare and the EU time to build the necessary technical standards and authorities (above all the new AI Office within the European Commission).

Part 2: The Four Tiers of the Risk Pyramid

The heart of the AI Act is a classification of every AI application into one of four risk tiers. It is best pictured as a pyramid: broad and barely regulated at the bottom, narrow and either tightly controlled or outright banned at the top.

The most important observation about this pyramid: the great mass of all AI applications sits at the bottom and remains unregulated. The AI Act is not a law that puts every line of machine learning under supervision; it concentrates its severity on a comparatively small number of clearly delineated, especially consequential use cases. This is a deliberate design choice – and at the same time the reason why correctly classifying a system is the first and most important compliance task. Once a system is in the high-risk category, the entire development process changes.

Part 3: The Forbidden Peak – Unacceptable Risk (Art. 5)

At the top of the pyramid sit practices the legislator considers so dangerous to fundamental rights that no risk management could justify them. They are simply prohibited and have been banned since 2 February 2025. Among them:

• Subliminal or manipulative techniques that distort people's behavior so that they can no longer make informed decisions, thereby causing significant harm.
• The exploitation of vulnerabilities based on age, disability, or socio-economic situation to distort behavior.
• Social scoring, i.e. evaluating or classifying people based on their social behavior or personal traits in a way that leads to detrimental treatment.
• Predicting the risk of criminal behavior based solely on profiling or personality traits (predictive policing in the narrow sense).
• Building facial recognition databases through untargeted scraping of images from the internet or surveillance cameras.
• Inferring emotions in the workplace and in educational institutions (except for medical or safety reasons).
• Biometric categorization that infers sensitive attributes (e.g. ethnic origin, political opinion, sexual orientation).
• Real-time remote biometric identification in public spaces for law enforcement – with narrowly defined exceptions (searching for missing persons, averting a concrete terrorist threat, identifying suspects of serious crimes), which additionally require prior authorization and a fundamental rights impact assessment.

This list reads like a catalogue of dystopian surveillance scenarios – and that is exactly the intent. The EU draws a red line here that holds regardless of economic benefit or technical feasibility.

Notably, this list is not static. As part of the Digital Omnibus (see Part 7), Article 5 is expected to be supplemented with a new prohibition: AI systems for generating non-consensual intimate imagery ("nudifiers") and child sexual abuse material. This shows that the prohibited zone grows along with technological reality.

Part 4: The Heart of the Matter – High-Risk Systems (Annex III, Art. 8–17)

By far the largest part of the legal text is devoted to the second tier: high-risk AI systems. This is where the actual regulatory work lies, and where most commercially relevant AI applications with societal reach end up.

How a System Becomes "High Risk"

There are two routes into this category. The first: the AI system is a safety component of a product that is already subject to EU law and requires third-party assessment (Annex I – e.g. medical devices, machinery, toys, vehicles). The second, more important route for software companies: the system falls under one of the use cases in Annex III. These include:

• Biometrics (where not already prohibited): remote identification, emotion recognition, biometric categorization.
• Critical infrastructure: AI as a safety component for water, gas, electricity, traffic, digital infrastructure.
• Education: systems deciding access, admission, or assessment of learners, or monitoring exams.
• Employment: systems for recruitment, applicant selection, promotion, termination, and performance evaluation – this is where the applicant-ranking system from the hook lands.
• Essential services: creditworthiness checks, eligibility for social benefits, risk assessment and pricing in life and health insurance, prioritization of emergency calls.
• Law enforcement, migration, and justice: risk assessments, evaluation of evidence, examination of asylum and visa applications, interpretation of the law.

An important subtlety: even if a system formally falls under Annex III, it can be deemed not high-risk if it performs only a narrow procedural task, merely improves the result of human work, or carries out a purely preparatory task – provided it does not profile individuals. Anyone invoking this exemption, however, must document that assessment before placing the system on the market. The burden of proof lies with the provider.

The Eight Obligations of High-Risk Providers

If a system is classified as high-risk, its provider (i.e. the developer) is subject to eight core obligations under Art. 8–17. To an experienced software engineer they read like a checklist for serious engineering – only now legally binding:

Anyone coming from IT security will immediately recognize the parallel to standards like ISO 27001 or to the Secure Development Lifecycle: this is not about a one-time checkmark, but a lasting, documented process. The difference is that human oversight, data governance, and a fundamental-rights orientation become first-rank, enforceable requirements here – not afterthoughts.

Before a high-risk system may enter the market, it must also undergo a conformity assessment and – for many use cases – be registered in an EU database. Only then may it bear the CE-like mark of conformity.

Part 5: General-Purpose AI – the Special Category of Foundation Models

When the AI Act was first proposed in 2021, almost no one was thinking of ChatGPT. The explosive spread of large language models from late 2022 forced the legislator to retrofit a separate category that cuts across the risk pyramid: General-Purpose AI (GPAI) – models that do not pursue a single goal but display "significant generality" and can be integrated into countless downstream applications – the foundation models behind chatbots, image generators, and coding assistants.

Two Tiers for GPAI

Here too a graduated logic applies. All GPAI providers must meet four basic obligations: draw up technical documentation, provide information for downstream developers, have a policy for complying with EU copyright law, and publish a "sufficiently detailed summary" of the training data. The last point is remarkable: for the first time, the EU demands a degree of transparency about what a model was trained on – a direct incursion into the previously closely guarded black box of training corpora. (Providers of free and open-source models need only meet the latter two obligations – unless their model poses systemic risk.)

Systemic Risk and the 10^25 FLOP Threshold

The upper tier concerns GPAI models with systemic risk – models whose capabilities are so far-reaching that their effect can "scale up" across the entire value chain. The legislator needed an objective, verifiable criterion and chose a strikingly concrete technical threshold: a model is presumed to pose systemic risk if the cumulative compute used for its training exceeds 10^25 floating-point operations (FLOP).

This number is a deliberate regulatory bet: compute serves as a coarse but measurable proxy for model capability. I am of the opinion that this FLOP threshold is conceptually elegant but fragile in the long run – algorithmic efficiency gains mean that future models below the threshold could be similarly capable, so the threshold serves better as a starting point than as a permanent boundary. If a provider crosses the threshold, it must notify the Commission within two weeks; only a small group of currently an estimated five to fifteen companies worldwide falls under it at present.

For these frontier models, additional obligations apply: model evaluations and documented adversarial testing (red-teaming), assessment and mitigation of systemic risks, reporting of serious incidents to the AI Office, and an adequate level of cybersecurity.

The Code of Practice – Voluntary, but with Incentive

To make these abstract obligations workable, the AI Office facilitated a General-Purpose AI Code of Practice, whose final version appeared in 2025. It is organized into three chapters: Transparency and Copyright (for all GPAI providers) and Safety and Security (only for models with systemic risk). Participation is voluntary – but those who sign the code receive a presumption of conformity: regulators then assume the obligations are met, which reduces bureaucracy and creates legal certainty. Those who do not sign must demonstrate their compliance by other, more onerous means. A classic mechanism that, without coercion, generates a strong pull toward self-commitment.

Part 6: The Teeth of the Law – Penalties (Art. 99)

A law is only as effective as its enforcement. The AI Act tiers its fines into three levels, each as "whichever is higher" between a fixed amount and a percentage of worldwide annual turnover – a mechanism familiar from the GDPR and deliberately designed to reach even large corporations:

Noteworthy is the safeguard clause for small and medium-sized enterprises (SMEs) and start-ups: for them, the lower of the two values applies, not the higher. This is meant to prevent a percentage-based maximum fine from ruining a young company while barely affecting a tech giant.

For comparison: the sharpest GDPR fine stands at €20 million or 4% of turnover. The AI Act's top fine (€35 million / 7%) exceeds it – a clear signal of how seriously the EU takes prohibited AI practices.

Part 7: The Timeline – and the Digital Omnibus That Rewrites It

The Original Staggering

As mentioned, the AI Act does not apply all at once but in phases, counted from its entry into force on 1 August 2024:

The Digital Omnibus: Braking on the Home Stretch

Here comes the most important current development – and a lesson that regulation is a living process. Over the course of 2025, concern grew that the necessary technical standards and administrative infrastructure would not be ready in time for 2 August 2026 to allow high-risk providers fair compliance. On 19 November 2025, the European Commission therefore tabled the Digital Omnibus – a package to simplify and stretch out digital regulation.

After tough negotiations, the Council and Parliament reached a provisional political agreement in early May 2026 (the Council's press release is dated 7 May 2026). The most important changes to the AI Act:

• Postponement of the high-risk obligations. Application for stand-alone high-risk systems under Annex III is deferred from 2 August 2026 to 2 December 2027; for systems embedded in products under Annex I, from 2 August 2027 to 2 August 2028.
• New prohibition. Article 5 is supplemented – as mentioned in Part 3 – with a ban on AI-generated non-consensual intimate imagery and abuse material. Stricter where it counts.
• Relief for smaller actors. Certain exemptions that previously applied only to SMEs are extended to "small mid-caps"; in narrowly defined cases, requirements are reduced.

Important for context: I am of the opinion that this postponement is no cause for relief but rather signals the opposite. The legislator is deferring the deadline precisely because it expects compliance preparation to be already underway – more time is not a deferral of starting, but a deferral of being finished. And a formal caveat: the new dates only bind once the Digital Omnibus is published in the Official Journal of the EU; formal adoption was expected before 2 August 2026. Until then, the old deadlines formally apply. Anyone wanting to play it safe plans according to the original dates and treats the postponement as a buffer, not a plan.

Part 8: What This Means in Practice – the Brussels Effect and the Engineer's View

Extraterritorial Reach

Perhaps the most important practical point: the AI Act applies not only to EU companies. It captures every provider that places an AI system on the market or puts it into service in the EU, as well as – and this is the far-reaching part – every provider from a third country whose AI output is used in the EU. A US start-up whose scoring model is deployed by a European customer falls under it. This is the Brussels Effect: because the EU market is too large to ignore, and because it is more expensive to maintain two separate product variants, globally operating firms often adopt the EU standard as their worldwide standard. The GDPR demonstrated this for data protection; the AI Act aims for the same leverage with AI.

Three Concrete Consequences for Daily Work

First: Classification is the first obligation. Before building an AI feature, you must know which risk tier it falls into. This question belongs at the start of the design, not its end – a retroactive classification as "high-risk" can call an entire architecture into question.

Second: Documentation is not an afterthought but an obligation. The required technical documentation, data governance, and logging cannot be invented retroactively. Whoever cleanly documents from the start which data trained a model, how it was evaluated, and how human oversight works has already met most of the high-risk obligations. This aligns strikingly with what good engineering demands anyway.

Third: AI literacy is mandatory. Since February 2025, providers and deployers must ensure that their staff have sufficient "AI literacy" – an often overlooked but immediately applicable point that makes training and awareness a legal duty.

An honest assessment of the evidence to close: the AI Act is a young law whose practical interpretation will only sharpen over the coming years through AI Office guidelines, harmonized standards, and ultimately court decisions. Much of what stands as a requirement today will only acquire its final contour through this practice. I am of the opinion that the greatest uncertainty currently lies not in the legal text but in the question of how strictly and how uniformly national supervisory authorities will interpret it – and that is exactly what makes a conservative, documentation-friendly approach the smartest strategy.

The Central Takeaway

The central, transferable insight of the EU AI Act is a single, simple idea with enormous leverage:

What is regulated is not the technology, but the risk of its use. The same algorithm can be unregulated, subject to transparency, strictly controlled, or prohibited – depending solely on what it is used for and what harm threatens. Anyone who builds or deploys AI must therefore first answer a legal question before asking a technical one: which risk tier does this system fall into? This classification decides documentation duties, oversight mechanisms, conformity assessments, and, in the worst case, fines in the millions.

Apply this to your own practice. The next time you design an AI feature that decides about people – their application, their loan, their access to a benefit – don't first ask "How do I best build this?" but "What happens if this system gets it wrong, and how would I prove to an authority that I took that possibility seriously?" The good news for engineers: most high-risk obligations – risk management, clean data, traceability, human control – are nothing other than the formalized description of responsible engineering. The AI Act makes what good developers should be doing anyway into a verifiable duty.

Reflection Question

Think of an AI system you've worked with in the past few months – one you built, integrated, or deployed yourself. Which of the four risk tiers would it fall into if you honestly checked it against the use cases in Annex III? And the more uncomfortable part: if an authority knocked tomorrow and demanded the technical documentation, the data governance, and proof of human oversight – how much of it could you produce today, and how much would you have to reconstruct first? Which one thing in your current development process would you change if you understood compliance not as a retroactive burden but as part of the design?

Cross-References in the Vault

• NIS2 and What It Really Means for Mid-Market IT Consulting Firms in Germany – The direct regulatory sibling: while the AI Act regulates AI by risk, NIS2 addresses the cybersecurity of critical sectors. Both share the risk-based approach, the duty to maintain documented management systems, and extraterritorial reach – and for an IT company, both must be thought of together.
• Harvest Now, Decrypt Later: Post-Quantum Cryptography and the Race Against the Quantum Computer – As with the AI Act, a standard-setting and compliance process is central here: regulators and standards bodies define what "state of the art" means for security, and companies must migrate early, long before the deadline bites.
• The Ghost in the Machine: How to Read a Neural Network From the Inside – The high-risk obligations on transparency, human oversight, and traceability presuppose that we understand what a model does internally. That very understanding is the research program of mechanistic interpretability – the technical foundation without which legally required "explainability" would remain an empty shell.

Sources

• European Union (2024): Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the EU, in force since 1 August 2024. https://eur-lex.europa.eu/eli/reg/2024/1689/oj
• Future of Life Institute: High-level summary of the AI Act. artificialintelligenceact.eu (updated per the corrigendum version). https://artificialintelligenceact.eu/high-level-summary/
• EU Artificial Intelligence Act: Article 99 – Penalties. https://artificialintelligenceact.eu/article/99/
• EU Artificial Intelligence Act: Annex III – High-Risk AI Systems and Article 51 – Classification of GPAI Models with Systemic Risk. https://artificialintelligenceact.eu/annex/3/ · https://artificialintelligenceact.eu/article/51/
• European Commission, DG CNECT: The General-Purpose AI Code of Practice and EU rules on general-purpose AI models start to apply. https://digital-strategy.ec.europa.eu/en/policies/contents-code-gpai
• Council of the EU (2026): Artificial intelligence: Council and Parliament agree to simplify and streamline rules (Digital Omnibus), press release of 7 May 2026. https://www.consilium.europa.eu/en/press/press-releases/2026/05/07/artificial-intelligence-council-and-parliament-agree-to-simplify-and-streamline-rules/
• Gibson Dunn (2026): EU AI Act Omnibus Agreement — Postponed High-Risk Deadlines and Other Key Changes. https://www.gibsondunn.com/eu-ai-act-omnibus-agreement-postponed-high-risk-deadlines-and-other-key-changes/

← All articles