EU AI Act: Obligations, Risk Classes and the New Timeline

Which systems and uses does the EU AI Act cover?

The EU AI Act is Regulation (EU) 2024/1689, formally the regulation laying down harmonised rules on artificial intelligence, and in German usage the KI-Verordnung. It entered into force on 1 August 2024 and is the first comprehensive legal framework for artificial intelligence. Its scheme is that of product law: obligations attach not to an industry but to the individual AI system, to its intended purpose, and to the role an organisation plays in relation to it.

The scope is drawn widely. An AI system within the meaning of the regulation is a machine-based system that operates with some degree of autonomy, that may exhibit adaptiveness after deployment, and that infers from the input it receives how to generate outputs: predictions, content, recommendations or decisions capable of influencing physical or virtual environments. Classic rule-based software therefore regularly falls outside it; a bought-in assistant built on a language model, a CV screening tool or a forecasting component inside a line-of-business application very much does not.

The regulation also reaches beyond the borders of the Union. It captures providers established outside the EU where their system is placed on the market or put into service in the Union, or where the output produced by the system is used in the Union. For companies that mainly use tools from non-European vendors, the origin of the vendor therefore changes nothing about their own role as deployer.

Excluded are, among other things, systems developed and used exclusively for military purposes, for defence or for national security, as well as pure research and development prior to placing on the market. Private, non-professional use by natural persons also stays outside. In day-to-day corporate practice these exclusions are rarely in point; the assessment normally ends at the question of intended purpose, not at the question of scope.

The roles

The distinction that governs is between the provider, who develops an AI system and places it on the market under their own name or trade mark, and the deployer, who uses a system under their own authority. Importers, distributors and product manufacturers come in addition. For most companies it is the deployer role that is in point, with one qualification that follows the logic of product law: whoever offers a bought-in system under their own name, substantially changes its intended purpose, or substantially modifies a high-risk system may become a provider themselves, and then carries the full programme of obligations.

Which risk classes does the EU AI Act define?

The regulation sorts AI systems by the risk they present. That classification is the decisive fork in the road: it determines whether a system is prohibited, subject to extensive requirements, merely required to be labelled, or left outside any specific obligation.

What is prohibited, and what July 2026 added

The Article 5 catalogue is the only part of the regulation that simply forbids a behaviour rather than attaching conditions to it. It has applied since 2 February 2025 and covers, among other things: manipulative or deceptive techniques that materially distort behaviour; exploitation of vulnerability arising from age, disability or social or economic situation; social scoring; predicting criminal offences solely on the basis of profiling or personality traits; untargeted scraping of facial images from the internet or CCTV to build databases; emotion recognition in the workplace and in education, with an exception for medical and safety reasons; biometric categorisation to infer protected characteristics; and, again with narrowly drawn exceptions, real-time remote biometric identification in publicly accessible spaces for law enforcement purposes.

The July 2026 amending regulation extended that catalogue by two grounds, inserted into Article 5(1), first subparagraph, as points (ba) and (bb): AI systems that generate or manipulate realistic intimate or sexually explicit depictions of an identifiable person without that person's consent, and systems that generate or manipulate material within the meaning of Directive 2011/93/EU. Those two grounds, together with the interpretive rules in the new Article 5(1a) and (1b), carry their own start date: under Article 113, third paragraph, point (a) as amended, they apply from 2 December 2026.

For providers the reach of the new prohibitions is narrower than the wording first suggests. Under Article 5(1a), placing a system on the market is prohibited only where generating such content is the system's intended purpose, or where its design, training, architecture, capabilities or user-facing functionality make that a reasonably foreseeable and reproducible outcome without significant technical modification and the system lacks reasonable and adequate technical safeguards against it. For deployers the prohibition bites only where they use the system for exactly that purpose. Anyone offering a generative system should therefore have documented the safeguards in place, and their effectiveness, before 2 December 2026.

For general-purpose AI models the regulation carries its own chapter, with duties covering technical documentation, information for downstream providers and copyright; for models with systemic risk, further requirements come on top. For companies that merely use such models these duties matter indirectly: they determine what information you can expect from your model provider.

Which deadlines apply after the Digital Omnibus?

This is where the currently widespread misreading is settled. Regulation (EU) 2026/1744, formally the Digital Omnibus on AI, was adopted on 8 July 2026, published in the Official Journal on 24 July 2026 and, taking effect on the third day after publication, entered into force on 27 July 2026. Alongside the AI Act it also amends Regulations (EU) 2018/1139 and (EU) 2023/1230. It postponed the applicability of the high-risk requirements and tightened the high-risk classification.

What moved were the high-risk dates alone. The date of general applicability, 2 August 2026, is unchanged.

Anyone who took from the coverage in the summer of 2026 that the AI Act had been postponed is wrong for the greater part of corporate practice. What is prohibited stays prohibited, and has done since February 2025. AI literacy under Article 4 has been required since then too. And the transparency duties under Article 50 have applied since 2 August 2026, concerning precisely the applications that are in broad use in companies today: customer-facing chatbots, generated images in communications, synthetic voice output. For systems already on the market there is a separate, clearly dated transitional period that is easily missed: the newly added Article 111(4) gives providers of AI systems generating synthetic audio, image, video or text content that were placed on the market before 2 August 2026 until 2 December 2026 to comply with Article 50(2). That is four months, and they are already running.

The postponement actually means a different planning horizon for high-risk projects. Two years sounds comfortable, and is not, where data quality and data governance, a risk management system across the life cycle, logging, human oversight, a quality management system and a conformity assessment all still have to be built. Add to this that the technical standards meant to give these requirements substance are not yet fully available, which is a reason to document your own interpretation early rather than wait for them.

The amending regulation also drew the high-risk classification more narrowly, and the clarification is specific enough to overturn an existing classification. Three paragraphs were inserted into Article 6:

• Paragraph 1a: AI systems used solely for non-safety-related aspects of user assistance, performance optimisation, service efficiency, automation, convenience or quality control do not qualify as safety components.
• Paragraph 1b: conversely, systems whose failure or malfunction would endanger health and safety do qualify as safety components. Paragraph 1a is therefore not a blanket exemption but a boundary drawn along safety relevance.
• Paragraph 1c: a product required to undergo third-party conformity assessment solely because of risks other than to health and safety (radio frequencies or electromagnetic interference, for instance) does not meet the condition in Article 6(1)(b).

Relief on evidence comes on top. The second subparagraph of Article 11(1) now lets SMEs, including start-ups, and small mid-cap companies provide the Annex IV technical documentation in a simplified manner using a form the Commission is to establish, and notified bodies must accept that form for the conformity assessment. Article 17(2) puts the quality management system expressly under a proportionality qualifier tied to the size of the provider's organisation.

A classification made before July 2026 should therefore be re-examined; today it may come out differently, above all for embedded systems that were carried as safety components across the board.

What obligations do providers and deployers of AI systems have?

The requirements for high-risk systems are distributed asymmetrically. The weight sits with the provider; the deployer carries a markedly leaner but self-standing set of duties.

Irrespective of the risk tier, the transparency duties of Article 50 have applied since 2 August 2026. They are comparatively simple to implement and are nonetheless frequently overlooked: individuals must be informed that they are interacting with an AI system, unless that is obvious. Synthetically generated image, audio, video or text content is to be marked in a machine-readable form. Deployers who publish deep fakes must disclose that they were artificially generated; comparable rules apply to AI-generated text on matters of public interest. Anyone using emotion recognition or biometric categorisation must inform the individuals concerned.

When Article 50 does not bite

The practically important question about Article 50 is not what has to be marked but what does not. The regulation answers it in the text of the provision itself, and the exceptions are wider than everyday impressions suggest:

The first row is the one that relieves day-to-day operations. A tool that runs a spell check, removes noise from a recording or reformats a text does not substantially alter the semantics of the input and therefore triggers no marking duty. The fourth row is the one editorial organisations can rely on, but it demands both limbs: the review and a named editorial responsibility. Whoever relies on one of these boundaries should record, per use case, which exception is being relied on; the reasoning is the evidence.

For certain deployers, in particular public bodies and entities providing public services, the regulation additionally provides for a fundamental rights impact assessment when a high-risk system is put to use.

On penalties: the regulation provides tiered fine ranges that, depending on the infringement, attach either to fixed maximum amounts or to a share of worldwide annual turnover. The most severe range applies to the prohibited practices. Enforcement runs through the national market surveillance authorities; at Union level the AI Office coordinates, in particular for general-purpose models.

How do you meet the AI literacy duty and set up AI governance?

Since 27 July 2026, as amended by Regulation (EU) 2026/1744, Article 4(1) requires providers and deployers to take measures to support the development of AI literacy of their staff and other persons dealing with the operation and use of AI systems on their behalf; it expressly does not require them to guarantee any specific level. The provision applies irrespective of the risk tier and has been applicable since February 2025.

A formal certificate is not what the article calls for. The yardstick is the technical knowledge, experience and education of the people concerned, the context of use, and the groups of people the systems are used on. In practice, role-specific, documented training works well: whoever selects and approves systems needs different content from whoever operates them daily. Without evidence the duty cannot be shown to have been met in a supervisory procedure; attendance lists, content and dates therefore belong on file.

Governance beyond training means, above all, taking decisions at a defined place. A written policy on AI use has proven itself: clear prohibitions and permitted use cases, an approval process for new systems, named business owners per system, and a connection into the existing bodies for information security, data protection and compliance. Anyone wanting to build that structure along a standard will find in ISO/IEC 42001 a management system standard for artificial intelligence that follows the same structure as other management system standards. It is not evidence of conformity under the AI Act, but it can serve as an ordering framework.

How do you build an AI inventory?

Every obligation in the regulation presupposes that you know which AI systems you use, and in which role. The inventory is therefore the first step, and at the same time the only one that cannot be delegated.

The hard part is not the table but the completeness. Three sources tend to get you there:

1. Review the software you already have. The greater part of the AI in a company was not purchased but arrived as a feature update inside applications already in use: office suites, CRM systems, ticketing tools, HR software. Work through the application estate systematically.
2. Ask the business functions. A short, concretely worded survey brings in more than a general appeal. Ask about tools, not about the term artificial intelligence.
3. Mine procurement. Invoices, card transactions and subscriptions reveal the systems that were introduced without IT involvement.

Per system, the inventory should record at least:

For the classification, a short but written justification will do in most cases. What matters is less the legal fine work than the traceability: who decided, on what factual basis, and when. Systems whose classification remains unclear after the July 2026 amendment belong on a separate list for legal review rather than being treated as high-risk as a precaution. Over-classification ties up effort that other systems need more urgently.

An inventory taken only once is out of date within a quarter. Tie it to the approval process for new systems and to a fixed review cycle. The effort pays twice over: the same register answers the supervisor's questions, the data protection questions, and the questions customers now routinely ask about AI use in supplier audits.

How does the EU AI Act relate to the GDPR?

The AI Act does not displace the GDPR. Both apply side by side, with different protective aims: the AI Act governs the system, its safety and its effects; the GDPR governs the processing of personal data. An AI system can be permissible under the AI Act and at the same time unlawful in data protection terms, where a legal basis, purpose limitation or transparency is missing.

The practical points of contact are reasonably easy to separate:

• Legal basis and purpose limitation for training as much as for operation are a purely data protection question; the AI Act does not answer it.
• Article 30 GDPR: the use of an AI system that processes personal data is to be entered in the record of processing activities as a processing activity. The AI inventory and the record should cross-refer rather than sit side by side.
• Article 35 GDPR: for systems that interfere with the rights of data subjects, a data protection impact assessment is frequently in point. It does not replace the fundamental rights impact assessment under the AI Act, but overlaps with it substantially in content.
• Article 22 GDPR: automated decisions with legal effect are subject to their own regime, including a right to human intervention, irrespective of how the system is classified under the AI Act.
• Article 28 GDPR: cloud-based AI services are regularly processing on behalf of a controller. Check in particular whether inputs may be used to improve the model.
• Article 32 GDPR: the technical and organisational measures apply unchanged; the AI Act's requirements on robustness and cybersecurity come alongside them.

For implementation this yields a welcome simplification: the first step is the same under both regimes. A complete inventory of the systems in use, with intended purpose, data categories and role allocation, carries the obligations of the AI Act and the accountability duties of the GDPR at once.

This article is general orientation and does not replace legal advice. What governs is Regulation (EU) 2024/1689 and amending Regulation (EU) 2026/1744, each as in force.

AI systems in Rizzqo

In Rizzqo the AI Act is present as a taxonomy on the asset model, meaning a structure for classifying AI systems. ISO/IEC 42001 is supported as well: its control catalogue is imported when a customer needs it, and its requirements then attach to the AI systems they concern.

The foundation is the inventory, and for AI systems it is unusually hard to survey, because such systems often arise inside business units. In Rizzqo an AI system is an asset like a business process, and the models, data sources, training and operating environments and the providers involved hang beneath it as supporting objects, each with a category and a named owner. Which categories of personal data reach into such a system follows from the primary assets above it and is passed along the chain, and the technical and organisational measures are answered and evidenced on those same objects.

For classifying by risk category that inventory supplies the factual basis: which systems exist, what they are used for and who is accountable for them is settled before the legal assessment starts.