The approved system rarely stays still
Procurement approval captures a point in time. After signature, an AI supplier may change its foundation model, system prompts, retrieval sources, tuning data, safeguards, hosting arrangement or subprocessors. Each change can affect performance, data exposure and the buyer's original risk decision.
Buyers do not need a stream of every engineering commit. They do need a reliable record of changes that could alter intended use, compliance, security, user impact or contractual commitments.
A supplier change log creates that record. It also gives product, procurement, security, privacy and compliance teams a common trigger for deciding when reassessment is necessary.
Record the system and model version
Each entry should identify the affected product or feature, previous and new version, release date and change owner. For externally supplied foundation models, record the provider and model family or version at the level the supplier can verify.
Where a provider uses automatic model routing, the log should explain the routing policy and material changes to the pool of available models. Otherwise the buyer may be unable to connect an incident or performance shift to the system that produced it.
Describe prompts, data and retrieval changes
Capture material changes to system instructions, fine-tuning or evaluation datasets, retrieval sources, retention rules and permitted uses of customer inputs or outputs. The description should state whether customer data handling changes as a result.
This is especially important where a seemingly small configuration change expands the service's purpose or introduces a new data source that was not part of the original privacy, security or accuracy review.
Track subprocessors and upstream dependencies
Record additions, removals and replacements of model providers, hosting providers, safety services and other material AI subprocessors. Link the entry to the relevant customer notice and objection process where one applies.
The log should make clear which responsibilities remain with the contracted supplier. An upstream dependency should not become an accountability gap when buyers ask for evidence or an incident occurs.
Show how safeguards and testing changed
For every material release, identify safeguards added, removed or adjusted, the testing performed and the outcome. Include relevant performance, robustness, bias, security, transparency and human-oversight checks based on the intended use.
Record known limitations and residual risks, not only successful test results. The buyer needs enough context to decide whether its own controls, user instructions or deployment restrictions must change.
Add impact, approval and customer action
A useful entry includes the supplier's impact assessment, approval owner, customer-notification date and recommended customer action. Classify the change by significance using agreed criteria rather than relying on an undefined label such as 'minor update'.
Possible buyer actions include no change, evidence refresh, focused testing, risk reassessment, contract review, restricted rollout or suspension. Record the decision and owner so the review trail remains complete.
Connect the log to contract and governance controls
The contract should define which changes require notice, the minimum information supplied and the buyer's remedies. The operating process should then connect those notices to the AI inventory, supplier register, risk record and approval workflow.
Review the log on a risk-based cadence and after significant notices or incidents. A dormant spreadsheet does not provide assurance; the value comes from consistently triggering the right review.
For the supporting contract structure, read our guide to seven AI contract clauses procurement teams need after signature. AI Act Ready helps buyers and suppliers maintain the change evidence behind those commitments.