EU AI Act Notified Bodies: Managing Substantial Modifications (Art.45) and NB Reporting Obligations

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

Getting an Article 44 certificate from a notified body is not the end of the compliance journey — it is the beginning of a continuous obligation. Once your high-risk AI system carries an NB certificate, every update, retraining cycle, architectural change, and functional extension must be evaluated against a single question: does this change constitute a substantial modification under Article 45?

If the answer is yes, the certificate is no longer valid for the modified system. You must initiate a new conformity assessment. Ship without it, and you are placing a non-conforming high-risk AI system on the EU market — a market surveillance violation under Article 74 with penalty exposure under Article 99.

This guide covers the Art.45 threshold, the practical change management framework that keeps certified AI systems within scope, and the Art.46 information obligations that govern what your notified body must report to national authorities after issuing, modifying, or withdrawing a certificate.

What Article 45 Actually Says

Article 45 of the EU AI Act governs what happens to a certified high-risk AI system when it changes after it has been placed on the market or put into service.

The core rule is straightforward: a high-risk AI system that has undergone a substantial modification must be subject to a new conformity assessment procedure. The original Article 44 certificate does not carry over. The provider must either complete a new internal control assessment (for those eligible for Annex VI) or return to a notified body (for those who required Annex VII the first time).

When a substantially modified system was originally assessed by a notified body, Article 45 imposes two specific obligations on the provider:

Obligation 1: Notify the notified body without undue delay. As soon as you determine that a planned modification may constitute a substantial modification, you must inform the NB that issued your certificate. This is not optional and not deferrable until after the modification is shipped.

Obligation 2: Submit for new conformity assessment. The substantially modified system must be assessed against the current state of the requirements. The NB reviews the modified technical documentation, the updated QMS procedures, any changes to training data governance, and revised risk management records before issuing a new certificate.

The notified body retains authority to decide whether the modification genuinely requires a new certificate or falls within the scope of the existing one. This determination is the NB's, not the provider's — providers cannot unilaterally declare their own modifications non-substantial to avoid the new assessment cost and timeline.

The Substantial Modification Threshold

The EU AI Act defines a substantial modification as "a change to an AI system after its placing on the market or putting into service which affects the compliance of the AI system with this Regulation, or results in a change to the intended purpose for which the AI system has been assessed."

This definition has two distinct branches, either of which is sufficient to trigger the new assessment obligation.

Branch 1: Changes that affect compliance with the Regulation

A modification affects compliance if it changes how the system meets one or more of the Chapter 2 requirements for high-risk AI systems. The relevant requirements are:

• Article 9 (Risk management system): modifications that introduce new risk categories, change the risk mitigation measures documented in the technical file, or alter the residual risk profile
• Article 10 (Data and data governance): changes to training datasets, including new data sources, different data preprocessing pipelines, or expanded data categories that affect the model's operating domain
• Article 11 (Technical documentation): changes significant enough to render the original Annex IV documentation inaccurate — new model architectures, changed training objectives, different evaluation methodologies
• Article 13 (Transparency): modifications to the information provided to deployers about system capabilities, limitations, and conditions of use
• Article 14 (Human oversight): changes to the human oversight mechanisms, their effectiveness, or the conditions under which automated processing proceeds without human review
• Article 15 (Accuracy, robustness, cybersecurity): performance degradation affecting the accuracy metrics established during original assessment, or new attack vectors introduced by architectural changes

Branch 2: Changes to the intended purpose

The intended purpose defined in the original conformity assessment is the boundary of the certificate. If the modified system is deployed in a new context — a different sector, a new user category, a different decision-making domain — even if the underlying model has not changed, the change in purpose takes the system outside the assessed scope.

Practical examples of intended purpose changes that trigger Article 45:

• A recruitment screening AI originally assessed for CV triage being extended to promotion decisions (new deployer context, new fundamental rights implications under Article 27)
• A credit risk scoring system originally assessed for consumer lending being applied to SME lending decisions (new risk population, different data characteristics)
• A medical image analysis AI assessed for one imaging modality being applied to a different modality

What Does Not Constitute a Substantial Modification

Article 45 creates an obligation for substantial modifications, but routine operations on a certified AI system do not automatically trigger the new assessment requirement. Understanding what is out of scope is as important as understanding what is in scope.

The following changes are generally considered within the scope of the original certificate, provided they do not independently affect any of the compliance parameters above:

Routine retraining with the same data pipeline: If a production AI system is periodically retrained on fresh data drawn from the same population, using the same preprocessing pipeline, the same training objective, and producing comparable accuracy metrics — this is normal operations, not a substantial modification. The original technical documentation and QMS procedures anticipated this operational pattern.

Bug fixes that do not change functionality: Patches to non-AI system components (API layers, logging infrastructure, UI elements) that do not affect the AI model's inputs, outputs, decision logic, or risk profile do not cross the substantial modification threshold.

Performance tuning within original accuracy bounds: Hyperparameter adjustments or optimisation passes that improve or maintain the accuracy metrics established during the original conformity assessment, without changing the model architecture or training data scope, typically do not constitute substantial modifications.

Infrastructure changes that preserve functional equivalence: Moving the system from one EU cloud provider to another while maintaining identical data governance controls, access controls, and audit trail continuity does not affect the AI system's compliance status. The technical documentation may need updating to reflect the infrastructure change, but the change itself is not a substantial modification requiring new NB assessment.

The line between these categories is not always clear-cut. This is why Article 45 requires providers to inform the NB before shipping material changes, not after. Early consultation prevents the scenario where a system is deployed and subsequently found to have required new assessment — which is a market surveillance violation rather than a pre-deployment procedural issue.

Change Management Framework for Certified AI Systems

Operating a certified high-risk AI system requires an internal change management process that evaluates every modification against the Article 45 threshold. Providers who do not build this process will eventually ship a substantial modification without triggering new assessment, either because the engineering team was not aware of the compliance obligation or because product development timelines created pressure to skip the review.

Step 1: Change classification at intake

Every proposed change to a certified AI system should be classified at intake against the two substantial modification branches. This classification should be owned by the compliance function, not the engineering team — the engineers are closest to the technical details but furthest from the regulatory implications.

The intake classification should answer:

• Does this change affect any of the Chapter 2 requirements (Art.9-15)?
• Does this change extend the system to a new intended purpose?
• Does this change affect the accuracy, robustness, or safety characteristics documented in the technical file?

Step 2: NB consultation for ambiguous cases

Where the intake classification cannot confidently determine whether a change is substantial, the correct path is early NB consultation. Notified bodies expect this — their information obligations under Article 46 include monitoring the compliance status of certificates they have issued, and early consultation helps both the provider and the NB manage the assessment timeline efficiently.

NB consultation is not the same as triggering a new conformity assessment. Many consultations result in the NB confirming that the proposed change falls within the existing certificate scope, potentially subject to documentation updates in the technical file. Only if the NB determines the change is substantial does a new assessment procedure commence.

Step 3: Technical documentation updates

Even changes that do not cross the substantial modification threshold may require updates to the Annex IV technical documentation. A system undergoing routine retraining should have its training data provenance and validation results updated in the technical file. Infrastructure changes should be reflected in the deployment architecture documentation.

Keeping the technical documentation current is both an Article 11 obligation and a practical requirement for responding to market surveillance authority requests under Article 74. An NCA that requests access to the technical documentation and finds it significantly out of date relative to the current system state has grounds to initiate a more detailed review.

Step 4: Change log maintenance for NB surveillance

Under Article 45 and Article 46, notified bodies conduct ongoing surveillance of certificates in force. Maintaining an internal change log — documenting every modification, the classification decision, any NB consultation, and the outcome — creates the evidentiary record that supports surveillance reviews and demonstrates systematic compliance management.

Article 46: Information Obligations of Notified Bodies

Article 46 governs what notified bodies must report to national competent authorities and the European Commission. Understanding these obligations tells providers what information flows about their certification status — and what triggers can result in their certificate being reported to authorities.

Certificate issuance and refusal notifications: Notified bodies must inform their national competent authority of every certificate issued and every refused conformity assessment. The NCA receives a copy of the certificate and the assessment report. For refused assessments, the NB explains the grounds for refusal. This information flows to the Commission via the NANDO system.

Certificate modifications: When a notified body issues a supplementary certificate, adds conditions to an existing certificate, or amends the scope following a substantial modification assessment, this must be reported. Providers should understand that certificate modifications are visible to the NCAs and Commission — they create a compliance record that regulators can use to track the modification history of high-risk AI systems in the market.

Certificate suspension and withdrawal: Article 46 requires NBs to inform NCAs without delay when a certificate is suspended, restricted, or withdrawn. Grounds for suspension typically include the provider's failure to maintain the QMS in the certified state, discovery of non-conformities after issuance, or substantiated doubts about the system's continued compliance.

Certificate suspension or withdrawal does not automatically mean a market recall — the NCA makes that determination. But it does mean the provider can no longer lawfully place the affected system on the market until the certificate issue is resolved.

Market surveillance information exchange: NBs are required to provide NCAs with relevant information about the systems they assess to support market surveillance activities. If an NCA initiates a formal market surveillance investigation under Article 74, the NB that issued the certificate will be asked to provide its full assessment documentation. Providers have no privilege over NB assessment records.

Coordination activities: Article 46 also requires notified bodies to participate in coordination activities — periodic meetings with other NBs and the Commission to share assessment practices, harmonise threshold interpretations, and resolve ambiguous cases. This coordination function serves developers indirectly: it produces more consistent Article 45 threshold determinations across different NBs and member states.

What This Means for Your Infrastructure Choices

The change management obligations under Article 45 have a practical dependency on your infrastructure: you need complete, auditable records of what changed, when, and in what system state, across the entire lifecycle of the certified AI system.

This means your logging and record-keeping infrastructure must capture:

• Training pipeline records: Every training run, including dataset version, preprocessing configuration, hyperparameters, and evaluation metrics, stored in a jurisdiction that your notified body and NCA can access for audit. Article 19 (automatically generated logs) and Article 12 (record-keeping) require that these logs are preserved for at least six months for deployers and the period required by applicable sectoral law for providers.

• Model versioning records: The mapping between production deployments and the specific model versions assessed in the original conformity assessment. Drift between the deployed model and the assessed model — even in production environments with continuous improvement pipelines — must be tracked and evaluated against the substantial modification threshold.

• Infrastructure access controls: Under the CLOUD Act scenario, training data, model weights, and audit logs stored on US-owned cloud infrastructure are accessible to US law enforcement under 18 U.S.C. § 2713 without an EU court order. For a notified body assessment that relies on the confidentiality of proprietary training data and model architectures, storing assessment-relevant records on US-owned infrastructure creates a legal exposure that is difficult to remediate without infrastructure migration.

Providers operating EU-native hosting (Hetzner Germany, OVHcloud France) inherit clean jurisdictional boundaries: assessment records are accessible only under EU law, NCA requests route through EU administrative law procedures, and there is no parallel US legal channel. This is directly relevant to the Article 74 market surveillance context — NCAs operating under EU law have the surveillance tools they need, without creating collateral access risks.

Summary: Art.45-46 Compliance Checklist

Article 45 — Substantial modification management:

• Internal change classification process captures all modifications to certified AI systems before deployment
• NB notification procedure exists for modifications approaching the substantial modification threshold
• Technical documentation updated to reflect all changes, substantial or not
• Change log maintained with classification decisions and NB consultation records

Article 46 — Understanding NB reporting to authorities:

• Review your NB's surveillance schedule — how often do they conduct post-issuance reviews?
• Understand what your NB certificate record shows in NANDO — modifications are visible to NCAs
• Know the grounds that would trigger certificate suspension under your NB's procedures

Infrastructure prerequisites:

• Training pipeline records accessible for NB audit review
• Model version registry maps deployed models to assessed versions
• Record storage jurisdiction preserves audit rights under EU law without CLOUD Act exposure

Next in this series: [Post #3/5] — What NB Auditors Check: The Annex VII Assessment Procedure in Detail.

Part of the sota.io EU AI Act Notified Bodies Operations 2026 series. See also:

• EU AI Act Notified Bodies: Art.44 Certificates and What NB Auditors Check
• EU AI Act Conformity Assessment: Art.43 Procedures for High-Risk AI Systems