When a government announces an AI programme, attention goes to the model, the partner and the launch date. The decisions that determine whether the programme can be governed are made earlier and more quietly, in a procurement file. The specification decides what evidence the supplier must produce. The evaluation criteria decide whether a polished demonstration can outscore a tested system. The contract decides who owns the logs, the rules and the case history, and whether the department can leave.
That makes procurement the first real test of an AI-native government. A department that cannot specify, evaluate and contract for evidence, control and exit will not be able to govern the service once it is live, however good its policy statements are.
It is also a test in a second sense. Procurement is one of the most rule-bound, document-heavy and audited processes in the state, so it is a natural candidate for AI assistance. How a department uses AI inside its own procurement chain shows whether it understands the difference between assisting a decision and taking one.
The legal ground, stated carefully
South African public procurement is currently governed by section 217 of the Constitution, the Public Finance Management Act for national and provincial departments and public entities, the Municipal Finance Management Act for municipalities, the Preferential Procurement Policy Framework Act and its regulations, and National Treasury instructions.
The Public Procurement Act 28 of 2024 was intended to consolidate much of this. It never came into operation, and on 17 September 2026 the Constitutional Court declared it invalid because Parliament had not facilitated adequate public participation (SAnews; BusinessTech). The Minister of Finance has said Treasury will prepare new legislation and that the existing statutes continue to apply in the meantime. For now, the existing framework applies, and any AI-native procurement design must work within it. This is general information, not legal advice; departments should confirm their own obligations with their legal advisers and Treasury.
The point for this series is simple. Whatever the next procurement statute says, the constitutional requirements of a fair, equitable, transparent, competitive and cost-effective system already apply. AI does not change them. It changes what evidence a department needs to show that it met them.
Procurement is an evidence chain
Procurement is easiest to understand as a chain of decisions, each of which must be recorded well enough for an auditor to follow later. We described this chain for technology programmes generally in What public-sector procurement reform teaches technology programmes. For an AI-assisted service, each link carries a specific risk.
- Need and demand plan. If the need is written as "an AI solution", the department has already chosen the answer. The need should describe the service outcome and the decision the AI will assist, as Part 6 argued in Digitising bureaucracy is not transformation.
- Specification. This is where evidence, control and exit requirements are written, or omitted.
- Evaluation. If functionality is scored on a demonstration, the best presenter wins. If it is scored on results against the department's own scenarios, the best system has a chance.
- Award. A decision for the bid adjudication committee and the accounting officer or their delegate, on the record.
- Contract, delivery and acceptance. Acceptance should repeat the evaluation tests on the delivered system, not sign off a go-live.
- Payment and audit. Payments tied to evidence of performance, and a file that can be audited without the supplier explaining it.
What to specify when buying an AI-assisted service
The Thukela Provincial Licensing Authority, the fictional licensing authority used throughout this series, is buying an AI-assisted assessment service for liquor licence renewals. Its specification groups requirements into three families.
Evidence. The supplier must run the system against a scenario library the authority supplies, covering routine cases, edge cases, ambiguous rules and deliberately invalid applications, and report results by scenario type. It must document known limitations and provide a change log for every release that could alter behaviour, including model, prompt and rule changes. The government AI evaluation harness describes how to build the scenario library itself.
Control. Every recommendation must record the rule version, model version and evidence it relied on. Officials must be able to override any recommendation and record reasons. Logs must be held in a form the authority can access and read without supplier assistance.
Exit. Rules, case records and logs must be exportable in documented, open formats. The contract must include transition assistance and must not make the authority's own case history dependent on a proprietary platform. Sovereign AI is more than data residency explains why exit is a sovereignty question, not only a commercial one.
Each requirement is written so it can be tested twice: once at evaluation, and again at acceptance. A supplier that cannot evidence a requirement scores zero for it, however confident its presentation.
Two things are deliberately absent. The specification does not name a model or a vendor, because that would narrow competition without a defensible reason and would date quickly. And it does not ask for "explainable AI" as a slogan. It asks for the specific records an official, an auditor or a court would need.
AI inside the procurement chain
Departments are also tempted to use AI to run procurement itself: reading bids, checking compliance, summarising responses and even scoring. Some of this is useful. Bid documents are long, compliance checks are repetitive and evaluation panels are stretched.
The line is the same one drawn throughout this series. AI may help prepare and check. It may not hold the authority to decide.
| Procurement task | Reasonable AI role | What stays with people |
|---|---|---|
| Drafting a specification | First draft from the need statement and templates | Content, criteria and sign-off by the specification committee |
| Compliance checks | Flag missing documents and mismatched details, with references | Confirmation of each disqualification |
| Functionality evaluation | Extract evidence from bids against each criterion | Scoring by panel members, with their own reasons |
| Award | None beyond assembling the record | Adjudication and award decision |
| Contract management | Compare delivery evidence to obligations | Acceptance, penalties and variations |
A bidder disqualified because a model misread a document has a strong complaint, and the department will have to show what happened. That requires the same records as any other AI-assisted decision: what the system flagged, which rule it applied, what the official checked and what they decided. AI can read the tender. It cannot own the bid makes the equivalent argument from the supplier's side.
Where AI-native procurement programmes go wrong
- Buying a platform before defining the decision. The specification describes capabilities rather than the service outcome and the authority the AI will support.
- Scoring demonstrations. Evaluation rewards presentation instead of tested results on the department's own cases.
- Leaving evidence to the supplier. Logs, rule versions and evaluation results sit in the supplier's environment and are available only on request.
- No acceptance testing. The system goes live because the project date arrived, not because it repeated the evaluation results.
- No exit. Case history and rules can only be read inside the supplier's product.
Each of these is cheaper to fix in the specification than in production. A department that gets them right has demonstrated, in a concrete and auditable way, that it can govern AI. One that gets them wrong has a governance problem before the first citizen uses the service. Buy, build or grow: procurement in the agent era covers the earlier choice of whether to buy at all.
Next: Part 8, AI-native government needs AI-confident officials. All parts are on the series page.
How CloudNala can help
CloudNala helps public bodies prepare procurement for AI-assisted services. We work with the specification and evaluation committees to turn a service need into testable evidence, control and exit requirements, build the scenario library used to evaluate bids and accept the delivered system, and review draft contracts for access to logs, rules and case history. We do not replace your supply chain management unit or legal advisers, and we do not bid on procurements we help prepare.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Start a Digital Discovery Sprint or write to us at consult@cloudnala.co.za