Your AI Compliance Evidence Expires, and Your Vendor Decides When

Every AI test result you file away is a photograph of a system that will not hold still.

The evidence looks permanent, and it is not

When a team assesses an AI system, it produces paper. Accuracy tests. A bias check. A red team report. A model card. All of it gets a date and goes in a folder, and from that day it is treated as settled fact.

A lot of these systems do not run a model you own. They call a model someone else hosts. So you did not test the model. You tested how it behaved on the day you called it, through the infrastructure sitting in front of it.

Nothing on that folder says when the contents stop being true.

Pinning the version does not pin the behavior

The standard advice is to pin a specific model version instead of a floating name. That advice is right. It is also not enough.

Anthropic's developer documentation is unusually direct about why. It says model weights are fixed for a given model identifier, but the serving infrastructure around the model can change over time. It names the parts: the request router, the safety classifiers, the sampling logic. Infrastructure updates, it says, can occasionally produce minor differences in observable behavior even when the model identifier and the weights have not changed.

That is a vendor stating plainly that a pinned version is not a frozen system. And an older short name can be a pointer that resolves to a newer snapshot on its own.

There is measured evidence of how far behavior moves. In 2023, Lingjiao Chen, Matei Zaharia and James Zou compared versions of the same services three months apart. On one task, telling prime numbers from composite numbers, GPT-4 fell from 84 percent accuracy in March to 51 percent in June. GPT-3.5 got better at the same task. The changes were real, they ran in both directions, and no customer chose them.

Pinning does not stop the clock, it starts one

A pinned version also carries a retirement date. OpenAI publishes its policy: a deprecated model gets a shut down date, with at least six months of notice for generally available models and at least three months for specialized variants. For preview models it can be about two weeks. Anthropic states that every model identifier has its own deprecation and retirement schedule.

So pinning does not buy permanence. It trades a silent change in behavior for a compulsory migration on a calendar that belongs to your supplier. Either way, the evidence in your folder has a shelf life you do not set.

The law already describes this problem

The EU AI Act has a term for this. A substantial modification is a change made after a system reaches the market that nobody foresaw or planned in the original conformity assessment, and that affects whether the system still meets the requirements. A high-risk system that gets one needs a fresh conformity assessment.

Notice what makes a change substantial. It turns on whether anyone planned for it. The Act uses that same logic explicitly in one narrow place: for high-risk systems that keep learning after release, changes the provider predetermined and recorded in the technical documentation are not substantial modifications.

That carve-out is written for learning systems, so do not stretch it over a vendor changing a model under you. Borrow the principle instead. Documenting an expected change does not pre-approve anything, but a surprise and a planned event are different things, and often the only difference is who wrote it down first.

A monitoring duty sits beside this. Organizations deploying high-risk systems have to monitor how the system operates and tell the provider when something looks wrong. You cannot report a change you never noticed.

The deadline pressure is real but not immediate. An amending regulation in force since 27 July 2026 moved the main obligations for stand-alone high-risk systems to 2 December 2027, and to 2 August 2028 for AI built into regulated products such as medical devices. That sounds far off until you remember that a useful baseline of behavior takes months to collect.

What to test

• Build a canary set of 30 to 50 frozen prompts covering your real use cases and the failure modes you already worry about. Fix every setting you can, and never edit the set casually.
• Run it daily against production and store the raw outputs, not just a pass or a fail.
• Compare each run with the last on three things: how many answers changed at all, the refusal rate, and the average length. Refusals and length tend to move first when a router or a safety classifier changes underneath you.
• Borrow the method rather than inventing it. A 2025 paper by Alden Dima, James Foulds, Shimei Pan and Philip Feldman, "You've Changed: Detecting Modification of Black-Box Large Language Models", found that simple linguistic features of generated text plus a statistical test can tell one model from another.
• Track one number: the days between a change happening and someone noticing it. If nobody can state that number, treat it as unbounded.

What to do

• Put expiry conditions on every piece of evidence. Record the model identifier, the date, the prompt version, any retrieval index version, and the tools the system could call. If one changes, the evidence is void rather than old.
• Keep supplier retirement dates in the same calendar as your audit dates. A shut down notice is a compliance event, not just an engineering ticket.
• Write down in advance which model versions your assessment covers, and what you will do when one of them changes.
• Run the canary set daily and give it a route to a named person. A detection with no owner is not a control.
• Check what your contract promises. Availability and latency are usually covered. Whether the model behaves the same way next month usually is not.

None of this needs a big program to start. It needs someone to accept that a folder of test results is a perishable asset, and to write the expiry date on the front.

More from our platforms

These sister platforms cover the parts of this problem that sit outside governance.

• Argus (argus.threatclaw.ai) records every trace an AI application produces and scans it for prompt injection, jailbreaks and data leaks, including the attacks hidden inside retrieved documents and tool results rather than in what the user typed. Governance decides what an AI agent is allowed to do. Argus shows what it actually did.
• ThreatClaw (www.threatclaw.ai) tracks the threat side of the same systems: 22 live intelligence feeds, exploitation predicted before it is officially confirmed, threat actor profiles, and detection rules you can deploy straight away. A control is only as good as the threat it is sized against.