EU AI Act Art.17 QMS Change Management: Classifying Modifications and the Art.45 Re-Assessment Threshold (2026)

Post #4 in the sota.io EU AI Act Art.17 Quality Management System Series

The first three posts in this series built the QMS foundation (Art.17 foundations), the documentation structure (Annex IV technical file), and the testing pipeline (T&V procedures). This post covers the part most engineering teams underestimate: what happens when the system changes after it goes live.

Art.17 requires that your quality management system include arrangements for managing changes to the high-risk AI system. This is not a soft requirement. Every modification to a certified high-risk AI system — new model weights, updated training data, revised acceptance thresholds, new deployment contexts — must be evaluated against a documented classification framework before the change is shipped. Ship first, classify later is a compliance failure that voids your conformity assessment.

The legal stakes are set by Art.45: when a modification qualifies as a "substantial modification," your existing conformity assessment is no longer valid. You must complete a new assessment before placing the modified system on the market. If your QMS does not include a documented change classification process, a notified body auditing your Art.17 compliance will flag the entire QMS as deficient — not just the change management section.

The Legal Basis: Art.17 and Art.45 Together

Art.17 establishes the QMS as the continuous compliance mechanism for high-risk AI systems. The quality management system governs the entire lifecycle — design, development, testing, deployment, and post-market operation. Change management is one of the pillars the regulation explicitly requires providers to address.

Art.45 governs the consequence side. A high-risk AI system that has undergone a substantial modification must be subject to a new conformity assessment procedure. Art.45 also imposes provider obligations when the original assessment was performed by a notified body: the provider must notify the NB without undue delay and submit the modified system for re-assessment. The NB that issued the original certificate retains authority to determine whether the modification is substantial — providers cannot self-declare a change non-substantial to avoid the re-assessment cost.

The definition that connects these two articles is Art.3(23): a substantial modification is "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 independent branches. A change that affects compliance with the Regulation's requirements (Art.9 through Art.15) qualifies. A change to the system's intended purpose also qualifies — independently of whether the underlying technical implementation changed at all. Your change classification framework must evaluate both branches for every modification.

The Three-Tier Classification Framework

A compliant Art.17 change management process needs a documented decision hierarchy. The practical implementation is a three-tier framework that every modification passes through before release. The three tiers are not equal in QMS documentation burden — they scale with compliance consequence.

Tier 1: Minor Change

A minor change does not affect any of the documented parameters of the high-risk AI system and does not alter the system's compliance with Chapter 2 requirements or its intended purpose. Minor changes include:

• Infrastructure changes that do not affect model behaviour (server upgrades, container base-image updates, logging configuration)
• UI changes to deployer-facing dashboards that do not alter the human oversight capabilities required by Art.14
• Bug fixes that restore documented performance without changing functionality
• Documentation corrections that do not reflect actual system changes
• Security patches that address implementation vulnerabilities without changing AI model behaviour

For Tier 1 changes, your QMS documentation requirement is a change log entry recording: the change description, the classification rationale, the engineer who performed the classification, and the date. No additional testing cycle beyond your standard CI/CD pipeline is required, and the Annex IV technical documentation does not need to be updated.

Tier 2: Non-Substantial Significant Change

A Tier 2 change is significant enough to require QMS review and technical documentation updates, but does not meet the threshold for substantial modification under Art.3(23). These changes affect the system's documented parameters while staying within the compliance scope of the original conformity assessment.

Tier 2 examples include:

• Model fine-tuning or parameter adjustments within the operating envelope documented in the Annex IV technical file — same architecture, same training data distribution, same task specification, improved performance on the existing evaluation benchmark
• Performance threshold updates that move within the accuracy ranges documented during conformity assessment
• New deployer features that do not change the AI-specific functionality or human oversight design
• Infrastructure changes that affect performance characteristics (latency, throughput) but remain within the operating conditions documented in the technical file
• Post-market monitoring configuration updates (new alert thresholds, extended monitoring periods) that strengthen but do not replace the Art.72 plan

For Tier 2 changes, your QMS documentation requirement is more substantial: an updated Annex IV technical documentation section covering the modified parameters, a quality review sign-off confirming the change stays within assessed scope, updated test results demonstrating continued compliance with the performance benchmarks established during original assessment, and a formal change record in the QMS linking the modification to the review evidence. Your declaration of conformity under Art.47 does not need to be reissued, but the technical documentation supporting it must be updated to reflect current system state.

Tier 3: Substantial Modification (Art.45)

A Tier 3 change is a substantial modification under Art.3(23). It triggers the full Art.45 re-assessment path. You must not ship the modified system until a new conformity assessment has been completed.

Changes that typically cross the Art.3(23) threshold include:

Compliance-affecting changes:

• Changes to the AI model architecture, training objective, or algorithmic approach that alter how the system meets Art.9 (risk management), Art.10 (data governance), Art.14 (human oversight), or Art.15 (accuracy, robustness, cybersecurity) requirements
• Significant training data changes — new data sources covering different demographic groups or geographic regions, major data preprocessing pipeline changes, or training data extension that shifts the model's operating domain
• Performance degradation that takes the system below the accuracy thresholds documented during the original conformity assessment
• Changes to the human oversight mechanism that reduce its effectiveness compared to the Art.14-compliant design in the technical file
• New cybersecurity attack vectors introduced by architectural changes that the original Art.15 assessment did not address

Intended purpose changes:

• Deploying the system in a new sector — a medical diagnostic AI originally assessed for one diagnostic category being extended to another
• Extending the system to new user categories where it makes decisions with different fundamental rights implications under Art.27
• Changing the decisional context from advisory (human reviews recommendation) to autonomous (system acts without review) where this was not the assessed scope

One Tier 3 change category that catches engineering teams off guard: inference-time scope expansion. If an AI system originally assessed for a defined input distribution is deployed against inputs outside that distribution — new languages, new data modalities, new geographic markets — the intended purpose change may qualify under Art.3(23) even if no model weights changed.

Building the Change Classification Decision Tree

The Art.17 QMS requirement is not satisfied by a policy document that describes the three tiers. It requires a documented procedure that engineers follow for every release. The procedure should be implemented as a structured assessment that generates a QMS artifact.

A practical implementation is a change assessment checklist that every release PR must complete before merging. The checklist has three decision gates:

Gate 1: Intended purpose assessment

• Does this change alter the system's intended purpose as defined in the technical file?
• Does this change extend the system to new user categories or deployment contexts not covered by the original assessment?
• Does this change alter the AI system's role from advisory to autonomous or vice versa?

If any Gate 1 answer is yes → Tier 3 (Art.45 substantial modification).

Gate 2: Compliance parameter assessment

• Does this change affect the model architecture, training data, or algorithmic approach?
• Does this change affect the human oversight mechanism or its effectiveness under Art.14?
• Does this change affect the performance characteristics covered by Art.15 accuracy requirements?
• Does this change alter the risk profile documented in the Art.9 risk management system?
• Does this change affect the operating conditions documented in Annex IV?

If Gate 1 = pass and any Gate 2 answer is yes → Tier 2 if the change remains within assessed scope, Tier 3 if it takes the system outside assessed scope. The boundary between Tier 2 and Tier 3 on Gate 2 questions is where engineering judgment is required — and where notified body authority overrides provider self-assessment.

Gate 3: Documentation scope assessment

• Does this change affect any parameter documented in Annex IV?
• Does this change require updating the technical file to accurately describe the current system?
• Does this change affect the QMS procedures themselves?

Gate 3 = all Tier 2 and Tier 3 changes. If Gate 1 = pass and Gate 2 = pass and Gate 3 = no → Tier 1.

The key design principle: when in doubt, classify higher. Misclassifying a substantial modification as Tier 2 is a market surveillance violation. The cost of an unnecessary Tier 2 review is low. The cost of shipping a non-conforming substantially modified system is a potential Art.99 penalty action and market withdrawal.

Git-Native Change Management for QMS Compliance

Your version control system is already tracking every change to your AI system. The QMS change management framework should build on this infrastructure, not duplicate it.

A practical Git-native implementation links your change assessment directly to your release workflow.

Change assessment as a PR requirement

Add the change classification checklist as a required PR template in your repository. Every PR that modifies AI model code, training pipeline code, data governance configuration, or deployment configuration must complete the checklist before the PR can be merged. The completed checklist becomes part of your change record — it is automatically linked to the commit that introduced the change, timestamped, and traceable.

Your PR template structure:

## AI Act Change Classification

### Gate 1: Intended Purpose
- [ ] Changes intended purpose: YES / NO
- [ ] Extends to new user categories: YES / NO
- [ ] Changes advisory-to-autonomous scope: YES / NO

### Gate 2: Compliance Parameters (if Gate 1 = all NO)
- [ ] Model architecture/training/algorithm change: YES / NO
- [ ] Art.14 human oversight mechanism change: YES / NO
- [ ] Art.15 performance characteristic change: YES / NO
- [ ] Art.9 risk profile change: YES / NO
- [ ] Annex IV operating conditions change: YES / NO

### Classification
**Tier**: [ ] 1-Minor / [ ] 2-Significant / [ ] 3-Substantial-Modification

### Rationale
[Required: explain the classification basis]

### QMS Artifacts Required
- [ ] Change log entry (all tiers)
- [ ] Technical documentation update (Tier 2+)
- [ ] Quality review sign-off (Tier 2+)
- [ ] Art.45 notification to notified body (Tier 3)
- [ ] New conformity assessment (Tier 3)

Tagging and traceability

When a change record is created, tag the release commit with the classification: qms/minor, qms/tier2, or qms/substantial-mod. This makes it possible to query the entire change history by classification tier with a single git log command:

git log --grep="qms/substantial-mod" --oneline --no-walk --tags

Your notified body can run this query against your repository during an audit and immediately see all substantial modification assessments in chronological order, linked to the commits that introduced the changes.

The QMS evidence store

Store the completed change assessment checklists alongside your CI/CD test results. The recommended path pattern is qms/changes/YYYY-MM-DD-<pr-number>-<classification>.md. This directory is an append-only audit evidence store — entries are never deleted or modified after the review is complete, matching the immutability requirement that makes QMS artifacts credible to an auditor.

Art.45 Notification: Timeline and Process

When a Tier 3 classification is reached, two obligations activate before the modified system can be shipped.

Obligation 1: Notify the notified body without undue delay

Notification must happen as soon as you determine the modification is substantial — not after re-assessment is complete, not after the PR is merged. The notification must describe the nature of the modification and the affected Annex IV sections. Include your change assessment checklist as an attachment.

"Without undue delay" is not defined with a specific number of days in Art.45. In practice, a 5-business-day notification window from the date the Tier 3 classification is confirmed is a defensible standard. Document the notification date and the NB's receipt confirmation in your QMS.

Obligation 2: New conformity assessment before placement on market

The Art.45 re-assessment must be completed before the modified system is placed on the EU market or put into service. For Annex VII systems (third-party conformity assessment), this means the NB must complete its review and issue a new certificate. For Annex VI systems (internal control), you complete the internal assessment process and issue a new EU declaration of conformity under Art.47.

The timeline consequence is significant. Annex VII re-assessments typically take 6-12 weeks from NB engagement to certificate issuance. If your release cycle is faster than this, you need either a pre-approved modification scope from your NB (covering planned changes that the NB has pre-assessed as non-substantial) or a parallel assessment track where NB engagement begins as soon as the Tier 3 classification is confirmed — not when development is complete.

EUDB update obligation

Art.45 re-assessment creates an Art.49 update obligation. Once the new conformity assessment is complete and the system is re-placed on the EU market, the EUDB registration must be updated to reflect the modified system. This is not optional and carries its own enforcement exposure independent of the Art.43/Art.45 assessment path.

Integration with Art.9 Risk Management

Change management and risk management are not separate QMS pillars — they are connected. Every Tier 2 and Tier 3 change must trigger a review of the Art.9 risk management records.

For Tier 2 changes, the risk management review asks: does this change alter any of the identified risks, their severity, or the effectiveness of the documented mitigation measures? If yes, the Art.9 records must be updated to reflect the revised risk profile before the change assessment is complete.

For Tier 3 changes (substantial modifications), the risk management system must be treated as a baseline that needs to be rebuilt for the modified system scope. A substantially modified system may introduce risk categories that did not exist in the original assessment — new training data distributions can introduce new bias risks, architectural changes can alter the system's failure modes, new deployment contexts can create new fundamental rights implications.

The traceability link from change record to risk management update is a required QMS artifact. Your Art.9 risk register should have a "last reviewed" timestamp and a link to the change record that triggered the review. Without this traceability, a notified body auditing your change management process cannot verify that risk management kept pace with system evolution.

What Notified Bodies Check During Change Management Audits

During an Art.43 conformity assessment — including re-assessments triggered by Art.45 — the notified body's review of your change management process covers five areas:

1. Completeness of change records: Is there a change record for every modification to AI model code, training data, and deployment configuration since the original assessment? Gaps in the change record are a QMS deficiency finding that may require corrective action before a certificate is issued or renewed.

2. Classification rationale quality: Are the classification rationales substantive? A change record that says "classified as Tier 1 because it's a minor change" fails the audit. The rationale must explain specifically why the change does not affect any compliance parameter or intended purpose component.

3. Art.45 notification history: For any Tier 3 changes identified during the review period, did the provider notify the NB before shipping? Retroactively submitted Tier 3 notifications for changes that were already placed on the market are evidence of QMS process failure and may trigger market surveillance referral.

4. Technical documentation synchronisation: Is the current Annex IV documentation consistent with the current state of the system? Every Tier 2 and Tier 3 change should have a corresponding technical documentation update. The NB will compare the documentation against the production system.

5. Risk management synchronisation: Does the Art.9 risk management record reflect the current state of the system including all post-market modifications? Risk records that were last updated at the original assessment date but the system has undergone multiple Tier 2 changes are a finding.

August 2026 Implementation Priorities

With the August 2026 deadline for full Art.17 compliance, the change management implementation should follow a four-week priority order.

Week 1: Establish the change classification procedure

Create the formal change assessment procedure document within your QMS. Define the three-tier classification criteria, the Gates 1-3 decision logic, and the documentation requirements for each tier. Have the procedure reviewed and signed by the responsible person for regulatory compliance. Date and version-control this document — it becomes a required QMS artifact.

Week 2: Implement the Git PR template

Add the change classification checklist to your repository as a required PR template. Configure branch protection rules to require checklist completion before merging to main or release branches. Test the workflow end-to-end with a representative sample of change types.

Week 3: Backfill the change record for the review period

Identify all modifications to the AI system since the original conformity assessment. For each modification, create a retrospective change record with classification, rationale, and (for Tier 2 changes) confirmation that technical documentation was updated. This backfill exercise often surfaces previously unclassified substantial modifications — changes that should have triggered Art.45 notification but did not. If you discover retrospective Tier 3 changes, your QMS must reflect how this was addressed and document the current compliance status.

Week 4: Verify notified body communication channel

If your system requires third-party conformity assessment (Annex VII), establish the formal communication channel with your NB for Art.45 notifications. Confirm the NB's preferred notification format, timeline expectations, and the contact point for urgent classification questions. This relationship should be active before you need it for a live Tier 3 notification.

Hosting Infrastructure and Change Management

One change management category that frequently surprises high-risk AI providers: infrastructure migration.

Migrating your AI system's inference infrastructure from a non-EU cloud provider to an EU-jurisdiction provider is generally a Tier 2 or Tier 1 change when the migration does not affect model behaviour. However, a migration that moves training data storage from EU-jurisdiction to non-EU-jurisdiction, or vice versa, requires a Tier 2 Art.10 data governance review — and may be Tier 3 if it affects the data provenance documentation in Annex IV.

Conversely, a migration that places training data and model weights in EU-exclusive infrastructure can strengthen your Art.9 residual risk documentation by eliminating Cloud Act exposure as a risk factor. Document this in the change record as a risk-reducing modification and update your Art.9 records accordingly.

Infrastructure jurisdiction is not an Art.45 criterion on its own — the regulation does not require EU-hosted infrastructure. But it is an Art.9 and Art.10 consideration that belongs in your change management assessment for any infrastructure migration. Providers running high-risk AI on EU-sovereign infrastructure have a simpler change management story for this category because the Cloud Act exposure risk was not present to begin with.

sota.io provides EU-sovereign PaaS infrastructure for AI teams building toward August 2026 compliance. View deployment options — infrastructure that simplifies your Art.17 change management by keeping data governance jurisdiction stable across model updates.

Conclusion

Art.17 change management is the mechanism that keeps your conformity assessment valid as your high-risk AI system evolves. Without a documented three-tier classification framework, every modification to the system is a potential compliance gap — a change that should have triggered Art.45 re-assessment but shipped without one.

The implementation framework in this guide gives you:

• A decision hierarchy (Gates 1-3) that produces consistent Tier 1/2/3 classifications
• Git-native change records that are automatically traceable and auditable
• A QMS evidence store that satisfies notified body audit requirements
• Art.45 notification and EUDB update procedures for Tier 3 changes
• An Art.9 risk management integration that keeps risk records synchronized with system evolution

The next and final post in this series covers the complete Art.17 QMS Audit Readiness Checklist — a structured verification framework you can use to confirm your QMS is ready for a notified body conformity assessment before the August 2026 deadline.

See Also:

• Art.17 QMS Foundations
• Art.17 QMS Documentation Requirements and Annex IV
• Art.17 QMS Testing, Validation and Verification Pipeline
• Art.9 Risk Management System Foundations
• Art.45 Substantial Modification and Notified Bodies