Artifact GuideEU

EU AI Act Conformity Assessment and Notified Bodies

Decide whether a high-risk AI system can use internal control, needs notified body involvement, or must follow a sectoral product-law assessment route.

Use the page to line up provider obligations, technical documentation, quality management evidence, declaration, CE marking, registration, and notified body records before market release.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 31, 2026
Sections
7

Structured answer sets in this page tree.

Primary sources
13

Cited legal and guidance references.

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

Classify the high-risk system before selecting a route or assessor. Annex III points 2 to 8 use internal control, Annex III point 1 biometrics uses internal control only when the standards or common-specification conditions in Article 43 are met, and product-linked systems follow the applicable Annex I Section A product-law procedure. A notified body is not required for every high-risk AI system.

Section 1

Route selection starts with the high-risk basis

Start by recording why the AI system is high-risk. Article 6 separates product-linked high-risk AI from Annex III use cases. That split controls the conformity route, the evidence package, and whether an existing product-law notified body may become part of the assessment.

For product-linked systems under Article 6(1), the AI system is high-risk when it is a safety component, or is itself a product, covered by Annex I Union harmonisation legislation and that product is already subject to third-party under that legislation. For Annex III systems, Article 43 generally points to internal control, with a narrower notified body route for point 1 Annex III systems in the conditions listed in Article 43(1).

Check the application date separately from the route. Regulation (EU) 2026/1744 was published on 24 July 2026 and enters into force on 27 July 2026. It applies Chapter III Sections 1-3 from 2 December 2027 for Annex III high-risk systems and from 2 August 2028 for Article 6(1) systems. For Article 6(1) systems related to products under Annex I Section B, the amendment limits direct AI Act application to Article 6(1), Article 60a, and Articles 102-112; Articles 57-59 apply only where the high-risk requirements have been integrated into the sector law. Record the exact Annex I instrument before selecting an AI Act conformity route.

  • Record the high-risk legal basis: Article 6(1) product route or Article 6(2) Annex III route.
  • For Annex III, identify the exact Annex III point and whether Article 6(3) non-high-risk reasoning is being used; if so, document the assessment before market release and register under Article 49(2).
  • For Annex III point 1 systems, check whether harmonised standards or common specifications fully cover the relevant Section 2 requirements and whether they have been applied without restriction.
  • For Annex I product systems, integrate the AI Act Section 2 requirements into the product-law rather than running a disconnected AI-only exercise.
Section 2

What internal control actually has to prove

Annex VI internal control still requires the provider to verify that the quality management system complies with Article 17, examine the technical documentation against the high-risk requirements in Chapter III Section 2, and verify that the design, development process, and post-market monitoring match the technical documentation.

The minimum evidence package should therefore connect the Section 2 requirements to system design and operating controls: risk management, data governance, technical documentation, logging, deployer information, human oversight, accuracy, robustness, and cybersecurity. A self-assessment that only stores a policy or vendor attestation does not answer Annex VI.

  • Keep an Article 17 quality management file covering regulatory strategy, design control, validation, data management, risk management, post-market monitoring, serious incident reporting, communications, record keeping, resources, and accountability.
  • Keep Article 11 and Annex IV technical documentation with intended purpose, versions, interfaces, architecture, datasets, validation and testing reports, human oversight measures, cybersecurity measures, standards or common specifications, declaration of conformity, and post-market monitoring plan.
  • Keep the internal-control conclusion as a traceable sign-off that names the applied standards or common specifications and explains any alternative technical solution.
  • Store provider logs where under provider control and align the log design with post-market monitoring and substantial-modification detection.
Section 3

When a notified body enters the assessment

A notified body is required under Article 43(1) for high-risk AI systems listed in point 1 of Annex III when the provider cannot rely fully on the relevant harmonised standards or common specifications, including where no such standards or specifications exist, only part of a standard is applied, a common specification is not applied, or a standard is published with a restriction for the relevant part.

For high-risk AI systems covered by Annex I Section A product legislation, Article 43(3) sends the provider to the procedure required by that product law. Notified bodies notified under those product laws may control conformity with AI Act Section 2 requirements if their compliance with specified AI Act notified-body requirements has been assessed in the relevant notification procedure.

When Annex VII applies to a system intended for use by law-enforcement, immigration, or asylum authorities, or by Union institutions, bodies, offices, or agencies, the relevant market surveillance authority acts as the notified body. Do not route those systems to an ordinary commercial notified body.

  • Prepare a notified-body application package with the provider details, covered AI systems, Article 17 quality management documentation, Annex IV technical documentation, and a declaration that the same application has not been lodged with another notified body.
  • Expect the notified body to examine the quality management system, examine technical documentation, request evidence or tests, and, where necessary and proportionate to its task, access training, validation, and testing datasets.
  • Treat model or system changes that could affect compliance or intended purpose as notified-body change events when a Union technical documentation assessment certificate has been issued.
  • Keep refusals, restrictions, suspensions, withdrawals, certificates, supplements, audit reports, and reasoned assessment decisions with the product release evidence.
Section 4

Provider obligations around declaration, CE marking, and registration

Article 16 makes the provider responsible for the complete pre-market chain: comply with Section 2 requirements, operate a quality management system, keep documentation, run the Article 43 before placement or putting into service, draw up the EU declaration of conformity, affix CE marking, and register where Article 49 applies.

Article 47 and Annex V require a declaration for each high-risk AI system, issued under the provider's sole responsibility. It must identify the system, the provider or authorised representative, applicable Union law, relevant standards or common specifications, and, where applicable, the notified body, procedure, and certificate.

  • Before release, confirm the EU declaration of conformity exists, is up to date, and can be provided to national competent authorities on request.
  • Affix CE marking visibly, legibly, and indelibly; for digital high-risk AI systems, use a digital CE marking only if it is easily accessible through the interface or another accessible electronic means.
  • Where a notified body was involved, include the notified body's identification number after the CE marking and in promotional material that refers to CE conformity.
  • Register providers and relevant high-risk AI systems in the EU database before placement on the market or putting into service where Article 49 requires registration.
Section 5

Notifying authorities and notified bodies are separate roles

Notifying authorities are Member State authorities responsible for the assessment, designation, notification, and monitoring of bodies. They must be organised to avoid conflicts of interest and to safeguard objectivity and impartiality. A notifying authority is not the provider's assessor in the same way as a notified body; it controls which conformity assessment bodies can become notified bodies and monitors them.

A notified body is the body that has been notified and may perform the notified-body assessment tasks within the scope of its notification. Article 31 requires notified bodies to be independent of providers and other economically interested operators, to avoid consultancy conflicts, to maintain confidentiality, and to have sufficient administrative, technical, legal, and scientific personnel for the relevant AI systems, data, computing, and AI Act requirements.

  • Use the notifying authority route for questions about designation, notification scope, monitoring, objections, or competence of a body.
  • Use the notified body route for assessment of the provider's quality management system, technical documentation, certificates, supplements, surveillance audits, and certificate changes.
  • Check the notified body's notification scope against the AI system type and conformity module before treating a certificate as applicable.
  • Use the Commission Single Market Compliance Space/NANDO-style listing to locate notified bodies by legislation as designations become available.
Section 6

Separate harmonised standards, common specifications, and voluntary guidance

A technical standard supports conformity only to the extent that it covers an applicable AI Act requirement. A harmonised standard creates a presumption of conformity only after its reference is published in the Official Journal and only for the requirements covered by that reference. A draft standard, an ISO or ETSI publication, or a standard used elsewhere in the organisation does not receive that legal effect automatically.

Common specifications are Commission acts used under the conditions in Article 41. Providers can use other technical solutions, but they must justify how those solutions meet an equivalent level of compliance. Codes of practice and Commission or standards-body guidance can organise evidence without replacing the binding requirement or the conformity route.

  • For each cited standard, record the edition, clause, AI Act requirement supported, Official Journal reference if any, date checked, applicable system version, test evidence, and uncovered residual requirement.
  • Treat ISO/IEC 42001 as management-system evidence and ISO/IEC 23894 as risk-management guidance unless a specific legal mechanism gives a provision a different effect.
  • Use ETSI AI security, data-supply-chain, privacy, transparency, and explicability material as technical input where it fits the system; label it as supporting evidence unless the relevant provision has acquired a formal presumption of conformity.
  • Recheck the standards register before and after a new Official Journal citation, common specification, system change, or certificate update.
Section 7

Practical review checklist before release

Treat this checklist as a release gate for a high-risk AI system. It focuses on whether the conformity file would let a competent authority, notified body, importer, distributor, or enterprise customer understand the route chosen and verify the evidence without rebuilding the history from memory.

Escalate the file for legal and regulatory review when the route depends on Annex I product law, Annex III point 1 conditions, partial standards coverage, a restricted harmonised standard, non-application of common specifications, a substantial modification, or a notified-body refusal or restriction.

Article 46 permits a market surveillance authority, on a duly justified request and for a limited period, to authorise a specific high-risk system before is complete for exceptional public-security, life and health, environmental, or key industrial and infrastructure reasons. This is an authority-controlled derogation, not an alternative provider route; the conformity procedure must still be completed without undue delay.

Does every high-risk AI system need a notified body under the EU AI Act?

No. Article 43 uses internal control for high-risk AI systems in Annex III points 2 to 8. Notified body involvement is triggered for Annex III point 1 systems in the conditions listed in Article 43(1), and Annex I product systems follow the relevant product-law route.

What evidence should a provider keep after ?

Article 18 requires providers to keep, for 10 years after placement on the market or putting into service, technical documentation, quality management documentation, approved notified-body change records where applicable, notified-body decisions and documents where applicable, and the EU declaration of conformity.

What changes can reopen ?

Article 43 requires a new after a substantial modification. For systems with a Union technical documentation assessment certificate, Annex VII also requires provider notice to the issuing notified body for changes that could affect compliance or intended purpose.

  • High-risk basis is recorded with Article 6 reasoning and, where relevant, the exact Annex III point or Annex I product legislation.
  • Article 43 route decision is written: Annex VI internal control, Annex VII notified-body assessment, or product-law conformity route.
  • Article 17 quality management documentation and Article 11/Annex IV technical documentation are complete enough to demonstrate Section 2 compliance.
  • EU declaration of conformity, CE marking decision, notified body certificate details where applicable, and Article 49 registration evidence are stored together.
  • Change-control rules identify when a new , notified-body supplement, or updated declaration is needed.
Primary sources

References and citations

ai-act-service-desk.ec.europa.eu
Referenced sections
  • Supports registration requirements for high-risk AI systems before placement on the market or putting into service.
"Registration"
eur-lex.europa.eu
Referenced sections
  • Supports the practical release-gate checks across Articles 16, 17, 18, 43, 47, 48, 49, Annex IV, Annex V, Annex VI, and Annex VII.
"Obligations of providers"
eur-lex.europa.eu
Referenced sections
  • Binding amendment supporting the revised Chapter III application dates and the limited direct AI Act provisions for Article 6(1) systems related to Annex I Section B products.
Related guides

Explore more topics

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