Name the provider and the purpose of each model, say what data it sees, and describe the process you follow when the model or its version changes. Naming a model version in a questionnaire goes stale quickly, so pair it with a change rule and a review date.
Why a static list is risky
A questionnaire answer is a snapshot. A provider may retire a version, a feature flag may switch a model, or an engineer may try a new one in a branch. If your answer lists a name and your system now uses another, the answer is wrong, even though nobody lied.
The fix is to answer in two layers: the current list, and the rule that governs changes.
The list layer
| Column | Example content |
|---|---|
| Feature or tool | Support drafting, code assistant |
| Provider | Name of the company hosting the model |
| Model family or role | General language model, embedding model |
| Data in | Data classes, not raw examples |
| Retention and training terms | As read on a stated date |
| Owner | A named person |
Use the model family or role if versions change often, and keep exact versions in an internal record you can show on request.
The change layer
State what happens on a change:
- Trigger. A new model, version or provider.
- Review. Check data terms, retention, region and behaviour on your test cases.
- Approval. A named role signs off before customer data reaches it.
- Record. The register and the questionnaire answer bank are updated.
- Notice. If your contracts require customer notice for subprocessor changes, you give it.
This is the same discipline you apply to a new dependency, so it fits existing change control. See what to watch during a trial when models change.
Testing behaviour, not just terms
Provider terms are half of the review. The other half is how the model behaves with your prompts and tools. A small regression set of prompts, including ones that attempt to trigger unwanted tool calls, gives you before and after evidence. Keep the results.
Sample wording
"Our features use hosted language models from named providers, listed in our subprocessor page by role. Exact versions are tracked in an internal register. A change of model or provider goes through review of data terms and behaviour tests, and needs approval from the security lead before customer data is sent. We update this answer when the register changes."
Be careful with benchmark claims
Do not cite model rankings or accuracy numbers unless you can show the source and date. A questionnaire is a place for control facts, not marketing.
Evidence
The model register extract, a change review record and a test summary. Safeguard has a model family page and tooling for compliance and evidence automation, which helps keep these records together; see safeguard.sh for the current model list.
Quick check
Should we list every experimental model?
List what touches customer data or production. Mention that experiments use test data only, if that is your rule, and make sure it is true.
What if the provider swaps versions without notice?
Ask the provider about their change policy, record the answer, and pin versions where the service allows it. Otherwise state the dependency.
Last reviewed: 19 October 2026.
