Intake WorkflowEU AI Act

EU AI Act Risk Classification Intake Workflow

Classify an AI system or GPAI model before launch, procurement, integration, substantial modification, or EU use by collecting the facts needed for Article 2 scope, Article 3 definitions, Article 5 prohibitions, Article 6 high-risk routes, Annex III use cases, and GPAI status.

Use the intake record to separate provider, deployer, importer, distributor, authorised representative, product manufacturer, downstream provider, and GPAI model-provider responsibilities before assigning compliance work.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
May 9, 2026
Sections
6

Structured answer sets in this page tree.

Primary sources
6

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated May 9, 2026
Overview

This intake workflow is a structured evidence record for EU AI Act risk classification. It is designed for product, legal, compliance, procurement, security, privacy, and model-governance teams that need to decide whether a system is outside scope, prohibited, high-risk under Article 6, covered by transparency duties, a GPAI model, or a GPAI model with systemic risk.

Section 1

Intake record header

Start with a stable record that describes the system or model, the EU connection, the operator roles, and the exact classification question. Do not classify from a product nickname alone; Article 3 classification depends on intended purpose, how the system is placed on the market or put into service, who uses it, and whether a GPAI model is integrated or supplied separately.

Create one intake record per materially different intended purpose. A recruiting screen, a customer-support assistant, a credit-scoring component, and a GPAI model API can have different AI Act routes even when they share an underlying model.

  • Record ID, system or model name, version, release stage, business owner, legal owner, technical owner, and evidence owner.
  • Short description of the machine-based system, input types, output types, autonomy level, adaptiveness after deployment, and whether outputs are predictions, content, recommendations, or decisions.
  • Intended purpose, context and conditions of use, user-facing materials, instructions for use, affected persons or groups, and reasonably foreseeable misuse.
  • EU nexus: provider or deployer location, Union market placement, Union put-into-service facts, Union output use, importer or distributor involvement, and whether affected persons are located in the Union.
  • Model facts: whether the item is an AI system, a GPAI model, a general-purpose AI system based on a GPAI model, or a downstream AI system integrating another model.
Sources for this answer
Regulation (EU) 2024/1689 (EU AI Act)
Supports the intake fields for Article 2 scope, Article 3 definitions, intended purpose, operator roles, AI system definition, GPAI model definition, and substantial modification.
Section 2

Article 2 scope screen

The first classification gate is not risk tier; it is whether the AI Act applies to the fact pattern. Article 2 covers providers placing AI systems or GPAI models on the Union market or putting AI systems into service in the Union, deployers established or located in the Union, third-country providers and deployers where output is used in the Union, importers, distributors, product manufacturers, authorised representatives, and affected persons located in the Union.

The same screen must capture exclusions so that out-of-scope decisions are not overbroad. Article 2 exclusions include areas outside Union law, military, defence or national security purposes, certain international law-enforcement or judicial cooperation uses, AI systems or models specifically developed and put into service solely for scientific research and development, pre-market research, testing or development activity other than real-world testing, purely personal non-professional deployer use, and free/open-source AI systems unless they are placed on the market or put into service as high-risk systems or fall under Article 5 or Article 50.

  • Scope evidence: contracting entity, establishment location, market-entry channel, deployment location, output-use location, affected-person location, supplier chain role, and product-manufacturer involvement.
  • Exclusion evidence: purpose category, research or pre-market status, real-world testing status, open-source licence terms, whether the system is high-risk, prohibited, or under Article 50, and whether the deployer use is purely personal and non-professional.
  • Decision output: in scope, out of scope, partial scope, or escalate because EU nexus, role, output-use, research, open-source, or national-security facts are incomplete.
Sources for this answer
Regulation (EU) 2024/1689 (EU AI Act)
Supports the Article 2 scope and exclusion criteria used in this intake screen.
European Commission - AI Act regulatory framework
Provides official Commission context for the AI Act risk-based framework and implementation support.
Section 3

Article 5 prohibition screen

Run the Article 5 screen before high-risk classification. A prohibited-practice hit should stop normal intake and move to legal escalation, product withdrawal, redesign, or non-use review rather than being treated as a manageable high-risk obligation.

Capture the exact practice, deployment context, affected persons, purpose, expected effect, data used, safeguards claimed, and whether any narrow law-enforcement biometric exception is being asserted.

  • Manipulation or deception: subliminal, purposefully manipulative, or deceptive techniques that materially distort behaviour and cause or are reasonably likely to cause significant harm.
  • Vulnerability exploitation: age, disability, or social or economic situation used to materially distort behaviour in a way causing or likely causing significant harm.
  • Social scoring: evaluation or classification of people over time leading to unrelated, unjustified, or disproportionate detrimental treatment.
  • Criminal-offence risk prediction: risk assessment of natural persons based solely on profiling or personality traits, unless supporting human assessment based on objective and verifiable facts linked to criminal activity.
  • Biometric and emotion restrictions: untargeted facial-image scraping, workplace or education emotion inference except for medical or safety reasons, and biometric categorisation to infer protected characteristics.
  • Real-time remote biometric identification in publicly accessible spaces for law enforcement: record whether a listed objective, strict necessity, fundamental rights impact assessment, registration, prior authorisation, notification, and national-law conditions are present.
Sources for this answer
AI Act Service Desk - Article 5 prohibited AI practices
Supports the prohibited-practice categories and narrow law-enforcement remote biometric identification conditions.
Regulation (EU) 2024/1689 (EU AI Act)
Primary legal source for Article 5 prohibited practices and related definitions.
Section 4

Article 6 and Annex III high-risk screen

If no Article 5 prohibition is identified, classify high-risk status through both Article 6 routes. Article 6(1) covers AI used as a safety component of a product, or as a product itself, where the product is covered by Annex I Union harmonisation legislation and requires third-party conformity assessment. Article 6(2) covers AI systems listed in Annex III.

For Annex III, intake must capture the use-case area and the Article 6(3) derogation analysis. A system listed in Annex III can be documented as not high-risk only where it does not pose a significant risk of harm to health, safety, or fundamental rights, including by not materially influencing decision-making, and one of the Article 6(3) conditions applies. Profiling of natural persons remains high-risk.

  • Article 6(1) evidence: product category, Annex I legislation, whether the AI is a safety component or product, third-party conformity assessment requirement, product manufacturer, and conformity owner.
  • Annex III evidence: biometrics, critical infrastructure, education or vocational training, employment or worker management, essential public or private services, law enforcement, migration/asylum/border control, or administration of justice and democratic processes.
  • Article 6(3) derogation evidence: narrow procedural task, improvement of a completed human activity, pattern or deviation detection without replacing or influencing human assessment without proper review, or preparatory task to an Annex III assessment.
  • Mandatory override: if the system performs profiling of natural persons in an Annex III use case, classify it as high-risk rather than relying on an Article 6(3) derogation.
  • Registration evidence: if an Annex III provider concludes not-high-risk under Article 6(3), record the assessment and Article 49(2) EU database registration need.
Sources for this answer
Regulation (EU) 2024/1689 (EU AI Act)
Supports Article 6 high-risk routes, Article 6(3) derogation criteria, the profiling override, and the Annex III use-case list.
AI Act Service Desk - Article 49 registration
Supports EU database registration checks for Annex III high-risk systems and Article 6(3) not-high-risk provider conclusions.
Section 5

GPAI model and downstream-provider screen

Run a separate GPAI screen whenever the intake involves a model supplied for integration, an API model, a foundation model, a modified model, or an AI system based on a GPAI model. Article 3 distinguishes a general-purpose AI model from a general-purpose AI system and defines downstream providers that integrate AI models into AI systems.

The GPAI screen should not replace system classification. A downstream AI system built on a GPAI model can still need Article 5, Article 6, Annex III, Article 50, deployer, and registration analysis.

  • GPAI status evidence: training scale, significant generality, capability to perform a wide range of distinct tasks, integration into downstream systems or applications, and whether the model is still only used for research, development, or prototyping before market placement.
  • Provider evidence: who develops the model, who has it developed, who places it on the Union market, who provides it under its own name or trademark, and whether a third-country provider needs an EU authorised representative.
  • Systemic-risk evidence: training compute, parameters, dataset size or tokens, modalities, benchmarks, autonomy, scalability, tools access, Union business-user reach, registered end-users, Commission designation, notification, or reassessment request.
  • Article 53 evidence: technical documentation, downstream-provider documentation, copyright policy, and public summary of training content.
  • Article 55 evidence: for systemic-risk models, model evaluation, adversarial testing, systemic-risk assessment and mitigation, serious-incident tracking and reporting, and cybersecurity protection.
Sources for this answer
Regulation (EU) 2024/1689 (EU AI Act)
Supports GPAI definitions, systemic-risk criteria, Article 51 classification, Article 52 notification and reassessment, and Articles 53 to 55 obligations.
European Commission - GPAI provider guidelines
Supports the operational screen for deciding whether GPAI obligations apply to a provider and how the Commission interprets GPAI provider scope.
Commission guidelines on GPAI obligation scope
Supports the provider, placing-on-the-market, downstream-modifier, systemic-risk, and open-source GPAI classification checks.
Section 6

Role boundary and reassessment triggers

Close the intake by assigning role-specific owners and reopening conditions. Article 25 can shift provider responsibilities to a distributor, importer, deployer, or other third party that puts its name or trademark on a high-risk AI system, substantially modifies a high-risk system, or changes the intended purpose of an AI system so that it becomes high-risk.

Treat classification as a maintained record. Reassess when the intended purpose, EU market path, user population, model supplier, product integration, Annex III use case, profiling status, biometric function, GPAI capabilities, training compute, documentation, or post-market evidence changes.

  • Provider boundary: identify who owns technical documentation, conformity assessment, high-risk registration, GPAI documentation, and public training-content summary duties.
  • Deployer boundary: identify who controls use context, worker or affected-person notices, input data, logs under deployer control, monitoring, fundamental-rights impact assessment where applicable, and authority notifications.
  • Supply-chain boundary: identify importer, distributor, authorised representative, product manufacturer, third-party tool or model supplier, written agreements, technical access, and assistance dependencies.
  • Reassessment triggers: substantial modification, intended-purpose change, new EU market or output-use path, new Annex III use case, profiling added, prohibited-practice risk, GPAI systemic-risk threshold or designation, serious incident, authority request, or registration-content change.
  • Final output fields: classification result, article route, role allocation, evidence gaps, escalation owner, source citations, approval date, next review trigger, and the reason the page owner can defend the classification.
Sources for this answer
Regulation (EU) 2024/1689 (EU AI Act)
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
Supports registration checks for provider, authorised representative, public-authority deployer, secure non-public registration, and national critical-infrastructure registration cases.
Recommended next step

Classify EU AI Act scope, risk tier, GPAI status, and role ownership

Sorena can help convert this intake into a maintained classification record with source citations, evidence gaps, role boundaries, and reassessment triggers for product, model, procurement, and compliance teams.

Research workflow
Open Research Copilot for EU AI Act

Ask source-linked questions about Article 2 scope, Article 5 prohibitions, Article 6 high-risk routes, Annex III use cases, GPAI classification, and registration evidence.

Explore next step
Talk to Sorena
Talk through implementation

Review a product, model, supplier, or deployment fact pattern against this intake structure with Sorena.

Explore next step
Primary sources

References and citations

AI Act Service Desk - Article 49 registration
ai-act-service-desk.ec.europa.eu
Referenced sections
  • Supports registration checks for provider, authorised representative, public-authority deployer, secure non-public registration, and national critical-infrastructure registration cases.
European Commission - GPAI provider guidelines
digital-strategy.ec.europa.eu
Referenced sections
  • Supports the operational screen for deciding whether GPAI obligations apply to a provider and how the Commission interprets GPAI provider scope.
Regulation (EU) 2024/1689 (EU AI Act)
eur-lex.europa.eu
Referenced sections
  • Supports Article 25 role-shift rules, deployer obligations, high-risk monitoring and registration facts, and substantial-modification reassessment triggers.
Related guides

Explore more topics

Are industry AI use cases high-risk under EU AI Act Annex III?
FAQ answer on when an industry AI use case falls under EU AI Act Annex III, how Article 6 classification works, when Article 6(3) can support a non-high-risk conclusion, and what evidence providers should keep.
EU AI Act AI System Classification Edge Cases FAQ
Answers for EU AI Act edge cases: AI system definition, inference versus simple rules, GPAI models, embedded products, territorial scope, roles, and classification evidence.
EU AI Act Applicability and Roles: Scope, Actor Map, and Evidence
Determine whether the EU AI Act applies to an AI system or GPAI model, map provider, deployer, importer, distributor, and product manufacturer roles, and record evidence for classification.
EU AI Act applicability test: scope, role, and risk classification
Stepwise EU AI Act applicability test for AI-system status, exclusions, territorial scope, operator role, prohibited uses, high-risk systems, GPAI models, transparency duties, and evidence records.
EU AI Act Article 5 Prohibited AI Practices Screening Guide
Screen AI systems against the EU AI Act Article 5 prohibitions, including manipulation, exploitation, social scoring, biometric and law-enforcement exceptions.
EU AI Act Article 50 transparency disclosures FAQ
Article 50 FAQ for EU AI Act transparency duties covering chatbot notices, synthetic content marking, biometric and emotion notices, deepfakes, public-interest text, timing, accessibility, and exceptions.
EU AI Act Article 50 transparency, labeling, and user disclosures
Source-grounded guide to EU AI Act Article 50 duties for user interaction notices, synthetic content marking, deepfake labels, emotion recognition notices, biometric categorisation notices, and related high-risk AI instructions for use.
EU AI Act Article 73 serious incident FAQ
FAQ on EU AI Act serious incident handling for high-risk AI systems, including Article 73 reporting, deployer escalation, corrective action, and GPAI systemic-risk distinctions.
EU AI Act Compliance Checklist by Risk Class
A practical EU AI Act checklist for classifying AI systems, assigning operator roles, screening prohibited practices, and collecting evidence for high-risk, GPAI, transparency, monitoring, and incident duties.
EU AI Act Compliance Program: roles, high-risk evidence, GPAI and incidents
Build an EU AI Act compliance program around provider, deployer, importer, distributor, high-risk, GPAI, transparency, monitoring, and incident evidence duties.
EU AI Act conformity assessment and notified bodies for high-risk AI
Grounded guide to EU AI Act high-risk AI conformity assessment routes, provider evidence, EU declaration of conformity, CE marking, and notified body involvement.
EU AI Act deadlines and compliance calendar | Article 113 dates
source-linked EU AI Act compliance calendar for Article 113 staged application dates, Article 111 transitions, GPAI, prohibited practices, AI literacy, and high-risk AI planning.
EU AI Act FAQ: scope, roles, high-risk AI, GPAI, FRIA, and dates
Grounded EU AI Act FAQ covering scope, provider and deployer roles, prohibited practices, high-risk classification, GPAI duties, transparency notices, FRIAs, EU database registration, serious incidents, and staged application dates.
EU AI Act FRIA FAQ: Article 27 Scope, Contents, and Notification
Source-grounded FAQ on when Article 27 requires a fundamental rights impact assessment, which deployers are covered, what the FRIA must contain, and how it relates to DPIAs and registration.
EU AI Act FRIA for high-risk AI systems: Article 27 scope and evidence
Source-grounded guide to EU AI Act Article 27 fundamental rights impact assessments: who must run a FRIA, Article 6(2) triggers, Annex III carveouts, DPIA overlap, notification, and registration evidence.
EU AI Act GPAI and Systemic-Risk Duties: Article 53 and 55 FAQ
FAQ on EU AI Act duties for general-purpose AI model providers, including Article 53 documentation, copyright and training-summary duties, Article 55 systemic-risk duties, serious incidents, cybersecurity, and staged enforcement.
EU AI Act GPAI evidence pack checklist for Article 53 and 55
Build a source-grounded evidence pack for EU AI Act GPAI model obligations: technical documentation, downstream information, copyright policy, training-content summary, and systemic-risk records where applicable.
EU AI Act GPAI Provider Obligations: Articles 53 and 55
Grounded guide to EU AI Act duties for general-purpose AI model providers: Article 53 documentation, copyright policy, training-content summary, downstream information, and Article 55 systemic-risk controls.
EU AI Act High-Risk AI Requirements: Articles 8-16 and 26
Map the EU AI Act requirements for high-risk AI systems: risk management, data governance, technical documentation, logs, transparency, human oversight, accuracy, robustness, cybersecurity, and deployer duties.
EU AI Act high-risk AI use cases by industry | Article 6 and Annex III guide
Industry-by-industry guide to EU AI Act high-risk classification under Article 6, Annex III, Annex I product safety routes, exclusions, and provider/deployer boundaries.
EU AI Act high-risk conformity assessment route selector
Select the EU AI Act Article 43 conformity assessment route for a high-risk AI system, including Annex I product legislation, Annex III categories, notified body triggers, standards, declaration, CE marking, registration, and evidence.
EU AI Act high-risk requirements checklist: Articles 8-15
Checklist for EU AI Act high-risk AI system requirements in Articles 8-15: risk management, data governance, documentation, logs, transparency, human oversight, accuracy, robustness, and cybersecurity.
EU AI Act penalties and fines: Article 99 tiers and GPAI exposure
EU AI Act penalties explained: Article 99 fine tiers, prohibited-practice exposure, incorrect information, SME caps, Member State rules, and GPAI model fines.
EU AI Act post-market monitoring and serious incident reporting
Grounded guide to EU AI Act Articles 72 and 73 for high-risk AI: monitoring plans, serious incident reporting, deployer escalation, corrective action, and GPAI distinctions.
EU AI Act post-market monitoring FAQ for high-risk AI systems
Answer to how providers and deployers should handle EU AI Act post-market monitoring for high-risk AI systems under Article 72, with serious-incident, log, corrective-action, and lifecycle-change triggers.
EU AI Act provider vs deployer role boundaries: Article 3 and Article 25 FAQ
FAQ on EU AI Act provider, deployer, operator, importer, distributor, authorised representative, product manufacturer, downstream provider, and GPAI model provider boundaries.
EU AI Act serious incident reporting triage workflow: Article 73 and Article 55
Triage EU AI Act serious incidents by definition, actor, reporting route, deadline, deployer escalation, corrective action, and separate GPAI systemic-risk reporting.
EU AI Act Technical Documentation and Provider Evidence Templates
Build AI Act evidence templates for high-risk AI providers: Article 11 technical documentation, Annex IV fields, quality management, conformity, CE marking, registration, logs, and post-market monitoring.
EU AI Act technical documentation FAQ | Article 11 and Annex IV
What Article 11 and Annex IV require in high-risk AI technical documentation: system identity, intended purpose, architecture, data, testing, oversight, cybersecurity, conformity, and post-market monitoring.
EU AI Act Timeline and Phasing Roadmap: practical obligations and evidence guide
Practical EU AI Act guide to Timeline and Phasing Roadmap: scope, owners, evidence, edge cases, checklist steps, and external source-linked citations.
EU AI Act vs ISO/IEC 42001: legal duties, controls, and evidence limits
Compare the EU AI Act and ISO/IEC 42001 across legal status, risk classification, high-risk AI, GPAI, transparency, conformity, evidence, and assurance limits.
EU AI Act vs NIST AI RMF: legal duties, risk controls, and evidence boundaries
Compare the binding EU AI Act with the voluntary NIST AI RMF, including role classification, high-risk duties, GPAI, transparency, conformity evidence, and reuse limits.
FAQ: EU AI Act conformity assessment procedures and notified body selection
source-linked FAQ on EU AI Act Article 43 conformity assessment routes, Annex VI internal control, Annex VII notified-body review, CE marking, declarations, and registration.