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 required route for Annex III points 2 to 8 (Article 43(2)); no notified body is involved. Also open to Annex III point 1 providers who have applied harmonised standards or common specifications covering the Section 2 requirements. 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 | Required for Annex III point 1 (biometrics) where harmonised standards or common specifications covering the Section 2 requirements do not exist or have not been applied in full (Article 43(1)); otherwise the provider may choose it. Not a route for Annex III points 2 to 8. Article 6(1) safety components follow the conformity procedure of their sectoral product law (Article 43(3)). |
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. A notified body is required in two situations:
- Biometrics under Annex III point 1 (remote biometric identification, excluding verification-only systems; biometric categorisation; emotion recognition), where harmonised standards or common specifications covering the Section 2 requirements (Articles 8 to 15) do not exist or have not been applied in full (Article 43(1)). Today that is every such system: the only harmonised standard cited so far, EN 18286:2026 (Commission Implementing Decision (EU) 2026/2274, 14 October 2026), covers the Article 17 quality management system, which is outside Section 2.
- 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.
For Annex III points 2 to 8 (critical infrastructure, education, employment, access to essential services such as credit scoring, law enforcement, migration and border control, justice and democratic processes), Article 43(2) prescribes internal control under Annex VI, which “does not provide for the involvement of a notified body”. A notified body is not an AI Act route for these systems, whether or not a harmonised standard exists.
Third-party review is still becoming a market signal. Procurement teams in regulated buyers (banks, insurers, public sector, healthcare) are starting to ask for an independent assessment as a shortlisting filter, irrespective of whether the regulation requires one. For Annex III points 2 to 8 that is a contractual or voluntary review outside the AI Act procedure, not an Annex VII certificate.
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 December 2027 Annex III 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 19 requires the logs to be kept for at least six months, longer where the intended purpose or other law requires; the technical documentation itself is kept for ten years under Article 18). 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 public record and early-mover reports 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?
Only for Annex III point 1 (biometrics), and only where harmonised standards or common specifications covering the Section 2 requirements have been applied: then the provider chooses Annex VI or Annex VII (Article 43(1)). Without them, Annex VII is required. For Annex III points 2 to 8 there is no choice: Annex VI applies and no notified body is involved (Article 43(2)).
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.