EU AI Act Developer Preparation Guide: Getting Your Technical Documentation NB-Ready

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

The previous posts in this series covered what notified bodies are, how they are designated, when a substantial modification triggers re-certification, and what NB auditors examine during an Annex VII assessment. This post shifts perspective: what does a developer or technical team need to do to be ready for a notified body audit?

The August 2, 2026 deadline applies not only to the market placement of high-risk AI systems, but to the preparation of the documentation that backs them. For NB-track systems, that documentation must be examination-ready. An NB assessment is not a documentation review where an auditor grades your effort — it is a technical scrutiny where gaps in evidence lead to corrective action requirements or outright certificate refusal.

This guide walks through each of the major documentation areas in the sequence an NB auditor will typically examine them, with specific instructions for making each area audit-ready.

Understanding What the NB Actually Receives

Before drilling into specifics, it is worth being clear about what the NB audit package consists of. Under Article 43 and Annex VII, the provider submits:

1. A formal application identifying the system and the Annex I sectoral legislation that triggers the NB route
2. The complete Annex IV technical documentation package
3. Evidence that the Article 17 quality management system covers the system being assessed
4. Test reports, validation records, and any pre-market clinical/safety evidence applicable to the sectoral context

The NB reviews the documentation first and then conducts an on-site or remote assessment. Some NBs issue an initial findings letter (a preliminary examination report) before the formal audit. Responding to this letter with complete, organized evidence significantly accelerates the assessment.

Annex IV Technical Documentation: The 15 Elements

Article 11 requires that technical documentation be drawn up before the system is placed on the market and kept up-to-date throughout the system's lifecycle. The structure is defined in Annex IV, which specifies 15 mandatory elements. Developers preparing for NB audit must be able to produce evidence for each.

Element 1 — System Description and Intended Purpose

This is the first thing an auditor reads. It must contain: the system name, version number, description of intended purpose, list of Annex III high-risk categories that apply, deployment contexts, and the intended users (operators and end-users).

Common gaps: Intended purpose is described at a high level without specifying the decision context, degree of autonomy, or the role of human oversight. Auditors look for specificity: who uses the system, what decisions it influences, and whether human review is part of the deployment design.

Element 2 — System Architecture and Design

This section must describe the overall software architecture, the components and sub-components that constitute the AI system, the logic connecting inputs to outputs, and the boundary between the AI system and the broader solution in which it is embedded.

Common gaps: Architecture diagrams show the commercial product but not the AI system boundary. Under the EU AI Act, the AI system boundary matters for scoping which obligations apply. If your AI system is a component within a larger platform, the documentation must clearly scope the assessment to that component.

Element 3 — Training, Validation, and Testing Data Governance

Article 10 data governance obligations flow directly into this element. The documentation must describe: data sources, data collection methodology, data annotation processes, data quality criteria applied, and the characteristics of the training, validation, and test datasets including coverage gaps.

Audit focus: NB auditors in regulated sectors (healthcare AI, HR screening, biometrics) pay particular attention to bias documentation. They will look for whether the datasets represent the intended deployment population and whether under-representation of demographic groups was assessed and addressed. Statistical characterization of datasets — not just descriptions — is expected at the NB level.

Element 4 — Computational Resources

A description of the hardware and software infrastructure required for training, deployment, and operation. This includes compute specifications, operating environment dependencies, and infrastructure requirements for logging under Article 12.

Element 5 — Pre-Trained Models and Third-Party Components

If the system incorporates pre-trained models, third-party components, or open-source AI components, this element must document: the source, the license, the version, any fine-tuning applied, and an analysis of how the pre-trained component affects the system's risk profile.

Key consideration: GPAI model integration creates a layered compliance situation. Under Article 25, the provider of the system incorporating a GPAI model must identify the portion of obligations that cannot be discharged based on the GPAI model provider's documentation. This analysis must appear in Element 5.

Element 6 — Risk Management System Documentation

Article 9 requires that providers establish, implement, document, and maintain a risk management system throughout the AI system's lifecycle. This is an iterative process — not a one-time pre-market exercise. The documentation must cover: the risk identification methodology, risk estimation and evaluation procedures, risk mitigation measures adopted, and post-market monitoring integration.

Audit finding risk: Auditors see many providers who treat risk management as a pre-market checklist rather than a lifecycle process. The documentation must show that risk management feeds into design decisions, training choices, and validation design — not just a residual risks table appended at the end.

The Article 9 risk management system is distinct from and additional to any risk management required by the sectoral legislation (e.g., the Medical Device Regulation risk management process under ISO 14971). Both must be present and coordinated.

Element 7 — Validation and Testing Methodology

This element documents how the system was validated against its intended purpose, what test datasets were used, how bias and performance across deployment-relevant subgroups were assessed, and how the system performed against defined accuracy thresholds.

NB auditors in technical fields will review statistical validity: sample sizes, confidence intervals, and whether the test population matches the deployment population. Test methodology gaps (e.g., testing only on a majority demographic and generalizing) are a common corrective action trigger.

Element 8 — Accuracy, Robustness, and Cybersecurity Metrics

This element must document the metric definitions used, the measured performance values, the conditions under which metrics were measured, and performance over the ranges specified in the intended purpose. For cybersecurity, this includes threat modelling results and security testing outcomes.

Element 9 — Pre-Market Testing Against Reasonably Foreseeable Misuse

The AI Act requires that systems be tested not only for correct use but for reasonably foreseeable misuse — inputs, users, or deployment contexts outside the intended purpose that could occur in practice. This testing must be documented.

Element 10 — Quality Management System Reference

A reference to the QMS that governs the system under Article 17, including the specific QMS procedures that apply to this system's development, validation, and change management.

Element 11 — Monitoring, Logging, and Audit Trail Capabilities

Under Article 12, high-risk AI systems must automatically record events and enable post-deployment traceability. This element documents the logging architecture: what events are logged, retention policy, access controls, and how the logs are used for post-market monitoring.

Infrastructure consideration: Log storage infrastructure is within scope. If logs are stored on a US-parent cloud provider (AWS, Azure, GCP) they fall within US CLOUD Act jurisdiction, meaning a compulsory disclosure order could retrieve audit-critical evidence without the EU provider's knowledge. This creates a compliance gap for Article 12 audit trail integrity. EU-sovereign log storage eliminates this vector.

Element 12 — Instructions for Use

Article 13 requires that high-risk AI systems be designed and developed to be sufficiently transparent that users can interpret and use the outputs appropriately. The instructions for use must cover: the identity and characteristics of the system, its intended purpose, performance levels and limitations, circumstances requiring human oversight, and technical measures for human oversight implementation.

Element 13 — Human Oversight Measures

How human oversight is technically implemented — the controls, override mechanisms, and interface design that enable human supervisors to understand, monitor, and intervene. This must be operationally specific, not a high-level statement.

Element 14 — EU Declaration of Conformity

Under Article 47, the provider must draw up an EU declaration of conformity before placing the system on the market. For NB-track systems, this declaration can only be signed after the NB certificate is issued.

Element 15 — Post-Market Monitoring Plan

A description of the planned post-market monitoring activities, including the serious incident reporting process under Article 73, performance drift monitoring, and the trigger conditions for updating the technical documentation.

Note on Article 73 deadlines: The serious incident reporting obligations use calendar day counts — 2 days for serious incidents posing imminent risk to life, 10 days for other serious incidents, 15 days for serious malfunctions. These are not 24-hour or 72-hour deadlines.

Article 17 Quality Management System: What Auditors Examine

The Article 17 QMS must be documented and implemented before the NB assessment. Auditors are not looking for a document titled "QMS" — they look for evidence that quality management is actually practiced in your development process.

The minimum required QMS elements under Article 17 are:

Regulatory compliance strategy: How you identify and track applicable requirements across the EU AI Act, relevant harmonised standards, and sectoral legislation. This includes how requirement changes (new delegated acts, updated harmonised standards) feed into your processes.

Design and development procedures: Design reviews, design verification, design validation, and change control. Each procedure must be documented and there must be evidence of execution for the system under assessment.

Supplier and third-party component controls: How you qualify and monitor suppliers of training data, computational infrastructure, and pre-trained components. For cloud infrastructure suppliers, this includes infrastructure compliance verification (jurisdiction, data residency, and access control documentation).

Data management procedures: Covering dataset sourcing, annotation quality control, bias assessment, and dataset change management. These procedures link directly to the Annex IV Element 3 documentation.

Post-market monitoring and feedback loop: Procedures for collecting post-deployment performance data, assessing incidents, and feeding findings back into the technical documentation and risk management system.

Document control: Version control for all QMS documents and technical documentation. The NB will verify that the documents they are reviewing are the current authorized versions.

Practical Preparation: Building an NB Audit Package

When organizing the documentation package for submission, structure matters as much as content. Auditors process dozens of submissions — a well-organized package that maps directly to the Annex IV structure signals maturity and accelerates the review.

Step 1 — Write to Annex IV explicitly. Number your documentation sections to match the 15 Annex IV elements. Do not require the auditor to map your custom structure to the legal requirements.

Step 2 — Provide an evidence index. For each documented claim, provide a pointer to the evidence artifact: test report, dataset statistics file, QMS procedure reference, code repository path, infrastructure provider documentation. Assertions without evidence are corrective action requests waiting to happen.

Step 3 — Document the risk management process, not just the outcome. Show the risk identification records, the assessment meetings, the design changes made in response to identified risks, and the residual risk justification. A risk register table with no process trail does not satisfy Article 9.

Step 4 — Handle GPAI components explicitly. If your system incorporates any foundation model, GPAI model, or pre-trained component, include a specific section that identifies which EU AI Act obligations you are discharging from the component provider's documentation and which you are addressing through your own development process.

Step 5 — Address the infrastructure jurisdiction question. For systems in sectors where data integrity and audit trail chain of custody matters (medical AI, HR screening, critical infrastructure monitoring), document your cloud infrastructure provider, their jurisdiction, and your analysis of CLOUD Act or equivalent third-country access risk. EU-sovereign infrastructure eliminates this documentation gap entirely — providers using AWS or Azure will need to address it explicitly.

Step 6 — Prepare your monitoring architecture. Article 12 logging must be operational at the time of the audit. Auditors for critical applications will want to verify the logging system actually works, not just that it is described.

25-Point NB Audit Readiness Checklist

Technical Documentation (Annex IV)

• Annex IV numbered 1–15, all elements present and substantive
• Intended purpose specifies deployment context, user roles, and autonomy level
• AI system boundary explicitly defined (especially for embedded components)
• Training/validation/test dataset statistics documented (sample sizes, demographic coverage, bias assessment)
• GPAI/pre-trained component compliance gap analysis included
• Risk management system shows iterative lifecycle process (not just pre-market checklist)
• Validation methodology covers subgroup performance and confidence intervals
• Article 73 serious incident reporting process documented with correct day-count deadlines
• Human oversight mechanisms described operationally (override controls, interface design)
• Post-market monitoring plan includes performance drift triggers

Quality Management System (Article 17)

• QMS documentation covers all 7 mandatory areas (strategy, design, data, suppliers, monitoring, infrastructure, document control)
• QMS procedures show evidence of execution, not just existence
• Change management procedure covers substantial modification assessment (see Art.45)
• Supplier qualification records available for cloud infrastructure and data providers
• Document version control system operational

Infrastructure and Logging (Article 12)

• Logging architecture documented (events logged, retention, access controls)
• Log storage jurisdiction assessed — EU-sovereign preferred for NB audit trail integrity
• Logging system operational (not just described)

Declaration and Registration

• EU Declaration of Conformity template prepared (signed only after NB certificate)
• EU database registration (Article 49) planned

Process

• NB selected and application submitted (allow 3–6 months for assessment)
• Evidence index mapping documentation to Annex IV elements prepared
• GPAI component provider documentation received and reviewed
• Internal pre-audit mock assessment completed against Annex VII scope
• Corrective action process defined for findings

Timeline: When to Start Preparation

The August 2, 2026 market placement deadline is the hard constraint. For NB-track systems, timeline works backward from the certificate:

• NB assessment duration: 3–6 months from complete documentation submission
• Documentation preparation: 2–4 months for first-time compliance teams
• Pre-audit internal review: 4–6 weeks

For providers starting in June 2026, the August 2 deadline is already very tight for a first-time NB assessment. The practical path for systems not yet NB-ready is a documented transitional risk mitigation plan and a committed NB assessment timeline — while continuing to build the documentation package.

What This Means for Infrastructure Choices

The NB audit documentation requirements create an infrastructure dependency that developers often discover late: log storage, training data repositories, and security audit records must be traceable, tamper-evident, and jurisdiction-clean.

A high-risk AI system whose Article 12 logs are stored on AWS S3 in the EU is operationally functional, but the logs are technically accessible under a US government CLOUD Act order without the EU provider's knowledge. For a notified body auditor in a sector where chain of custody of audit evidence matters (medical AI, biometric identification systems), this creates a documentation gap that must be addressed.

EU-sovereign infrastructure — platforms like sota.io running on Hetzner Germany with no US parent entity — eliminates the CLOUD Act jurisdictional exposure for all AI system components: model weights, training data, logs, post-market monitoring data. The compliance documentation is straightforwardly clean. For developers assembling an NB audit package, this is worth the early infrastructure decision.

Next: The Complete NB Audit Readiness Checklist Finale

The final post in this series (#5/5) consolidates everything into a comprehensive NB audit readiness framework — the complete documentation structure, QMS implementation guide, and a pre-submission checklist that maps to the Annex VII examination scope.

If you are building a high-risk AI system and approaching the August 2026 deadline, the preparation guide above covers the core documentation requirements. The infrastructure question — where your data, models, and logs live — is one of the few structural choices that cannot be retrofitted easily. Getting that right now, before the documentation is locked, avoids a compliance gap that surfaces during the NB review.