Notified body evidence for the AI Act: what they actually ask for
Article 43 of Regulation (EU) 2024/1689 lets a high-risk provider choose between two conformity-assessment routes: internal control under Annex VI, or third-party assessment by a notified body under Annex VII. The second route is mandatory for a narrow set of systems and increasingly the preferred posture for the rest. This page is the working guide to what an Article 31 notified body actually wants to see — written for the engineering and compliance teams that will produce the artefacts, not the lawyers that will review them.
Article 43: two routes, one outcome
Conformity assessment under the AI Act produces the same final artefact regardless of route: a signed EU declaration of conformity under Article 47 and a CE marking under Article 48. The two routes differ in who attests that the technical documentation under Article 11 (and detailed in Annex IV) is complete and the system meets Chapter III Section 2 requirements.
| Route | Who attests | When it applies |
|---|---|---|
| Annex VI | Provider itself, internal control | The default for most Annex III high-risk systems. The provider draws up the technical documentation, runs internal verification, and signs the declaration of conformity. No external audit before placing on the market. |
| Annex VII | Notified body, third-party assessment of the quality management system and the technical documentation | Mandatory for biometric identification systems falling under Annex III(1)(a). Available as a voluntary route for other Annex III systems. Mandatory for Article 6(1) safety components where the underlying product directive already requires third-party assessment. |
The Article 6(1) row carries an extra layer that catches most teams the first time they read it. If your AI is a safety component of a Class IIb or III medical device, an Annex IIA machinery product, or another Annex I product with mandatory third-party assessment under its own directive, you inherit a notified body engagement from that directive plus the AI Act overlay. The notified body designated under your sectoral directive must also be designated under the AI Act, or you need to engage a second one.
Which AI systems require Annex VII (notified body)
The mandatory list is narrower than the casual reading of the regulation suggests. Annex VII applies as a requirement in three cases:
- Biometric identification systems under Annex III(1)(a) — real-time or post remote biometric identification systems, excluding the verification-only sub-category. Most facial-recognition vendors hit this line.
- Article 6(1) safety components where the underlying harmonised product law mandates third-party assessment. This is determined by the sectoral directive, not by the AI Act itself.
- Annex III systems where the provider has not applied harmonised standards or common specifications, or has applied them only in part. Article 43(1) and (2) together create this trigger.
The third case is operationally the most interesting. If you are an Annex III provider and there is no harmonised standard for your system class (which is the position for most Annex III categories as of mid-2026, because CEN-CENELEC JTC 21 standards are still being adopted), you can either wait for the standard, apply common specifications adopted by the Commission under Article 41, or go through Annex VII voluntarily.
The voluntary Annex VII route is becoming a market signal. Procurement teams in regulated buyers (banks, insurers, public sector, healthcare) are starting to ask "have you been through a notified body" as a shortlisting filter, irrespective of whether the regulation strictly requires it. That is not the regulation's fault; it is risk-averse buyers using third-party attestation as a trust shortcut.
What an Annex VII assessment actually involves
Annex VII has two parts that operate in parallel: an assessment of the provider's quality management system under Article 17, and an examination of the technical documentation under Article 11 (detailed in Annex IV). Both are conducted by the same notified body.
- Application. The provider submits an application to a single notified body of choice, with the QMS documentation and a list of systems covered. The notified body cannot reasonably refuse to engage if it is designated for the relevant categories.
- QMS audit. The notified body audits the documented quality management system on site or remotely. The audit covers regulatory strategy, design controls, examination and verification procedures, post-market monitoring, communication with competent authorities. ISO 9001 alignment helps; ISO/IEC 42001 alignment is the most direct precursor.
- Technical documentation assessment. For the system or family of systems under review, the notified body examines the Annex IV technical documentation. This is the document-heavy part of the process.
- Decisions and certificate. If both parts succeed, the notified body issues a quality management system approval certificate (valid for up to five years) and a technical documentation assessment certificate per system family.
- Surveillance. The notified body conducts periodic audits during the certificate validity. Significant changes to the system or to the QMS trigger reassessment.
The timeline for an initial Annex VII engagement is typically four to eight months from application to certificate. For a provider entering the 2 August 2026 application date without prior engagement, this means the QMS work needs to be at maturity now, with the application submitted before the deadline rather than as a response to it.
The six artefact families a notified body will request
The Annex IV technical documentation list is comprehensive on paper. In practice, notified-body engagements consistently surface the same six families of evidence as the load-bearing ones. The list below maps each to the Annex IV section it derives from.
1. System description and intended purpose
What the system does, how it is integrated into deployer workflows, the intended population of use, foreseeable misuse, and the development methodology at a level of detail that lets the assessor reproduce your reasoning. This is the document that every other artefact attaches to. Underspecified system descriptions cause cascading rework downstream.
2. Dataset documentation and data governance
Training, validation, and test data: provenance, scope, main characteristics, the criteria used to ensure data quality, and the steps taken to identify and mitigate bias and discrimination. For each dataset, an identifier traceable to specific bytes is the operational target. Data governance practices under Article 10 are evaluated against this documentation.
3. Accuracy and robustness evidence
The metric, comparator, threshold, and test set used to evaluate the system, with results that an assessor can reproduce. This is where pre-registration of evaluation claims matters: a notified body assessor reading a technical documentation file will treat a metric committed before evaluation differently from a metric reported after. Cryptographic pre-registration is not required by the regulation but is the cleanest available defence against the post-hoc-rationalisation question. See how we structure this.
4. Human oversight measures
The technical and organisational measures that allow a competent person to interpret system outputs, decide when to override, and stop the system when necessary. The assessor will ask for both the design (how is oversight built in) and evidence that it is exercised (training records, override logs, audit trail).
5. Logging architecture
The events logged, the retention duration, and the controls that ensure log integrity over the system's lifetime (Article 18 sets a ten-year floor on retention for placed-on-market systems). Tamper-evident logging is not explicitly required but is increasingly expected as the regime matures. See our Article 12 crosswalk.
6. Risk management file and QMS documentation
A risk register per system, mitigation log, and the quality management system documentation that ties everything together. ISO 9001 structure works as a backbone; ISO/IEC 42001 is the AI-specific overlay that maps cleanly to Article 17 obligations. The assessor will follow the chain from a logged event back through the risk register back into the QMS without effort, or they will flag the gap.
Five of the six artefact families are document-heavy. The third (accuracy and robustness) is the only one where the load-bearing object is an experiment record rather than a written description. That asymmetry is consistent with what teams report after their first notified-body engagement: the engineering work was on item 3; everything else was writing.
Where most providers are under-prepared
Across the engagements we have seen and the public artefacts of the early-mover providers that have already entered the process under the harmonised product directives, four gaps recur:
- Accuracy claims with no reproducible evidence trail. The metric is in the marketing material and in the technical documentation, but the path from "we report 87 percent" to "here is the run that produced 87 percent, here is the test set, here is the seed" is broken. This is the single most common rework demand from notified bodies.
- Datasets identified by name only. "ImageNet-val-2012" is not a sufficient identifier. The notified body will ask for the content hash of the specific bytes used, particularly for validation and test sets. Providers without a content-hashed dataset registry find this expensive to retrofit.
- Logging that exists but is not tamper-evident. Article 12 talks about automated logging without requiring cryptographic guarantees. But a notified body assessor reading "we log to /var/log/ai-events" will ask the obvious question: can this log be edited after the fact? If the answer is yes, the log is recorded but not evidentiary. Tamper-evident logging (Merkle anchoring, signed event streams, append-only logs with rotation hashes) is the cheap fix.
- Risk register that is a one-time document. Article 9 specifically requires the risk management system to be iterative and updated through the lifecycle. A risk register dated Q1 of the previous year and never re-opened is a finding waiting to happen during surveillance.
None of these are exotic problems. They are gaps that compound under time pressure and that are cheap to close if discovered three months out and expensive to close if discovered three weeks out.
Where PRML and falsify fit
The Pre-Registered ML Manifest specification (PRML v0.1) is the open spec we maintain for committing an evaluation claim to a SHA-256 hash before the run. In notified body engagements, PRML closes three of the six artefact families partially and one fully:
- Dataset documentation (family 2). PRML's
dataset.hashfield commits to specific content bytes. PARTIAL — provenance and bias documentation still sit outside the manifest. - Accuracy and robustness evidence (family 3). The pre-registered metric, comparator, threshold, seed, and producer identity are committed to a hash before the run. FULL — this is the case where PRML maps cleanly to a single Annex IV requirement.
- Logging architecture (family 5). Manifest hashes can be anchored into the log stream, giving Article 12 logs a cryptographic spine. PARTIAL — operational logging is broader than evaluation logging.
- Risk register and QMS (family 6). A manifest registry produces a queryable, content-addressed trail of every evaluation claim made. PARTIAL — the risk register itself sits in the QMS, not in PRML.
PRML does not replace technical documentation, QMS infrastructure, or the four other Annex IV families. It is one defensible answer to one specific kind of assessor question. We say this on every page because the alternative — pretending a manifest format closes a regulation — is the kind of overselling that wastes notified-body time and erodes trust.
What to do next
FAQ
Can I switch routes between Annex VI and Annex VII?
Yes, in either direction, before the declaration of conformity is signed. Some providers start with Annex VI and switch to Annex VII when a regulated buyer requires it; some start with Annex VII for credibility and downgrade to Annex VI for subsequent product families. Each switch resets the technical-documentation work product but not the underlying engineering.
How do I find a notified body designated for AI Act conformity assessment?
The Commission maintains a public list under the NANDO (New Approach Notified and Designated Organisations) database. Notified bodies designated under sectoral product directives are listed there and will be supplemented with AI-Act-specific designations as Member States complete the Article 28 designation process. Designation lag is real; expect a constrained supply of designated bodies through late 2026.
Does an ISO/IEC 42001 certificate substitute for the notified body assessment?
No. ISO/IEC 42001 is a management-system standard, not a conformity-assessment certificate under the AI Act. A 42001 certificate is strong evidence that the QMS half of an Annex VII assessment will pass cleanly, and a notified body may rely on it under Article 40, but it does not replace the technical-documentation assessment.
What happens if a notified body finds non-conformity?
The body issues findings with a corrective-action window. Minor non-conformities are typically resolved without affecting the certificate timeline. Major non-conformities suspend the assessment until resolved. If the provider cannot demonstrate conformity, the certificate is refused, and the system cannot be placed on the market via the Annex VII route.
How long does a quality-management-system certificate last?
Up to five years, subject to surveillance audits at intervals set by the notified body. Significant changes to the QMS or to the systems covered trigger reassessment. The technical-documentation assessment certificate is per system family and is valid for the lifecycle of those systems, subject to material-change rules.