EU AI Act Conformity Assessment: What Notified Body Auditors Check

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

For most EU AI Act high-risk AI providers, conformity assessment is a self-directed process. You compile the Annex IV technical documentation, implement the Article 17 quality management system, sign the Article 47 EU declaration of conformity, and register in the EU database under Article 49. No external auditor sees your work. The assessment is internal control.

But for providers subject to the notified body route — systems covered by the Annex I sectoral legislation, and certain real-time remote biometric identification systems — the process is fundamentally different. A designated third-party assessor will systematically examine your documentation, processes, and evidence before your system can enter the EU market. Under Article 43, these providers must obtain a certificate from a notified body before placing their system on the market after August 2, 2026.

This post breaks down what notified body auditors actually check during an Annex VII conformity assessment. It is designed for developers and technical leads who are preparing for a third-party audit or want to understand the depth of scrutiny their documentation will face.

The Annex VII Assessment Procedure

Annex VII defines two assessment modules. Module A covers quality management system assessment. Module B covers technical documentation assessment. In practice, most high-risk AI system assessments under the EU AI Act combine both: the NB reviews the provider's QMS framework and then conducts a specific examination of the technical documentation for the AI system being certified.

The assessment is not a checkbox review. Notified bodies under the EU AI Act are required to have genuine AI-specific technical competence — including expertise in the categories of systems they assess (medical AI, safety-critical automation, biometric systems, and so on). The auditors will ask probing questions about your training data, risk management process, and validation methodology. Documentation that satisfies a checklist but does not reflect actual engineering practice will not pass scrutiny.

The following sections map the major examination areas in the sequence auditors typically work through them.

Examination Area 1: Technical Documentation (Article 11 + Annex IV)

Article 11 requires providers to draw up technical documentation before placing a high-risk AI system on the market and keep it up to date throughout the system's lifecycle. The required content is defined in Annex IV.

Annex IV technical documentation must cover:

1.1 General Description of the AI System

• The intended purpose: what the system does, who deploys it, in what context
• The level of accuracy, robustness, and cybersecurity performance, as specified under Article 15
• Hardware and software specifications and the environment in which the system operates

1.2 Development Process Documentation

• The methods and steps used to develop the system, including data collection, preprocessing, labelling, validation, and testing approaches
• The design specifications, including the general logic of the system and the key design choices
• A description of the architecture, including which components are AI components and which are conventional software

1.3 Training Methodology

• The datasets used for training, validation, and testing, including their provenance, characteristics, and governance under Article 10
• How the training process was designed and controlled
• Evidence of the data quality measures implemented (representativeness, completeness, bias controls)

1.4 Testing and Validation

• The metrics used to measure performance and the results achieved
• Known limitations of the system's performance
• How the system behaves under foreseeable misuse conditions and in edge cases
• Validation against the intended deployment context

1.5 Monitoring and Logging

• The logging design and how it supports the record-keeping obligations under Article 12
• How the logs support post-market monitoring under Article 72
• Data retention, access controls, and log integrity mechanisms

What NB auditors look for at this stage: completeness (is every Annex IV item addressed?), internal consistency (do the stated metrics match the test reports?), and specificity (is the documentation describing your actual system or could it describe any AI system?). Generic boilerplate that does not reflect the specific architecture and dataset will be flagged.

Examination Area 2: Quality Management System (Article 17)

Article 17 requires providers of high-risk AI systems to implement and maintain a quality management system. The QMS is one of the most substantial areas of NB examination under Annex VII.

The Article 17 QMS must address:

2.1 Strategic and Governance Elements

• The quality policy: documented senior-level commitment to compliance
• A documented compliance strategy that addresses the EU AI Act obligations as a whole
• Clear assignment of responsibilities for QMS functions

2.2 Techniques and Processes for High-Risk AI Development

• Documented procedures for design and development, including version control, change management (relevant to Article 45 modification tracking), and release control
• Documented procedures for risk management (see below)
• Documented procedures for testing and validation at each development stage

2.3 Examination, Testing, and Validation Procedures

• Pre-deployment testing protocols
• Regression testing when the model is updated
• Validation procedures for the intended use environment
• How deviations and defects are identified, tracked, and resolved

2.4 Standards and Technical Specifications

• Documentation of which harmonised standards the provider has applied
• If standards are not fully applied, documentation of the alternative solutions used
• Evidence that the standards applied are appropriate for the AI system's risk category

2.5 Supplier and Third-Party Management

• How third-party components (foundation models, datasets, inference infrastructure) are governed
• Contractual and technical measures to ensure third-party compliance does not undermine the provider's EU AI Act obligations
• This is directly relevant for infrastructure-as-a-service dependencies, including cloud providers

2.6 Post-Market Systems

• The post-market monitoring plan required under Article 72
• Procedures for responding to serious incidents under Article 73
• Procedures for corrective actions and information obligations under Article 20

What NB auditors look for at this stage: whether the QMS is a living management system or a documentation exercise. Auditors will cross-reference the documented procedures against the actual technical documentation and testing records to check for consistency. They will ask for evidence of QMS activity — meeting minutes, review records, change logs, incident reports — to assess whether the system functions in practice.

Examination Area 3: Risk Management System (Article 9)

Article 9 requires providers to implement a risk management system as an ongoing iterative process. It is one of the foundational obligations of the EU AI Act for high-risk AI providers, and NB auditors treat it as a central pillar of the assessment.

The Article 9 risk management system must:

• Identify and analyse known and reasonably foreseeable risks to health, safety, or fundamental rights
• Estimate and evaluate risks for intended uses and reasonably foreseeable misuse
• Evaluate risks from actual use data, drawing on post-market monitoring information
• Adopt risk mitigation measures — eliminating risks through design if possible, implementing safeguards where design elimination is not feasible, and informing users about residual risks

What auditors examine in risk management documentation:

• Is the risk analysis specific to the actual system and deployment context, or is it generic?
• Does the risk identification cover the categories of harm specifically referenced in the EU AI Act (health, safety, fundamental rights)?
• Are the risk mitigation measures traceable from the risk analysis through to the technical implementation?
• Is there a documented residual risk acceptance process and evidence of senior-level sign-off?
• How does the risk management system incorporate feedback from post-market monitoring?

The risk management documentation must be current. If the system has been modified since initial assessment, the risk management records must reflect the updated risk profile. NB auditors will check whether the risk documentation has been maintained or whether it represents a point-in-time snapshot created for the assessment.

Examination Area 4: Data Governance (Article 10)

Article 10 imposes specific data governance requirements on providers of high-risk AI systems. These requirements cover the training, validation, and test datasets and are among the most technically demanding elements of the assessment.

The Article 10 requirements that NB auditors examine include:

4.1 Data Quality Practices

• Evidence of data quality assessment: the methods used to evaluate whether datasets are fit for purpose
• Documentation of how bias was identified and addressed in the training data
• Coverage of the intended deployment population: is the dataset representative of the contexts and populations where the system will be used?

4.2 Data Provenance

• Documentation of where the training data came from, including how it was collected and processed
• Records of data labelling processes: who labelled the data, what instructions were given, what quality controls were applied
• For synthetic or augmented data: documentation of the generation process and its limitations

4.3 Data Management Processes

• Data version control: the ability to reproduce the training dataset used for a given model version
• Data storage and access controls: evidence that data governance did not expose personal data or sensitive data inappropriately during development
• Procedures for handling data quality issues discovered after deployment

4.4 Special Data Categories Where the training data included special categories of personal data (health data, biometric data, racial or ethnic origin data, political opinions, and so on), the documentation must address the legal basis for processing under GDPR and the additional safeguards applied. NB auditors are not data protection authorities, but they are required to check that the data governance documentation does not reveal obvious GDPR non-compliance.

Infrastructure relevance: Providers using cloud infrastructure for AI development and training should document where their training data is stored and processed. For providers using US-headquartered cloud providers, the Article 10 documentation must not reveal that datasets were processed in a way that creates CLOUD Act exposure — particularly where the datasets contain personal data or sensitive content that is subject to EU data protection requirements.

Examination Area 5: Human Oversight (Article 14)

Article 14 requires high-risk AI systems to be designed and developed such that they can be effectively overseen by natural persons during the period of use. This is a technical design requirement with documentary requirements, and NB auditors examine both.

The human oversight provisions require providers to:

• Enable persons responsible for oversight to understand the system's capabilities and limitations
• Enable oversight persons to detect and address anomalous functioning, unexpected performance, and situations where the system should not be used
• Enable oversight persons to interpret the system's output and override or halt the system
• Design the system so that oversight can be exercised using an interface or other tool provided to or identified by the deployer

What NB auditors check for human oversight:

• Is the oversight mechanism documented in the technical documentation?
• Is there evidence that the oversight design was tested — not just described?
• For automated systems, what are the intervention points where a human can review or override a decision?
• For systems used in high-stakes contexts (medical triage, credit scoring, law enforcement), is the oversight mechanism adequate for the risk level?
• Does the transparency documentation provided to deployers under Article 13 adequately inform them about the oversight requirements?

Auditors treat human oversight as a substantive design element, not a documentation requirement. A system that has no technically meaningful human intervention points, or where oversight is theoretically available but practically unusable, will not satisfy Article 14. The documentation must describe the actual oversight design and demonstrate that it functions as intended.

Examination Area 6: Accuracy, Robustness, and Cybersecurity (Article 15)

Article 15 requires high-risk AI systems to achieve appropriate levels of accuracy, robustness, and cybersecurity throughout their lifecycle. NB auditors examine the documentation and evidence supporting the stated performance levels.

6.1 Accuracy

• The accuracy metrics and their definitions: what does 'accuracy' mean for this specific system and use case?
• The test results achieved: what levels of accuracy were demonstrated during validation?
• Benchmarking: how do the achieved accuracy levels compare to relevant baseline rates and to the performance of alternative approaches?
• Performance across subgroups: is accuracy consistent across demographic groups and deployment contexts?

6.2 Robustness

• How the system performs under degraded input conditions (poor data quality, incomplete inputs, edge cases)
• Resilience against adversarial inputs, where relevant to the use case
• Testing under distribution shift: how does performance degrade when the deployment context differs from the training distribution?

6.3 Cybersecurity

• The cybersecurity threat model for the AI system specifically (not just the hosting infrastructure)
• Documented measures addressing adversarial machine learning threats: data poisoning, model inversion, evasion attacks
• Evidence that cybersecurity testing was performed and that identified vulnerabilities were addressed
• Integration of the AI system's cybersecurity design with the provider's broader cybersecurity programme

Examination Area 7: Transparency and Deployer Information (Article 13)

Article 13 requires providers to design high-risk AI systems to ensure that their operation is sufficiently transparent to enable deployers to interpret the system's output and use it appropriately. NB auditors examine the transparency design and the deployer documentation.

What auditors check for Article 13:

• The deployer instructions document: does it cover the intended purpose, performance limitations, input data specifications, human oversight requirements, and maintenance obligations?
• The transparency design of the system itself: does it provide outputs that deployers can meaningfully interpret?
• For systems that produce recommendations or scores, is the basis for those outputs accessible to oversight persons in a form they can understand?
• Are the known limitations clearly documented so that deployers can identify contexts where the system should not be used?

Examination Area 8: Logging and Record-Keeping (Articles 12 and 19)

Article 12 requires high-risk AI systems to have the capability to automatically record events (logging) relevant to identifying risks to health, safety, or fundamental rights throughout the system's lifecycle. Article 19 addresses documentation keeping by providers.

What auditors examine:

• The logging architecture: what events are captured, at what granularity, and for how long?
• Whether the logging design supports the post-market monitoring obligations under Article 72
• Whether the logs are protected against tampering and accessible to authorised parties (including market surveillance authorities under Article 74)
• Whether the logging design is consistent with the risk management documentation: are the events that the risk management system identified as significant actually being logged?

The Audit Process: What to Expect

Understanding what NB auditors check is only useful if you understand how they structure the assessment process. A typical Annex VII assessment for a high-risk AI system proceeds as follows:

Stage 1: Documentary Review The provider submits the complete technical documentation package to the NB before the assessment begins. The NB conducts an initial review to assess whether the documentation is complete and whether there are obvious gaps that must be addressed before the on-site assessment.

Stage 2: Pre-Assessment Meeting The NB will typically schedule a preparation call to clarify the scope of the assessment, identify the key personnel who will participate, and flag any documentation gaps identified in Stage 1.

Stage 3: On-Site Assessment (or Remote Assessment) The assessment itself involves interviews with technical personnel, review of evidence, and demonstration of the system. Auditors will verify that the documentation matches the actual system and will probe areas where they identified inconsistencies or gaps in Stage 1.

Stage 4: Findings and Corrective Actions If the assessment identifies non-conformities, the NB issues findings. Minor non-conformities (documented gaps that do not affect the fundamental safety assessment) can be resolved through corrective action documentation. Major non-conformities require resolution before the certificate can be issued.

Stage 5: Certificate Issuance If the assessment is successful, the NB issues an Article 44 certificate. The certificate specifies the scope of the assessment, the assessed version of the system, the validity period, and any conditions attached to the certificate.

Stage 6: Periodic Surveillance Article 44 certificates are not a one-time pass. The NB will conduct periodic surveillance assessments to verify that the certified system continues to meet the EU AI Act requirements and that the QMS remains effective. Modifications to the system that constitute a substantial modification under Article 45 require reassessment.

Preparing for a Notified Body Assessment: Developer Checklist

Use this checklist to audit your current readiness before engaging a notified body:

Technical Documentation (Article 11 + Annex IV)

• General description of the AI system: intended purpose, hardware/software specs, deployment environment
• Development process documentation: training methodology, architecture choices, design rationale
• Dataset documentation: provenance, characteristics, governance measures, bias analysis
• Performance documentation: accuracy metrics, test results, known limitations, edge case testing
• Logging documentation: log design, retention policy, access controls, post-market monitoring integration

Quality Management System (Article 17)

• Quality policy and governance structure
• Documented procedures for development, change management, and version control
• Testing and validation procedures with evidence of implementation
• Third-party management procedures: how supplier and infrastructure dependencies are governed
• Post-market monitoring and incident response procedures

Risk Management System (Article 9)

• Risk identification: specific to the actual system and deployment context
• Risk estimation and evaluation: covering intended use and foreseeable misuse
• Risk mitigation measures: traceable from risk analysis to technical implementation
• Residual risk acceptance: documented and signed off at appropriate level
• Risk management integration with post-market monitoring

Data Governance (Article 10)

• Data quality assessment documentation
• Data provenance records including labelling process documentation
• Data version control: ability to reproduce the training dataset
• Handling of special categories of personal data (if applicable)

Human Oversight (Article 14)

• Oversight mechanism documented and tested
• Intervention points identified and accessible to oversight persons
• Deployer information covers oversight requirements

Performance and Cybersecurity (Article 15)

• Accuracy metrics defined and test results documented
• Robustness testing completed and documented
• AI-specific cybersecurity threat model prepared and testing completed

Transparency (Article 13)

• Deployer instructions document: covers intended purpose, limitations, oversight requirements
• Output transparency design: interpretable by oversight persons

Logging and Records (Articles 12 and 19)

• Logging architecture in place and tested
• Log protection against tampering
• Log accessibility for market surveillance authorities

Infrastructure Implications

The notified body examination covers not just the AI model but the operational infrastructure in which it runs. Several of the Article 9, 10, 12, and 15 requirements have direct infrastructure dependencies.

Log integrity and accessibility (Article 12): Logs that are stored on US-headquartered cloud infrastructure are potentially subject to CLOUD Act requests. For high-risk AI systems whose logs contain records of decisions affecting individuals, log storage jurisdiction matters for both Article 12 compliance and for the broader Article 74 market surveillance regime. Market surveillance authorities need to be able to access these logs; providers cannot guarantee unfettered authority access if logs are held by a provider subject to foreign jurisdiction orders.

Data governance (Article 10): Training data stored on infrastructure subject to CLOUD Act exposure may create conflicts with GDPR obligations where personal data is involved. NB auditors are not data protection authorities, but documentation that reveals obvious data sovereignty gaps may be flagged.

Post-market monitoring (Article 72): The post-market monitoring plan must specify where monitoring data is collected and stored. Providers operating sovereign infrastructure can offer unambiguous data access to market surveillance authorities — an increasingly relevant factor as the NCA enforcement regime under Article 74 begins to operate.

Timeline Context

The EU AI Act August 2, 2026 deadline applies to high-risk AI systems placed on the market after that date. For systems already on the market before August 2, 2026 that undergo a substantial modification under Article 45, the full conformity assessment requirement applies to the modified version.

For providers subject to the notified body route, the practical timeline is tight:

• Notified bodies designated under the EU AI Act are operational as of June 11, 2026 (the CRA notified bodies deadline which also triggers EU AI Act NB notifications in several member states)
• Assessment timelines for a complete Annex VII assessment typically run 3-6 months from submission of the full documentation package
• The documentation package itself — for a system of any complexity — requires 2-4 months to prepare properly

Providers who do not have a designated NB contracted and documentation preparation underway by end of June 2026 face a realistic risk of missing the August 2 deadline.

This is the third post in our five-part series on EU AI Act notified bodies. The next post covers how to prepare your technical documentation and QMS to be NB-ready — the pre-assessment documentation sprint that determines whether your assessment proceeds efficiently or returns a list of major non-conformities.