Search every question across sub-FAQs

An industry AI use case is high-risk under Annex III only when the AI system is intended to be used for one of the listed Annex III areas or when it separately meets the product safety-component rule in Article 6(1). The Commission FAQ explains that high-risk classification is based on intended purpose: the function performed by the system and the specific purpose and modalities for which it is used.

For industrial teams, that means a predictive-maintenance dashboard, production-quality analytics tool, or internal knowledge assistant is not high-risk merely because it is used in a factory, utility, insurer, bank, or public-sector supplier. The question is whether the intended purpose matches a listed high-risk use case, such as safety components in specified critical infrastructure, recruitment, worker management, creditworthiness, life or health insurance risk assessment and pricing, emergency triage or dispatch, biometric use, education, law enforcement, migration, justice, or democratic processes.

The practical boundary is not the customer's industry label; it is the legal use case. Annex III covers eight areas: biometrics; critical infrastructure; education and vocational training; employment, workers' management and access to self-employment; access to essential private and public services and benefits; law enforcement; migration, asylum and border control management; and administration of justice and democratic processes.

Industrial uses most often need closer review where the AI affects natural persons or safety-critical infrastructure. Examples include recruitment screening for plant workers, task allocation or performance monitoring based on worker behaviour, credit scoring of natural persons, life or health insurance pricing, emergency-call triage, biometric identification, emotion recognition, or an AI safety component in road traffic, critical digital infrastructure, or water, gas, heating or electricity supply. By contrast, equipment-failure forecasting, inventory planning, energy-use optimisation, document search, or translation may fall outside Annex III if they do not serve a listed intended purpose.

Article 6(3) is an exception to the Annex III rule, not a shortcut around it. It can apply where an Annex III-referred system does not pose a significant risk of harm to health, safety, or fundamental rights, including because it does not materially influence the outcome of decision-making.

The supported conditions are narrow: a narrow procedural task; improving the result of a previously completed human activity; detecting decision-making patterns or deviations without replacing or influencing the prior human assessment without proper human review; or performing a preparatory task for an Annex III assessment. The exception is not available where the Annex III system performs profiling of natural persons, because Article 6(3) says such systems are always high-risk.

For an Annex III high-risk conclusion, provider evidence should connect the intended purpose to the relevant Annex III point, then show the high-risk system records needed for conformity, traceability, and registration. The Commission FAQ identifies provider obligations before EU market placement or putting into service, including conformity assessment, quality management, and EU database registration.

For an Article 6(3) non-high-risk conclusion, the evidence should be different: it should explain the condition relied on, the grounds for the non-high-risk conclusion, and why the system does not materially influence a decision or otherwise pose significant risk. Annex VIII Section B specifically includes the Article 6(3) condition or conditions and a short summary of the grounds for treating the system as not high-risk.

A borderline tool is more likely to be an AI system when it is machine-based, operates with some autonomy, and infers from inputs how to generate outputs such as predictions, content, recommendations, or decisions that can influence a physical or virtual environment.

A tool is less likely to be an AI system when it only executes rules defined solely by people, such as fixed validation checks, deterministic routing tables, hard-coded eligibility rules, or ordinary calculations with no learning, reasoning, modelling, or inference beyond basic data processing.

Do not collapse a general-purpose AI model and an AI system into the same record. The model is the reusable capability; the AI system is the deployed or supplied system that uses a model to serve an intended purpose. A downstream provider can integrate a GPAI model into an AI system and then have system-level obligations for that integration.

Embedded and product-linked cases need two checks. First, decide whether the AI component itself is an AI system. Second, decide whether Article 6 makes it high-risk because it is a safety component, is itself a covered product, or falls into an Annex III use case.

Territorial scope is not limited to EU-established providers. The Act can apply to providers placing AI systems or GPAI models on the Union market, EU deployers, non-EU providers or deployers whose AI-system output is used in the Union, importers, distributors, product manufacturers, authorised representatives, and affected persons located in the Union.

Role classification is fact-specific and can change after launch. A distributor, importer, deployer, or other third party can become the provider of a high-risk AI system if it puts its name or trademark on the system, substantially modifies it, or changes the intended purpose so that the system becomes high-risk.

A defensible classification file should show the same facts a reviewer would need to reach the answer again: the object classified, why it is or is not an AI system, whether it is a GPAI model or a system, the intended purpose, the EU nexus, the operator role, and the high-risk screening result.

For high-risk and near-high-risk cases, align the evidence with Annex IV-style system description fields even if the team is still at classification stage: interactions with other hardware or software, form of supply, product integration, development methods, third-party components, output quality, monitoring, limits, and lifecycle changes.

Providers must design and develop AI systems intended to interact directly with natural persons so that the people concerned are informed that they are interacting with an AI system.

The notice is not required when the interaction is obvious to a reasonably well-informed, observant, and circumspect person in the circumstances and context of use. The direct-interaction duty also has a law-enforcement exception for systems authorised by law to detect, prevent, investigate, or prosecute criminal offences, subject to safeguards, unless the system is available for the public to report a criminal offence.

Providers of AI systems, including general-purpose AI systems, that generate synthetic audio, image, video, or text content must ensure the outputs are marked in a machine-readable format and detectable as artificially generated or manipulated.

Article 50 frames this as a technical design duty: the marking solution must be effective, interoperable, robust, and reliable as far as technically feasible, taking account of content type, implementation cost, and the generally acknowledged state of the art.

Deployers of an emotion recognition system or a biometric categorisation system must inform the natural persons exposed to the operation of the system.

Article 50 also states that personal data must be processed in accordance with the applicable EU data-protection instruments, including the GDPR, Regulation (EU) 2018/1725, or Directive (EU) 2016/680 depending on the context.

Deployers that use an AI system to generate or manipulate image, audio, or video content constituting a deep fake must disclose that the content has been artificially generated or manipulated.

Deployers that publish AI-generated or manipulated text for the purpose of informing the public on matters of public interest must also disclose that the text has been artificially generated or manipulated, unless the supported human-review and editorial-responsibility exception applies.

A useful evidence file separates provider technical marking duties from deployer disclosure duties. It should show the triggering capability, affected natural persons, notice or marking mechanism, timing, accessibility handling, and any exception relied on.

The evidence should be product-specific enough for a reviewer to reproduce the conclusion from the Article 50 text and the actual user or publication experience.

For a high-risk AI system, Article 73 requires the provider to report any serious incident to the market surveillance authorities of the Member States where the incident occurred. Article 3, point (49), defines a serious incident as an incident or malfunctioning of an AI system that directly or indirectly leads to death or serious harm to health, serious and irreversible disruption of critical infrastructure management or operation, infringement of Union-law obligations protecting fundamental rights, or serious harm to property or the environment.

The provider does not wait for perfect certainty about root cause. The Article 73 clock is tied to awareness of the serious incident and to establishing a causal link between the AI system and the incident, or a reasonable likelihood of that link.

Article 73 sets a default outer deadline of 15 days after the provider, or where applicable the deployer, becomes aware of the serious incident. Shorter outer deadlines apply for two categories: a widespread infringement or a serious and irreversible disruption of critical infrastructure management or operation must be reported not later than two days after awareness, and a death-related incident must be reported not later than 10 days after awareness.

If a complete report would delay timely reporting, Article 73 allows an incomplete initial report followed by a complete report. After reporting, the provider must without delay investigate the serious incident and the AI system concerned, including a risk assessment and corrective action, and must cooperate with competent authorities and, where relevant, the notified body.

A deployer is not the normal Article 73 reporter, but it has an explicit escalation duty when it identifies a serious incident: inform the provider first, then the importer or distributor and the relevant market surveillance authorities. Importers and distributors have their own high-risk AI system duties to withhold, notify, or help correct non-conforming or risky systems, so incident intake should route them into the communication record even when the provider owns the Article 73 report.

Do not merge this workflow with the EU AI Act rule for providers of general-purpose AI models with systemic risk. Article 55 requires those providers to keep track of, document, and report without undue delay to the AI Office and, as appropriate, national competent authorities relevant information about serious incidents and possible corrective measures. The Commission's GPAI serious-incident template is for that Article 55 model-provider context, not a replacement for Article 73 high-risk AI system reporting.

Article 27 requires the assessment before deployment of a high-risk AI system referred to in Article 6(2), which points to the Annex III high-risk areas. The rule expressly excludes high-risk AI systems intended to be used in the area listed in point 2 of Annex III, the critical-infrastructure area.

The trigger then depends on the deployer. A FRIA is required for deployers that are bodies governed by public law, private entities providing public services, and deployers of high-risk systems in Annex III points 5(b) and 5(c), which cover creditworthiness or credit scoring and risk assessment or pricing for life and health insurance.

Article 27 gives a concrete assessment list. The record should describe the deployer's process in which the high-risk AI system will be used, the intended period and frequency of use, the categories of natural persons and groups likely to be affected, and the specific risks of harm for those groups.

The FRIA also needs the human oversight implementation described according to the instructions for use, plus the measures to take if the risks materialise. Those measures include internal governance and complaint mechanisms, so the evidence should reach beyond legal sign-off into operating procedures.

The FRIA is not a replacement for a GDPR or law-enforcement data protection impact assessment. Article 27 says that where Article 27 obligations are already met through a DPIA under GDPR Article 35 or Directive (EU) 2016/680 Article 27, the FRIA complements that DPIA.

After performing the FRIA, the deployer must notify the market surveillance authority of the results by submitting the filled-out template referred to in Article 27. Separately, Article 49 requires public authorities, Union bodies, agencies, offices, or persons acting on their behalf to register their use of Annex III high-risk systems in the EU database, except Annex III point 2 systems, which are registered nationally.

Article 53 requires providers of general-purpose AI models to keep technical documentation for authorities, provide information to downstream AI system providers, maintain a copyright-compliance policy, and publish a sufficiently detailed summary of the content used for training.

The downstream information is not marketing copy. It must help AI system providers understand the model's capabilities and limitations and comply with their own AI Act obligations, while still protecting intellectual property, confidential business information, and trade secrets.