A substantial modification review begins with the accepted baseline

EU AI Act substantial modification analysis for a high-risk system asks whether a change affects compliance with the Regulation or changes the intended purpose, subject to the exact definition and context. Article 25 also addresses cases where another party acquires provider responsibilities through branding, substantial modification, or a purpose change that makes a system high-risk.

The decision requires a baseline. Without the accepted system version, purpose, performance, and controls, the team cannot explain what changed.

This framework connects the legal test to the system evidence required for a change decision.

Article 25 names three responsibility-changing cases

For high-risk systems, Article 25 identifies circumstances where a distributor, importer, deployer, or other third party may be considered the provider. These include applying its name or trademark, making a substantial modification while the system remains high-risk, and changing the intended purpose of a system so that it becomes high-risk.

The original provider and new provider can then have defined cooperation and information duties, subject to the Act's conditions. Read the consolidated post-Omnibus provision and relevant contractual rules.

Customization is not one legal category

Changing interface colors, connecting a new source, replacing a model, fine-tuning, changing a threshold, adding an action, or repurposing the system are technically different changes. Their legal effects differ.

A prompt edit may be minor in one system and material in another if it changes the decision behavior. A code-free configuration can redirect an internal assistant into applicant ranking. Assess effect and purpose, not effort measured in engineering hours.

Use a six-trigger change card

Record the old state, new state, evidence affected, owner, legal conclusion, tests, and release decision.

Test changed purpose before changed code

Purpose drift can happen through contracts, user instructions, onboarding, or repeated practice while the code remains identical.

An event-operations assistant may begin by preparing logistics briefs. A manager later asks it to score freelancers and allocate shifts based on behavioral history. That change may engage Annex III employment or worker-management analysis even if the same model and interface remain.

Monitor actual use and prohibit unreviewed purposes. The operator can narrow or suspend the path until authorized legal and technical review is complete.

Skybridge release history creates the factual spine

Skybridge records material changes in dated changelogs, deploys to development first, and requires deliberate production promotion. Releases can name code revisions and environment configuration. These practices help establish the before-and-after record.

The 2026 environment incident also changed the review method. A script initialized its database client before the intended development configuration loaded. The team corrected the pattern and audited 11 scripts, finding one additional latent case. A change review should examine the class of cause, not only the observed file.

These engineering practices support the factual record. They do not answer whether a change is substantial under the Act.

Put change cooperation into supplier contracts

Define who can modify the system, which changes require notice, which evidence the supplier provides, and how the parties handle renewed testing, documentation, conformity activity, customer notice, or suspension.

Ask upstream model and component providers for version, deprecation, incident, and material-change information. A downstream provider cannot reassess an invisible change.

Store the decision with the technical documentation and system inventory.

Separate planned change from emergency correction. A planned release can complete classification, evidence, testing, and approval before production. An emergency may need immediate containment first. Record the temporary measure, affected scope, authority, and expiry, then complete the full change review before treating the correction as permanent.

Define a rollback boundary for configuration as well as code. Restoring the previous application image may leave a new model route, prompt, database migration, connector permission, or source index in place. The baseline should include every component needed to reproduce the accepted behavior.

Use a change review meeting for high-consequence paths. Product explains the intended result. Engineering shows the technical delta. Operations explains the workflow effect. Security and privacy identify changed exposure. Legal decides whether role, classification, documentation, or conformity work reopens. The release owner records the outcome and any conditions.

After deployment, compare actual behavior with the approved change. A feature can pass acceptance and still produce a new use pattern once people adopt it. Early monitoring should look for purpose drift, new affected groups, and action volume outside assumptions.

Modification questions

Does every model update count as a substantial modification?

Assess the legal definition, planned change rules, intended purpose, compliance effect, and system evidence against the accepted baseline.

Can a no-code configuration change provider responsibility?

Potentially. Legal effect depends on what the change does, including whether it changes intended purpose or compliance, rather than the coding method.

Who decides whether the change is substantial?

The accountable organization should run a documented legal and technical decision, with authority involvement where required. Supplier claims can inform the analysis.