Updated 17 October 2026. An AI addendum can allocate responsibilities. It cannot revoke a credential. That is the difference I want procurement conversations to keep in view.
Contracts matter. They can set service obligations, audit rights, incident notifications and remedies. Calling them useless would be as misleading as treating a signed agreement as proof that an agent behaves safely. The contract and the product need to describe the same arrangement.
Translate the clause into a control
Imagine a support agent permitted to draft responses but not issue refunds. The supplier promises that it will remain within scope. Before release, the buyer should be able to see where that boundary is enforced, what an attempted refund produces and who receives the resulting exception.
A paragraph saying “appropriate safeguards” leaves those questions open. The operational specification should name the permitted action, the identity used to request it, the enforcement point and the evidence retained. Otherwise the promise is doing a lot of unpaid engineering.
| Contract topic | Operational question | Evidence |
|---|---|---|
| Scope | Which actions are permitted? | Permission test results |
| Incident response | Who can stop further actions? | Rehearsed stop and escalation path |
| Audit access | What can the buyer inspect? | Accessible, appropriately protected records |
| Exit | Can the workflow move elsewhere? | Tested export and replacement procedure |
Ask what stopping actually means
A stop button is not time travel. It might prevent the next tool call without reversing an email already sent or a transaction already completed. The buyer needs to know what can be interrupted, what needs compensation and what cannot be undone.
Use a harmless test environment to demonstrate those differences. Record the behaviour when a credential expires, a tool fails or an approval is withdrawn. A reliable stop procedure should identify both the technical action and the person responsible for the remaining work.
Keep legal review and product evidence connected
The NIST AI Risk Management Framework is a voluntary reference for organising AI risk work. It is not a substitute for reviewing a particular contract or the obligations that apply to a particular deployment.
For a product team, the useful next step is a short decision record linking the commercial promise to the implementation and its test evidence. Each unresolved assumption should have an owner. “The vendor handles it” is not an owner unless the vendor has actually accepted and implemented the responsibility.
Then use separate evaluations for outcome, authority and recovery. A correct answer is welcome. It does not prove that the system had permission to take every action on the way there.
The strongest procurement answer is a contract you can map to working controls. Keep the lawyers and the engineers in the same conversation. Neither should have to discover the other team’s assumptions during an incident.
