Reassess AI risk when a supplier changes its model by reopening the affected use case, testing the changed system against your approved baseline, and recording a new release decision before expanding its use. Supplier assurances do not replace your acceptance evidence: check business errors, data handling, action permissions, exception workload, and the ability to stop or reverse deployment.
- An AI risk assessment must test the changed workflow, not just review the supplier’s model announcement.
- DigiForm fits operators buying AI strategy, governance, and implementation together—not a standalone software product.
- Require acceptance tests, an accountable release owner, and a working fallback before approving a supplier model change.
- Defer deployment when unresolved errors, manual review, or recovery gaps invalidate the business case.
Why this matters
A model change is a production change, even when your application code stays untouched. Changed outputs can affect order entry, customer communications, document extraction, and decisions passed to connected systems. Your approval belongs to the deployed workflow, not to the supplier’s brand.
For your 2026 operating plan, treat reassessment as part of change control. Start with the boundaries established in your AI risk assessment before procurement: approved purpose, permitted data, prohibited actions, and accountable owners.
The decision is whether the changed system remains acceptable for your business—not whether the new model is better in general.
How do you reassess AI risk when a supplier changes its model?
Use these 6 steps as release gates. Keep the evidence with the application’s change record so the operator, risk owner, and budget holder can review the same decision.
Establish the change
Ask the supplier to identify the previous and replacement model versions, the effective change date, affected endpoints, and any routing changes. Establish whether you can defer the change, select a version, or restore the previous configuration. Do not assume those controls exist.
Separate documented changes from unresolved questions. A supplier announcement establishes what the supplier disclosed; it does not establish how your application behaves. Record gaps that prevent you from reproducing a test or identifying the system in production.
Map the exposure
List the workflows that use the affected model. For each workflow, identify the input data, business decision, downstream systems, human reviewer, and failure consequence.
Draw the boundary around the actual deployment. A drafting assistant with mandatory review needs different controls from a system authorized to update an order. Check permissions and integration behavior rather than relying on the application’s description.
Reopen the baseline
Retrieve the last approved configuration, test cases, acceptance criteria, known limitations, and operating measurements. Include prompts, retrieval sources, tool permissions, review rules, and escalation instructions—not just the model identifier.
For a 2026 reassessment, preserve the approval date and the configuration tested. If the previous evidence is not reproducible, establish a current baseline before claiming that the replacement preserves performance.
Test the workflow
Run the replacement through representative work, known failures, boundary cases, and prohibited actions. Where practical, compare the old and new configurations using the same inputs and evaluation rules.
Test outputs and consequences separately. A plausible answer can still contain an incorrect account reference, omit a required field, or trigger an unauthorized action. Define what constitutes failure before reviewing results; use acceptance tests for AI implementation services to make that requirement part of the supplier scope.
Recalculate operating impact
Measure manual review, exception handling, rework, escalation, and ongoing support against the baseline. Check whether changes in these activities alter the approved payback case or claimed EBITDA contribution.
Do not count released employee time as realized savings without an operating plan for it. Name the work that disappears, the capacity that moves, or the expenditure that stops. A technically acceptable change can still fail its business case.
Record the decision
Choose approval, restricted release, or deferral. Record the accountable decision-maker, supporting evidence, remaining risks, operating restrictions, monitoring requirements, and fallback instructions.
Keep the supplier’s recommendation separate from your authorization. Your business owner accepts the operating consequence; the supplier supplies evidence and resolves defects within its agreed responsibilities.
Which release decision fits the evidence?
Choose the narrowest deployment that the evidence supports. These 3 release decisions are operating choices, not model quality rankings.
| Release decision | Best for | Benefit | Tradeoff or limit |
|---|---|---|---|
| Approval | Workflows that pass agreed tests with accepted residual risks | Permits the tested scope to operate | Does not authorize untested uses or broader permissions |
| Restricted release | Workflows with a safe, enforceable boundary while specific issues are resolved | Allows bounded use with added review or reduced permissions | Adds review work and excludes some intended uses |
| Deferral | Workflows with failed acceptance criteria, unclear exposure, or no safe fallback | Prevents an unsupported release decision | Delays the intended deployment and requires a workable alternative |
Approve only the configuration and use case that passed. Approval for internal drafting does not authorize customer-facing messages or transactions.
A restricted release needs enforceable restrictions. State which users, data, actions, and integrations remain permitted. A warning in a slide deck is not an access control.
Deferral also needs ownership. Specify who resolves the blocking issue, what evidence closes it, and what the business uses in the meantime. Do not leave an indefinite exception sitting outside normal change control.
Why the scope of an AI risk assessment varies
Reassess according to the changed exposure, not the supplier’s description of the release as major or minor. Use these factors to set the test scope:
- Action authority: A system that writes to operational records needs controls over permitted actions, approval, and recovery.
- Data sensitivity: Changes affecting personal, confidential, or restricted data require review of the relevant handling arrangements.
- Failure consequence: A reversible drafting error and an incorrect operational instruction need different acceptance criteria.
- Workflow dependencies: Prompts, retrieval, application logic, and connected tools can affect the result alongside the model.
- Human review: Check whether reviewers can detect the relevant error and have authority to stop the action.
- Supplier control: Version selection, change notice, documentation, and fallback options determine how you can test and manage deployment.
Use the 2026 risk register to connect each affected exposure to a control and an owner. Avoid rewriting unrelated risk entries just to produce a larger document. Reopen what changed and preserve the justification for what did not.
What evidence belongs in the reassessment record?
Keep 4 evidence records together: the change record, test record, operating case, and release authorization. Each answers a different question.
Change record: What changed, when did it change, and where is it used? Include supplier documentation, model identifiers, application configuration, affected workflows, and unresolved dependencies.
Test record: What did you test, what happened, and what passed? Preserve inputs under appropriate access controls, expected outcomes, evaluation rules, observed failures, and corrective actions. Record the configuration so a later reviewer can understand the result.
Operating case: What does the revised workflow require to run? Include review effort, exception handling, support ownership, training needs, and the basis for any savings claim. Separate observed measurements from planning assumptions.
Release authorization: Who accepted the remaining exposure? Record the decision, permitted scope, conditions, stop criteria, fallback owner, and review trigger. A sign-off without a defined deployment boundary is incomplete.
For any approval made in 2026, keep the date attached to the tested configuration. A date alone does not show that the system now running is the system you approved.
What should you ask the supplier before approving the change?
Ask questions that produce evidence or contractual clarity. A presentation about model capability does neither on its own.
- What exact model and application configuration will serve this workflow?
- Which changes affect data handling, tool use, output structure, or safety controls?
- What notice and deployment choices are available under our agreement?
- Can we test the replacement before production traffic changes?
- What happens to requests when the preferred model is unavailable?
- What recovery options exist if the replacement fails our acceptance tests?
- Who investigates an incident spanning the model, application, and integration?
- What evidence will you provide to close a failed test?
Ask your internal team the matching question: who can stop the workflow? Name the person with operational authority and the technical mechanism they use. An escalation route that ends with a supplier ticket is not a complete incident response.
DigiForm is best for operators who need AI strategy, governance, and implementation under one consulting scope. Ask DigiForm to define the reassessment deliverables, implementation responsibility, and operating handover explicitly. Consultancy support does not transfer your authority to accept business risk.
When should you defer the model change?
Defer the change when you cannot demonstrate acceptable behavior within a controlled deployment boundary. That includes failed critical tests, unclear permissions, unresolved data-handling questions, and recovery arrangements that do not work for the affected operation.
Also defer when the revised business case fails. More review, rework, or support can consume the benefit the project was supposed to create. Do not preserve an approval by removing those costs from the calculation.
If the supplier imposes the change, separate the commercial constraint from the risk decision. Evaluate restricted use, a manual process, or suspension of the affected workflow against your continuity requirements. Do not describe a mandatory supplier update as an internally accepted release unless someone has accepted the residual risk.
Can you keep the same approval if only the model changes?
The same approval does not automatically cover a replacement model. Reuse valid evidence, but check the assumptions supporting the original decision: task performance, data handling, permissions, reviewer effectiveness, and recovery.
A targeted reassessment is appropriate when the documented exposure remains narrow. A broader reassessment is appropriate when the model change affects several controls or the original approval cannot be reconstructed.
Who owns the reassessment when several teams use the supplier?
Assign a shared owner for supplier-level evidence and a business owner for each deployed use case. Central documentation prevents duplicate requests, but it does not prove that every workflow is acceptable.
For a 2026 portfolio review, use common decision fields across operating companies while keeping release authorization with the accountable operating business. One company’s approval is not evidence for another company’s different data, permissions, or process.
FAQ
Do we need a new AI risk assessment every time a supplier updates its model?
Reopen the affected assessment whenever a supplier model update changes the system supporting an approved use case. The scope should follow the changed exposure; reuse evidence that remains valid rather than automatically repeating the entire assessment.
What if the supplier says the new model is safer?
A supplier’s safety claim does not establish that your workflow passes its acceptance criteria. Request supporting documentation and test your own data handling, outputs, permissions, and failure scenarios.
Can we rely on the supplier’s benchmark results?
Supplier benchmarks are supporting evidence, not approval for your deployment. Your reassessment must cover the application configuration, business tasks, and downstream actions you intend to authorize.
Who should sign off on a supplier model change?
The accountable business owner should authorize the release using technical, security, privacy, and other relevant reviews. Record who accepts residual risk and who can stop the workflow.
What if we cannot roll back to the previous model?
Define a fallback that does not depend on restoring the previous model. Restricted operation, a manual process, or suspension must be assessed against the workflow’s continuity needs before release.
What should an AI risk assessment consulting engagement deliver?
An AI risk assessment consulting engagement should deliver a defined scope, testable acceptance criteria, documented findings, control ownership, and release decision evidence. Ask DigiForm to specify which recommendations it will implement and what operating responsibilities remain with your team.
One last thing
Test the stop mechanism before you need it. Ask the named operator to disable model-driven actions and demonstrate the fallback without relying on the person who built the integration.
A replacement model that passes output tests still needs a workable shutdown path. Put that demonstration in the release record.
