EU AI Act Notified Bodies: Art.44 Certificates and What NB Auditors Check

Post #1602 in the sota.io EU Regulatory Compliance Series — EU AI Act Notified Bodies Operations 2026 #1/5

For most SaaS providers, the EU AI Act conformity assessment process is handled entirely in-house: compile the technical documentation, complete the quality management system, issue the EU declaration of conformity, register in the EU database. No external auditor. No certificate. Internal control, as defined in Annex VI, is the default route.

But for a defined subset of high-risk AI systems — those embedded in products covered by sectoral EU safety legislation, and real-time remote biometric identification systems deployed in publicly accessible spaces — internal control is not available. These systems require a third-party notified body assessment under Annex VII. The notified body issues a certificate under Article 44. Without that certificate, the provider cannot issue a valid EU declaration of conformity. Without the declaration, the system cannot lawfully enter the EU market after August 2, 2026.

This is the first post in our five-part series on notified bodies under the EU AI Act. We start with the fundamentals: what notified bodies are, how they are designated, what Article 44 certificates cover, and what NB auditors actually examine when they assess a high-risk AI system.

What Is a Notified Body Under the EU AI Act

A notified body (NB) is a third-party conformity assessment organisation designated by a national competent authority in an EU member state and formally notified to the European Commission. The designation gives the NB legal authority to conduct conformity assessments and issue certificates valid across the entire EU.

The EU AI Act does not create a new accreditation infrastructure from scratch. It builds on the New Legislative Framework (NLF) that governs notified bodies across EU product safety legislation — the same framework that designates medical device notified bodies under the MDR, machinery NBs under the Machinery Regulation, and radio equipment NBs under the RED.

Under the NLF, the sequence from accreditation to designation works as follows:

Step 1: National Accreditation Before an organisation can apply for NB designation under the EU AI Act, it must be accredited by its national accreditation body (NAB). In Germany, that is DAkkS (Deutsche Akkreditierungsstelle). In the Netherlands, it is RvA. In France, COFRAC. Accreditation verifies that the organisation meets the competency, independence, and operational requirements defined in harmonised standards — primarily ISO/IEC 17021 (management system certification) and ISO/IEC 17065 (product certification).

Step 2: Application to National Competent Authority The accredited organisation applies to its national competent authority (NCA) for designation under the EU AI Act. The NCA assesses whether the applicant meets the specific requirements set out in the Act's provisions on notified bodies — independence from providers, the ability to assess QMS systems, AI-specific technical competence, confidentiality obligations, and liability coverage.

Step 3: Commission Notification via NANDO The NCA notifies the European Commission through the NANDO (New Approach Notified and Designated Organisations) database. Once the notification is accepted — after a two-week period during which other member states and the Commission can raise objections — the body becomes an officially recognised notified body for the EU AI Act with authority to issue Art.44 certificates.

Step 4: NANDO Database Listing The designated NB appears in the public NANDO database with its designation number, the regulations it is designated under, and the scope of its accreditation. For developers choosing an NB, NANDO is the authoritative source for verifying that a given body is legitimately designated for EU AI Act assessments.

When Your System Requires a Notified Body

Under Article 43, the notified body route applies in two specific situations.

Situation 1: Annex I Safety Components

If your high-risk AI system is a safety component in a product covered by EU harmonised legislation listed in Annex I of the EU AI Act, you must use the notified body route. Annex I legislation includes, among others:

• MDR and IVDR — Medical Devices Regulation and In Vitro Diagnostic Medical Devices Regulation
• Machinery Regulation — Safety components in industrial and consumer machinery
• Radio Equipment Directive — AI functions in radiocommunication devices
• Civil Aviation Regulation — Safety functions in aviation equipment
• Automotive and vehicle safety legislation

The rationale is vertical integration: if your AI system is a safety component in a product that already requires NB certification under sectoral legislation, the AI Act adds a layer requiring NB assessment of the AI component specifically. In many cases, the provider already has a relationship with an NB from the sectoral certification — the AI Act assessment can be coordinated with the same body, provided it holds the appropriate AI Act designation.

Situation 2: Real-Time Remote Biometric Identification

Article 43(3) establishes a mandatory NB requirement for AI systems used for real-time remote biometric identification of natural persons in publicly accessible spaces. Internal control is explicitly not available for this category, regardless of whether the system is embedded in an Annex I product. The real-time biometric category receives heightened scrutiny precisely because of its direct impact on fundamental rights.

Article 44: What the Certificate Covers

When a notified body completes a conformity assessment under Annex VII and determines the system is compliant, it issues a certificate under Article 44.

Certificate validity: Article 44 certificates have a maximum validity period of four years. After four years, the provider must submit the system for a new conformity assessment to renew the certificate. There is no automatic renewal — the NB must re-examine the current state of the system.

Certificate conditions: The certificate is conditional on the system remaining materially consistent with what was assessed. If the provider makes modifications that substantially change the design, performance, or risk profile of the system, the certificate may be invalidated. Article 45 governs this: if a substantial modification occurs, a new conformity assessment is required. The NB that issued the original certificate should be informed of planned modifications and consulted on whether they trigger the substantial modification threshold.

Certificate scope: The certificate specifies exactly what was assessed — the technical documentation reviewed, the QMS procedures audited, the version or release of the AI system, and any limitations or conditions the NB identified. Scope limitations matter: an unqualified certificate is a stronger instrument than a conditional one. Providers in regulated verticals should understand that procurement counterparties and downstream deployers will scrutinize the scope.

Certificate database registration: Under Article 49, providers of high-risk AI systems using Annex VII assessment must register the system in the EU database on AI before placing it on the market. The registration record must reference the NB certificate number and the notified body's designation number from NANDO.

What NB Auditors Actually Check

The Annex VII conformity assessment procedure follows a two-track structure: quality management system assessment and technical documentation review. Both are required. An NB cannot issue an Art.44 certificate based on documentation review alone without QMS assessment, or vice versa.

Quality Management System Assessment (Article 17)

The NB's first examination is the quality management system established under Article 17. The QMS must cover the entire lifecycle of the AI system — design, development, testing, deployment, post-market monitoring, and incident response. Auditors specifically examine:

QMS documentation completeness: Is the QMS actually documented, or does it exist only as informal processes? NBs expect written procedures, version-controlled documentation, roles and responsibilities explicitly assigned, and evidence that the procedures are followed in practice rather than just declared.

Design and development controls: What controls govern how the AI system moves from concept to production? How are requirements captured? How are changes to the model or training data approved? How are test failures addressed? Is there a defined process for handling pre-deployment validation failures?

Supplier and data governance: Who supplies training data? How is data quality assessed? Are there data processing agreements in place that actually deliver compliance, or are there gaps between what the contracts say and how the data infrastructure works? Auditors will ask for evidence that data governance obligations under Article 10 are being operationally met, not just contractually stipulated.

Post-market monitoring (PMM): Article 72 requires providers to establish a post-market monitoring system. The QMS must include the PMM procedures. Auditors will look for a defined process for collecting performance data from deployment, a mechanism for identifying when the system's accuracy or behaviour has drifted from what was documented at assessment time, and a procedure for triggering corrective action when problems are identified.

Incident and serious incident handling: If the system causes or contributes to a serious incident, how does the provider identify it, document it, and report it under Article 73? The QMS must have a defined incident response workflow. Auditors will ask for evidence of exercises or test runs of the procedure, not just a documented policy.

Technical Documentation Audit (Annex IV)

The NB reviews the technical documentation package against the requirements of Annex IV. This is the most document-intensive part of the assessment. Key areas:

System description and intended purpose: Is the intended purpose of the AI system precisely defined? Does the technical documentation accurately describe the operational context, the population the system is intended for, the conditions under which it is expected to perform, and the conditions under which it should not be deployed? Vague intended purpose documentation is a common reason NB assessments are delayed or conditioned.

Risk management system (Article 9): The risk management documentation must demonstrate an iterative, ongoing process of identifying, analysing, and mitigating known and reasonably foreseeable risks throughout the system's lifecycle. Auditors look for documented risk assessments, mitigation measures that are technically implemented rather than just stated, and evidence that residual risk has been evaluated.

Data governance documentation (Article 10): The training, validation, and testing datasets must be described in enough detail for an auditor to evaluate whether data governance obligations have been met. This includes: how datasets were assembled, what bias mitigation practices were applied, how data quality was assessed, whether synthetic data was used and how its quality was controlled, and how the provider handles data that becomes stale or distribution-shifted after deployment.

Accuracy, robustness, and cybersecurity (Article 15): Technical documentation must demonstrate the performance metrics used to measure accuracy, the testing procedures used to establish robustness against inputs that are corrupted, erroneous, or adversarial, and the cybersecurity measures implemented at the system level. NBs will ask for test reports, not just claims.

Human oversight controls (Article 14): High-risk AI systems must be designed to allow effective human oversight. The technical documentation must show that human oversight is technically implemented — not just that users have been trained to override outputs. Auditors look for documented override mechanisms, procedures for detecting when the system is operating outside its intended parameters, and evidence that oversight procedures are testable in practice.

Transparency documentation (Article 13): Instructions for use, system cards, and the information made available to deployers and users must meet the Annex IV requirements for completeness and clarity. Auditors check that the documentation a deployer would receive is actually sufficient for them to deploy and operate the system in compliance with their own Article 26 obligations.

The Infrastructure Evidence Problem

One issue that is emerging as NB assessments begin in 2026 is what experienced NB auditors describe as the infrastructure evidence gap: the technical documentation describes the AI system's data architecture, security controls, and logging as it was at documentation time — but the actual system, running in production, may differ if the underlying cloud infrastructure has changed since the documentation was finalized.

For providers hosting AI systems on US-owned cloud infrastructure, this gap has a specific compliance dimension. If the NB assessment was based on technical documentation describing a logging architecture controlled by the provider, and production logs are accessible to a US-controlled infrastructure provider under CLOUD Act orders without requiring provider authorization, the evidence integrity claimed in the documentation is incomplete. The NB certificate covers the system as documented; it does not certify what the actual operational state is post-deployment.

Providers using EU-controlled infrastructure — where the jurisdiction of the infrastructure provider is EU-only and no equivalent disclosure mechanism applies — face a simpler documentation posture: the evidence described in the Annex IV documentation is consistent with what is operationally true.

Developer Preparation Checklist

Before engaging an NB, the following baseline documentation should be in place:

• Annex III category confirmed and documented with evidence of why the system falls under that category
• Annex I linkage assessed — does the system function as a safety component in any Annex I product?
• Art.17 QMS documented with written procedures for development, change control, data governance, testing, PMM, and incident response
• Annex IV technical documentation complete — system description, risk management, data governance, accuracy/robustness testing, human oversight controls, instructions for use
• Art.9 risk management documentation covering the full lifecycle, with documented mitigations for identified risks
• Art.10 data governance records — training dataset descriptions, quality assessments, bias mitigation evidence, validation procedures
• Art.15 test reports — accuracy benchmarks, robustness test results, cybersecurity assessment outputs
• Art.72 PMM system — documented process with defined triggers and corrective action procedures
• NB selected and scope agreed — body verified in NANDO database with EU AI Act designation, scope discussion completed
• Infrastructure evidence consistent — technical documentation accurately describes the operational deployment, including cloud provider jurisdiction and logging architecture

What Comes Next in This Series

Post #2/5 covers Article 45 and NB obligations — what independence, competence, and operational requirements notified bodies must satisfy, and why these requirements affect how NBs can and cannot structure their assessments.

The August 2, 2026 deadline is now under eight weeks away. For systems that require NB assessment, the documentation package needs to be substantially complete now. NB capacity is finite, assessment timelines are measured in weeks, and late submissions risk missing the deadline. The time to start is not after the summer.

sota.io is a EU-native managed PaaS on Hetzner Germany — no US parent company, no CLOUD Act exposure. Developers building high-risk AI systems on sota.io have a cleaner documentation posture for the infrastructure evidence components of NB technical documentation review.