AI governance in procurement: what to require before you authorise execution
Published 2026-08-05 · Last updated 2026-08-05
AI governance in procurement means defining what software may do, bounding it explicitly, holding consequential decisions with named people, and retaining evidence that allows any action to be reconstructed. The practical test is whether the platform can show its permission model, a blocked action, an escalation and an override record.
The question is accountability, not capability
Most enterprise objections to autonomous execution are not about whether software can perform the task. They are about who is accountable when it does.
That reframes the assessment. Instead of asking how advanced the AI is, ask how precisely its authority can be described, and how completely its actions can be reconstructed.
Six controls to require
These six controls are what turn autonomous execution into something a security and audit function can approve.
- Role-based access: users and agents operate inside explicit roles scoped by entity, category and data.
- Agent permissioning: each agent has defined permitted actions, value limits and escalation paths rather than general authority.
- Policy and threshold controls: policy is executable, so routine work proceeds and material exceptions stop.
- Human approval checkpoints: consequential decisions reach named roles and cannot be bypassed by an agent.
- Explainability and override: any material action can be explained and reversed by an authorised person, with the reason recorded.
- Complete audit trail: the observation, rule, action, approval, exception and override are retained together.
Segregation of duties applies to agents too
If your policy separates preparation from approval for people, the same separation should apply to software. An agent that prepares an award package should not also hold the authority to approve it.
This is straightforward to configure and easy to overlook, and it is one of the first things an internal audit function will ask about.
What to ask a vendor to demonstrate
Descriptions of governance are easy to produce. Demonstrations are not. A short, specific list is more revealing than a long questionnaire.
- Show the permission set for one agent in the configuration, not in a slide.
- Show an action being blocked at a threshold, with the rule that blocked it.
- Show an escalation reaching a named approver with the reason attached.
- Show an authorised override and the record it leaves.
- Retrieve the complete action history for a single transaction.
- Show how a change to policy or permissions is itself approved and recorded.
Governance also determines adoption speed
Organisations that define authority carefully tend to widen automation faster, because each expansion is a small, evidenced decision rather than a fresh act of faith.
A practical sequence is to give agents coordination authority first, accumulate an audit record, review it with security and audit, then extend execution rights.
Five confusions. Governance is none of them.
What people mistake for a control.
“Governance is a policy document.”
A document describes intended behaviour. Governance in this context means rules that execute during the work and prevent the behaviour they prohibit. A policy nobody can bypass is a control; a policy in a folder is an intention.
“Governance means slowing things down.”
Applied as approval layers, yes. Applied as executable rules, the opposite: the correct route becomes the fastest one, which is the only reliable way to stop people routing around it.
“An audit trail is enough.”
A trail records what happened. Governance also constrains what can happen. A complete record of an unauthorised action is evidence, not control.
“Compliance certification covers AI governance.”
Certification assesses an organisation's management system. It says nothing about whether a specific agent's authority is bounded or whether a checkpoint can be bypassed.
“We can add governance later.”
Authority granted without a boundary is difficult to withdraw once teams depend on it. The boundary is cheaper to define before execution starts than after.
Seven requirements. Demonstrated, not described.
What to put on the agenda before authorising execution.
- The enumerated permitted-action set for every agent.
- The list of decisions that always return to a person.
- Proof that a checkpoint cannot be bypassed by configuration.
- A demonstration of an action blocked at a threshold.
- An override performed and then retrieved with author and reason.
- The complete action history for one transaction, as an auditor would receive it.
- Written positions on data residency, retention and subprocessors.
The questions we get asked. Answered straight.
The ones that come up when a shortlist is being narrowed.
In practice it is shared: procurement owns the policy content, information security owns access and permissioning, internal audit owns the evidence requirements, and legal owns the claims and data obligations. Ownership gaps between them are where problems appear.
For any given transaction: what the software was permitted to do, what it did, which rule applied, who approved the consequential steps and whether anything was overridden. If those five are retrievable, most audit conversations become manageable.
That is a policy decision rather than a technical one. Many organisations authorise coordination — reminders, document requests, acknowledgement chasing — while reserving commercial communication for people.
Override it through an authorised role, record the reason, then correct the underlying configuration. Treating each error as a configuration signal rather than an isolated incident is what improves the model over time.
Defining authority takes effort at the start and usually accelerates everything afterwards, because each expansion of the permitted action set becomes an evidenced decision rather than a debate.
AI governance is the set of controls determining what an AI system is permitted to do, who remains accountable for consequential decisions, and what evidence is retained. In procurement it is the difference between autonomy a security function can authorise and autonomy it cannot.
Accountability usually sits jointly: procurement owns the policy and thresholds, security owns the permission model review, and internal audit owns the evidence standard. A deployment where only one of the three has been consulted tends to stall at review.
Data governance concerns how information is classified, accessed, retained and protected. AI governance concerns what software is permitted to do with it and who is accountable for the resulting actions. Both are required; neither substitutes for the other.