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 determines the system's classification. The classification determines whether Article 26 even applies. If it does, Article 26(1) requires using it in accordance with its instructions, with technical and organisational measures; Article 26(2) requires assigning oversight to specific people; Article 26(6) requires keeping the records it generates; and Article 26(7) requires informing the workers affected.
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, so Article 26 may now apply where it didn't before — and with it, the oversight designation, the records and the information to workers. 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 signed. 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.
None of this is required by any article, and it's worth saying so: the Regulation asks for the outcome — using the system in accordance with its instructions, with oversight assigned and records kept — not 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 Article 26 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.