--- title: "EU AI Act FAQ: scope, roles, high-risk AI, GPAI, FRIA, and dates" canonical_url: "https://www.sorena.io/artifacts/eu/artificial-intelligence-act/faq" source_url: "https://www.sorena.io/artifacts/eu/artificial-intelligence-act/faq/items/page/2" author: "Sorena AI" description: "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." published_at: "2026-05-09" updated_at: "2026-05-17" keywords: - "EU AI Act FAQ" - "high-risk AI" - "GPAI obligations" - "AI Act FRIA" - "AI Act registration" - "Article 50 transparency" - "EU AI Act" - "AI Act FAQ" - "GPAI" - "FRIA" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # 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. *FAQ* *EU* ## EU AI Act frequently asked questions Answers to the recurring EU AI Act questions that decide whether a product team is in scope, which operator role applies, whether the system is prohibited or high-risk, and which records must exist before launch or deployment. Use the citations to check the underlying legal source before applying an answer to a specific product, supplier, model, customer use case, or Member State enforcement route. This EU AI Act FAQ answers practical questions about scope, operator roles, prohibited practices, high-risk AI systems, general-purpose AI models, transparency, fundamental rights impact assessments, registration, serious incidents, and staged application. It avoids penalty figures and other details unless they are needed for this FAQ and supported by the cited grounding sources. ## Browse sub-FAQ modules ### [Are industry AI use cases high-risk under EU AI Act Annex III?](/artifacts/eu/artificial-intelligence-act/faq/annex-iii-industry-use-cases.md) 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. - 4 items ### [EU AI Act AI System Classification Edge Cases FAQ](/artifacts/eu/artificial-intelligence-act/faq/ai-system-classification-edge-cases.md) Answers for EU AI Act edge cases: AI system definition, inference versus simple rules, GPAI models, embedded products, territorial scope, roles, and classification evidence. - 4 items ### [EU AI Act Article 50 transparency disclosures FAQ](/artifacts/eu/artificial-intelligence-act/faq/article-50-transparency-disclosures.md) 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. - 5 items ### [EU AI Act Article 73 serious incident FAQ](/artifacts/eu/artificial-intelligence-act/faq/serious-incidents.md) 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. - 3 items ### [EU AI Act FRIA FAQ: Article 27 Scope, Contents, and Notification](/artifacts/eu/artificial-intelligence-act/faq/fria.md) 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. - 3 items ### [EU AI Act GPAI and Systemic-Risk Duties: Article 53 and 55 FAQ](/artifacts/eu/artificial-intelligence-act/faq/gpai-and-systemic-risk-duties.md) 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. - 5 items ### [EU AI Act post-market monitoring FAQ for high-risk AI systems](/artifacts/eu/artificial-intelligence-act/faq/post-market-monitoring.md) 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. - 4 items ### [EU AI Act provider vs deployer role boundaries: Article 3 and Article 25 FAQ](/artifacts/eu/artificial-intelligence-act/faq/provider-and-deployer-role-boundaries.md) FAQ on EU AI Act provider, deployer, operator, importer, distributor, authorised representative, product manufacturer, downstream provider, and GPAI model provider boundaries. - 5 items ### [EU AI Act technical documentation FAQ | Article 11 and Annex IV](/artifacts/eu/artificial-intelligence-act/faq/technical-documentation.md) 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. - 3 items ### [FAQ: EU AI Act conformity assessment procedures and notified body selection](/artifacts/eu/artificial-intelligence-act/faq/conformity-assessment-and-notified-bodies.md) 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. - 4 items Browse all indexed questions: [/artifacts/eu/artificial-intelligence-act/faq/items](/artifacts/eu/artificial-intelligence-act/faq/items.md) ## All FAQ items *Page 2 of 2. Showing 20 of 40 items.* ### [When is a GPAI model classified as having systemic risk?](/artifacts/eu/artificial-intelligence-act/faq/gpai-and-systemic-risk-duties.md#when-is-a-gpai-model-classified-as-having-systemic-risk) *Module: [EU AI Act GPAI and Systemic-Risk Duties: Article 53 and 55](/artifacts/eu/artificial-intelligence-act/faq/gpai-and-systemic-risk-duties.md)* Article 51 classifies a general-purpose AI model as a GPAI model with systemic risk if it has high-impact capabilities, or if the Commission designates it after an ex officio assessment or a qualified alert from the scientific panel using Annex XIII criteria. - Record the model's training compute estimate, methodology, and supporting evidence before market placement decisions. - Escalate if training compute exceeds 10^25 FLOP or if model reach, modalities, autonomy, scalability, tools, user base, or training data suggest Annex XIII significance. - If relying on the Article 52 exception argument, keep objective evidence for why the model does not present systemic risk despite meeting the high-impact presumption. - Track Commission designation and reassessment decisions because systemic-risk status changes the provider duty set. Sources for this answer: - [Regulation (EU) 2024/1689 (EU AI Act)](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for Article 51 classification, Article 52 notification and reassessment, and Annex XIII designation criteria. - [European Commission - GPAI provider guidelines](https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers?ref=sorena.io) - Commission guidance explaining GPAI scope, the systemic-risk presumption, notification to the AI Office, and training-compute estimation context. ### [What extra duties apply under Article 55 for GPAI models with systemic risk?](/artifacts/eu/artificial-intelligence-act/faq/gpai-and-systemic-risk-duties.md#what-extra-duties-apply-under-article-55-for-gpai-models-with-systemic-risk) *Module: [EU AI Act GPAI and Systemic-Risk Duties: Article 53 and 55](/artifacts/eu/artificial-intelligence-act/faq/gpai-and-systemic-risk-duties.md)* Article 55 duties apply in addition to Articles 53 and 54. Providers of GPAI models with systemic risk must evaluate the model with state-of-the-art protocols and tools, conduct and document adversarial testing, assess and mitigate systemic risks at Union level, track and report serious incidents, and protect the model and its physical infrastructure with adequate cybersecurity. - Model evaluation file: protocols, benchmarks or other methodologies, evaluation criteria, metrics, results, known limitations, and who performed the evaluation. - Adversarial testing file: internal or external testing plan, test scope, model adaptations, red-team findings, mitigation decisions, and unresolved risk rationale. - Systemic-risk file: Union-level risk sources, affected public interests, likelihood and severity, mitigation measures, residual risk, and post-market monitoring triggers. - Serious-incident file: incident facts, model version, affected use or integration, known or likely harm, corrective measures, reporting route to the AI Office and, where appropriate, national competent authorities. - Cybersecurity file: controls for weights, algorithms, servers, datasets, access management, physical security, leak prevention, vulnerability handling, and attack response. Sources for this answer: - [Regulation (EU) 2024/1689 (EU AI Act)](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for Article 55 model evaluation, systemic-risk mitigation, serious-incident reporting, and cybersecurity duties. - [European Commission - AI Act serious incident template](https://digital-strategy.ec.europa.eu/en/library/ai-act-commission-publishes-reporting-template-serious-incidents-involving-general-purpose-ai?ref=sorena.io) - Commission page announcing the reporting template for serious incidents involving GPAI models with systemic risk. - [European Commission - GPAI Code of Practice](https://digital-strategy.ec.europa.eu/en/policies/contents-code-gpai?ref=sorena.io) - Commission page explaining the GPAI Code of Practice chapters, including the Safety and Security chapter for Article 55 systemic-risk obligations. ### [How do copyright policy, training summaries, open-source models, and the Code of Practice fit together?](/artifacts/eu/artificial-intelligence-act/faq/gpai-and-systemic-risk-duties.md#how-do-copyright-policy-training-summaries-open-source-models-and-the-code-of-practice-fit-together) *Module: [EU AI Act GPAI and Systemic-Risk Duties: Article 53 and 55](/artifacts/eu/artificial-intelligence-act/faq/gpai-and-systemic-risk-duties.md)* The Article 53 copyright policy and public training-content summary are separate duties. The copyright policy is an internal compliance policy for Union copyright and related-rights law. The public summary is a transparency artifact about the content used for model training, published according to the AI Office template. - Copyright policy: identify and comply with rights reservations under Article 4(3) of Directive (EU) 2019/790, including through state-of-the-art technologies where relevant. - Training-content summary: publish a sufficiently detailed summary using the AI Office template, generally comprehensive in scope while protecting trade secrets and confidential business information. - Open-source caveat: Article 53(2) excludes only Article 53(1)(a) and (b) for qualifying open-source GPAI models, and not for GPAI models with systemic risk. - Code of Practice caveat: providers may rely on approved codes of practice to demonstrate compliance until harmonised standards are published, but providers outside an approved code or standard must show alternative adequate means to the Commission. - Copyright Code caveat: the GPAI Copyright Chapter helps demonstrate Article 53(1)(c) implementation, but it does not itself decide compliance with Union copyright law. Sources for this answer: - [Regulation (EU) 2024/1689 (EU AI Act)](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for Article 53 copyright, training-summary, open-source exemption, and code-of-practice provisions. - [European Commission - Training-content summary template](https://digital-strategy.ec.europa.eu/en/library/explanatory-notice-and-template-public-summary-training-content-general-purpose-ai-models?ref=sorena.io) - Commission page for the explanatory notice and template for public summaries of training content under Article 53(1)(d). - [European Commission - Training-content summary FAQ](https://digital-strategy.ec.europa.eu/en/faqs/template-general-purpose-ai-model-providers-summarise-their-training-content?ref=sorena.io) - Commission FAQ explaining that the template gives a common minimal baseline for public training-content summaries. - [GPAI Code of Practice - Copyright Chapter](https://ec.europa.eu/newsroom/dae/redirection/document/118115?ref=sorena.io) - Code chapter used for the caveat that adherence supports Article 53(1)(c) demonstration but does not itself determine Union copyright-law compliance. ### [What staged application and enforcement points are supported for GPAI duties?](/artifacts/eu/artificial-intelligence-act/faq/gpai-and-systemic-risk-duties.md#what-staged-application-and-enforcement-points-are-supported-for-gpai-duties) *Module: [EU AI Act GPAI and Systemic-Risk Duties: Article 53 and 55](/artifacts/eu/artificial-intelligence-act/faq/gpai-and-systemic-risk-duties.md)* The Commission guidelines state that Chapter V obligations for GPAI model providers apply from 2 August 2025. They also state that Commission enforcement powers for these obligations enter into application on 2 August 2026, and that providers of GPAI models placed on the market before 2 August 2025 must take necessary compliance steps by 2 August 2027. - From 2 August 2025: Chapter V GPAI provider obligations enter into application according to the Commission guidelines. - From 2 August 2026: the Commission says its enforcement powers for GPAI provider obligations enter into application, including fines under Article 101. - By 2 August 2027: providers of GPAI models placed on the market before 2 August 2025 must take necessary steps to comply, according to the guidelines and Article 111(3) reference. - Do not use this GPAI FAQ to infer deadlines for unrelated high-risk AI system, prohibited-practice, transparency, product-law, or national-authority obligations. Sources for this answer: - [European Commission - GPAI provider guidelines](https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers?ref=sorena.io) - Commission guidance supporting the Chapter V application date, enforcement-power date, legacy-model compliance date, non-binding-guidance caveat, and Commission enforcement role. - [Regulation (EU) 2024/1689 (EU AI Act)](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for Article 101, Article 111, Article 113, and the underlying Chapter V obligations referenced by the Commission guidelines. ### [What does Article 72 require for EU AI Act post-market monitoring?](/artifacts/eu/artificial-intelligence-act/faq/post-market-monitoring.md#what-does-article-72-require-for-eu-ai-act-post-market-monitoring) *Module: [EU AI Act post-market monitoring FAQ for high-risk AI systems](/artifacts/eu/artificial-intelligence-act/faq/post-market-monitoring.md)* Article 72 requires providers of high-risk AI systems to establish and document a post-market monitoring system that is proportionate to the AI technologies and risks of the system. The system must actively and systematically collect, document, and analyse relevant data on the high-risk AI system's performance throughout its lifetime. - Define the monitored high-risk AI system, intended purpose, deployed versions, integrations, and known interaction points with other AI systems. - Specify which performance, safety, fundamental-rights, robustness, cybersecurity, anomaly, complaint, and incident signals are collected after deployment. - Explain how deployer feedback and other external sources are triaged, documented, analysed, and fed into risk management and technical documentation updates. - Link monitoring outputs to Article 20 corrective action and Article 73 serious-incident reporting so risk signals do not stop at product support. - Keep the monitoring plan with the technical documentation and update the lifecycle change record when provider-made changes affect the system. Sources for this answer: - [Regulation (EU) 2024/1689 (EU AI Act)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689&ref=sorena.io) - Primary legal text for Article 72 provider post-market monitoring systems, monitoring plans, and Annex IV technical-documentation links. - [European Commission - AI Act regulatory framework](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai?ref=sorena.io) - Commission policy page for official EU AI Act context and the risk-based framework used by the page. ### [How should deployer feedback, serious incidents, logs, and corrective action connect?](/artifacts/eu/artificial-intelligence-act/faq/post-market-monitoring.md#how-should-deployer-feedback-serious-incidents-logs-and-corrective-action-connect) *Module: [EU AI Act post-market monitoring FAQ for high-risk AI systems](/artifacts/eu/artificial-intelligence-act/faq/post-market-monitoring.md)* Deployers are not the Article 72 plan owner, but Article 26 makes them important monitoring inputs. Deployers must monitor high-risk AI systems on the basis of the instructions for use and, where relevant, inform providers under Article 72. - Deployer feedback intake: capture the system, version, use context, instruction-for-use step, observed output, affected persons or groups, operator action, and available logs. - Risk escalation: if the deployer reports an Article 79(1)-type risk, record the suspension status, market-surveillance authority notice, and provider response owner. - Serious-incident escalation: link the record to Article 73 reporting analysis, causal-link assessment, authority routing, investigation, risk assessment, and corrective action. - Corrective action: document whether the provider brought the system into conformity, disabled it, withdrew it, recalled it, or informed distributors, deployers, authorised representatives, or importers. - Log handling: use Article 12 and Article 19 provider logs and Article 26 deployer-controlled logs to reconstruct the event, but check privacy, sector, and law-enforcement limits before requesting or transferring data. Sources for this answer: - [Regulation (EU) 2024/1689 (EU AI Act)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689&ref=sorena.io) - Primary legal text for Articles 12, 19, 20, 26, 72, and 73 on logs, deployer monitoring, corrective action, post-market monitoring, and serious incidents. - [AI Act Service Desk - Article 20 corrective actions](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-20?ref=sorena.io) - Official AI Act Service Desk article page for provider corrective actions and duty of information. - [AI Act Service Desk - Article 73 reporting of serious incidents](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-73?ref=sorena.io) - Official AI Act Service Desk article page for serious-incident reporting by providers of high-risk AI systems. ### [What evidence should a high-risk AI provider keep for Article 72?](/artifacts/eu/artificial-intelligence-act/faq/post-market-monitoring.md#what-evidence-should-a-high-risk-ai-provider-keep-for-article-72) *Module: [EU AI Act post-market monitoring FAQ for high-risk AI systems](/artifacts/eu/artificial-intelligence-act/faq/post-market-monitoring.md)* The evidence should show that monitoring is systematic enough to evaluate continuing compliance, not just that incidents were logged. Keep the plan, the monitored signals, the analysis records, the outcomes, and the technical-documentation updates together so a reviewer can trace why a risk signal did or did not trigger corrective action, a conformity update, or a serious-incident report. - Post-market monitoring plan: scope, data sources, deployer-feedback channels, signal taxonomy, analysis cadence, escalation paths, and responsible roles. - Signal records: complaints, anomalies, performance drift, bias or discrimination indicators, cybersecurity issues, human-oversight failures, misuse patterns, and interaction issues with other AI systems. - Log evidence: provider-controlled automatically generated logs, deployer-controlled logs when shared lawfully, retention basis, access controls, and integrity checks. - Decision records: root-cause analysis, continued-compliance assessment, serious-incident determination, corrective-action decision, and authority communication status. - Lifecycle records: versions, configuration changes, model or data changes, intended-purpose changes, integration changes, and any substantial-modification or new conformity-assessment trigger considered. Sources for this answer: - [Regulation (EU) 2024/1689 (EU AI Act)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689&ref=sorena.io) - Primary legal text for Annex IV technical documentation, including lifecycle changes and the Article 72 post-market performance-evaluation system. ### [Which changes should reopen the post-market monitoring review?](/artifacts/eu/artificial-intelligence-act/faq/post-market-monitoring.md#which-changes-should-reopen-the-post-market-monitoring-review) *Module: [EU AI Act post-market monitoring FAQ for high-risk AI systems](/artifacts/eu/artificial-intelligence-act/faq/post-market-monitoring.md)* Reopen the Article 72 review when the real-world system no longer matches the monitoring plan, instructions for use, technical documentation, or risk-management assumptions. The strongest triggers are changes that affect intended purpose, high-risk classification, performance, affected groups, human oversight, logs, integration context, or risk controls. - New or changed intended purpose, user population, deployment context, country rollout, or affected group. - Substantial modification to a high-risk AI system after placement on the market or putting into service. - Integration with another AI system, model, data source, workflow, or product that changes performance or risk assumptions. - Observed performance drift, repeated anomalies, serious-incident indicators, or unresolved deployer feedback. - Changes to logs, human oversight, instructions for use, cybersecurity controls, or maintenance processes that affect traceability or safe operation. Sources for this answer: - [Regulation (EU) 2024/1689 (EU AI Act)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689&ref=sorena.io) - Primary legal text for Article 25 value-chain responsibility changes, Article 43 substantial-modification conformity assessment, and Annex IV lifecycle-change documentation. - [European Commission - serious-incident template for GPAI models with systemic risk](https://digital-strategy.ec.europa.eu/en/library/ai-act-commission-publishes-reporting-template-serious-incidents-involving-general-purpose-ai?ref=sorena.io) - Commission page for serious-incident reporting resources for GPAI models with systemic risk; included to distinguish that GPAI reporting route from high-risk AI system Article 73 handling. ### [What is the core provider-versus-deployer test under Article 3 of the EU AI Act?](/artifacts/eu/artificial-intelligence-act/faq/provider-and-deployer-role-boundaries.md#what-is-the-core-provider-versus-deployer-test-under-article-3-of-the-eu-ai-act) *Module: [EU AI Act provider vs deployer role boundaries: Article 3 and Article 25](/artifacts/eu/artificial-intelligence-act/faq/provider-and-deployer-role-boundaries.md)* A provider is the actor that develops an AI system or general-purpose AI model, or has one developed, and places it on the market or puts the AI system into service under its own name or trademark. That test is about development control, commissioning, market placement, service launch, and branding, not only technical authorship. - Treat name, trademark, market-placement records, commissioning contracts, technical documentation, and launch materials as provider evidence. - Treat business-process ownership, user instructions, access controls, input-data procedures, monitoring records, and logs under the organisation's control as deployer evidence. - Do not use 'owner' as a substitute role. The AI Act uses defined actors such as provider, deployer, importer, distributor, authorised representative, product manufacturer, and operator. - Classify each system and model separately. A party can be the deployer of one AI system, the provider of a modified high-risk system, and a downstream provider integrating a GPAI model in another product. Sources for this answer: - [Regulation (EU) 2024/1689 - Article 3 definitions](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Defines provider, deployer, authorised representative, importer, distributor, operator, placing on the market, putting into service, intended purpose, substantial modification, and GPAI model. ### [How do importer, distributor, authorised representative, product manufacturer, and operator roles fit around provider and deployer roles?](/artifacts/eu/artificial-intelligence-act/faq/provider-and-deployer-role-boundaries.md#how-do-importer-distributor-authorised-representative-product-manufacturer-and-operator-roles-fit-around-provider-and-deployer-roles) *Module: [EU AI Act provider vs deployer role boundaries: Article 3 and Article 25](/artifacts/eu/artificial-intelligence-act/faq/provider-and-deployer-role-boundaries.md)* The AI Act uses 'operator' as an umbrella term that includes provider, product manufacturer, deployer, authorised representative, importer, and distributor. It is useful for scoping the full value chain, but it is not enough for assigning concrete duties because the named roles have different triggers. - For authorised representatives, keep the written mandate and the provider identity; the mandate does not erase the provider role. - For importers, keep evidence of the third-country name or trademark on the AI system and the first Union market placement route. - For distributors, keep supply-chain records showing the system was made available without the distributor being the provider or importer. - For product manufacturers, keep the product-law file showing whether the AI system is a safety component and whether it is marketed or put into service under the manufacturer's name or trademark. - For operators, map every concrete actor to one of the named Article 3 roles before assigning obligations. Sources for this answer: - [Regulation (EU) 2024/1689 - Article 3 operator and supply-chain definitions](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Supports the distinction between operator as an umbrella term and the specific roles of authorised representative, importer, distributor, deployer, provider, and product manufacturer. - [Regulation (EU) 2024/1689 - Article 25 responsibilities along the AI value chain](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Explains when a product manufacturer is treated as provider for high-risk AI systems that are safety components of products. ### [When does Article 25 shift a deployer or other third party into provider status?](/artifacts/eu/artificial-intelligence-act/faq/provider-and-deployer-role-boundaries.md#when-does-article-25-shift-a-deployer-or-other-third-party-into-provider-status) *Module: [EU AI Act provider vs deployer role boundaries: Article 3 and Article 25](/artifacts/eu/artificial-intelligence-act/faq/provider-and-deployer-role-boundaries.md)* Article 25 is the role-shift rule for high-risk AI systems. A distributor, importer, deployer, or other third party is treated as the provider, and is subject to provider obligations, when one of three triggers is met: it puts its name or trademark on an already placed or put-into-service high-risk AI system; it makes a substantial modification to an already placed or put-into-service high-risk AI system so that it remains high-risk; or it changes the intended purpose of an already placed or put-into-service AI system, including a GPAI system, so that the system becomes high-risk. - Rebranding evidence: trademark, UI branding, packaging, app-store listing, customer contract, and public materials showing whose name is attached to the high-risk AI system. - Substantial-modification evidence: change request, architecture or operating-system change, model or software change, conformity-impact analysis, and whether the modification was foreseen in the initial conformity assessment. - Intended-purpose evidence: original instructions for use, technical documentation, sales materials, new use case, deployment context, and why the changed use brings the system within Article 6 high-risk classification. - Cooperation evidence: information requests to the initial provider, technical-access records, assistance received, refusals or limitations, and trade-secret handling. Sources for this answer: - [Regulation (EU) 2024/1689 - Article 25 responsibilities along the AI value chain](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary source for Article 25 role-shift triggers: rebranding, substantial modification, changed intended purpose, cooperation by the initial provider, and product-manufacturer treatment. - [Regulation (EU) 2024/1689 - Article 3 substantial modification definition](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Defines substantial modification by reference to unplanned post-market or post-service changes affecting high-risk compliance or intended purpose. ### [How should teams classify GPAI model providers, AI system providers, and downstream providers?](/artifacts/eu/artificial-intelligence-act/faq/provider-and-deployer-role-boundaries.md#how-should-teams-classify-gpai-model-providers-ai-system-providers-and-downstream-providers) *Module: [EU AI Act provider vs deployer role boundaries: Article 3 and Article 25](/artifacts/eu/artificial-intelligence-act/faq/provider-and-deployer-role-boundaries.md)* A GPAI model provider is not automatically the provider of every AI system that later integrates the model. The legal text defines a general-purpose AI model separately, and Annex XII requires transparency information for downstream providers that integrate the model into their AI systems. - Keep separate records for the GPAI model provider, the AI system provider, and the deployer that uses the system in a concrete process. - Ask for downstream-provider information listed in Annex XII, including model tasks, integration types, acceptable-use policies, release and distribution methods, licence, input and output modalities, and technical means for integration. - If a team fine-tunes or otherwise modifies a GPAI model, record who controlled the modification, what changed, the additional training data or compute evidence available, and whether the change affects generality, capabilities, or systemic risk. - If the GPAI model is integrated into a high-risk AI system, preserve the chain from model documentation to system technical documentation, instructions for use, human oversight, monitoring, and conformity evidence. Sources for this answer: - [Regulation (EU) 2024/1689 - GPAI model definition and Annex XII downstream-provider information](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Defines general-purpose AI model and lists transparency information that GPAI model providers provide to downstream providers integrating the model into AI systems. - [European Commission - Guidelines for providers of general-purpose AI models](https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers?ref=sorena.io) - Commission guidance on who is a GPAI model provider, when models are placed on the Union market, and when downstream modifiers become providers. - [European Commission - GPAI Model Documentation Form](https://ec.europa.eu/newsroom/dae/redirection/document/118118?ref=sorena.io) - Template evidence source showing information intended for AI Office, national competent authorities, and downstream providers integrating GPAI models. ### [What evidence should prove a provider/deployer boundary decision?](/artifacts/eu/artificial-intelligence-act/faq/provider-and-deployer-role-boundaries.md#what-evidence-should-prove-a-providerdeployer-boundary-decision) *Module: [EU AI Act provider vs deployer role boundaries: Article 3 and Article 25](/artifacts/eu/artificial-intelligence-act/faq/provider-and-deployer-role-boundaries.md)* The evidence should prove the legal role, the factual trigger, and the boundary of responsibility. Avoid one generic AI owner record. Instead, keep a role matrix for each AI system and GPAI model version, because the same supplier relationship can involve several actors at different layers of the value chain. - Role matrix: provider, deployer, importer, distributor, authorised representative, product manufacturer, GPAI model provider, AI system provider, and downstream provider for each model or system version. - Market and service evidence: first Union market availability, putting into service, brand or trademark, product bundle, app or API release, and customer-facing materials. - Intended-purpose evidence: provider instructions, technical documentation, sales materials, deployment use case, affected user groups, and any changed purpose assessment. - Change evidence: modification description, whether the change was foreseen in the initial conformity assessment, impact on high-risk requirements, new conformity-assessment need, and provider cooperation records. - GPAI integration evidence: Annex XII-style downstream information, model dependencies, distribution channel, licence, integration means, acceptable-use policy, and modification or fine-tuning record. - Deployer operation evidence: oversight assignment, input-data controls, monitoring notes, log-retention rationale, worker or affected-person notices where applicable, and escalation records. Sources for this answer: - [Regulation (EU) 2024/1689 - Article 26 deployer obligations](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Supports deployer evidence for instructions-for-use compliance, human oversight, input-data relevance, monitoring, logs, workplace notice, affected-person notice, and authority cooperation. - [Regulation (EU) 2024/1689 - Article 27 fundamental rights impact assessment](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Supports evidence expectations for covered deployers of high-risk AI systems, including process, frequency, affected groups, risk, oversight, and mitigation information. ### [What does Article 11 require for EU AI Act technical documentation?](/artifacts/eu/artificial-intelligence-act/faq/technical-documentation.md#what-does-article-11-require-for-eu-ai-act-technical-documentation) *Module: [EU AI Act technical documentation](/artifacts/eu/artificial-intelligence-act/faq/technical-documentation.md)* For a high-risk AI system, Article 11 makes technical documentation a pre-market or pre-service requirement. The file must be drawn up before the system is placed on the market or put into service, kept up to date, and written to demonstrate compliance with the high-risk requirements in Chapter III, Section 2. - Identify the AI system, provider, version, deployment form, intended purpose, and relevant software, firmware, hardware, API, or embedded-product context. - Explain the system architecture, development process, algorithms, design choices, assumptions, expected outputs, output quality, and any third-party pre-trained systems or tools used. - Document training, validation, and testing data where relevant, including provenance, scope, main characteristics, selection, labelling, cleaning, and data-governance choices. - Include validation and testing procedures, metrics for accuracy and robustness, discrimination-impact checks where relevant, test logs, and dated reports signed by responsible persons. - Tie the file to the Article 9 risk-management system, Article 14 human-oversight measures, cybersecurity measures, conformity evidence, and post-market monitoring plan. Sources for this answer: - [Regulation (EU) 2024/1689 - Article 11 and Annex IV](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32024R1689&ref=sorena.io) - Primary legal text for the Article 11 timing rule and Annex IV minimum technical-documentation contents for high-risk AI systems. - [European Commission - AI Act regulatory framework](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai?ref=sorena.io) - Commission overview confirming that high-risk AI providers must address documentation, human oversight, robustness, cybersecurity, conformity assessment, registration, declaration of conformity, and CE marking. ### [Which Annex IV sections should product and engineering teams populate?](/artifacts/eu/artificial-intelligence-act/faq/technical-documentation.md#which-annex-iv-sections-should-product-and-engineering-teams-populate) *Module: [EU AI Act technical documentation](/artifacts/eu/artificial-intelligence-act/faq/technical-documentation.md)* Treat Annex IV as a technical-file table of contents. The first section identifies what the system is and how it is supplied. The second section explains how it was built. Later sections show how it is monitored, controlled, tested, changed, and assessed against the AI Act requirements. - System identity: provider name, system name, version, relation to prior versions, intended purpose, deployment form, user interface, instructions for use, and hardware or software interactions. - Architecture and development: software components, model or algorithm logic, design choices, assumptions, optimization targets, expected output quality, computational resources, third-party systems, and integration or modification decisions. - Data: training methodologies and techniques, training datasets, provenance, scope, main characteristics, collection and selection methods, labelling, cleaning, and data-quality gaps that affect compliance. - Validation and testing: procedures, validation and test data, metrics for accuracy and robustness, checks against Chapter III Section 2 requirements, discriminatory-impact assessment, signed reports, and test logs. - Controls: human-oversight measures, interpretability support for deployers, input-data specifications, cybersecurity measures, risk-management description, lifecycle changes, and post-market performance evaluation. Sources for this answer: - [Regulation (EU) 2024/1689 - Annex IV technical documentation](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32024R1689&ref=sorena.io) - Primary legal text listing the system description, architecture, data, validation, testing, oversight, cybersecurity, risk-management, standards, conformity, and post-market items required in technical documentation. ### [How do standards, conformity, and post-market monitoring fit the file?](/artifacts/eu/artificial-intelligence-act/faq/technical-documentation.md#how-do-standards-conformity-and-post-market-monitoring-fit-the-file) *Module: [EU AI Act technical documentation](/artifacts/eu/artificial-intelligence-act/faq/technical-documentation.md)* Annex IV does not stop at design-time evidence. It asks for the harmonised standards applied in full or in part when their references have been published in the Official Journal of the European Union. If no such harmonised standards have been applied, the file must describe the solutions adopted to meet the high-risk requirements and list other relevant standards and technical specifications applied. - Standards register: list Official Journal-referenced harmonised standards used in full or in part, and map each one to the AI Act requirement it supports. - Alternative solutions: where no harmonised standard is used, document the technical or organisational solution adopted for the relevant Chapter III, Section 2 requirement. - Conformity file: include the EU declaration of conformity and keep it aligned with system identity, provider identity, applicable Union law, and any standards or common specifications cited. - Post-market plan: describe how performance data, deployer feedback, incidents, lifecycle changes, and interactions with other AI systems will be collected and analysed to evaluate continued compliance. - Change control: record relevant lifecycle changes and reassess whether the technical documentation, conformity route, or notified-body assessment needs an update. Sources for this answer: - [Regulation (EU) 2024/1689 - Annex IV, Annex V, and Article 72](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32024R1689&ref=sorena.io) - Primary legal text requiring standards or alternative-solution evidence, a copy of the EU declaration of conformity, and a post-market monitoring plan within technical documentation. - [European Commission - Standardisation of the AI Act](https://digital-strategy.ec.europa.eu/en/policies/ai-act-standardisation?ref=sorena.io) - Commission page explaining that harmonised standards translate AI Act requirements into technical language and that applying standards remains voluntary. - [Joint Research Centre - Harmonised Standards for the European AI Act](https://ai-watch.ec.europa.eu/news/harmonised-standards-european-ai-act-2024-10-25_en?ref=sorena.io) - JRC brief explaining that European harmonised standards published in the Official Journal provide a legal presumption of conformity with the AI Act. ### [When does Article 43 require a notified body?](/artifacts/eu/artificial-intelligence-act/faq/conformity-assessment-and-notified-bodies.md#when-does-article-43-require-a-notified-body) *Module: [FAQ: EU AI Act conformity assessment procedures and notified body selection](/artifacts/eu/artificial-intelligence-act/faq/conformity-assessment-and-notified-bodies.md)* Article 43 uses different routes for different high-risk AI systems. For high-risk systems listed in point 1 of Annex III, the provider may use Annex VI internal control only when it demonstrates compliance by applying harmonised standards under Article 40 or, where applicable, common specifications under Article 41. - Start with the legal basis for high-risk classification: Annex III point 1, Annex III points 2-8, or Annex I Section A product legislation. - Record which harmonised standards or common specifications were applied in full, applied in part, unavailable, or published with restrictions. - Use Annex VII when Article 43 makes notified-body assessment mandatory for the route, not simply because the system is high risk. - Treat a substantial modification after an assessment as a trigger for a new conformity assessment unless the change was pre-determined in the initial technical documentation. Sources for this answer: - [Regulation (EU) 2024/1689 Article 43 conformity assessment](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:L_202401689&ref=sorena.io) - Primary legal text for the Article 43 split between Annex VI internal control, Annex VII notified-body assessment, and Annex I product-law conformity routes. - [Regulation (EU) 2024/1689 Annex VI and Annex VII](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:L_202401689&ref=sorena.io) - Primary annex text defining internal control and notified-body assessment of the quality management system and technical documentation. ### [What evidence supports Annex VI internal control?](/artifacts/eu/artificial-intelligence-act/faq/conformity-assessment-and-notified-bodies.md#what-evidence-supports-annex-vi-internal-control) *Module: [FAQ: EU AI Act conformity assessment procedures and notified body selection](/artifacts/eu/artificial-intelligence-act/faq/conformity-assessment-and-notified-bodies.md)* Annex VI internal control is still a formal conformity assessment. The provider verifies that its quality management system complies with Article 17, examines the technical documentation to assess compliance with Chapter III Section 2 requirements, and verifies that design, development, and post-market monitoring are consistent with the technical documentation. - Maintain Article 17 quality-management records covering regulatory strategy, design control, development, validation, standards, data management, risk management, post-market monitoring, serious-incident reporting, authority communications, record keeping, resources, and accountability. - Keep Article 11 and Annex IV technical documentation current with the system version, intended purpose, interfaces, data, testing, human oversight, cybersecurity, risk management, standards, declaration of conformity, and post-market monitoring plan. - Retain the Article 18 evidence set for 10 years after the high-risk AI system is placed on the market or put into service. - Link release gates to the provider duties in Article 16: conformity assessment, EU declaration of conformity, CE marking, and Article 49 registration before market placement or service. Sources for this answer: - [Regulation (EU) 2024/1689 Articles 11, 16, 17 and 18](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:L_202401689&ref=sorena.io) - Primary legal text for technical documentation, provider release duties, quality-management system content, and 10-year documentation keeping. - [Regulation (EU) 2024/1689 Annex IV](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:L_202401689&ref=sorena.io) - Primary annex listing the technical-documentation content used to show high-risk AI system conformity. - [ETSI White Paper 52 on AI activities and the EU AI Act](https://www.etsi.org/images/files/ETSIWhitePapers/ETSI-WP52-ETSI-activities-in-the-field-of-AI.pdf?ref=sorena.io) - Technical context explaining that conformity assessment can be third-party or internal-control based and focuses on technical documentation. ### [What changes when Annex VII applies?](/artifacts/eu/artificial-intelligence-act/faq/conformity-assessment-and-notified-bodies.md#what-changes-when-annex-vii-applies) *Module: [FAQ: EU AI Act conformity assessment procedures and notified body selection](/artifacts/eu/artificial-intelligence-act/faq/conformity-assessment-and-notified-bodies.md)* Annex VII adds notified-body review of both the provider's quality management system and the technical documentation for the AI system. The provider's application includes provider identity, the AI systems covered by the same quality management system, technical documentation for each system, quality-management documentation covering Article 17, procedures to keep the system adequate and effective, and a declaration that the same application was not lodged with another notified body. - Prepare one package for the quality management system and one for the AI system technical documentation. - Do not lodge the same Annex VII application with multiple notified bodies at the same time. - Plan how the provider will supply further evidence, testing, data-set access, or model access if the notified body requests it within the limits of Annex VII. - Track certificate conditions, supplements, refusal reasons, surveillance audit reports, and notified-body change decisions as controlled release records. Sources for this answer: - [Regulation (EU) 2024/1689 Annex VII](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:L_202401689&ref=sorena.io) - Primary annex for notified-body assessment of quality management systems, technical documentation, certificates, changes, and surveillance. - [Regulation (EU) 2024/1689 Articles 34 and 35](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:L_202401689&ref=sorena.io) - Primary legal text stating notified bodies verify conformity under Article 43 and that the Commission makes notified-body lists public. - [Single Market Compliance Space notified bodies by legislation](https://webgate.ec.europa.eu/single-market-compliance-space/notified-bodies/by-legislation?ref=sorena.io) - European Commission Single Market Compliance Space page for checking notified bodies by legislation. ### [What happens after a successful assessment?](/artifacts/eu/artificial-intelligence-act/faq/conformity-assessment-and-notified-bodies.md#what-happens-after-a-successful-assessment) *Module: [FAQ: EU AI Act conformity assessment procedures and notified body selection](/artifacts/eu/artificial-intelligence-act/faq/conformity-assessment-and-notified-bodies.md)* The conformity assessment route should close into release evidence. Article 47 requires the provider to draw up a written, machine-readable, physical, or electronically signed EU declaration of conformity for each high-risk AI system, keep it available to national competent authorities for 10 years, identify the system, state conformity with the Section 2 requirements, include Annex V information, translate it for relevant national competent authorities, and keep it up to date. - Attach the Article 47 declaration to the system record and include Annex V content such as system identification, provider identity, responsibility statement, conformity statement, standards or common specifications, notified-body details where applicable, and signature information. - Confirm the CE mark location: interface, machine-readable code, packaging, or accompanying documentation, depending on the system form. - When a notified body was involved, include its identification number after the CE marking and in CE-conformity promotional material. - Submit and maintain Article 49 and Annex VIII registration information where the system or deployer falls within the registration rules. Sources for this answer: - [Regulation (EU) 2024/1689 Articles 47, 48 and 49](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:L_202401689&ref=sorena.io) - Primary legal text for EU declarations of conformity, CE marking, notified-body identification numbers, and registration duties. - [Regulation (EU) 2024/1689 Annex V and Annex VIII](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:L_202401689&ref=sorena.io) - Primary annex text for declaration content and registration information submitted under Article 49. - [AI Act Service Desk Article 49 registration](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-49?ref=sorena.io) - Official AI Act Service Desk article explaining Article 49 registration duties for providers and certain deployers. ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/artificial-intelligence-act/faq/items](/artifacts/eu/artificial-intelligence-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 2 of 2 Pages: [1](/artifacts/eu/artificial-intelligence-act/faq/items.md) | [2](/artifacts/eu/artificial-intelligence-act/faq/items/page/2.md) [Previous page](/artifacts/eu/artificial-intelligence-act/faq/items.md) *Recommended next step* *Placement: before sources* ## Map each answer to a role, risk class, source, and artifact Sorena can help convert EU AI Act FAQ decisions into scope records, role maps, high-risk assessments, GPAI files, transparency notices, FRIA records, registration checks, and incident workflows. - [Open Research Copilot for EU AI Act](/solutions/research-copilot.md): Ask cited questions about EU AI Act scope, high-risk classification, GPAI duties, transparency, FRIA, registration, and incident records. - [Talk through implementation](/contact.md): Review your EU AI Act role map, risk classification, source gaps, and evidence plan with Sorena. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/artificial-intelligence-act/faq/items/page/2