Somewhere on your approved AI tools list is a product that no longer does what it did when you approved it.
Nobody did anything wrong. The model underneath it reached its retirement date on a schedule published for software developers, in release notes nobody at your school has ever read. The supplier moved to the next model. The product kept its name, its login and its place on your list.
Approval, the way most schools write it, is a photograph. The product is a film.
What should a school do when an approved AI tool changes?
Treat a material change as a new approval decision, not as a notification to file.
That sounds heavier than it is. Most changes are not material, and you can say in advance which ones are. What makes this work feel heavy is doing it without a rule, one anxious email at a time, in the week a parent asks a question nobody has an answer to.
Here is the rule I suggest.
The Still-True Test is three questions I ask when an approved AI tool changes under a school: Would we approve this today, arriving as it now is? Which sentence in our own approval has stopped being true? And did we find out from the supplier, or from a teacher? A change that survives all three is an update. A change that fails any of them is a new tool wearing an old tool's name, and it is sitting on your approved list without a decision behind it.
I offer it as a way of thinking, not a tested instrument.
The second question only works if you wrote something down in the first place. That is the school's own half of an approval: what the tool is for, who owns it, and what would take it off the list, which I have set out elsewhere as the two signatures a school should require before approving an AI tool. If your approval was a tick in a column, there is no sentence to check against, and the Still-True Test has nothing to bite on.
The third question is the one leadership teams flinch at, and it is the most diagnostic of the three. A school that learns about a change from a teacher who noticed the marking felt different has no early warning system. It has luck.
Why an approval goes stale faster than your governance cycle
Because the companies that build these models publish retirement dates, and those dates are shorter than a school year.
Anthropic's model deprecations page commits the company to "at least 60 days' notice before model retirement for publicly released models." Its own table shows how that plays out: claude-opus-4-1 was announced for deprecation on June 5, 2026 and retired on August 5, 2026. Two months, start to finish.
OpenAI's deprecations page sets a longer floor for its main models, "at least 6 months," with "at least 3 months" for some specialized variants. Preview models are different: they can be retired "with much shorter notice, such as 2 weeks." The company's Assistants API was announced for shutdown on August 26, 2025 and switched off on August 26, 2026.
Now put those numbers beside your own calendar. Sixty days is shorter than the gap between many governing body meetings. Two weeks is shorter than a half term.
There is a second problem hiding inside the first, and it matters more than the arithmetic. Those notices go to the developers who build products on top of the models. They do not go to you. Your supplier receives sixty days; what reaches you depends entirely on what your own agreement says about being told, and almost no school approval checklist asks that question. It is the question I would now put at the top: not only what this product does with our data today, but how quickly you will tell us when it stops being the product we approved.
Which changes actually break an approval?
Three do: the model changed, the terms changed, or the job changed.
The model changed. The interface is identical and the behavior is not. This is the change schools are least equipped to spot, because there is nothing to see. If a department validated the quality of a tool's output before approving it, what they validated was a version.
The terms changed. What the supplier may do with your students' and staff's work has moved: training, retention, who else processes it. A school that secured a written promise about training data has secured it against the terms that existed on the day it asked.
The job changed. A feature arrived that widened what the product is for. A marking assistant grows a chat companion. A staff planning tool opens a student-facing mode. This is the change that quietly moves a tool from one approval bar to a much higher one, and it usually arrives announced as an improvement.
The Mistake I See Most Often
The mistake I see most often is a school that wrote down who approved a tool and never wrote down who watches it.
Across the leadership teams I work with, approval records are better than they were two years ago. They have dates. They have names. They have the supplier's written answers filed next to them. What they almost never have is a person whose job is Tuesday: the ordinary, uneventful day on which a release note appears and somebody has to decide whether it matters.
In the years I have spent writing about this, for Forbes and across the books I have written on AI in education, the thing that has changed most is not what these tools can do. It is how often they change, and how little of that change reaches the people who are accountable for it. Governance built for software that shipped once a year is being asked to hold products that ship on a Thursday.
The tell is easy to check, and you can check it this week. Ask who would find out if your most-used AI tool changed its model tomorrow. If the honest answer is a teacher, eventually, you do not have a governance gap. You have a governance vacancy.
Regulators already have a name for this
European law treats a significant change to an AI system as an event that reopens obligations, rather than as a routine update.
The EU's AI Act, in Article 25, defines a substantial modification as "a change to an AI system ... which is not foreseen or planned in the initial conformity assessment ... and as a result of which the compliance of the AI system with the requirements ... is affected or results in a modification to the intended purpose." The consequence is sharp: an organization that makes such a modification, or that changes what an AI system is for in a way that makes it high-risk, takes on the obligations of a provider rather than a user.
Education is not incidental to that Act. Annex III lists as high-risk the AI systems used "to evaluate learning outcomes," to "determine access or admission" to institutions, and for "monitoring and detecting prohibited behaviour of students during tests."
Most schools reading this are not governed by the AI Act, and its obligations are phasing in rather than live everywhere at once. Borrow the concept, not the compliance. The useful idea is that a change which alters what a system is for belongs in a different category from a bug fix, and deserves a different response.
England's Department for Education has the opposite gap. Its Generative AI: product safety standards, published on January 19, 2026, run to thirteen areas and address change in a single line, addressed to the developer: "If any new features or modifications are added to a product, developers should review the intended purpose and indicate any changes in use cases."
Read that carefully. It asks a developer to review, and to indicate. It does not say to whom, or how quickly, or what a school should do when they do. The developer's half of the transaction is written down. Yours is not.
The change clause: five lines for every approved tool
Write the re-approval rule at approval time, when nobody is under pressure, and keep it in the same place as the approval itself.
These five lines fit in five spreadsheet columns and take about ten minutes per tool:
- What we approved. The version, model or plan, not just the product name. "Teacher review required, student-facing mode off" is a record you can check against later. "Approved" is not.
- Who watches, and where. One named person, and the specific place a change would appear: the supplier's release notes, a status page, an account manager who has been asked to email that person directly.
- What counts as material here. Three or four triggers, decided now. A sensible starting set: the underlying model changes; data handling or retention changes; a student-facing feature appears; the tool begins to influence a decision about a student.
- What happens when a trigger fires. Who is told, within how many days, and who may suspend use while the question is open. Make suspension an ordinary move that one named person can make, not something that waits for a full meeting.
- The date we look anyway. Because the supplier may simply not tell you. A short check on a fixed date, whether or not anything has been announced.
The fourth line is the one most worth arguing about before you need it. A school that cannot pause a tool without convening a committee will not pause it.
When a change should not reopen the decision
Most changes should not, and a school that reopens every one will soon stop reading the notices at all.
Interface redesigns, speed improvements, a new export format, ordinary bug fixes: log them and move on. The trigger list above is deliberately short, and it should stay short. Governance that raises an alarm every fortnight trains people to ignore alarms, which leaves you worse off than having no list at all.
There is an honest limit here too, and it is worth stating plainly rather than glossing. You cannot re-test every version of every tool. A model swap is sometimes invisible and entirely harmless, and no school has the capacity to check every one. What you can do is decide in advance which uses are sensitive enough to justify a fresh look, and that set is much smaller than your approved list. For most schools it is the student-facing tools, and anything that touches a decision about a student. Everything else can be logged and left.
Scale the watching to the stakes, in other words, exactly as you scaled the approval.
What should leaders do this term?
Open your approved list and add two columns: who watches this, and what would make us look again.
Fill them in for the student-facing tools first, then for anything holding student data, then for the rest if you get to it. Where a tool has no watcher, either name one or take the tool off. An entry nobody is watching is not approved. It is remembered.
Then send your suppliers one question, the one your original checklist probably missed: how, and how quickly, will you tell us when the model behind this product changes? The answers will sort your list faster than any audit. Suppliers who can answer in a sentence have thought about schools. Suppliers who cannot have thought about developers.
The next step
If your leadership team is working out how to keep its AI decisions true rather than merely made, this is the kind of work I support through AI strategy sessions for schools. For the wider picture, what responsible AI adoption looks like in practice sets out the habits an approved list belongs to.
Sources and further reading
- Anthropic, "Model deprecations," Claude platform documentation, accessed September 17, 2026. platform.claude.com
- OpenAI, "Deprecations," OpenAI developer documentation, accessed September 17, 2026. developers.openai.com
- European Union, "Article 25: Responsibilities Along the AI Value Chain," Artificial Intelligence Act. artificialintelligenceact.eu
- European Union, "Annex III: High-Risk AI Systems Referred to in Article 6(2)," Artificial Intelligence Act. artificialintelligenceact.eu
- Department for Education, "Generative AI: product safety standards," GOV.UK, January 19, 2026. gov.uk
Dan Fitzpatrick is the founder of The AI Educator, a Forbes contributor and the author of bestselling books on AI in education. Read more about Dan.
