Short answer. Treat every model change as a controlled release. Ask one question first: does the change affect the system’s compliance or its intended purpose? If yes, the EU AI Act calls it a substantial modification and, under Article 43(4), a high-risk system needs a fresh conformity assessment before it goes live, while DORA treats the same change as an ICT change that needs testing, approval, and a rollback. Banks that pre-define their update envelope in the technical documentation keep routine retraining out of that rule.
A model in production is never finished. Fraud scores get retrained on new patterns, a credit model is recalibrated after a portfolio shift, a chatbot swaps its underlying language model, or a threshold moves to cut false positives. Each of these is a change, and in a regulated bank each one carries a compliance question that the pilot team rarely thought about.
The discipline that separates a shipped system from a stalled one is release control. Of the 34 production AI projects Ableneo delivered in 2025, the ones that kept running were the ones where a model change followed the same gate every time: assess the change, test it, document it, approve it, and keep the ability to roll back. Around 80% of Ableneo projects reach production, and staying compliant after go-live is part of what keeps them there.
Two regulations frame the answer for banks and insurers in Central Europe. The EU AI Act, Regulation (EU) 2024/1689, sets obligations for high-risk AI systems that apply from 2 August 2026. Credit scoring and creditworthiness assessment sit in Annex III, so a Slovak or Czech bank running an AI credit model is squarely in scope. The Act defines a substantial modification in Article 3(23) and requires, in Article 43(4), that a high-risk system undergoes a new conformity assessment when such a modification happens after it is placed on the market.
DORA, Regulation (EU) 2022/2554, has applied since 17 January 2025 and treats every AI system a bank runs as ICT. That pulls model changes into the bank’s ICT change management process: controlled deployment, testing, approval gates, and documented rollback. Banks already run a material-model-change regime for their regulatory-capital models under the ECB, and from 1 October 2026 the ECB lets banks implement material changes shortly after submitting a complete application. The lesson for AI is direct. The muscle for governing model change already exists inside the bank, and it needs to reach the AI systems too.
Treat every model change as a controlled release, and ask first whether it affects compliance or intended purpose.
A substantial modification is a change made after the system is placed on the market that was not foreseen in the initial conformity assessment, and that either affects the system’s compliance with the high-risk requirements or changes its intended purpose. The test is not how much code changed. It is whether the change touches compliance or purpose. Moving a fraud model to a new customer segment can be substantial even with no code change, because the intended purpose shifted. Fixing a logging bug usually is not, because neither compliance nor purpose moves.
No. The Act anticipates that models keep learning. Under Article 43(4) and Recital 128, changes that the provider pre-determined at the time of the initial conformity assessment, and documented in the technical documentation required by Annex IV, do not count as substantial modifications. In practice this means you define your allowed update envelope up front: the retraining cadence, the data sources, the performance bounds, and the metrics you monitor. Retraining inside that envelope is routine. A change that steps outside it, a new data source, a materially different performance profile, or a new use, is where the fresh assessment obligation bites.
DORA does not ask whether a change is substantial. It asks whether the change to an ICT asset was controlled. A model update must pass through the bank’s ICT change management process with testing before release, an approval record, and a tested rollback. The bank also keeps the model in its ICT asset inventory and continues resilience testing after the change. Where the model comes from a third party, the vendor’s update becomes a third-party change the bank still owns the risk for, which is why the contract and the update notice matter.
Run a short, repeatable gate. First, classify the change: is it inside the documented update envelope or outside it? Second, if it is outside, run the impact assessment against the high-risk requirements and decide whether a new conformity assessment is needed. Third, test the change against the same validation set used before go-live, plus fairness and performance checks. Fourth, record the approval, the version, and the reason in the audit trail. Fifth, keep the previous version ready to restore. This gate takes hours for a routine retrain and days for a genuine change, and it is the difference between a defensible system and a surprise in the next audit.
Monitoring watches for change you did not choose. Change control governs change you did choose. Drift monitoring tells you the world moved and the model needs attention. Model-change governance is what happens next, when a person decides to retrain, recalibrate, or replace and has to do it in a way that keeps the system compliant. The two work together. Monitoring is the trigger, and controlled change is the response.
Ableneo builds AI systems that stay in production, not just systems that pass a demo. Across 34 production projects in 2025 for clients in financial services and insurance across Slovakia, the Czech Republic, and Austria, the pattern that holds is boring on purpose: define the update envelope before launch, wire model change into the bank’s existing ICT change process, and keep the audit trail current. That is how a model that improves every quarter also stays compliant every quarter. See how this fits the wider governance picture in the Ableneo AI Transformation FAQ.
Key takeaways
Planning AI in a regulated business? Ableneo takes systems from classification to governed production.