We use privacy-by-default, cookieless analytics.

Optional analytics cookies are used only if you accept them.

Read our Terms of Use and Privacy Policy.

Intake WorkflowEU AI Act

EU AI Act Classify a tool before approval

Collect the facts you need before buying, building, changing or launching AI.

Use one record to check scope, prohibited uses, high-risk status, transparency duties and model-provider duties.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Oct 21, 2026
7 sections10 primary sources
Overview

Start with the intended use of the or general-purpose AI model. Work through the checks below, assign an owner to unresolved questions and save the evidence behind the decision. Repeat the review when the use, system or model changes.

Section 1

1. Describe the tool and its intended use

Create one record for each materially different intended purpose. A recruitment screen and a customer-support assistant may share a model but have different duties.

Write down what the system or model does, who uses it, who it affects and how it reaches the EU. A product name alone is too little to classify it.

  • Identity: record ID, name, version, release stage and business, legal, technical and evidence owners.
  • Function: inputs, outputs, objectives, inference, autonomy and possible adaptation after deployment.
  • Use: purpose, operating conditions, instructions, user-facing materials, affected people and foreseeable misuse.
  • EU connection: provider and deployer locations, market supply, first use, output use, affected people and supply-chain roles.
  • Model or system: distinguish a reusable GPAI model, general-purpose and application built with a model.
Section 2

2. Check scope and exclusions

Article 2 covers providers supplying systems or GPAI models to the EU market, providers putting systems into service in the EU, and EU-based deployers. It can also cover non-EU providers and deployers whose outputs are used in the EU, specified supply-chain actors and affected people in the EU.

Check exclusions individually. They include activity outside EU law; military, defence and national-security uses; specified international law-enforcement or judicial cooperation; solely scientific research; pre-market research and development; personal non-professional use; and qualifying free and open-source systems.

Those exclusions have limits. Real-world testing is outside the pre-market exclusion. The open-source system exclusion does not cover high-risk systems or systems under Article 5 or 50.

For Annex I products, record Section A or B. Amended Article 2(2) directly applies Article 6(1), Article 60a and Articles 102-112 to Section B systems. Articles 57-59 apply only insofar as high-risk requirements have entered sector law. A Section A limitation under Article 2(13) requires an applicable delegated act and its conditions.

  • Attach contracts, entity locations, market-entry and deployment facts, output-use locations and supply-chain records.
  • For an exclusion, retain the purpose, research stage, real-world testing position, licence and high-risk or Article 5/50 checks.
  • Record the conclusion: in scope, excluded, partly covered or unresolved. Assign missing facts and legal questions to an owner.
Section 3

3. Stop if a prohibited practice may apply

Check Article 5 before approving the tool. Escalate a possible prohibited use for legal review, redesign, withdrawal or non-use.

Record the function, purpose, data, affected people, likely effects and any claimed exception. Test each condition of an exception against evidence.

  • Harmful manipulation: subliminal, purposefully manipulative or deceptive techniques that materially distort behaviour, impair informed choice and cause or are reasonably likely to cause significant harm.
  • Exploitation: age, disability or social or economic vulnerability used to materially distort behaviour with significant actual or likely harm.
  • Social scoring: scoring people over time that leads to unrelated, unjustified or disproportionate detrimental treatment.
  • Criminal-risk prediction: reliance solely on profiling or personality traits. The narrow exception supports a human assessment already based on objective, verifiable facts directly linked to criminal activity.
  • Biometrics: untargeted facial-image scraping, restricted biometric categorisation, or workplace/education emotion inference without the medical or safety exception.
  • Law-enforcement live remote identification in publicly accessible spaces: verify the listed objective, strict necessity, impact assessment, registration, authorisation, notification and national-law conditions.
  • Content ban from 2 December 2026: check provider intent, foreseeable reproducible prohibited intimate or child sexual abuse outputs, safeguards, and deployer use for the prohibited purpose. Apply the distinct tests and limits in the detailed guide.
Section 4

4. Test both high-risk routes

For Article 6(1), ask whether the AI is a covered product or safety component under Annex I and whether the product requires third-party conformity assessment. An assessment required only for risks unrelated to health and safety does not satisfy that condition.

Amended Article 6 excludes solely non-safety assistance, optimisation, efficiency, automation, convenience and quality control from the safety-component route. A system whose failure would endanger health and safety is a safety component.

For Article 6(2), match the exact intended use to Annex III. An Article 6(3) exception requires no significant risk of harm, including no material influence on decision outcomes, and a listed task condition. An Annex III system that profiles people remains high-risk.

  • Product route: record the product, Annex I law, safety function, third-party assessment requirement, manufacturer and assessment owner.
  • Annex III route: check biometrics, critical infrastructure, education, employment, services, law enforcement, migration and borders, justice and elections.
  • Exception: record the narrow procedural task, improvement of completed human work, properly reviewed detection of patterns or deviations, or preparatory task.
  • Profiling: confirm whether the system profiles people; an Annex III system that does cannot use the exception.
  • Registration: a provider relying on Article 6(3) must document the assessment and check Article 49(2) EU database registration.
Section 5

5. Check notices and output marking

Article 50 can apply alongside high-risk duties. Check direct AI interaction, synthetic content, emotion recognition, biometric categorisation, deepfakes and AI text published to inform the public on matters of public interest.

Providers handle interaction notices and synthetic-output marking. Deployers handle notices to people exposed to emotion or biometric systems and disclosures for covered publications. Give clear, distinguishable, accessible information by the first interaction or exposure; check each specific exception.

  • Interaction: show that people are told they are interacting with AI, unless it is obvious to a reasonably well-informed, observant and circumspect person in context or another stated exception applies.
  • Synthetic content: retain machine-readable marking, detectability tests, technical limits, content types, costs and state-of-the-art assessment. Cost alone does not excuse marking.
  • Emotion or biometric use: retain the notice and separate data-protection assessment.
  • Deepfakes and public-interest text: record disclosure, publication context, human review, editorial responsibility and any applicable creative-work or law-enforcement exception.
  • Dates: Article 50 applies from 2 August 2026. Only Article 50(2) marking for systems supplied before that date has a transition to 2 December 2026. The July 2026 final Commission guidelines are non-binding interpretation.
Section 6

6. Check GPAI model duties separately

A model supplied for integration, through an API or as a download needs a separate GPAI review. The Act distinguishes a general-purpose AI model, a general-purpose and a provider building a system with a model.

GPAI is a model framework, not a fifth system risk category. The application built with the model still needs its own prohibited-use, high-risk, transparency and role checks.

  • Model facts: significant generality, range of tasks, training scale, integration options and whether it remains pre-market research or a prototype.
  • Provider: who develops or commissions the model, supplies it under its name and places it on the EU market; check any required EU representative.
  • Systemic risk: retain training compute, parameters, data scale, modalities, benchmarks, autonomy, tools, reach and any Commission designation or notification.
  • Article 53: model documentation, information for integrators, copyright policy and public training-content summary.
  • Article 55: for systemic-risk models, evaluations, adversarial tests, risk mitigation, incident records and cybersecurity.
Section 7

7. Assign duties and review after changes

Name the owner of each applicable duty. Under Article 25, rebranding a high-risk system, substantially modifying it while it remains high-risk, or changing its purpose so it becomes high-risk can make another party the provider.

Keep the classification current. Review changes to purpose, EU supply, users, model supplier, product integration, profiling, biometric functions, model capabilities, training compute or monitoring findings.

The original prohibitions have applied since 2 February 2025, GPAI duties since 2 August 2025 and Article 50 since 2 August 2026. The new content prohibitions apply from 2 December 2026.

The 2026 amendment entered into force on 27 July 2026. Chapter III Sections 1-3, except Article 6(5), apply from 2 December 2027 for Annex III systems and 2 August 2028 for Article 6(1) products. Providers of GPAI models supplied before 2 August 2025 have until 2 August 2027 under Article 111(3).

  • Provider: assign documentation, conformity, high-risk registration, model documentation and training-summary duties as applicable.
  • Deployer: assign operating controls, notices, controlled input data and logs, monitoring, any required fundamental-rights impact assessment and authority notifications.
  • Supply chain: identify importers, distributors, representatives, manufacturers and suppliers; agree access, information and assistance.
  • Review triggers: substantial modification, new purpose, EU supply or output use, Annex III use, profiling, possible prohibited use, systemic-risk threshold, incident, authority request or registration change.
  • Save the classification, article, roles, evidence gaps, owner, citations, approval date and next review trigger.
Get help

Review a classification record

Sorena can help check the evidence, role assignments and unresolved questions before approval.

Research workflow
Ask Research Copilot

Ask about scope, risk categories, GPAI duties or registration for a specific use.

Explore next step
Talk to Sorena
Discuss your AI Act review

Review your use case, evidence and next steps with Sorena.

Explore next step
Primary sources

References and citations

Regulation (EU) 2024/1689 (EU AI Act)
eur-lex.europa.eu8 citations
Referenced sections
  • Primary source for Article 2 scope, Article 3 definitions, Article 5 prohibitions, Article 6 high-risk routes, Article 25 role changes, Articles 51 to 55 GPAI rules, Annex III, and Annex XIII.
  • Supports the intake fields for Article 2 scope, Article 3 definitions, intended purpose, operator roles, AI system definition, GPAI model definition, and substantial modification.
  • Supports the Article 2 scope and exclusion criteria used in this intake screen.
Show 5 more
  • Primary legal source for Article 5 prohibited practices and related definitions.
  • Supports Article 6 high-risk routes, Article 6(3) derogation criteria, the profiling override, and the Annex III use-case list.
  • Article 50 sets provider and deployer transparency duties, timing, and exceptions for interactive systems, synthetic content, emotion recognition, biometric categorisation, deepfakes, and public-interest text.
  • Supports GPAI definitions, systemic-risk criteria, Article 51 classification, Article 52 notification and reassessment, and Articles 53 to 55 obligations.
  • Supports Article 25 role-shift rules, deployer obligations, high-risk monitoring and registration facts, and substantial-modification reassessment triggers.
AI Act Service Desk - Article 49 registration
ai-act-service-desk.ec.europa.eu3 citations
Referenced sections
  • Official Service Desk article page supporting registration checks for Annex III high-risk systems and Article 6(3) not-high-risk conclusions.
  • Supports EU database registration checks for Annex III high-risk systems and Article 6(3) not-high-risk provider conclusions.
  • Supports registration checks for provider, authorised representative, public-authority deployer, secure non-public registration, and national critical-infrastructure registration cases.
AI Act Service Desk - Article 5 prohibited AI practices
ai-act-service-desk.ec.europa.eu2 citations
Referenced sections
  • Official Service Desk article page supporting the prohibited-practice intake screen.
  • Supports the prohibited-practice categories and narrow law-enforcement remote biometric identification conditions.
Commission guidelines on GPAI obligation scope
ec.europa.eu2 citations
Referenced sections
  • Commission guidelines supporting GPAI classification, provider status, downstream modifiers, systemic-risk designation, and open-source exemption checks.
  • Supports the provider, placing-on-the-market, downstream-modifier, systemic-risk, and open-source GPAI classification checks.
European Commission - AI Act regulatory framework
digital-strategy.ec.europa.eu2 citations
Referenced sections
  • Commission overview supporting the risk-based structure and official public framing of the EU AI Act.
  • Provides official Commission context for the AI Act risk-based framework and implementation support.
European Commission - GPAI provider guidelines
digital-strategy.ec.europa.eu2 citations
Referenced sections
  • Commission policy page supporting GPAI provider scope, compliance context, and document submission references.
  • Supports the operational screen for deciding whether GPAI obligations apply to a provider and how the Commission interprets GPAI provider scope.
European Commission - Guidelines on Article 50 transparency obligations
digital-strategy.ec.europa.eu2 citations
Referenced sections
  • Final Commission guidance supporting the Article 50 transparency screen for interactive systems, synthetic content, emotion recognition, biometric categorisation, deepfakes, and covered public-interest text.
  • Final Commission guidelines published on 20 July 2026 explain the Article 50 duties that apply from 2 August 2026; the guidance is interpretive rather than binding legislation.
Regulation (EU) 2026/1744 - Digital Omnibus on AI
eur-lex.europa.eu2 citations
Referenced sections
  • Binding amendment used for the revised high-risk application dates, added Article 5 content prohibitions, and Article 6 safety-component clarifications.
  • Supports the binding application dates and the Article 5 and Article 6 amendments that require classification and reassessment records.
Regulation (EU) 2026/1744 - amended Article 5
eur-lex.europa.eu
Referenced sections
  • Supports the added content-related prohibitions, separate provider and deployer tests, safeguard conditions, and 2 December 2026 application date.

Related guides

Common questions, clear answers | EU AI Act

Clear answers on AI Act scope, risk categories, provider and user duties, general-purpose models, disclosures, rights, assessments and deadlines.

EU AI Act deadlines and compliance calendar

Find the AI Act deadline for your system or model. Check high-risk dates, transparency duties, older-model transitions and the evidence to prepare.

EU AI Act fundamental rights impact assessments

Check who needs an Article 27 fundamental rights impact assessment, what it must contain and how DPIA reuse, notification and registration work.

EU AI Act GPAI model evidence checklist

Collect model documentation, integration information, copyright records and training summaries. Add testing, incident and security records for systemic risk.

EU AI Act monitoring and serious incidents

Set up high-risk AI monitoring, identify serious incidents and check reporting deadlines, recipients, deployer escalation and corrective action.

EU AI Act penalties and fines

Check the AI Act fine tiers, smaller-organisation caps, GPAI provider fines and the facts authorities consider when deciding a penalty.

Show all related guides (34)

EU AI Act serious incident reporting steps

Check serious-incident harm, preserve evidence and choose the reporting deadline and recipient for high-risk AI systems and systemic-risk GPAI models.

EU AI Act timeline and phased deadlines

See which AI Act rules apply now and what comes next. Check high-risk dates, older-model transitions and the difference between legal and standards dates.

EU AI Act vs ISO/IEC 42001

Compare AI Act legal duties with ISO/IEC 42001 management-system requirements. See which records can be reused and what certification does and does not cover.

EU AI Act vs NIST AI RMF

Compare AI Act legal duties with the voluntary NIST AI RMF. Map risk records to specific requirements and identify legal steps that need separate evidence.

EU AI Act: Check whether the Act applies

Use five checks to establish AI Act scope, exclusions, your role, risk categories and evidence for the decision.

EU AI Act: Choose a high-risk assessment route

Choose between provider-run internal control, notified-body assessment and a product-law procedure before release.

EU AI Act: Compliance checklist

Check each AI tool, decide which duties apply, and give every action an owner and evidence link.

EU AI Act: Conformity assessment

Some high-risk systems use a provider-run assessment. Others need an authorised independent assessor or a product-law assessment.

EU AI Act: Does it apply to you?

Check whether the AI Act applies to your system or model, identify your provider or deployer role, and keep evidence for the decision.

EU AI Act: Duties for general-purpose AI models

Check GPAI provider duties for documentation, integrator information, copyright and training summaries, plus extra requirements for systemic-risk models.

EU AI Act: High-risk requirements

High-risk providers must meet system requirements before supply. Deployers must use and monitor the system under the provider's instructions.

EU AI Act: High-risk system checklist

Check the system's risk controls, data, documentation, logs, instructions, human oversight and testing before release.

EU AI Act: Is your use case high-risk?

Find high-risk AI examples in recruitment, banking, education, healthcare, public services and products. Check Article 6 conditions and exceptions.

EU AI Act: Plan your compliance work

Build a compliance plan for each AI tool: your role, the duties that apply, the evidence needed and the person responsible.

EU AI Act: Standards and quality management

Use EN 18286:2026 to organise provider quality-management procedures and keep evidence that they work for each high-risk system.

EU AI Act: Technical file and evidence templates

Build the technical file and provider records for a high-risk AI system, with owners and evidence links for each field.

EU AI Act: When must you disclose AI?

Check Article 50 chatbot notices, synthetic-output marking, biometric notices, deepfake disclosures and public-interest text exceptions.

EU AI Act: Which AI uses are banned?

Check Article 5 prohibited AI practices, the narrow exceptions, evidence to retain and the new content prohibitions from 2 December 2026.

Are you the provider or the deployer? | EU AI Act

Check provider, deployer, importer and distributor roles, when changes create provider duties, and how model and system responsibilities differ.

Do you need a notified body? | EU AI Act

Find the assessment route for high-risk AI, when a notified body is required, and which declaration, CE-marking and registration records you need.

Does this tool count as AI? | EU AI Act

Check whether software counts as AI, how models differ from systems, when embedded AI is high-risk, and which scope and role evidence to keep.

How do you monitor AI after release? | EU AI Act

Understand high-risk AI monitoring under Article 72: the provider plan, deployer feedback, logs, corrective action, incidents and change reviews.

Is this industry use high-risk? | EU AI Act

See which industry AI uses fall under Annex III, when Article 6(3) can apply, and what providers must document and register.

What belongs in the technical file? | EU AI Act

See what Article 11 and Annex IV require in high-risk AI technical documentation, from system identity and testing to monitoring and retention.

What must general-purpose model providers do? | EU AI Act

Check general-purpose model duties, systemic-risk classification, open-source conditions, copyright, training summaries, incidents and application dates.

When must you disclose AI use? | EU AI Act

Check AI interaction notices, technical content marking, biometric notices, deepfake and text disclosures, exceptions, accessibility and deadlines.

When must you report a serious incident? | EU AI Act

Check serious-incident outcomes, reporting roles, 15-, 10- and two-day deadlines, authority recipients, corrective action and the separate model route.

Who needs a rights impact assessment? | EU AI Act

Check who needs an Article 27 fundamental rights impact assessment, what it must cover, and how privacy assessments, notification and registration fit.