If your company deploys AI systems and already has them documented, this is about what comes next. Almost everything written about AI governance describes how to reach a state: classify, document, assign owners, keep records. Very little describes what happens afterwards, when something changes.
And things change constantly. What's interesting is that Article 26 is built as a chain, so a change at one end causes things at the other end to lapse — and in a process run by hand, nothing flags what was affected.
The chain, read top to bottom
Read the deployer's obligations in order and a dependency appears that the article never states outright but that its structure imposes:
The intended purpose — the one the provider sets out in the instructions for use — determines the system's classification. The classification determines whether Article 26 even applies: it only reaches deployers of high-risk systems. And it does so from a given date:
Article 26 applies from 2 December 2027 for Annex III high-risk systems and from 2 August 2028 for Annex I systems; it does not reach Annex I, Section B products.
Once it applies, Article 26(1) requires appropriate technical and organisational measures to use the system in accordance with its instructions for use; Article 26(2) requires assigning human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support; Article 26(6) requires keeping the logs the system generates automatically, to the extent they are under the deployer's control, for a period appropriate to its intended purpose of at least six months, unless provided otherwise in applicable Union or national law, in particular in Union law on the protection of personal data; and Article 26(7) requires deployers who are employers to inform workers' representatives and the affected workers before the system is put into service or used at the workplace.
Each link rests on the one before it. And from that comes the question almost no one asks: if the first one changes, what happens to the other four?
Three common changes, and their ripple effect
The intended use changes. A tool that ranked candidates by administrative criteria starts scoring them by suitability instead. The intended purpose is now different, so the classification may be different — evaluating candidates falls within Annex III, point 4(a), and where the system performs profiling the Article 6(3) derogation is not available — so Article 26 may now apply where it didn't before — and with it, the oversight designation, the records and the information to workers. And if it is the deploying company that changes the purpose, of a system that was not high-risk, in such a way that it becomes high-risk, Article 25(1)(c) considers it a provider, subject to the obligations in Article 16. A change that, in practice, is a single checkbox toggled in the product.
Who oversees the system changes. The person designated under Article 26(2) leaves or moves to a different role. The obligation doesn't leave with them. But the document that named them still gives their name, and nothing marks it as expired — and if whoever is left can't stop the system, the designation is nominal.
The system changes underneath. The provider releases a version with new features. The instructions for use are now different ones, so Article 26(1)'s requirement to use the system "in accordance with the instructions for use" is measured against a text different from the one read when it was deployed.
In all three cases, what was documented still exists, legible and dated. It has simply stopped describing reality.
Why it doesn't propagate by hand
It isn't a question of diligence. It's that the information needed to propagate the change doesn't exist anywhere.
To know what lapses when a system's purpose changes, you need to know which documents, designations and decisions depended on that purpose. That relationship — what depends on what — is exactly what a set of separate documents doesn't contain. Each one describes its own part, and none of them knows about the others.
So propagation depends on one person remembering the entire chain at the moment the change happens. And the moment the change happens is usually a five-minute operational conversation that never reaches that person.
It's the same failure mode that lets a spreadsheet inventory age without warning: nothing breaks, and that's exactly why it isn't caught. Here it's worse in one respect — there, a row was missing; here, what exists is internally coherent and outwardly false.
The question that turns this into a process
There's a simple way to build this into day-to-day operations without setting anything up, and it's to change the moment the question gets asked.
Instead of reviewing periodically, attach a question to the changes that are already being communicated:
When something changes about a system — what it's used for, who is responsible for it, what it accesses, which version is running — the question is: which of the things we wrote about it stop being true?
It doesn't need to be answered well the first time. It needs to be asked, because it's the only thing that walks the chain all the way down. And it's usually enough for the answer to be noted next to the change, not somewhere else.
What's worth having in writing, and it isn't much
Three relationships, not three documents.
What purpose each system has, dated. It's the first link; if it isn't dated, there's no way to know whether it changed.
Which decisions relied on that purpose. The oversight designation, the classification conclusion, the decision on which records to keep. Naming them is enough.
And who finds out when something changes. Not who authorises it — who gets notified. Without that person, the two points above describe a chain that nobody walks.
No article requires this particular mechanism, and it's worth saying so: for high-risk systems, the Regulation asks for appropriate technical and organisational measures to use the system in accordance with its instructions, with oversight assigned and logs kept, and recognises the deployer's freedom to organise its own resources when implementing human oversight measures (Article 26(3)); it doesn't dictate the mechanism that keeps it true. The mechanism is yours, and it's the part that decides whether everything else is still true a year from now.
Content in accordance with Articles 2, 3, 6, 25, 26 and 113 and Annex III of Regulation (EU) 2024/1689, as amended by Regulation (EU) 2026/1744 (Official Journal of the EU, 24 July 2026).
This article is for informational purposes only and does not constitute legal advice.