AI System Change Management: When to Reassess Risk and Classification

Why AI systems change

AI systems may evolve through new versions, models, retraining, configurations, data sources, integrations, users, markets, suppliers or functionality. External vendors may introduce some changes directly.

Governance therefore continues after deployment and must control system evolution.

What AI change management means

Change management provides a process to detect changes, assess impact, decide what to review, approve the change, document it and monitor the outcome.

It keeps the original assessment aligned with the system that exists today. A product may retain the same name while changing substantially.

Which changes should trigger a review

Pay particular attention to intended purpose, affected population, context of use, model, data, autonomy, supplier, integration, human oversight, architecture, performance and controls.

Incidents, deviations and regulatory change can also trigger a review. This does not mean repeating everything; it means asking what has genuinely changed.

Model and version changes

A new version may contain minor improvements or may alter behaviour, accuracy, bias, robustness, explainability, limits or functionality.

Record the previous and new versions, date, supplier, declared changes and testing. Ask not merely whether it is a new version, but whether it changes risk or compliance.

Data changes

New sources, datasets, categories, populations, quality issues, representativeness and data drift may change system behaviour even when the model remains the same.

This may require a reassessment of risk, bias, performance, impact and controls through AI risk management.

Changes in intended purpose and context of use

A tool used for internal assistance or drafting may later support selection, assessment, prioritisation or recommendations affecting people.

Changes in intended purpose may change risk, classification and obligations. Intended purpose should therefore be recorded clearly.

Supplier and component changes

The application may remain the same while the base model, API, cloud supplier, external service or monitoring tool changes.

Review data, security, performance, documentation, contracts, traceability and responsibility through AI vendor management.

Changes in autonomy and human oversight

Autonomy may increase gradually: people first review every output, then only exceptions, and eventually the system executes some decisions automatically.

Operational risk changes even if the technical system appears unchanged. Reassess authority, escalation, controls, evidence and oversight.

How to assess a change step by step

Step 1. Record and compare

Document what changes, when, and how it differs from the previous state.

Step 2. Assess impact

Review purpose, affected persons, data, autonomy, performance, supplier and risk.

Step 3. Reassess risk and classification

Identify new risks or severity changes and confirm whether classification remains valid.

Step 4. Update controls and documentation

Adapt measures and preserve traceability.

Step 5. Approve and monitor

Assign change approval and monitor post-implementation behaviour.

The process should be proportionate.

When to reassess risk

Reassess when a risk appears, likelihood or impact changes, users, autonomy or data change, an incident occurs, the supplier changes, the context changes or controls stop working effectively.

A change may leave regulatory classification untouched while significantly altering risk. Classification and risk management are not the same.

When to review AI Act classification

Review classification where a change may alter the original criteria, particularly intended purpose, context, affected population, system function, integration or organisational role.

Article 6 governs high-risk AI systems. The Commission’s 2026 draft classification guidelines provide non-binding interpretative guidance and examples; they do not replace the Regulation.

Do not assume that an earlier classification remains valid after a significant change.

What constitutes a substantial modification

Under the AI Act, a substantial modification is a post-market or post-service change that was not foreseen or planned in the initial conformity assessment and either affects compliance with high-risk requirements or changes the intended purpose for which the system was assessed.

Not every update is substantial. For high-risk systems that continue to learn, changes predetermined by the provider and assessed in the initial conformity assessment may not constitute substantial modification.

Changes capable of affecting conformity or intended purpose require a much deeper analysis.

New conformity assessment

Article 43 requires a new conformity assessment when an already assessed high-risk system undergoes a substantial modification, whether it is redistributed or continues to be used by the current deployer.

Change management can therefore lead to a new conformity assessment, but only when the change reaches that threshold.

What documentation and evidence should be updated

Relevant evidence may include the change description, date, version, accountable person, rationale, impact analysis, before-and-after risk, reviewed classification, changed controls, testing, approval and monitoring.

Update the AI inventory, practical register, risk and impact assessments, technical documentation, instructions, contracts and oversight evidence as appropriate.

The record should explain what changed, why, what was reviewed and which decision was taken.

How to integrate change management into AI governance

Connect change management with inventory, risk, classification, suppliers, evidence, human oversight, monitoring and audit.

It should form part of the AI system lifecycle and AI governance framework, rather than operate as an isolated procedure.

Common mistakes

Reviewing only model changes

Data, purpose and suppliers also change.

Treating every update as substantial modification

The two are not equivalent.

Leaving classification untouched

The context may have changed.

Failing to record versions

This weakens traceability.

Relying only on supplier information

The organisation must assess its own use.

Failing to reassess human oversight

Greater autonomy may significantly change risk.

Failing to update evidence

The decision becomes difficult to explain later.

Risk does not end when the system enters production

An AI system may begin as suitable for one context and cease to be suitable after a series of changes.

Change management connects:

change → impact → risk → classification → controls → evidence.

The aim is not to stop every update. It is to know when an update changes something important.

When the process works, the organisation governs the AI it actually uses today, not only the system it approved in the past.

References

• Regulation (EU) 2024/1689 — Artificial Intelligence Act.
• Article 3(23) — Substantial modification.
• Article 6 — Classification rules for high-risk AI systems.
• Article 43 — Conformity assessment.
• Annex IV — Technical documentation.
• European Commission — Draft Guidelines on the classification of high-risk AI systems.
• ISO/IEC 42001:2023 — Artificial intelligence management system.
• ISO/IEC 23894:2023 — Guidance on AI-related risk management.