EU AI Act Notified Bodies: Complete NB-Audit Readiness Checklist for High-Risk AI Developers

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

This series has covered the full lifecycle of notified body involvement in EU AI Act conformity assessment: what NBs are and how they are designated under Article 44, what constitutes a substantial modification requiring re-assessment under Article 45, what NB auditors examine when applying Annex VII, and how to prepare your technical documentation package for the audit. This finale brings together all of that into one structured readiness framework.

The August 2, 2026 deadline is not a soft goal. It is the date by which high-risk AI systems on the NB track must have valid certificates or completed self-assessments in place. For systems requiring notified body involvement, the practical submission deadline was months earlier — NBs are operating with capacity constraints, and audit scheduling queues are filling as of mid-2026. If your submission is not already under NB review, the August 2 date requires urgent attention.

This post gives you a consolidated framework: what to build, what to document, what to audit before submission, and what happens after certification.

Part 1: Scope Confirmation — Do You Need an NB?

Before investing in NB audit preparation, confirm whether your system requires a notified body at all.

The EU AI Act uses a tiered conformity assessment approach under Article 43:

Self-assessment track (Article 43(2)): Most Annex III high-risk AI systems can use internal quality management procedures, provided the provider complies with harmonized standards or common specifications. This is the default track for most high-risk AI systems.

NB track (Article 43(1)): Required only when:

• The high-risk AI system is covered by the EU directives listed in Annex I, Section A (meaning Union harmonization legislation for products such as machinery, medical devices, toys, radio equipment, and others where existing sectoral legislation mandates NB involvement), and
• The provider has not fully applied harmonized standards covering all relevant requirements

Practical implication: If your AI system does not fall under Annex I sectoral legislation (for example, a standalone SaaS AI tool used in recruitment, credit scoring, or education), you are almost certainly on the self-assessment track. The NB route is most likely to apply to AI embedded in regulated products: medical devices with MDR/IVDR intersection, machinery with Machinery Regulation requirements, or radio equipment with RED obligations.

If you are unsure, the confirmation check is: does your AI system form part of a product regulated under one of the Annex I directives, and has that sectoral regulation been amended to require NB assessment for the AI component? If yes, you need an NB. If no, you are on the self-assessment track and this checklist still applies — you simply conduct the assessment internally rather than submitting to an NB.

Part 2: Pre-Submission Package — The Complete Documentation Set

Whether your assessment is conducted by an NB or self-assessed, the documentation requirements under Article 11 and Annex IV are identical. The difference is who examines them.

Annex IV Technical Documentation — All 15 Areas

1. System identification and general description

• Name, version, purpose of use, intended deployers
• Modality (language model, vision system, tabular predictor, etc.)
• Jurisdictions and deployment contexts (EU-only, or global with EU deployment)

2. Detailed system description and development process

• Architecture diagram
• Training pipeline description
• Key design choices and the technical rationale behind them
• Third-party components, external datasets used

3. Monitoring, functioning, and control

• How the system operates during inference
• Logging and monitoring mechanisms
• Feedback loops and retraining triggers

4. Description of changes through the system lifecycle

• Version history with technical delta per release
• Change management procedure reference
• Substantial modification assessment record for each major version (see Article 45 obligations from post #3 of this series)

5. Risk management system documentation (Article 9)

• Risk identification methodology
• Risk evaluation records per identified risk
• Residual risk assessment after mitigations
• Risk management plan with review schedule

6. Data governance documentation (Article 10)

• Training data sourcing, collection, and processing records
• Data provenance and lineage
• Bias testing records and methodology
• Data quality metrics per dataset

7. Test records and accuracy metrics (Article 15)

• Accuracy, robustness, and cybersecurity test results
• Adversarial testing records
• Performance across demographic groups and deployment contexts

8. Human oversight measures (Article 14)

• Description of interfaces enabling human oversight
• Override and intervention mechanisms
• Training requirements for human overseers

9. Transparency information for deployers (Article 13)

• Instructions for use
• Limitations of the system
• Foreseeable misuse scenarios

10. Cybersecurity measures

• Threat model for the AI system
• Security controls in place
• Vulnerability disclosure process

11. Post-market monitoring plan (Article 72)

• Metrics to be collected in production
• Alert thresholds triggering re-assessment
• Serious incident reporting obligations under Article 73

12. Quality management system description (Article 17)

• QMS scope and coverage
• Document control procedures
• Internal audit schedule
• Corrective and preventive action (CAPA) process

13. Substantial modification assessment procedure

• Criteria used to classify changes as substantial vs. non-substantial
• Decision log for each assessed change
• Re-certification triggers

14. Certificates and declarations

• EU declaration of conformity
• Prior certificates if applicable
• Standardization compliance declarations

15. Additional information for specific Annex I products Where the system falls under sectoral legislation: cross-references to the sectoral documentation requirements and how the AI documentation integrates with the product technical file.

Part 3: Quality Management System Audit Trail

The Article 17 QMS is not a document — it is an evidence-backed process system. NB auditors do not evaluate your QMS policy documents; they evaluate whether the QMS actually produced auditable records for the system under assessment.

What the QMS Must Cover for the AI System

Design controls: Records showing how design inputs (system requirements) were translated into design outputs (specifications), with design review records at each stage.

Validation records: Evidence that the system was validated against its intended purpose and performance requirements before deployment. This is distinct from training metrics — it covers performance in the intended deployment context.

Change control records: For every version released, a change request, impact assessment, and approval record. If the change was assessed as non-substantial under Article 45, the assessment record must exist.

Supplier and component controls: For any third-party model, dataset, or component incorporated into the system, evidence of supplier qualification or component assessment.

Internal audit records: Completed internal audits against the documented QMS, with findings and closure records.

Post-market monitoring records: Evidence that monitoring has occurred as specified in the post-market monitoring plan, including any corrective actions taken.

QMS Documentation Infrastructure

A common failure mode is maintaining these records in systems that are not demonstrably controlled. "Controlled" means:

• Document version history is maintained
• Documents cannot be modified without a controlled change record
• Access logs are available showing who accessed or modified records
• Backup and retention policies are defined and evidenced

For providers using AWS, Azure, or GCP for documentation storage, the US CLOUD Act creates a potential evidence availability problem: documentation stored on US-parent infrastructure is reachable by US law enforcement under 18 U.S.C. § 2713 without EU judicial involvement. For NB audits, this is primarily a confidentiality concern (audit packages contain proprietary technical information) rather than a legal barrier. For EU-native infrastructure (Hetzner, Scaleway, OVH), this exposure does not exist.

Part 4: NB Selection and Engagement

If your system is on the NB track, NB selection is a legal decision: the NB must be designated for the specific sectoral legislation under which your product falls, and that designation is visible in the NANDO database.

Finding the Right NB

The NANDO database (ec.europa.eu/growth/tools-databases/nando/) lists all EU-designated NBs by directive and product category. For AI Act NB designation, the EU AI Act applies an analogous framework: NBs must be designated by a member state national authority for the conformity assessment activities covered under the Act.

Key selection criteria:

Sectoral coverage: The NB must be designated for the Annex I legislation applicable to your product, not just for the AI Act generally.

Technical competence in AI: This is an evolving area. Established medical device NBs (notified under MDR 2017/745) that are also developing AI competencies are the most likely candidates for MDR-intersecting AI systems. For machinery or radio equipment, the relevant machinery or RED NBs apply.

Capacity and timeline: As of mid-2026, NB capacity for AI Act assessments is limited. Pre-engagement conversations to confirm scheduling availability are essential before formal submission.

Subsidiary and subcontracting: Under Article 47, NBs can subcontract specific assessment tasks or use subsidiaries. You have the right to know which organizations will handle your assessment and to object to subcontractors.

Engagement Process

Formal NB engagement typically involves:

1. Pre-submission meeting: Most NBs offer (and require) an initial meeting to discuss the system, confirm scope, and align on documentation requirements. Use this to identify any documentation gaps before formal submission.

2. Formal application: Submission of the Annex IV package and QMS documentation. The NB will conduct an initial completeness check (typically 2–4 weeks) before entering full assessment.

3. Technical assessment: The detailed review of documentation, potentially including on-site visits or system demonstrations. Duration varies by system complexity — allow 3–6 months for complex systems.

4. Corrective action cycle: If the NB identifies non-conformities, you will receive a corrective action request. Minor corrective actions can be resolved quickly; significant gaps may require substantial re-documentation.

5. Certificate issuance: If the assessment is successful, the NB issues a certificate under Article 44. The certificate specifies the assessed version and any conditions or limitations.

Part 5: Post-Certification Obligations

Certification under Article 44 is not a one-time event. Ongoing obligations run for the lifetime of the certified system.

Article 72: Post-Market Monitoring

The post-market monitoring plan submitted as part of the Annex IV package must be actively implemented. Required activities include:

• Collecting performance data from deployed instances
• Tracking user feedback and incident reports
• Running periodic bias and robustness re-evaluations against production distribution
• Comparing production performance against the pre-certification performance envelope

Where monitoring reveals degradation beyond thresholds, corrective actions must be documented and the NB must be informed if the degradation affects the certification basis.

Article 73: Serious Incident Reporting

For high-risk AI systems in use within the EU, serious incidents must be reported to the national market surveillance authority:

• Serious incidents are defined as incidents that have led or could have led to death, serious harm to health, or serious disruption to critical infrastructure
• Reporting timelines are set by the Act (consult the implementing measures for exact timeframes, as these were established through delegated acts)
• Incident reports must also be shared with the NB that issued the certificate

Article 45: Change Management and Re-Assessment

Any change that constitutes a "substantial modification" under Article 45 requires the provider to assess whether a new conformity assessment is needed. Substantial modifications include:

• Changes that affect the intended purpose of the system
• Changes that affect the level of accuracy, robustness, or cybersecurity
• Changes that affect the compliance of the system with the essential requirements in Articles 9–15

The decision log for each change must be maintained and available for NB review. The NB may conduct surveillance assessments to verify that change management procedures are being applied correctly.

Certificate Validity and Renewal

Article 44 certificates have defined validity periods. Before expiry, a re-assessment against the current system state (including all changes since original certification) is required. Begin renewal engagement with the NB at least 6 months before expiry to avoid certification gaps.

Part 6: The 35-Point NB-Audit Readiness Checklist

Use this checklist in the 8 weeks before NB submission to confirm readiness.

Scope and Classification (5 points)

• 1. Confirmed that system falls under Annex III (high-risk classification confirmed)
• 2. Confirmed whether Annex I sectoral legislation applies (NB track vs. self-assessment)
• 3. Identified the correct NB designation category for the applicable sectoral legislation
• 4. Confirmed NB availability and scheduling timeline
• 5. Completed pre-submission meeting with selected NB

Annex IV Technical Documentation (10 points)

• 6. System description complete with version number matching deployment
• 7. Architecture and data flow diagrams current and accurate
• 8. Training data provenance records complete for all datasets used
• 9. Risk management system documentation covers all identified risks per Article 9
• 10. Test records include robustness and adversarial testing per Article 15
• 11. Human oversight interface description matches deployed implementation
• 12. Instructions for use are complete and reflect system limitations
• 13. Post-market monitoring plan is specific (metrics, thresholds, schedule)
• 14. Serious incident reporting procedure is documented and aligned with Article 73
• 15. For Annex I products: integration with sectoral technical file is complete

Quality Management System (8 points)

• 16. QMS scope explicitly covers the AI system being certified
• 17. Design control records exist for each major development stage
• 18. Validation records demonstrate performance in intended deployment context
• 19. Change control records exist for all versions since QMS establishment
• 20. Internal audit against QMS has been conducted within the last 12 months
• 21. All internal audit findings have documented closure records
• 22. CAPA records exist for any significant non-conformities identified
• 23. Document control system maintains version history with access logs

Change Management (4 points)

• 24. All system versions since development inception have change records
• 25. Each change record includes a substantial modification assessment
• 26. Criteria for classifying modifications as substantial are documented and applied consistently
• 27. No undocumented version changes exist in the current deployment

Post-Certification Readiness (5 points)

• 28. Post-market monitoring tooling is in place and generating data
• 29. Alert thresholds for performance degradation are defined and tested
• 30. Incident reporting channel to national authority is identified and documented
• 31. Team members responsible for Article 73 reporting are designated and trained
• 32. NB certificate renewal reminder is set for 6 months before expiry

Infrastructure and Evidence Integrity (3 points)

• 33. All Annex IV documentation is stored in a controlled, versioned system
• 34. Backup and retention policy for compliance documentation is defined and active
• 35. Infrastructure jurisdiction has been assessed for third-party data access risk (CLOUD Act exposure)

Series Summary: What You Have After This Series

Across these five posts, the NOTIFIED-BODIES-OPERATIONS-2026 series has covered:

Post 1 (#1602): What notified bodies are, how they are designated under Article 44, which NBs are relevant for which AI Act systems, and how to find them in NANDO.

Post 2 (#1603): What constitutes a substantial modification under Article 45, how change management must be structured to track modification decisions, and what Article 46 NB obligations mean for ongoing certification relationships.

Post 3 (#1604): What NB auditors actually examine during Annex VII assessment — the specific documentation areas, the evidence standards, and the corrective action process.

Post 4 (#1605): How to build and present the Annex IV technical documentation package, the 15 required areas, and how QMS documentation integrates with technical file preparation.

Post 5 (this post): The complete pre-submission readiness framework, NB selection and engagement process, post-certification obligations, and the 35-point checklist.

The August 2, 2026 deadline requires that high-risk AI systems have their conformity assessment complete. For NB-track systems, that means the NB certificate in hand before the deadline. Given NB scheduling constraints, the submission window for August 2 compliance closed in early Q2 2026 for most complex systems. If you are only beginning preparation now, use this framework to move as quickly as possible — and document the preparation effort itself as evidence of good faith compliance.

What This Means for Your Infrastructure

One consistent theme across notified body assessment is that evidence must be credible, controlled, and available. The QMS documentation, the change control records, the monitoring data — these are only as strong as the infrastructure that stores them.

For EU AI Act compliance purposes, evidence stored on EU-native infrastructure (no US parent, no CLOUD Act reach) is categorically cleaner than evidence stored on AWS, Azure, or GCP. The NB cannot compel you to use EU infrastructure — but the absence of CLOUD Act exposure simplifies the confidentiality position of your audit package and removes one category of legal complexity from the certification relationship.

Practically: if your QMS documentation, training data records, and audit trails are on EU-native managed infrastructure (Hetzner, Scaleway, OVH — or a PaaS built on them, such as sota.io), you have one fewer exposure to address when preparing for NB submission.

See Also

• EU AI Act Notified Bodies: Art.44 Certificates and What NB Auditors Check — Series #1/5: how NBs are designated and what their certificates cover under Article 44
• EU AI Act Notified Bodies: Managing Substantial Modifications (Art.45) — Series #2/5: when a change triggers a new conformity assessment and how to structure change management
• EU AI Act Conformity Assessment: What Notified Body Auditors Check — Series #3/5: the specific documentation areas and evidence standards auditors apply during Annex VII assessment
• EU AI Act Developer Preparation Guide: Getting Your Technical Documentation NB-Ready — Series #4/5: building the Annex IV package and integrating QMS documentation
• EU AI Act Art.43 Conformity Assessment + CLOUD Act: What Notified Body Auditors Will Find — how CLOUD Act exposure in AWS/Azure/GCP-hosted evidence creates an audit integrity gap that NBs are trained to identify

This post completes the EU AI Act Notified Bodies Operations 2026 series. For the next series in the sota.io compliance sequence, see the blog topic pipeline for upcoming EU AI Act compliance content through the August 2026 deadline.