Why this object hangs off that object

Assess Article 5, Article 6 and Annex III in that order and document purpose, context and any Article 6(3) exception.

Hangs off: Annex III: high-risk AI

Editorially reviewed | high-risk

Assess origin, representativeness, errors and completeness and examine possible bias with appropriate mitigation.

Hangs off: Article 10: data and data governance

Editorially reviewed | high-risk-requirements

Document system description, development process, data, oversight measures, performance and risk management before market placement.

Hangs off: Article 11: technical documentation

Editorially reviewed | high-risk-requirements

Ensure the system automatically records events relevant to risk identification and post-market monitoring.

Hangs off: Article 12: logging and traceability

Editorially reviewed | high-risk-requirements

Describe capabilities, limitations, accuracy, oversight measures and expected lifetime in comprehensible form.

Hangs off: Article 13: transparency towards deployers

Editorially reviewed | high-risk-requirements

Determine oversight measures per system, appoint competent persons and give them the mandate to intervene or stop.

Hangs off: Article 14: human oversight

Editorially reviewed | high-risk-requirements

Determine appropriate accuracy, test robustness against errors and misuse, and take AI-specific security measures.

Hangs off: Article 15: accuracy, robustness and cybersecurity

Editorially reviewed | high-risk-requirements

Describe strategies, procedures and responsibilities for compliance, from design and data to post-market monitoring.

Hangs off: Article 17: quality management system

Editorially reviewed | high-risk-requirements

Determine for each role, system and context which combination of instruction, guidance, practice or training is appropriate.

Hangs off: Article 4: AI literacy

Editorially reviewed | ai-literacy

Before procurement, build or deployment, check whether the use case falls under a prohibited practice and stop or redesign early rather than after the fact.

Hangs off: Article 5: prohibited practices

Editorially reviewed | prohibited-practices

First determine which paragraph of Article 50 applies, then implement the specific transparency measure.

Editorially reviewed | transparency

Evaluate the model including adversarial testing, assess and mitigate systemic risks, report serious incidents and secure the model.

Hangs off: Article 55: GPAI models with systemic risk

Editorially reviewed | gpai-systemic-risk

Systematically collect and analyse real-world data on the system’s performance and compliance throughout its lifetime.

Hangs off: Article 72: post-market monitoring

Editorially reviewed | post-market

Define what a serious incident is, assign the reporting route to the supervisor and rehearse the process.

Hangs off: Article 73: serious incident reporting

Editorially reviewed | post-market

Identify and analyse known and reasonably foreseeable risks, evaluate them and take measures, repeating the cycle on every change.

Hangs off: Article 9: risk management system

Editorially reviewed | high-risk-requirements

Select the correct assessment procedure, draw up the EU declaration of conformity, affix the CE marking and register in the EU database.

Hangs off: Articles 43-49: conformity assessment, CE and registration

Editorially reviewed | conformity

Assess process, duration, affected persons, risks, oversight, mitigation and complaint mechanisms and notify results where required.

Hangs off: Article 27: FRIA

Editorially reviewed | fundamental-rights, high-risk

Maintain technical documentation, information for downstream providers, a copyright policy and a public summary of training content.

Hangs off: Article 53: GPAI model providers

Editorially reviewed | gpai

On white-labelling, substantial modification or purpose change, assess whether your organisation becomes the provider, and arrange the representative for non-EU supply.

Hangs off: Articles 22-25: value chain and authorised representative

Editorially reviewed | value-chain

The Commission office that supervises providers of general-purpose AI models. AI Office enforcement is active since 2 August 2026.

Editorially reviewed | enforcement, governance, gpai

A deployer of the relevant creditworthiness or life and health insurance systems in Annex III point 5(b) or 5(c).

Editorially reviewed | fundamental-rights, high-risk

An organisation using an AI system under its authority, excluding personal non-professional use.

Editorially reviewed | governance

A party that places a general-purpose AI model on the Union market.

Editorially reviewed | gpai

The national authority that supervises compliance with the Regulation and receives serious incident and risk notifications. Which body fills this role per Member State is not recorded in the graph.

Editorially reviewed | enforcement, governance

A party that develops or has an AI system developed and places it on the market under its own name.

Editorially reviewed | governance

A deployer that is a body governed by public law.

Editorially reviewed | fundamental-rights

A private deployer providing public services.

Editorially reviewed | fundamental-rights

The regulation entered into force on 1 August 2024, after which the obligations followed in phases.

Hangs off: Article 4: AI literacy, Article 5: prohibited practices

Placed against the official source | timeline

Since 2 February 2025 the Article 5 prohibition and the Article 4 AI literacy duty apply.

Hangs off: Article 4: AI literacy, Article 5: prohibited practices

Placed against the official source | ai-literacy, timeline

The voluntary code of practice gives GPAI model providers a route to demonstrate compliance.

Hangs off: Article 53: GPAI model providers

Placed against the official source | gpai

The Commission explains when someone becomes the provider of a GPAI model, including through fine-tuning.

Hangs off: Article 53: GPAI model providers, Article 55: GPAI models with systemic risk

Placed against the official source | gpai

The Commission draws the line between software that does and does not fall under the regulation.

Hangs off: Annex III: high-risk AI, Article 4: AI literacy

Placed against the official source | scope

Worked examples for each Article 5 prohibition, with the line between permitted and prohibited.

Hangs off: Article 5: prohibited practices

Placed against the official source | prohibited

Since 2 August 2025 the obligations for providers of general-purpose AI models apply.

Hangs off: Article 53: GPAI model providers, Article 55: GPAI models with systemic risk

Placed against the official source | gpai, timeline

The Commission explains in consultation when a system falls under Annex I or Annex III.

Hangs off: Annex III: high-risk AI, Articles 43-49: conformity assessment, CE and registration

Placed against the official source | high-risk

A voluntary route to comply with parts of Article 50, in two separately signable sections.

Placed against the official source | transparency

EN 18286:2026 on the quality management system is the first completed standard under the standardisation request.

Hangs off: Article 17: quality management system

Placed against the official source | standards

The Commission works out the transparency duties and confirms they apply from 2 August 2026.

Placed against the official source | transparency

The amended application date has been binding law since 27 July 2026.

Hangs off: Annex III: high-risk AI

Placed against the official source | high-risk

Since 27 July 2026 the organisational duty supports the development of AI literacy without guaranteeing an individual level.

Hangs off: Article 4: AI literacy

Placed against the official source | ai-literacy

The FRIA for the relevant Annex III route follows 2 December 2027 and may include or cross-reference relevant DPIA elements.

Hangs off: Article 27: FRIA

Placed against the official source | fundamental-rights, high-risk

The Digital Omnibus prohibits AI for child sexual abuse material and non-consensual intimate imagery.

Hangs off: Article 5: prohibited practices

Placed against the official source | prohibited, timeline

Models placed on the market before 2 August 2025 have until 2 August 2027.

Hangs off: Article 53: GPAI model providers, Article 55: GPAI models with systemic risk

Placed against the official source | gpai, timeline

AI as a safety component of products under Annex I follows on 2 August 2028.

Hangs off: Annex III: high-risk AI, Articles 43-49: conformity assessment, CE and registration

Placed against the official source | high-risk, timeline

Reopen classification when intended purpose, use context or system functionality changes materially.

Hangs off: Annex III: high-risk AI

Editorially reviewed | control, high-risk

Repeat the data quality assessment before every retraining or dataset change.

Hangs off: Article 10: data and data governance

Editorially reviewed | control, high-risk-requirements

Update the file before every release and retain earlier versions traceably.

Hangs off: Article 11: technical documentation

Editorially reviewed | control, high-risk-requirements

Periodically verify that logging works, is complete and is retained according to the regime.

Hangs off: Article 12: logging and traceability

Editorially reviewed | control, high-risk-requirements

At every deployment and update, verify instructions are present, current and internally translated.

Hangs off: Article 13: transparency towards deployers

Editorially reviewed | control, high-risk-requirements

Before go-live, test that intervening, stopping and disregarding output actually works and is assigned.

Hangs off: Article 14: human oversight

Editorially reviewed | control, high-risk-requirements

Monitor whether the system stays within declared levels in production and escalate on deviation.

Hangs off: Article 15: accuracy, robustness and cybersecurity

Editorially reviewed | control, high-risk-requirements

Periodically audit whether practice follows the described system and record deviations and improvements.

Hangs off: Article 17: quality management system

Editorially reviewed | control, high-risk-requirements

Check when systems, roles or risks change whether the selected measures remain appropriate.

Hangs off: Article 4: AI literacy

Editorially reviewed | ai-literacy, control

Repeat the screening for every new system, procurement and material change of purpose or context; an earlier clearance does not cover a new use.

Hangs off: Article 5: prohibited practices

Editorially reviewed | control, prohibited-practices

Before release, test that the applicable disclosure, marking or label is timely, clear and technically effective.

Editorially reviewed | control, transparency

Monitor cumulative training compute and notify the Commission when the threshold is reached.

Hangs off: Article 55: GPAI models with systemic risk

Editorially reviewed | control, gpai-systemic-risk

Ensure real-world signals (deviations, complaints, incidents) demonstrably lead to analysis and, where needed, measures.

Hangs off: Article 72: post-market monitoring

Editorially reviewed | control, post-market

Periodically test whether an incident can be reported within the legal deadlines, including the deployer-to-provider chain.

Hangs off: Article 73: serious incident reporting

Editorially reviewed | control, post-market

Reopen the risk management process on changes in purpose, data, model or use context and before every release.

Hangs off: Article 9: risk management system

Editorially reviewed | control, high-risk-requirements

Rerun the conformity route whenever the system is substantially modified.

Hangs off: Articles 43-49: conformity assessment, CE and registration

Editorially reviewed | conformity, control

Block deployment until applicability, assessment, mitigation and notification have been completed.

Hangs off: Article 27: FRIA

Editorially reviewed | control, fundamental-rights

Update documentation and downstream information when the model, capabilities or risks change.

Hangs off: Article 53: GPAI model providers

Editorially reviewed | control, gpai

Repeat the role assessment on every rebranding, modification or new use of an existing system.

Hangs off: Articles 22-25: value chain and authorised representative

Editorially reviewed | control, value-chain

Traceable rationale covering intended purpose, Annex III category, Article 6(3) assessment and registration decision.

Hangs off: Annex III: high-risk AI

Editorially reviewed | evidence, high-risk

Record per dataset of origin, choices, assumptions, bias examination and mitigations.

Hangs off: Article 10: data and data governance

Editorially reviewed | evidence, high-risk-requirements

Technical documentation kept current per system version, ready for a supervisor’s request.

Hangs off: Article 11: technical documentation

Editorially reviewed | evidence, high-risk-requirements

Log files with a retention period appropriate to the purpose and at least six months for deployers (Articles 19 and 26).

Hangs off: Article 12: logging and traceability

Editorially reviewed | evidence, high-risk-requirements

The received instructions for use plus their internal translation into work instructions per role.

Hangs off: Article 13: transparency towards deployers

Editorially reviewed | evidence, high-risk-requirements

Record of oversight measures, appointed persons, their training and the moments of intervention.

Hangs off: Article 14: human oversight

Editorially reviewed | evidence, high-risk-requirements

Declared accuracy levels, test results, and measures against data poisoning and adversarial attacks among others.

Hangs off: Article 15: accuracy, robustness and cybersecurity

Editorially reviewed | evidence, high-risk-requirements

The documented quality system with procedures, role assignment and references to the underlying files.

Hangs off: Article 17: quality management system

Editorially reviewed | evidence, high-risk-requirements

Versioned record of roles, context, measures, participation or instruction and review moments.

Hangs off: Article 4: AI literacy

Editorially reviewed | ai-literacy, evidence

A record per system that the Article 5 screening was performed, with outcome and reasoning. The conclusion "no prohibited practice" is evidence too.

Hangs off: Article 5: prohibited practices

Editorially reviewed | evidence, prohibited-practices

Record of scenario, actor, disclosure or marking, technical implementation, test and owner.

Editorially reviewed | evidence, transparency

Evaluation results, risk assessments, mitigations, incident reports and security measures per model version.

Hangs off: Article 55: GPAI models with systemic risk

Editorially reviewed | evidence, gpai-systemic-risk

The plan as part of the technical documentation plus the periodic analyses and follow-up actions.

Hangs off: Article 72: post-market monitoring

Editorially reviewed | evidence, post-market

Record of incidents, analyses, reports to supervisors and corrective measures.

Hangs off: Article 73: serious incident reporting

Editorially reviewed | evidence, post-market

Versioned record of risk analyses, chosen measures, residual risks and test results per system version.

Hangs off: Article 9: risk management system

Editorially reviewed | evidence, high-risk-requirements

The assessment, EU declaration of conformity, CE marking and registration proof, per system version.

Hangs off: Articles 43-49: conformity assessment, CE and registration

Editorially reviewed | conformity, evidence

Dated impact assessment, measures, residual risks and, where required, notification to the market surveillance authority.

Hangs off: Article 27: FRIA

Editorially reviewed | evidence, fundamental-rights

Current technical documentation, downstream information, copyright policy and public training summary.

Hangs off: Article 53: GPAI model providers

Editorially reviewed | evidence, gpai

Record per system of role, contractual arrangements on information and cooperation, and the appointment of a representative where required.

Hangs off: Articles 22-25: value chain and authorised representative

Editorially reviewed | evidence, value-chain

An organisation secures the entrances to its buildings with facial recognition and uses that biometric access control to register visitors as well. When the system returns no match, a security officer reviews the camera images and decides personally whether someone may enter. The question is whose measures have to reach that officer: those of the supplier of the model, those of the department that deploys the system, or both.

Hangs off: Article 4: AI literacy

Placed against the official source | examples

A police force uses AI to search large volumes of investigation files and surface connections a detective would otherwise miss. The outputs feed into the choice of which suspect is pursued further and end up in documents that enter the criminal process. The question is whether one and the same basic instruction is enough for the analyst operating the model and for the detective who acts on its output.

Hangs off: Article 4: AI literacy

Placed against the official source | examples

A newsroom uses generative AI to prepare summaries, headlines and imagery, after which an editor finishes the piece and the desk decides to publish. Part of that work sits with freelancers, and an outside agency produces marketing content with the same tools. The question is whether your AI literacy measures must reach those freelancers and that agency, or only the people on the payroll.

Hangs off: Article 4: AI literacy

Placed against the official source | examples

A recruiter deploys an AI chat that puts candidates through a first screening conversation after they respond to a job posting, and adds their answers to their CV. The chat introduces itself with a first name and writes in a casual conversational tone. The question is whether these applicants reasonably realise that they are talking to an AI system.

Placed against the official source | examples

An organisation admits staff through facial recognition at its access control gate and additionally runs a camera in the visitor area that sorts faces into age groups. Both applications run on the same biometric infrastructure and the same images. The question is which of the two requires the people involved to be actively informed.

Placed against the official source | examples

A software company uses an AI assistant for code suggestions and code review, available only to professional developers. The same company also runs a helpdesk chatbot for customers.

Placed against the official source | examples

A bank opens an AI-driven reporting portal where customers can flag suspected fraud around their payment account or loan. The system asks follow-up questions, categorises the report and routes it to fraud detection and, where money laundering signals appear, to the internal reporting team. Because the portal concerns criminal offences, the bank assumes the disclosure duty for direct AI interaction does not apply.

Placed against the official source | examples

A municipality has an AI system write the web pages about a changed scheme for social assistance and allowances, meant to explain to citizens what they are entitled to. A communications officer reads the text for style and spelling and publishes it. The question is whether this public service thereby falls under the exception to the labelling duty.

Placed against the official source | examples

An organisation gives staff an internal AI assistant for HR, legal, procurement, compliance and IT questions. Must that assistant disclose at every turn that it is AI?

Placed against the official source | examples

A hospital deploys an interactive AI system used exclusively by properly trained health professionals to support medical diagnosis and suggest treatments. The question is whether the patient or the clinician must be told it is AI.

Placed against the official source | examples

An authority empowered by law to detect criminal offences wants to deploy an interactive AI system without telling those involved that they are communicating with AI.

Placed against the official source | examples

An employer uses an AI system that scores employee performance and lets that score weigh in promotion and dismissal. After a change to the model it turns out that a group of staff was scored too low for months, and decisions have already been taken on those scores. HR wonders whether this is a serious incident and who would have to report it.

Hangs off: Article 73: serious incident reporting

Placed against the official source | examples

An automated border gate uses biometric facial recognition to compare a traveller’s face with the photo in the passport chip. The same camera could technically also compare against a law-enforcement database, and exactly that difference decides whether this biometrics is high-risk.

Hangs off: Annex III: high-risk AI

Placed against the official source | examples

A manufacturer supplies an AI system that runs as a safety component in a machine on the production line and at the same time drives quality control. At a customer's factory an operator is seriously injured after the machine failed to stop on an anomaly. The question is who reports, to whom, and which clock is already running at that moment.

Hangs off: Article 73: serious incident reporting

Placed against the official source | examples

A municipality wants to deploy an AI system that sorts applications for social assistance benefits and indicates which files merit extra scrutiny before a case worker decides. The application is already listed in the public algorithm register. The question is what has to be in place before the first citizen passes through this system.

Hangs off: Article 27: FRIA

Placed against the official source | examples

A police service deploys an AI system that estimates the recidivism risk of a suspect, as an aid to the judgements later made by the prosecution service and the court. The model is subsequently retrained on newer investigative data and use is extended to a second region. The question is whether the assessment made for first use remains adequate.

Hangs off: Article 27: FRIA

Placed against the official source | examples

A university of applied sciences has an AI system rank applications for a vocational programme, using the exam results of earlier students to calibrate that ranking. A data protection impact assessment already exists for this processing. The question the school asks is whether that also covers the fundamental rights side of admission.

Hangs off: Article 27: FRIA

Placed against the official source | examples

A health insurer uses AI for risk assessment and pricing of health and life insurance. The question is whether this falls under point 5(c) of Annex III, and with that whether the Article 27 FRIA duty comes into play.

Hangs off: Article 27: FRIA

Placed against the official source | examples

A university of applied sciences uses a purchased AI system that ranks student admissions and also raises flags during digital assessment. The logs sit in the supplier environment, which hands them over on request. The teaching organisation wonders whether that settles the matter or whether the school retains a duty of its own.

Hangs off: Article 12: logging and traceability

Placed against the official source | examples

A manufacturer supplies an AI system that runs as a safety component inside the machinery of a production line and also drives quality control. The factory operating the line keeps only the alerts visible in the local controller; the rest of the recording flows to the supplier environment. The question is who has to keep which logs when it later has to be reconstructed why the line was halted.

Hangs off: Article 12: logging and traceability

Placed against the official source | examples

An employer deploys an AI system that handles task allocation among staff and summarises their performance for the performance review. HR wants to know what record of those outcomes has to be retained when an employee objects months later to a promotion decision.

Hangs off: Article 12: logging and traceability

Placed against the official source | examples

A police service fine-tunes an open general-purpose model on its own files from ongoing criminal investigations, so that detectives can see links between suspects and cases sooner. The fine-tuned model stays inside the service and is not made available to anyone else. The question is whether the service thereby becomes a provider of a general-purpose AI model itself, and so falls under Article 53.

Hangs off: Article 53: GPAI model providers

Placed against the official source | examples

A provider supplies a system that summarises employee performance data and supports HR in promotion decisions. After a year in use, departments turn out to apply it differently than intended, and managers factor the outputs into the performance review. The question is what the provider is supposed to know about that.

Hangs off: Article 72: post-market monitoring

Placed against the official source | examples

A vendor offers proctoring software that flags possible cheating during exams. Several universities of applied sciences use the system, each with its own assessment formats and its own student populations. The vendor wants to know which real-world data it must keep collecting after roll-out, and from whom.

Hangs off: Article 72: post-market monitoring

Placed against the official source | examples

A manufacturer supplies an AI safety component that halts machinery on a production line as soon as someone comes too close to the robot. The component already falls under product legislation for machinery, and the manufacturer runs quality control and incident follow-up for it. The question is what Article 72 adds on top of that.

Hangs off: Article 72: post-market monitoring

Placed against the official source | examples

A university of applied sciences uses proctoring software during an online exam and finds that a group of students is systematically and wrongly flagged as suspicious, after which grades were withdrawn. Teaching staff and the examination board want to know whether this pattern is a serious incident and, if so, who has to report it and within what time.

Hangs off: Article 73: serious incident reporting

Placed against the official source | examples

A software company supplies a SaaS platform that monitors network traffic at an operator of critical digital infrastructure and reports anomalous patterns to that customer's security team. Its developers see that use at such an operator may fall under point 2 of Annex III and wonder whether their own product therefore becomes a high-risk AI system.

Hangs off: Annex III: high-risk AI

Placed against the official source | examples

A higher education institution procures an AI system that organises student applications and enrolment and produces an admission recommendation for each candidate in its vocational programmes. The supplier says it handles the conformity assessment itself and affixes the CE marking. What is left unresolved is whether the institution still has a step of its own to take before the system goes into use in its teaching.

Hangs off: Articles 43-49: conformity assessment, CE and registration

Placed against the official source | examples

A hospital uses AI to prioritise incoming patients at the emergency department. The question is not whether the system is high-risk but by which route: as a medical device under product legislation, or directly under Annex III.

Hangs off: Annex III: high-risk AI

Placed against the official source | examples

A non-food retail chain lets customers pay later in its webshop and decides at checkout whether a consumer qualifies. The team builds that assessment system in house, on top of a pre-trained model supplied by a vendor. The question is what has to be on record before the feature goes live, and who has to put it there.

Hangs off: Article 11: technical documentation

Placed against the official source | examples

Classification route for standalone high-risk AI systems under Article 6(2) and Annex III.

Placed against the official source | high-risk

Quality and governance requirements for training, validation and test data of high-risk AI.

Placed against the official source | high-risk-requirements

The technical file demonstrating before market placement that a high-risk system meets the requirements.

Placed against the official source | high-risk-requirements

Automatic recording of events over the lifetime of a high-risk AI system.

Placed against the official source | high-risk-requirements

Comprehensible instructions for use and system information so deployers can operate the system correctly.

Placed against the official source | high-risk-requirements

High-risk AI must be designed so that humans can effectively oversee it and intervene.

Placed against the official source | high-risk-requirements

Appropriate levels of performance, robustness and security across the lifecycle of high-risk AI.

Placed against the official source | high-risk-requirements

The documented quality system through which a high-risk AI provider structurally assures compliance.

Placed against the official source | high-risk-requirements

Fundamental rights impact assessment before deploying certain high-risk AI systems.

Placed against the official source | fundamental-rights, high-risk

Providers and deployers take measures that support the development of AI literacy.

Placed against the official source | ai-literacy

The prohibition of AI practices carrying unacceptable risk, such as manipulation, social scoring and certain biometric applications.

Placed against the official source | prohibited-practices

Documentation, information, copyright and transparency duties for providers of general-purpose AI models.

Placed against the official source | gpai

Additional duties for the most capable general-purpose AI models, on top of Article 53.

Placed against the official source | gpai-systemic-risk

Systematic monitoring of high-risk AI in real use, after market placement.

Placed against the official source | post-market

The duty to report serious incidents with high-risk AI, under strict deadlines.

Placed against the official source | post-market

A continuous, documented risk management system across the entire lifecycle of a high-risk AI system.

Placed against the official source | high-risk-requirements

The route from assessment to CE marking and EU database registration before market placement of high-risk AI.

Placed against the official source | conformity

Role shifts in the AI value chain and the mandatory representative for non-EU providers.

Placed against the official source | value-chain

Public classifier for the high-risk use cases in Annex III.

Hangs off: Annex III: high-risk AI

Editorially reviewed | high-risk, template

The full legal text in the public AI Act Explorer.

Hangs off: Article 10: data and data governance

Editorially reviewed | high-risk-requirements, template

The full legal text in the public AI Act Explorer.

Hangs off: Article 11: technical documentation

Editorially reviewed | high-risk-requirements, template

The full legal text in the public AI Act Explorer.

Hangs off: Article 12: logging and traceability

Editorially reviewed | high-risk-requirements, template

The full legal text in the public AI Act Explorer.

Hangs off: Article 13: transparency towards deployers

Editorially reviewed | high-risk-requirements, template

The full legal text in the public AI Act Explorer.

Hangs off: Article 14: human oversight

Editorially reviewed | high-risk-requirements, template

The full legal text in the public AI Act Explorer.

Hangs off: Article 15: accuracy, robustness and cybersecurity

Editorially reviewed | high-risk-requirements, template

The full legal text in the public AI Act Explorer.

Editorially reviewed | high-risk-requirements, template

The full legal text in the public AI Act Explorer.

Hangs off: Article 17: quality management system

Editorially reviewed | high-risk-requirements, template

The full legal text in the public AI Act Explorer.

Editorially reviewed | template, value-chain

The full legal text in the public AI Act Explorer.

Editorially reviewed | template, value-chain

The full legal text in the public AI Act Explorer.

Editorially reviewed | high-risk-requirements, template

Public route for structuring measures by role and context.

Hangs off: Article 4: AI literacy

Editorially reviewed | ai-literacy, template

The full legal text of the prohibited practices with all categories and exceptions, in the public AI Act Explorer.

Hangs off: Article 5: prohibited practices

Editorially reviewed | prohibited-practices, template

Public decision route for the distinct transparency obligations.

Editorially reviewed | template, transparency

The full legal text in the public AI Act Explorer.

Hangs off: Article 55: GPAI models with systemic risk

Editorially reviewed | gpai-systemic-risk, template

The full legal text in the public AI Act Explorer.

Editorially reviewed | innovation, template

The full legal text in the public AI Act Explorer.

Editorially reviewed | innovation, template

The full legal text in the public AI Act Explorer.

Hangs off: Article 72: post-market monitoring

Editorially reviewed | post-market, template

The full legal text in the public AI Act Explorer.

Hangs off: Article 73: serious incident reporting

Editorially reviewed | post-market, template