Model versioning means recording exactly which model, at which version, with which prompt, produced each output. Change control means nothing changes in that setup without a test and an approval. Without both, you cannot explain next year why a workpaper says what it says.
Last reviewed: 17 October 2026. Facts checked. We opened Hugging Face's documentation on downloading a specific version of a model by tag, branch or full commit hash. We opened NIST's AI Risk Management Framework page. We ran a web search on model deprecation and pinned versions; the results were practitioner blogs, and they gave provider dates and a 2023 accuracy example that we did not verify on official provider pages, so we cite none. Check each vendor's own deprecation page.
Why models change
A model is not a fixed tool like a calculator. Four things can change what you get:
- The vendor updates the model behind a name or alias.
- The vendor retires an old version, so calls stop working.
- You change the prompt or the settings.
- You change the documents the model reads, for example a knowledge base.
Search results described teams whose prompts "passed QA last quarter" and later produced malformed output after a silent change. We could not verify the specific cases, but the mechanism is easy to understand. If you call a model by a general name, you may get a different model later.
Pin the version
Hosted models. Use a dated version identifier where the vendor offers one, not a general alias. Pinning does not stop the vendor retiring that version, so note the end-of-life date.
Models you host. Hugging Face's documentation shows that you can download a specific version by tag, branch, pull request or commit hash, and that the commit hash must be the full-length hash. Record that hash. Store a copy of the weights you actually tested.
Keep a model register
| Field | Example entry |
|---|---|
| Use | Extracting invoice fields |
| Model and exact version | Name plus version or commit hash |
| Licence | As stated on the developer's page |
| Where it runs | Our server, partner, vendor API |
| Prompt version | Reference to the saved prompt |
| Test date and result | Link to test record |
| Owner and approver | Named people |
| Retirement date, if known | From vendor notice |
This is the single most useful page for an auditor or a reviewer. It also supports the firm-level thinking NIST describes under its voluntary framework: knowing what you run and who is accountable.
A change-control routine
- Request. Someone proposes a change: new model, new prompt, new source documents.
- Test. Run your saved test set, described in our LLM test plan. Compare to the last result, case by case.
- Approve. A named person signs off if results meet the pass mark.
- Deploy and record. Update the register. Note the date.
- Watch. Review a sample of live outputs in the first weeks.
- Roll back. Keep the previous version available until you are sure.
Treat vendor notices as change requests too.
Record the version in the engagement file
For each AI-assisted working paper, note:
- Model and version.
- Prompt version.
- Date and time of the run.
- Reviewer.
If an engagement spans months, the model may change midway. Decide whether to freeze the version for the engagement. If you cannot freeze it, re-test at each change and note it.
This is the AI cousin of our guide on client changes books after the audit started. Different object, same discipline: know which version your evidence came from.
What to test after a change
- The saved test set. Compare scores to the prior run.
- Output format. A small change can break downstream steps.
- Behaviour on refusals and unknown answers.
- Prompt injection and data leakage checks.
Keeping it light for a small firm
You do not need software. A shared sheet for the register, a folder for test results and a rule that "nobody changes the model or the prompt without a note" gets you most of the value. Use the AI governance internal audit workpaper to document it.
Frequently Asked Questions
What is model versioning?
Recording the exact model and settings behind each output so you can reproduce and explain it.
Does pinning a version guarantee identical output?
Not necessarily. Outputs can vary, and vendors retire old versions. Pinning reduces change but does not remove the need for testing.
Who should approve a model change?
A named senior person, ideally someone who did not propose the change.
Do we need to re-test when only the prompt changes?
Yes. A prompt change can alter behaviour as much as a model change.
Related Articles
Statutory facts on this page are checked against their sources, and the page says where it relied on secondary reporting. How we verify · Report an error