High-Risk AI Under the EU AI Act

How should an organization determine whether an AI system is classified as high-risk under the EU AI Act, and what implementation obligations follow from that classification?

Executive Summary

1. The binding baseline is Regulation (EU) 2024/1689. EUR-Lex identifies the AI Act as Regulation (EU) 2024/1689, OJ L 2024/1689, published 2024-07-12, with EUR-Lex status “In force.” The Regulation entered into force on 2024-08-01 and is directly applicable in all Member States.
2. Classification must proceed in gates. The correct sequence is: Article 2 scope; Article 3 “AI system” definition; Article 5 prohibited-practices screen; Article 6(1) product/safety-component route; Article 6(2) Annex III route; Article 6(3) derogation; profiling override; then documentation, registration, conformity, and deployer obligations.
3. Article 6(1) is a two-condition product route. An AI system is high-risk where it is intended to be used as a safety component of a product, or is itself a product, covered by Annex I EU harmonisation legislation, and the product or system must undergo third-party conformity assessment before being placed on the market or put into service.
4. Article 6(2) is the Annex III use-case route. Annex III captures specific use cases in biometrics, critical infrastructure, education, employment, access to essential services, law enforcement, migration/asylum/border control, justice, and democratic processes.
5. The Article 6(3) derogation is narrow. An Annex III system may be treated as not high-risk only if it does not pose a significant risk of harm to health, safety, or fundamental rights, including by not materially influencing decision-making, and only if it performs one of the listed narrow functions. If the Annex III system performs profiling of natural persons, the derogation is unavailable and the system remains high-risk.
6. High-risk status triggers a compliance system. Providers must satisfy requirements for risk management, data governance, technical documentation, logging, transparency and instructions, human oversight, accuracy, robustness, cybersecurity, quality management, conformity assessment, EU declaration of conformity, CE marking where relevant, registration, post-market monitoring, and serious-incident reporting.
7. Deployers also have direct obligations. Deployers must use high-risk systems according to instructions, assign competent human oversight, ensure relevant and sufficiently representative input data where under their control, monitor operation, keep logs in specified circumstances, inform workers or affected persons in certain cases, register public-authority uses, and conduct a fundamental-rights impact assessment for covered high-risk deployments.
8. The binding implementation dates remain the enacted AI Act dates unless amended. The Act generally applies from 2026-08-02, with Chapters I and II applying from 2025-02-02, governance/GPAI/penalty-related provisions applying from 2025-08-02, and Article 6(1) plus corresponding obligations applying from 2027-08-02. Transitional rules separately apply to pre-existing high-risk systems, public-authority systems, GPAI models, and certain large-scale EU IT systems.
9. The Digital Omnibus timing changes should be tracked but not treated as controlling law until adopted. Official Council materials state that the provisional agreement would move stand-alone high-risk AI obligations to 2027-12-02 and embedded-product high-risk obligations to 2028-08-02, but also state that the provisional agreement still requires endorsement, legal-linguistic revision, and formal adoption.
10. Penalty exposure is material. Article 99 requires Member States to establish penalties. Non-compliance with prohibited-practices rules may reach EUR 35 million or 7% of worldwide annual turnover; other listed non-compliance may reach EUR 15 million or 3%; supplying incorrect, incomplete, or misleading information may reach EUR 7.5 million or 1%, subject to SME/start-up adjustments.

Analysis by Issue

Issue 1 — Is the system within AI Act scope?

Conclusion. The AI Act may apply even where the provider is outside the EU if the output of the AI system is used in the Union. The scope analysis must identify the operator role and EU nexus before high-risk classification begins.

Rule. Article 2 applies to providers placing AI systems or GPAI models on the EU market or putting them into service in the Union; deployers established or located in the Union; providers and deployers outside the Union where the system output is used in the Union; importers and distributors; product manufacturers placing or putting into service products with AI systems under their name or trademark; authorised representatives; and affected persons in the Union. Article 2 also contains exclusions, including certain national security, military, defence, scientific R&D, personal non-professional activity, and open-source exceptions subject to limits.

Application. For implementation, create a scope record for every system with the following fields: provider entity; deployer entity; importer/distributor; product manufacturer; authorised representative if any; EU market-placement status; EU putting-into-service status; whether outputs are used in the Union; whether affected persons are in the Union; and whether an exclusion is claimed. A non-EU SaaS provider may still be in scope if the system’s output is used by an EU deployer or affects EU persons. A purely internal non-professional personal use may fall outside scope, but this exclusion should not be used for enterprise deployments.

Limitations / counterarguments. Scope is not resolved by server location, model-hosting location, or corporate domicile alone. Output use, market placement, and deployment location are legally relevant. A system can also trigger multiple operator roles simultaneously; for example, a company may be a deployer for a vendor model and a provider if it substantially modifies the system or markets it under its own name.

Issue 2 — Is the technology an “AI system”?

Conclusion. High-risk classification applies only if the system first qualifies as an “AI system” under Article 3. The analysis should focus on autonomy, inference from inputs, and output type.

Rule. Article 3 defines an AI system as a machine-based system designed to operate with varying levels of autonomy, that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers from input how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments. Article 3 also defines “intended purpose” as the use for which the provider intends the AI system, including the specific context and conditions of use as specified in information supplied by the provider.

Application. A machine-learning scoring model, recommender system, image-recognition model, NLP classifier, generative model, biometric-matching system, or predictive analytics system will usually require AI Act analysis because it infers outputs from inputs. A deterministic rules engine with no inference, no autonomy, and no AI-like output generation may be outside the definition, but the conclusion must be documented because many systems combine deterministic workflow logic with AI scoring or recommendation layers.

The “intended purpose” evidence should be collected from product specifications, user manuals, technical documentation, marketing materials, deployment contracts, model cards, release notes, procurement documents, UI labels, and internal use-case approvals. Intended purpose is especially important because Article 6 classification depends on the use for which the system is intended, not merely on the model architecture.

Limitations / counterarguments. A general-purpose model is not automatically a high-risk AI system merely because it could be used in a high-risk context. Classification normally attaches to the AI system and intended purpose as placed on the market or put into service. However, a GPAI model integrated into a downstream Annex III or Annex I high-risk system may become part of a high-risk compliance chain.

Issue 3 — Article 5 prohibited-practices gate

Conclusion. Article 5 screening must occur before high-risk classification. If the use is prohibited, the implementation question is not “how to comply as high-risk”; the use may be barred unless a specific exception applies.

Rule. Article 5 prohibits specified practices, including manipulative or deceptive techniques causing or likely causing significant harm; exploitation of vulnerabilities; social scoring by public or private actors leading to detrimental or unfavourable treatment; certain criminal-risk assessments based solely on profiling or personality traits; untargeted scraping of facial images to build facial-recognition databases; emotion inference in workplaces and education institutions except for medical or safety reasons; biometric categorisation to infer sensitive or protected attributes; and certain real-time remote biometric identification in publicly accessible spaces for law enforcement except under strict conditions.

Application. The following should be hard-stop review categories:

Workplace emotion recognition for productivity, engagement, stress, or sentiment monitoring is often prohibited unless the purpose is medical or safety-related.

Education emotion recognition for attention or engagement scoring is subject to the same prohibition unless the purpose is medical or safety-related.

Social scoring based on behaviour or personal traits causing detrimental treatment is prohibited where Article 5 conditions are met.

Untargeted scraping of faces from the internet or CCTV to build recognition databases is prohibited outright.

Biometric categorisation that infers sensitive traits is prohibited unless the Act’s limited exceptions apply.

Real-time remote biometric identification in public spaces for law enforcement is prohibited unless a narrow statutory exception applies and the required safeguards are met.

Limitations / counterarguments. Article 5 contains exceptions and sector-specific conditions, especially for law-enforcement biometric identification and medical/safety emotion-recognition uses. These require specific factual and national-law analysis. A system outside Article 5 may still be high-risk under Article 6.

Issue 4 — Article 6(1): high-risk product / safety-component route

Conclusion. Article 6(1) applies to AI systems linked to EU-regulated products where third-party conformity assessment is required. This is the principal route for product-integrated AI, including many safety-relevant medical-device, machinery, toy, lift, PPE, radio equipment, and vehicle-related systems.

Rule. Article 6(1) has two cumulative conditions. The AI system must be intended to be used as a safety component of a product, or must itself be a product, covered by EU harmonisation legislation listed in Annex I. The product or AI system must also be required to undergo third-party conformity assessment under that Annex I legislation before being placed on the market or put into service.

Annex I Section A includes, among other regimes, machinery, toys, recreational craft, lifts, ATEX equipment, radio equipment, pressure equipment, cableway installations, personal protective equipment, gas appliances, medical devices, and in vitro diagnostic medical devices. Annex I Section B includes specified aviation, vehicle, marine, rail, and motor-vehicle regimes.

Article 3 defines “safety component” as a component that fulfils a safety function for a product or AI system, or whose failure or malfunction endangers the health and safety of persons or property.

Application. Use this four-step product-route test:

Step 1. Ask whether the AI system is itself a product, or is part of a product. Evidence includes product architecture, bill of materials, user documentation, marketing claims, and the CE file. If there is no product nexus, Article 6(1) usually does not apply.

Step 2. Ask whether the product is covered by Annex I legislation. Evidence includes the applicable harmonisation legislation, product category, and the sectoral compliance file. If no Annex I law applies, Article 6(1) does not apply.

Step 3. Ask whether the AI system is a safety component, or is itself the regulated product. Evidence includes a hazard analysis, safety case, failure-mode analysis, and intended purpose documentation. If the system plays neither a safety nor a product role, Article 6(1) does not apply.

Step 4. Ask whether the sectoral law requires third-party conformity assessment. Evidence includes the notified-body route, product-risk class, and conformity-assessment module. If the answer is yes, the AI system is high-risk under Article 6(1).

Examples:

A diagnostic AI system that is itself a medical device, or a safety-relevant component of a medical device, may be high-risk under Article 6(1) if the Medical Devices Regulation or In Vitro Diagnostic Medical Devices Regulation requires third-party conformity assessment for the relevant product. A pure HR recruitment SaaS tool is generally not an Article 6(1) system because it is not a covered Annex I product, but it may be high-risk under Annex III employment rules. A robotics-control model embedded in machinery may be Article 6(1) high-risk if it is a safety component and the relevant machinery conformity-assessment pathway requires third-party assessment.

Special product-manufacturer rule. Article 25 provides that a product manufacturer is treated as the provider of a high-risk AI system where an AI system is a safety component of a product covered by Annex I Section A, or where the AI system itself is such a product, and the system is placed on the market together with the product under the manufacturer’s name or trademark or put into service under the manufacturer’s name or trademark.

Conformity-assessment consequence. For high-risk systems covered by Annex I Section A, the AI Act’s conformity assessment is integrated into the relevant sectoral product conformity-assessment procedure, and the AI Act’s high-risk requirements are checked as part of that assessment.

Limitations / counterarguments. Article 6(1) classification cannot be concluded from product category alone. The decisive facts are safety-component/product status and whether third-party conformity assessment is required under the relevant Annex I legislation. For Annex I Section B systems, the AI Act contains special scoping limitations that require separate sectoral review.

Issue 5 — Article 6(2): Annex III high-risk route

Conclusion. Article 6(2) is the main route for non-product AI systems used in socially sensitive decision contexts. The legal question is whether the system’s intended purpose places it in an Annex III category.

Rule. Article 6(2) states that AI systems referred to in Annex III are high-risk. Annex III then lists specific categories and use cases.

The categories are:

Biometrics. High-risk uses include remote biometric identification, biometric categorisation by sensitive or protected attributes, and emotion recognition. Biometric verification whose sole purpose is to confirm a claimed identity is excluded from the remote biometric identification item. Article 5 may separately prohibit some biometric or emotion-recognition uses before the high-risk analysis is reached.

Critical infrastructure. High-risk uses are AI systems that serve as safety components in the management or operation of critical digital infrastructure, road traffic, or the supply of water, gas, heating, or electricity. The system must function as a safety component in the relevant context; operational or optimisation tools without a safety function fall outside this category.

Education and vocational training. High-risk uses include determining access, admission, or assignment to education and vocational training institutions; evaluating learning outcomes; steering learning processes; assessing education levels; and monitoring and detecting prohibited behaviour during tests. Tutoring or content support is not automatically high-risk unless it performs one of these functions.

Employment, worker management, and self-employment. High-risk uses include recruitment, targeted job advertisements, candidate filtering and evaluation, setting employment terms, promotion, termination, task allocation based on behaviour or personal traits, and monitoring and evaluating performance and behaviour. Candidate ranking and employee scoring are the central risk cases.

Essential private and public services. High-risk uses include eligibility assessment for public benefits and services, healthcare-related public services, creditworthiness evaluation or credit scoring (except financial fraud detection), life and health insurance risk assessment and pricing, and evaluation and classification of emergency calls and dispatch triage. The fraud detection exception should not be stretched to cover ordinary creditworthiness decisions.

Law enforcement. High-risk uses include victim-risk assessment, polygraphs and similar tools, assessment of evidence reliability, offending and reoffending risk, and profiling in criminal detection, investigation, and prosecution. These uses are in scope only where permitted under applicable Union or national law.

Migration, asylum, and border control. High-risk uses include polygraphs and similar tools, person-level risk assessments for entry, security, health, and irregular migration, AI assistance in asylum, visa, and residence permit decisions and related complaints, and detection or identification of persons except travel-document verification. National and EU border and asylum law may impose additional constraints.

Justice and democratic processes. High-risk uses include AI deployed by or on behalf of judicial authorities to research, interpret, or apply facts and law to concrete cases, and AI intended to influence election or referendum outcomes or voting behaviour. Administrative and logistical campaign tools are excluded where they do not directly expose natural persons to system outputs.

Application. The Annex III classification memo should answer these questions:

1. What is the system’s intended purpose?
2. Which Annex III category, if any, matches that intended purpose?
3. Does the system make, recommend, rank, filter, triage, score, classify, detect, or monitor in that category?
4. Does the output materially influence a decision about a natural person?
5. Does the system perform profiling of natural persons?
6. Is the system merely performing a narrow procedural, preparatory, or quality-improvement function?
7. Is the Article 6(3) derogation claimed and documented?
8. Has the provider registered the system or the non-high-risk Article 6(3) claim where required?

Limitations / counterarguments. A system used in a sensitive domain is not automatically Annex III high-risk unless its intended purpose matches the listed function. Conversely, a system marketed as “decision support” may still be high-risk if, in practice and documentation, it filters candidates, ranks individuals, assesses eligibility, triages services, or materially shapes human decisions.

Issue 6 — Article 6(3) derogation: when an Annex III system is not high-risk

Conclusion. The Article 6(3) derogation is best understood as an exception for low-impact Annex III-adjacent tools. It is not a broad escape route for systems that rank, score, filter, recommend adverse action, or materially influence human decision-making.

Rule. Article 6(3) provides that an Annex III system is not high-risk where it does not pose a significant risk of harm to health, safety, or fundamental rights, including by not materially influencing decision-making. The system must perform one of four functions: a narrow procedural task; improvement of the result of a previously completed human activity; detection of decision-making patterns or deviations from prior patterns, without replacing or influencing the previous human assessment without proper human review; or a preparatory task to an Annex III assessment. Article 6(3) then states that an Annex III system is always high-risk where it performs profiling of natural persons.

Article 6(4) requires a provider that considers an Annex III system not high-risk under Article 6(3) to document its assessment before placing the system on the market or putting it into service. Such a provider is also subject to Article 49(2) registration.

Application. Apply this derogation test in strict sequence:

Threshold risk. Ask whether the system avoids significant risk to health, safety, or fundamental rights. Low risk is indicated by the absence of material adverse effects, no vulnerable population involved, no denial or restriction of services, no strong power imbalance, and reversible outputs.

Material influence. Ask whether the output materially influences decision-making. Material influence is likely where the output ranks, filters, gates, scores, recommends rejection, prioritises access, or determines escalation.

Listed function. Ask whether the system performs only one of the four listed low-impact functions. Examples of qualifying functions include formatting, deduplication, clerical routing, post-human quality checking, pattern detection subject to genuine human review, and preparatory summarisation.

Profiling override. Ask whether the system profiles natural persons. If it does, the Annex III system remains high-risk regardless of the answers to the preceding steps.

Documentation. Confirm that the provider has documented the Article 6(3) assessment in writing, with supporting evidence, before placing the system on the market or putting it into service.

Registration. Confirm that the required Article 49(2) registration in the EU database has been completed where required.

Examples:

A tool that merely checks whether all fields in a job application are complete may be a narrow procedural tool. A tool that ranks applicants, predicts cultural fit, flags likely attrition, recommends interview/no interview, or filters out candidates is much more likely to materially influence recruitment and therefore be high-risk under Annex III employment rules. A school tool that converts teacher-entered grades into a standard report may be low-impact; a tool that evaluates learning outcomes, steers students into different learning tracks, or detects prohibited exam behaviour is likely high-risk. A credit application system that extracts documents for a human analyst may be preparatory; a model that generates creditworthiness scores or recommends approval/denial is likely high-risk.

Limitations / counterarguments. Human review is not automatically enough. The question is whether the human review is meaningful and whether the AI output materially influences the decision. Rubber-stamp review, default acceptance of AI recommendations, unexplained rankings, or operational pressure to follow system outputs undermines a derogation claim.

Issue 7 — Provider obligations for high-risk systems

Conclusion. A provider of a high-risk AI system must build an auditable compliance file before placing the system on the market or putting it into service. The obligations are lifecycle obligations, not one-time documentation obligations.

Rule and implementation detail.

Compliance with high-risk requirements. High-risk systems must comply with Section 2 requirements, having regard to intended purpose and the generally acknowledged state of the art. Implementation artifact: compliance matrix against Articles 8 to 15.

Risk management. Providers must maintain a continuous iterative lifecycle process to identify, analyse, estimate, evaluate, and manage known and reasonably foreseeable risks, including reasonably foreseeable misuse. Implementation artifacts: risk-management plan, hazard log, misuse analysis, and residual-risk acceptance.

Data governance. Training, validation, and testing data must be subject to governance practices addressing design choices, data collection, preparation, assumptions, availability, suitability, bias, and representativeness. Implementation artifacts: data-governance file, dataset sheets, bias testing, data lineage, and mitigation logs.

Technical documentation. Documentation must be drawn up before placing the system on the market or putting it into service, and kept up to date throughout the lifecycle. Implementation artifact: Annex IV technical file.

Logging. High-risk systems must technically allow automatic recording of events relevant to lifecycle operation. Implementation artifacts: logging specification, event taxonomy, and retention rules.

Transparency and instructions. Systems must be designed and developed with sufficient transparency to enable deployers to interpret output and use it appropriately, and instructions for use must accompany the system. Implementation artifacts: user instructions, limitations statement, intended use description, accuracy metrics, and oversight instructions.

Human oversight. Systems must enable effective human oversight by natural persons during use. Implementation artifacts: oversight design, escalation protocols, override controls, and reviewer training.

Accuracy, robustness, and cybersecurity. Systems must achieve appropriate levels of accuracy, robustness, and cybersecurity and perform consistently throughout their lifecycle. Implementation artifacts: test reports, performance thresholds, red-team results, and cyber controls.

Provider duties. Providers must ensure compliance, maintain quality management, keep documentation and logs, undergo conformity assessment, draw up an EU declaration of conformity, affix CE marking where applicable, register, take corrective action, and demonstrate conformity. Implementation artifacts: QMS, declaration of conformity, CE file, registration record, and CAPA process.

Post-market monitoring. Providers must establish a proportionate post-market monitoring system that actively and systematically collects, documents, and analyses relevant data over the system lifetime. Implementation artifacts: PMS plan, monitoring reports, and feedback channels.

Serious incident reporting. Providers must report serious incidents to market surveillance authorities within the Regulation’s timeframes, including shorter windows for widespread incidents, fundamental-rights incidents, and deaths. Implementation artifacts: incident classification SOP and reporting playbook.

Application. A provider cannot safely classify a system as high-risk and then only add a user notice. The high-risk regime requires technical, organizational, documentary, and governance controls. For enterprise implementation, the minimum provider compliance package should include an AI Act classification memo, Article 5 screen, risk-management file, data-governance file, Annex IV technical documentation, logging design, instructions for use, human-oversight design, test and validation reports, cybersecurity file, quality-management procedures, conformity-assessment record, registration evidence, post-market monitoring plan, and serious-incident procedure.

Limitations / counterarguments. The exact conformity-assessment pathway depends on the route. Article 6(1) product systems may be assessed through sectoral product conformity procedures. Many Annex III systems use internal control, except specified biometric systems where notified-body involvement may be required if harmonised standards or common specifications are not fully applied.

Issue 8 — Deployer obligations and FRIA

Conclusion. Deployers are not passive users. They must operate high-risk systems under the provider’s instructions and must implement their own controls where the AI system is used in decision processes affecting people.

Rule. Article 26 requires deployers of high-risk AI systems to take appropriate technical and organisational measures to use systems according to instructions; assign human oversight to persons with necessary competence, training, authority, and support; ensure input data are relevant and sufficiently representative where under their control; monitor operation; notify providers or authorities in specified risk or incident scenarios; keep logs where required; inform workers before workplace use; register certain public-authority uses; and inform affected natural persons where a high-risk Annex III system is used to make or assist decisions concerning them.

Article 27 requires a fundamental-rights impact assessment before first deployment for specified Article 6(2) high-risk systems, including covered public bodies and private entities providing public services, and for certain creditworthiness and life/health insurance systems. The FRIA must address the deployer’s processes, period and frequency of use, affected persons and groups, specific risks of harm, human oversight, and measures to take if risks materialise.

Application. A deployer implementation file should include:

Use according to instructions. The deployer must map its SOPs to the provider’s instructions for use and ensure operation remains within the intended purpose.

Human oversight. Identify named oversight roles, maintain training records, and document escalation and override procedures for each covered deployment.

Input-data quality. Put in place controls to ensure input data are relevant and sufficiently representative where the deployer controls the input to the system.

Monitoring. Implement operational and, where applicable, drift monitoring with defined issue-escalation procedures and clear lines for notifying the provider or relevant authority.

Logs. Maintain a log retention process with access controls and a complete audit trail, in accordance with the provider’s logging specification and applicable law.

Worker notice. Notify workers’ representatives and affected workers before deploying the system in a workplace context, as required under Article 26.

Affected-person notice. Notify affected natural persons where an Annex III high-risk system makes or assists in making decisions concerning them, to the extent required by the Regulation.

FRIA. Complete the Article 27 fundamental-rights impact assessment before first use, where the deployer falls within the categories required to conduct one.

Public authority registration. Register the use in the EU database where required for public-authority or covered deployer uses.

Incident response. Establish a clear pathway for notifying both the provider and the relevant market-surveillance or competent authority in the event of a serious incident.

Limitations / counterarguments. Deployers may not control training data, model architecture, or provider-side technical documentation. However, lack of technical control does not eliminate deployer obligations. It shifts the focus to procurement, instructions, input data, human oversight, monitoring, FRIA, and contractual access to required information.

Issue 9 — Value-chain and role-shifting risks

Conclusion. AI Act responsibility can shift when an actor rebrands, substantially modifies, or changes the intended purpose of an AI system. Contracts must allocate documentation, audit, incident, and support duties.

Rule. Article 25 provides that a distributor, importer, deployer, or other third party is considered a provider of a high-risk AI system where it puts its name or trademark on a system already placed on the market or put into service; makes a substantial modification while the system remains high-risk; or modifies the intended purpose of a non-high-risk system so that it becomes high-risk. Article 25 also requires written agreements for certain high-risk value-chain dependencies involving tools, services, components, or processes supplied by third parties.

Application. A company using a vendor AI system may become a provider if it relabels the system as its own, changes the intended purpose, or substantially modifies functionality in a way that affects compliance or high-risk status. Fine-tuning, integrating into a new decision workflow, adding new input categories, changing thresholds, or changing use from analytics to eligibility scoring may require reassessment. Vendor contracts should include AI Act role allocation, access to technical documentation, data-governance evidence, logging interfaces, conformity evidence, post-market monitoring support, incident cooperation, change-notification rights, and support for deployer FRIA.

Limitations / counterarguments. Not every configuration change is a substantial modification. Article 3 defines substantial modification in terms of a change after placing on the market or putting into service that affects compliance or results in modification of the intended purpose. The analysis depends on technical and operational impact.

Issue 10 — Conformity assessment, registration, and authorities

Conclusion. High-risk classification must be linked to the correct conformity-assessment and registration pathway. This is where many implementation plans fail because they classify the system but do not map the procedural route.

Rule. Article 43 sets conformity-assessment procedures. Certain Annex III biometric systems may use internal control where harmonised standards or common specifications are fully applied, but notified-body assessment may be required in specified cases. Annex III points 2–8 generally follow internal control under Annex VI. Article 6(1) product-route systems under Annex I Section A are assessed through the sectoral product conformity-assessment procedure, with AI Act Section 2 requirements integrated. A new conformity assessment is required where a high-risk AI system is substantially modified, subject to the Regulation’s continuing-learning qualification.

Article 49 requires providers to register certain high-risk AI systems in the EU database before placing them on the market or putting them into service. Providers that classify an Annex III system as not high-risk under Article 6(3) must also register that system. Public-authority deployers must register use of certain high-risk AI systems. Article 71 establishes the EU database, including secure non-public sections for sensitive law-enforcement, migration, asylum, border-control, and critical-infrastructure information.

Article 70 requires each Member State to designate at least one notifying authority and at least one market-surveillance authority and to identify a single point of contact. Article 74 links AI Act market surveillance to Regulation (EU) 2019/1020 and allocates surveillance to sectoral authorities in product contexts and to financial or data-protection authorities in specified contexts.

Application. For each high-risk system, identify:

1. Article 6 route: product route or Annex III route.
2. Annex I sectoral product law, if any.
3. Whether third-party conformity assessment is required.
4. Whether harmonised standards or common specifications are available and applied.
5. Whether notified-body involvement is required.
6. Whether internal control is sufficient.
7. Whether EU database registration is required.
8. Whether registration is public, restricted, or national.
9. Which Member State authority is likely responsible.
10. Whether market surveillance falls to a sectoral product authority, financial supervisor, data-protection authority, or general AI market-surveillance authority.

Limitations / counterarguments. The Commission’s draft high-risk guidelines may clarify examples, but the binding answer remains the Regulation and any adopted implementing/delegated measures. The draft guidance should be treated as non-binding until finalised and even then as interpretive unless issued in legally binding form.

Confidence: High on the procedural framework; medium for specific systems until standards, common specifications, and product-sector routes are checked.

Issue 11 — Implementation timeline and transition

Conclusion. Implementation should be managed with two date columns: binding enacted-law baseline and pending Omnibus-change monitoring. The binding column controls unless and until an amendment is formally adopted and published.

Rule: enacted AI Act timeline.

2024-08-01. The Regulation enters into force and becomes directly applicable in all Member States.

2025-02-02. Chapters I and II apply, bringing in the AI literacy obligation and the prohibited-practices rules under Article 5.

2025-08-02. Several governance, notified-body, GPAI, confidentiality, and penalty provisions take effect, with the exception of the specified Article 101 penalty timing.

2026-08-02. General application date. The Regulation applies in full, subject to the transitional provisions in Article 111.

2027-08-02. Article 6(1) and corresponding obligations apply under the enacted text.

2030-08-02. Certain public-authority high-risk systems placed on the market or put into service before 2026-08-02 must comply by this date.

2030-12-31. Certain large-scale IT systems listed in Annex X placed on the market or put into service before 2027-08-02 must comply by this date.

Article 111 provides transition rules for already placed or put-into-service systems. High-risk systems placed on the market or put into service before 2026-08-02 are subject to the Regulation only if they are subject to significant design changes from that date. GPAI models placed on the market before 2025-08-02 must comply by 2027-08-02.

Omnibus monitoring. Council materials state that the provisional Digital Omnibus agreement would introduce fixed later dates: 2027-12-02 for stand-alone high-risk AI systems and 2028-08-02 for embedded high-risk AI products. The same Council material states that the provisional agreement still requires endorsement by the Council and Parliament, legal-linguistic revision, and formal adoption.

Application. Do not delay compliance solely because of the provisional Omnibus agreement. The prudent implementation plan is:

AI literacy and prohibited-practices screening. Already applicable under enacted law; action is required now.

Inventory and classification. Must begin immediately. This work is needed before the compliance obligations mature and the lead time for accurate classification should not be underestimated.

Annex III high-risk compliance. Build to the 2026-08-02 baseline unless and until a formal amendment changes timing.

Product-route Article 6(1) systems. Build to the 2027-08-02 enacted baseline while tracking the possible 2028-08-02 Omnibus change.

Provider and deployer contracts. Must be addressed immediately. Lead times for negotiating AI Act-compliant provisions are long, and many obligations depend on information that can only be obtained contractually.

FRIA and registration. Prepare ahead of first covered deployment; do not wait for the compliance date to begin the assessment.

Post-market monitoring and incidents. Design the monitoring system and incident procedures before deployment, not after launch.

High-Risk Classification Analytics by Common Use Case

CV screening that ranks, filters, scores, or recommends candidates — High-risk. Annex III employment covers recruitment and selection, including analysing and filtering job applications and evaluating candidates. The Article 6(3) derogation is unlikely where the tool materially influences interview or hiring decisions.

Targeted job advertisements — High-risk. Annex III expressly includes systems used to place targeted job advertisements.

Employee performance scoring, monitoring, or task allocation based on behaviour or personal traits — High-risk. Annex III covers systems used for employment-related decisions, task allocation based on individual behaviour or personal traits, and systems used to monitor and evaluate performance and behaviour.

Payroll calculation tool — usually not high-risk, but fact-dependent. Where the tool performs a narrow procedural calculation and does not determine employment terms, promotion, termination, monitoring, or behavioural evaluation, Article 6(3)-type reasoning may support a non-high-risk conclusion. If it affects compensation eligibility or employment terms through scoring or profiling, that conclusion changes.

Exam proctoring that detects prohibited behaviour — High-risk. Annex III education includes systems used to monitor and detect prohibited behaviour during tests.

AI tutor recommending practice questions only — fact-dependent. Not automatically high-risk unless the system evaluates learning outcomes, steers learning processes in a way captured by Annex III, assesses education level, or materially affects access or assignment.

Student admission or placement model — High-risk. Annex III education covers determining access, admission, or assignment to education and vocational training institutions.

Creditworthiness score for individuals — High-risk. Annex III covers evaluation of creditworthiness or establishment of credit scores, except systems used to detect financial fraud.

Payment fraud detection — often not high-risk under the creditworthiness item. Annex III excludes AI systems used for detecting financial fraud from the creditworthiness item. Other Annex III categories still require review on their own facts.

Life or health insurance pricing and risk assessment — High-risk. Annex III covers risk assessment and pricing in relation to natural persons for life and health insurance.

Emergency-call triage or ambulance, fire, and police dispatch prioritisation — High-risk. Annex III covers evaluation and classification of emergency calls and systems used to dispatch or prioritise emergency first-response services.

Medical diagnostic AI — often high-risk under Article 6(1). Where the AI is a medical device or safety component covered by Annex I legislation and third-party conformity assessment is required, Article 6(1) applies independently of the Annex III route.

Biometric identity verification for access control — fact-dependent. Annex III excludes biometric verification whose sole purpose is confirming that a person is who they claim to be from the remote biometric identification item. Other biometric, GDPR, employment, or national-law issues may still apply.

Remote biometric identification — high-risk or prohibited depending on context. Annex III covers remote biometric identification as a high-risk use. Article 5 separately prohibits certain real-time law-enforcement use in publicly accessible spaces unless strict exceptions apply.

Emotion recognition in workplace or education — often prohibited. Article 5 prohibits emotion inference in workplaces and education institutions except for medical or safety reasons.

Judicial decision-support tool used to research, interpret, or apply law to facts — High-risk. Annex III covers AI used by or on behalf of judicial authorities to assist in researching or interpreting facts and law and applying the law to concrete facts.

Election persuasion, voter targeting, or referendum influence system — High-risk. Annex III covers AI intended to influence election or referendum outcomes or voting behaviour, except certain administrative or logistical tools not directly exposed to natural persons.

Customer-service chatbot — usually not high-risk solely as a chatbot. A general-purpose customer service chatbot is unlikely to be high-risk on that basis alone. It may trigger transparency duties under Article 50 or become high-risk if deployed for eligibility assessment, credit decisions, public benefits, emergency triage, employment screening, or another Annex III function.

Recommended Implementation Architecture

AI inventory

Each record should include:

System name, version, owner, and vendor. Required for traceability across the compliance lifecycle and across operator roles.

Provider, deployer, importer, distributor, and product manufacturer. Determines which legal duties apply to which party for this system.

EU nexus. Establishes whether Article 2 scope is engaged and on which basis.

Intended purpose. The central variable driving Article 6 classification. Collect evidence from product specifications, manuals, marketing materials, contracts, and internal use-case approvals.

Actual deployment context. Detects intended-purpose drift and role shift that may change classification or trigger Article 25.

Output type. Supports the Article 3 AI-system analysis by confirming that the system generates predictions, recommendations, decisions, or similar outputs.

Affected persons. Determines fundamental-rights relevance and whether specific Annex III categories are engaged.

Product integration. Identifies whether the Article 6(1) product route applies.

Annex I product law. Maps the system to the applicable sectoral harmonisation legislation for the product-route analysis.

Third-party conformity assessment. The decisive condition for Article 6(1) classification. Confirm whether the applicable Annex I legislation requires it.

Annex III category. Identifies the Article 6(2) use-case route if applicable.

Profiling of natural persons. Triggers the Article 6(3) override that prevents an Annex III system from being treated as not high-risk.

Human review design. Relevant to the material-influence analysis under Article 6(3) and to deployer obligations under Article 26.

Article 5 prohibited-practices screen. Hard-stop compliance gate. Must be completed before any high-risk classification analysis.

Article 6(3) derogation claim. Triggers the documentation and registration requirements under Articles 6(4) and 49(2) if the provider concludes the system is not high-risk.

Registration status. Tracks compliance with Articles 49 and 71 EU database registration obligations.

FRIA status. Tracks compliance with the Article 27 fundamental-rights impact assessment obligation for covered deployers.

Post-market monitoring owner. Assigns accountability for the lifecycle monitoring obligation under Articles 26 and 72.

Classification memo template

For each system, prepare a memo with this structure:

1. System description and version.
2. EU scope analysis under Article 2.
3. AI-system analysis under Article 3.
4. Operator-role analysis.
5. Intended-purpose evidence.
6. Article 5 prohibited-practices screen.
7. Article 6(1) product-route analysis.
8. Article 6(2) Annex III mapping.
9. Article 6(3) derogation analysis, if claimed.
10. Profiling analysis.
11. Final classification: prohibited / high-risk / limited-risk transparency / GPAI / out of scope / not high-risk.
12. Obligations triggered.
13. Missing facts and owner.
14. Approval and reassessment trigger.

High-risk compliance pack

For each high-risk system, maintain:

1. Article 6 classification memo.
2. Article 5 prohibited-practices screen.
3. Risk-management file.
4. Data-governance file.
5. Technical documentation under Annex IV.
6. Logging design and retention policy.
7. Instructions for use and transparency materials.
8. Human-oversight design.
9. Accuracy, robustness, and cybersecurity test reports.
10. Quality-management system evidence.
11. Conformity-assessment evidence.
12. EU declaration of conformity.
13. CE marking evidence, where applicable.
14. Registration record.
15. Post-market monitoring plan.
16. Serious-incident reporting procedure.
17. Deployer support package.
18. FRIA support documentation.
19. Vendor/value-chain agreements.
20. Change-control and substantial-modification procedure.

Additional Details and Implementation Insights

Treat the 2026 High-Risk Guidelines as “Official Draft Interpretation,” Not Binding Law

The Commission’s 2026 draft high-risk classification guidelines are useful because they organize the classification exercise around the two Article 6 routes: the Annex I product/safety-component route and the Annex III sensitive-use-case route. The Commission states that the guidelines set out its interpretation of classification concepts and give examples of systems that should or should not be classified as high-risk, but the examples are not exhaustive and may be updated.

Intended Purpose Is the Central Classification Variable

The Commission’s Service Desk summary states that before Article 6 classification, two threshold questions must be answered: whether the system is an AI system and what intended purpose the provider specifies. The same page ties intended purpose to Article 3(12), meaning the use intended by the provider, including the specific context and conditions described in the information and documentation supplied by the provider.

Article 6(1) Product Route: “Safety Component” Is Broader Than a Stated Safety Purpose

The Service Desk product-route summary states that Article 6(1) has two cumulative conditions: the system must be intended as a safety component of a product, or itself be a product, covered by Annex I legislation; and the product or system must require third-party conformity assessment.

The same Commission summary gives two ways a system can be a safety component: it may fulfil a safety function, or its failure/malfunctioning may endanger health, safety, or property. It distinguishes safety functions from ordinary optimization, comfort, service-efficiency, billing, or non-safety quality-control functions.

A system marketed as “optimization” can still be safety-relevant if malfunction could create physical harm. The draft examples identify lane assistance, lift door timing / obstacle detection, agricultural spraying systems near persons, machinery safe-stop vision, ATEX gas shutdown, pressure-equipment protective shutdown, and rail collision/derailment prevention as safety-related examples. Conversely, a music recommender in a connected toy and agronomic yield forecasting / irrigation optimization are given as examples of non-safety components.

Article 6(3) Filter: “Human Review” Is Not Enough

The horizontal draft-guidance summary explains that Article 6(3)’s filter can remove certain Annex III systems from high-risk classification, but only where the system does not pose significant risk and performs a narrow procedural, preparatory, improvement, or pattern-detection function. The Service Desk also states the provider’s self-assessment must be documented before the system is placed on the market or put into service.

The examples clarify the difference between low-impact support and material influence. Sorting school applications into predefined categories, scanning visa files into fixed folders, detecting duplicate attachments, and flagging incomplete forms may be narrow procedural tasks if they do not rank, hide, label usefulness, suggest next steps, or evaluate credibility. By contrast, a system that proposes a different substantive decision or solution is not merely “improving” a completed human activity.

The real question is whether the AI output materially shapes the human decision. Rankings, risk flags, eligibility labels, credibility signals, “recommended rejection,” “high risk,” “top candidates,” “secondary screening,” and prioritization outputs are all strong evidence of material influence.

Natural Person Boundary Matters, Especially in Credit and Corporate Contexts

The horizontal guidance examples distinguish systems assessing natural persons from systems assessing companies or business data. A system assessing a company’s creditworthiness using company financial statements is not treated as evaluating a natural person so long as it is not intended to assess personal finances. The guidance also states that an owner assessed in support of a company loan does not fall under the creditworthiness use case where the primary credit beneficiary is the company.

For B2B credit, underwriting, vendor-risk, and corporate KYC tools, the classification file should expressly state whether the system evaluates a legal entity, a natural person, or both. If individual guarantors, directors, sole traders, or beneficial owners are scored on personal financial or behavioural attributes, the conclusion may change.

Annex III Detail — Biometrics

The biometrics guidance gives a sharper boundary between remote biometric identification, biometric verification/authentication, biometric categorisation, and emotion recognition. It treats facial/voice recognition against media archives, voiceprint database matching, post-event stadium CCTV matching, CCTV identification of a burglary suspect, CSAM matching against suspect databases, and reverse-image biometric searches as in-scope remote biometric identification examples.

The same guidance treats smartphone unlocking, online banking authentication, roadside fingerprint verification against an ID card, registered smart-home access, and secure premises access as out-of-scope for the remote biometric identification item where the system is used for verification/authentication and the person actively participates.

For emotion recognition, the draft examples treat call-centre voice emotion inference, body-worn camera emotion inference, gaming emotion measurement, crowd mood screening, and wearable mood monitoring as in scope. The guidance treats driver drowsiness/fatigue detection as out of scope for emotion recognition because fatigue is a physical state rather than an emotion or intention.

Annex III Detail — Critical Infrastructure

The critical-infrastructure guidance states that AI systems used as safety components in critical digital infrastructure, road traffic, or supply of water, gas, heating, or electricity are high-risk because malfunction could endanger lives/health and disrupt social/economic activity. It gives fire-alarm control in cloud computing centres as an in-scope critical digital infrastructure example.

For road traffic, in-scope examples include AI traffic-light adjustment, AI recognition of heavy objects on vulnerable bridges/quaysides, and AI water-level-to-lock-management tools in flood-risk scenarios. Out-of-scope examples include trouble-ticket management, network-load prediction, network optimization, and technical user-guide interactions where there is no direct safety function.

Annex III Detail — Education and Vocational Training

The education guidance frames the risk by reference to a person’s educational and professional trajectory and potential impacts on education, non-discrimination, and livelihood. It treats automated admissions systems, school assignment systems, vocational training assignment tools, and scholarship eligibility assessment systems as in scope.

The same guidance treats general admissions-information chatbots and student-facing programme recommendation platforms as out of scope where they do not make admissions decisions or materially influence admissions. It treats file-handling, indexing, application organization, ex post admissions-review tools, and admissions data organizers as potentially covered by the Article 6(3) filter where they do not affect the substantive admissions decision.

For learning evaluation, AI grading and feedback systems count as in scope where they contribute to final/summative evaluation. Student-only language-learning feedback, pronunciation feedback, and neurodiverse learning companions may be out of scope where they do not determine grades or assess learning for institutional decisions. Exam proctoring and cheating-detection systems are in scope, while plagiarism checking of homework outside a test setting is treated as out of scope for the “monitoring prohibited behaviour during tests” item.

Annex III Detail — Employment and Worker Management

The employment guidance treats AI job matching/ranking, candidate sourcing across platforms, ranking self-employed service providers, pilot visual-capacity assessment, scoring applicant answers, apprenticeship recruitment screening, targeted job advertisements, employment-agency vacancy matching, and recruitment background checks as in-scope examples.

The guidance treats discriminatory-wording detection in job ads, employer-brand advertising, employer reputation monitoring, employee onboarding support, candidate-controlled CV-tailoring tools, and candidate-controlled job-search assistants as out of scope for recruitment/selection where they do not influence employer selection or access to work. It treats credential verification, CV information organization, interview scheduling, retrospective anonymized hiring-bias audits, and personalized acknowledgement emails as examples that may be covered by the Article 6(3) filter.

For worker management, the guidance treats shift allocation based on behavioural/performance signals, platform tutor suspension/deactivation, law-firm workload allocation based on behavioural data, dynamic platform-worker pay, and post-allocation of civil servants as in scope. It treats parcel-tracking operations support, voluntary training-feedback tools, office-space optimization, corporate travel planning, and optional non-penalizing delivery-area suggestions as out of scope.

Annex III Detail — Essential Services, Credit, Insurance, and Emergency Services

The essential-services guidance treats systems deciding or recommending unemployment benefits, social benefits, social housing, home-care prioritization, benefit fraud/irregularity flags, personalised legal-answer chatbots for benefit eligibility, healthcare-application triage, and preventive-screening eligibility invitations as in scope.

The same guidance treats proactive preventive-care identification without eligibility determination, matching people to public support services without eligibility evaluation, case-handler allocation, and reimbursement assessment for legal persons as out of scope for the public-benefits item. It treats factual chatbots, medical-report summaries, translation of applications, and speech-to-text summaries as potentially filtered where the case handler reviews the underlying information and the system does not evaluate eligibility.

For credit, the guidance treats consumer-lending and mortgage credit scoring as in scope and adds that a credit agency’s score can be in scope even where the deployer of the scoring system is different from the third party that uses the score for lending, housing, healthcare, or telecommunications access decisions. It treats customer segmentation, personalised marketing, applicant support outside the formal credit scoring process, complaints handling after a credit decision, internal prudential monitoring after credit is granted, collateral-only evaluation, and margin-credit for leveraged trading as out-of-scope examples.

For insurance, the guidance treats life-insurance risk assessment and premium pricing using applicant data, mortality tables, health status, family history, lifestyle, or occupation as in scope. It treats health-insurance claims management as out of scope where it is distinct from risk assessment or pricing.

Annex III Detail — Law Enforcement

The law-enforcement guidance emphasizes the power imbalance in policing and the possibility of surveillance, arrest, deprivation of liberty, and fundamental-rights harm. It treats domestic-violence victim-risk assessment and human-trafficking vulnerability detection as in scope, especially where profiling is involved and the Article 6(3) filter cannot apply.

It treats location-focused crime-risk mapping, accident-risk models, crowd-hazard video analytics, flood-risk and wildfire models, and initial scene situational-awareness tools as out of scope for the victim-risk item where they do not assess risks to specific natural persons.

For evidence reliability, the guidance treats AI digital forensics for detecting altered images/audio/video, forged documents/signatures, authenticity of digital evidence from devices, and credibility of human sources as in scope. It treats forensic reconstruction, image enhancement, data recovery, crime-scene mapping, pattern detection, CSAM content flagging, ballistic matching, and indexing/tagging evidence as out of scope or potentially filtered where they do not evaluate evidentiary reliability.

For offending/reoffending, risk scoring of detained youth suspects, probation/parole assessments, penitentiary reoffending prediction, and criminal-court recidivism assessment are in scope. Location-only predictive crime mapping is out of scope for person-level offending/reoffending, and form-completeness or case-file preparation tools may be filtered.

Annex III Detail — Migration, Asylum, and Border Control

The migration/border guidance treats credibility indicators in border interviews or visa interviews as in scope under the polygraph/similar-tool item. Transcription, translation, and neutral interview summaries are out of scope where they do not infer deception or credibility.

For person-level risk assessment, the guidance treats risk scoring for entry checks, visa risk scoring, online-search-based migration-intent flagging, health-risk flagging, vehicle/route signals mapped to a named traveller, and group-level risk indicators applied to named individuals as in scope. It also states that a combined setup may be high-risk where an AI analytics module and a non-AI rules engine together produce person-level risk flags, even if each component considered separately would not be high-risk.

Aggregate migration-flow analytics, group-level public-health measures applied uniformly, vehicle-focused screening not mapped to a person, stolen-vehicle screening, and post-decision data cleaning are treated as out of scope for person-level risk assessment. For application examination, evidence appraisal, consistency analysis, phone-data route validation, document-morphing detection in eligibility examination, discrepancy analysis, and speech-origin inference used in eligibility reasoning are in scope; FAQs, appointment scheduling, status notifications, fixed file organization, completeness checks, neutral transcription/translation/summaries, grammar correction after human decisions, and ex post pattern detection may be out of scope or filtered depending on function.

For detecting, recognizing, or identifying natural persons, the guidance treats live facial recognition at border crossings, satellite/tower/unmanned-platform human-presence alerts used for border-control response, maritime detection and tracking for migration management, hidden-person detection in vehicles, and person-level monitoring in reception/detention areas as in scope. It treats search-and-rescue-only systems, travel-document verification, collision avoidance, historical fraud-pattern analytics, and crowd-size / gate-occupancy estimation as out of scope when not used for border-control person detection.

Added classification insight: in border/migration use cases, “location” is not decisive. The guidance says maritime detection can be in scope irrespective of whether it occurs in territorial waters, the contiguous zone, or the high seas; what matters is intended purpose.

Annex III Detail — Justice and Democratic Processes

For justice, the guidance treats systems that draft judicial decisions, generate small-claims or payment-order decisions, support judges in similar/repetitive cases, or select relevant law and precedents for a concrete set of facts as in scope. The guidance states that assisting in either researching/interpreting facts and law or applying law to facts can be enough.

The guidance treats speech-to-text systems, court-information chatbots, press-release or public-summary drafting, case assignment based on workload/specialization/holiday, evidence management/search without evaluation, anonymization/pseudonymization, internal communications, address search, court-fee checks, e-signature processing, and power-of-attorney verification as out of scope where they are ancillary and do not affect adjudication of individual cases.

Potentially filtered justice examples include pre-classification of incoming claims, metadata extraction, advanced case-law search, proofreading or style improvement, and post-draft factual-question checks where they do not assess credibility, determine facts, or materially influence judicial determination.

For democratic processes, the guidance treats political ad targeting / delivery optimization, political persuasion chatbots, virtual spokespersons, and voter-advice applications recommending parties/candidates as in scope. It treats campaign staff optimization, rally scheduling, donor-likelihood analytics, political content drafting without dissemination, elected-official monitoring, objective sociological analysis, academic electoral-behaviour research, ballot counting/OCR, and neutral election-information chatbots as out of scope.

Harmonised Standards Are a Compliance Path, Not Yet a Complete Safe Harbour

The Commission’s standardisation FAQ states that European harmonised standards translate legal requirements into technical specifications and that AI Act harmonised standards are being developed for high-risk requirements such as risk management, data quality, logging, transparency, human oversight, accuracy, robustness, cybersecurity, QMS, post-market monitoring, and conformity assessment.

The FAQ also states that a product or system is presumed to satisfy relevant EU legal requirements where it complies with harmonised standards referenced in the Official Journal, and that the Commission will review AI Act standards after publication before submitting references for publication in the OJEU. It expects first CEN/CENELEC standards in 2026.

The Commission’s 2026 Guidance Pipeline Should Become a Workstream Map

The Commission states that in 2026 it will develop guidance on high-risk classification, Article 50 transparency, serious-incident reporting, high-risk requirements, provider/deployer obligations, FRIA template, value-chain responsibilities, substantial modification, post-market monitoring template, SME/SMC QMS elements, and interplay with other EU law, including AI Act / data-protection guidance.

National Implementation Is Fragmented and Must Be Tracked Separately

The AI Act Service Desk national resources page shows a country-by-country implementation environment, including market-surveillance authorities, national helpdesks, regulatory sandboxes, and other national initiatives. It lists, for example, Cyprus’s Commissioner of Communications as notifying authority, market-surveillance authority, and single point of contact, and Lithuania’s assignments involving the Innovation Agency and Communications Regulatory Authority.