Practical perspectives
When Should an AI Procurement Agent Ask for Approval?
A practical decision-rights map for procurement AI that drafts, recommends or acts across supplier communication and purchasing.
“Autonomous” can describe very different products. A system might draft a supplier email, send it after a buyer approves, negotiate within a limit, or commit an order. Those are different authority levels even when the interface makes them look like one conversation.
Buyers should define what the system may read, propose, send and commit before evaluating a claimed agentic workflow. The right boundary depends on the transaction, risk and organisation. This article offers a decision-rights worksheet, not a universal approval policy.
1. Separate reading, drafting, sending and committing
Describe each action with a verb and an object: read a quote, compare offers, draft a clarification, send an RFQ, accept a term or create an order. Ask the provider to identify which action the AI performs today, which a person approves, and which the product does not support. Do not infer authority from words such as “assistant,” “copilot” or “agent.”
The NIST AI Risk Management Framework core ↗ calls for defined human-AI roles, oversight processes and monitoring across the lifecycle. It is a risk-management framework, not a procurement-specific rule requiring a particular approval threshold.
2. Put the authority boundary beside the procurement action
| Action | Possible boundary to test | Evidence to request |
|---|---|---|
| Summarise supplier responses | Read and draft; buyer checks source passages. | Source citation, correction history and a way to mark unknowns. |
| Recommend a shortlist | Propose options; buyer confirms eligibility and rationale. | Criteria, exclusions and the record of the buyer decision. |
| Send a clarification or RFQ | Prepare a message; a named role approves recipients and final text. | Recipient preview, approved content and sent-message record. |
| Negotiate within limits | Act only within explicitly approved scope, counterparties and limits. | Configured boundaries, exception handling, pause and override demonstration. |
| Accept terms or create an order | Require the authority designated by the buyer’s process. | Approval record, downstream transaction and reversal or correction path. |
These are examples, not a recommendation that every RFQ needs a human click or that every negotiation can be delegated. The buyer must set authority under its own policies and agreements. What matters in evaluation is whether the product enforces the chosen boundary in the proposed configuration.
3. Define when the system pauses instead of guessing
Write a few exception triggers before the demonstration: unknown supplier identity, missing unit price, a term outside an approved range, a new recipient, changed specification or unavailable source record. Ask what the system does when two instructions conflict. A safe response may be to stop, ask for clarification and preserve the original evidence.
Test both the normal case and an exception. Verify that a user can inspect the pending action, decline it, edit it and recover after a mistaken or failed send. The UK AI procurement guidelines ↗ emphasise oversight, governance, limitations and ongoing evaluation; the exact control design remains the buyer’s responsibility.
- Scope change: a supplier offers an alternative specification rather than the requested item.
- Commercial limit: a proposed price or concession moves beyond the approved range.
- Recipient change: the system adds a contact or company that the buyer did not approve.
- Uncertain evidence: an AI summary cannot point back to the source quotation or agreement.
- System failure: the downstream record is not created after a message or approval.
4. Inspect the record of who decided and what was sent
For one test case, ask to see the input, AI proposal, cited source, policy or limit used, human intervention, final external action and downstream record. The log should distinguish a draft from a sent message and a recommendation from an approved commitment. Ask who can read and correct the record and how long it is kept.
A generic activity feed may not answer these questions. Ask the vendor to demonstrate a disputed supplier message or changed quote from beginning to end. NIST describes oversight, monitoring, override and change management as connected practices in its AI RMF core ↗.
5. Start with the authority you can validate
A buyer may start with read-only analysis, then permit drafted communications, then consider more delegated actions after observing accuracy, exceptions and supplier response. Advancement is a separate decision, not a reward for a polished demo. Record the current permitted scope, owner, review cadence and trigger for suspension.
To compare adjacent products, see the negotiation-support guide and the autonomous procurement overview. For a hands-on test, use the real-workflow evaluation method. A category listing does not establish a product’s actual autonomy or approval controls.