A manager approves a purchase, then the price and delivery date change. What should an AI assistant be allowed to do next, and where should those limits be enforced?
One Operational Ecosystem, Part 3
The purchasing manager approves an order for 500 components. The supplier is approved, the specification is current, and the quote meets the budget. The assistant has done its preparation well.
Before it submits the order, the supplier updates the quote. The price has increased and delivery has moved to the following week. The order still falls within the manager's spending limit.
Should the assistant proceed?
The manager approved a particular purchase. The assistant now has a different one in front of it. Whether that change is acceptable depends on what the manager authorized and the rules the business has established for changed terms.
This is the next step in our hypothetical purchasing example. Part 1 followed the work from a supplier search to an order. Part 2 examined which records the assistant should rely on. Here, I want to look at how permission to act should work once the information has been checked.
Be specific about the action
“Help with purchasing” leaves a great deal open to interpretation. Searching a catalog, preparing an order, sending it to a supplier, and changing payment details each carry different consequences.
I would start by listing the actions the assistant will be able to take. For each, the business should decide who can authorize it, which conditions apply, and whether a person needs to review the individual transaction.
An assistant could prepare comparisons without further approval while requiring a manager's decision before submitting an order. Changing a supplier's bank details could remain outside its scope altogether.
These choices should be reflected in the connections the assistant is given. If its job is to prepare draft orders, its account should be restricted to that job. An account with broad purchasing access creates opportunities for actions the business may never have intended to delegate.
The ability to connect to an application tells us little about which decisions the assistant should be allowed to make there.
Make the approval describe the purchase
For the order in our example, I would want the approval to identify the supplier, component specification, quantity, price, delivery terms, and relevant quote version. It should also identify the person approving it and the scope of their authority.
Some businesses may allow limited changes without another review. A manager might approve a total up to a stated amount, provided the supplier and specification remain the same and delivery meets a deadline. Those limits should be explicit and enforceable.
An approval can also expire. If an order waits in a queue for several days, the business needs to decide whether the original decision still applies. A change in the supplier's status may require the order to be held even when every commercial term remains unchanged.
In Chapter 7 of The Hyperproof Manifesto, I describe a mandate as a signed declaration of intent tied to a specific decision and explicit constraints. Applied to this example, the aim is to preserve what the manager actually authorized so it can be checked against the action that follows.
A signature can help make that record verifiable and tamper-evident. The system still needs to check the person's authority and the conditions under which the approval can be used.
Check the conditions where the order is submitted
The assistant might have checked the supplier's status when it began preparing the comparison. By the time the order is ready, that status could have changed.
I would put the final checks in the service that accepts the order. It should compare the proposed transaction with the approval and confirm that the required conditions still hold. If it cannot establish that, it should hold the transaction and provide a reason the team can act on.
That check needs to apply regardless of how the request arrives. A restriction enforced only by a button in the assistant's interface may be missed when another integration submits the same request.
The assistant can explain a rejected order and help prepare a corrected one. It should have no means to rewrite its own spending limit or treat a failed check as permission to try a less restricted route.
This is the practical concern behind the control points discussed in Chapter 6 of my Applied AI Handbook. A purchasing rule needs to affect whether the purchase can happen. The team should be able to demonstrate that effect with a transaction that falls outside the rule.
Give the reviewer a meaningful decision
The manager's screen should make clear what will happen after approval. Will it save a draft, send the order immediately, or release it to a queue for later submission?
For our changed quote, I would show the previous and proposed terms together, with the price and delivery changes clearly identified. The manager should be able to inspect the supporting records and return the order for clarification.
The time available for review matters. If the process expects someone to approve dozens of complex purchases in a few minutes, the business should examine whether that person can realistically perform the checks assigned to them.
Chapter 3 of the Applied AI Handbook treats human oversight as a design choice. It affects the work people must do, the authority they need, and the information they receive.
A useful review process also explains what happens when the reviewer does nothing. For this purchase, a missing response should leave the order pending. Any escalation should go to someone authorized to make the decision, with the unresolved conditions still visible.
Keep a way to withdraw approval
Suppose the manager approves the revised order, then learns that production no longer needs the components. The order is still waiting to be sent.
The team needs a way to withdraw that approval and confirm whether the order was stopped. That requires a reliable view of its current state and a check before queued work proceeds.
An order already accepted by the supplier is a different situation. Stopping the assistant will not cancel it. Procurement needs to know that the order was sent and follow the appropriate cancellation process.
I would make those distinctions visible: prepared, approved, submitted, accepted, or awaiting confirmation. The labels should correspond to events the system can establish. When the outcome is uncertain, the interface should say so.
For example, a connection may fail after submission but before the assistant receives a response. Automatically sending another order could create a duplicate. The workflow should use a stable transaction reference and check the receiving system, or route the uncertainty to an operator before attempting another purchase.
Decide what can be delegated in advance
Requiring a fresh approval for every action may add work without improving the decision. A business could authorize routine replenishment within an agreed scope: specified components, approved suppliers, quantity limits, a defined budget period, and clear expiry and cancellation conditions.
That delegation needs an owner. Someone should review its continued use and be able to suspend it when circumstances change.
Limits also need to account for repeated actions. Ten orders that each fall below an individual spending limit can still exceed the intended budget. I would check cumulative spending and repeated submissions as part of the same design.
The appropriate scope depends on the task and its consequences. Begin with a narrow, observable workflow that the business can support, then use its operating record to decide whether to extend it.
Test the boundaries before extending them
For our purchasing assistant, I would test a changed price, a late delivery, a withdrawn approval, an expired delegation, and an uncertain submission result. I would also try an approver whose authority is insufficient for the purchase.
For each case, agree on the expected outcome beforehand. Then confirm what the receiving system actually did, what the reviewer saw, and who was asked to resolve the issue.
Retain enough of that history to connect the request, approval, checks, and outcome. It should help an operator answer a practical question: did this order proceed under the conditions that were authorized?
The purchasing manager's original approval gives us a useful place to finish. The price and delivery date changed. A well-designed workflow would detect that change, check it against the agreed limits, and either proceed within those limits or return the revised purchase for a new decision.
Choose one action your AI system can take today. Ask what authorizes it, where that authority is checked, and how you would withdraw it before the action occurs. Those answers establish the boundaries within which the business is prepared to let the system operate.
Further reading
- Dom Jocubeit, Applied AI Handbook: Implementing AI Without Breaking the Business, the Law, or Trust, Chapter 3, “System Design as Governance,” pp. 37-39; Chapter 6, “Governance, Compliance, and Ethics in Practice,” particularly “Embedding Governance at Control Points,” p. 54.
- Dom Jocubeit, The Hyperproof Manifesto: On Legitimacy, Consent & Executable Authority, Chapter 7, “What a Mandate Is,” pp. 77-82.