Why does fragmented procurement make public-sector AI harder to govern?

What fragmented procurement does to governance

Fragmented procurement turns one policy problem into many contract-level exceptions. Instead of a single intake, review, and approval path for AI services, each department may negotiate its own vendor terms, logging obligations, data-sharing limits, and exception process. That makes governance harder because control ownership shifts from a central standard to a patchwork of programme-specific decisions.

This is especially visible when buyers procure similar tools for casework, analytics, or citizen services but specify them differently. The organisation ends up governing products one by one rather than governing the risk pattern, so even basic questions such as who approved the use case, what data was exposed, or which logs exist become harder to answer consistently.

Fragmentation also weakens comparability. If one programme requires audit logs, another keeps only vendor-side telemetry, and a third allows local data export, the central function cannot confidently compare controls or assess whether two deployments meet the same minimum bar. That is a governance failure as much as a procurement failure, because the organisation loses a common basis for oversight.

Why duplicated pilots become a control problem

Duplicated pilots are not just inefficient, they create inconsistent evidence. One team may test an AI workflow under strict supervision, while another tests a nearly identical workflow under looser data rules and different escalation thresholds. When the pilots are not standardised, lessons do not transfer cleanly, and procurement does not produce reusable control evidence for the next programme.

That inconsistency matters in public-sector settings because approval paths often determine what data can be used, which systems can be connected, and which logs must be retained. Public Sector Identity Security Guide is useful here because governance breakdowns often start when departments allow the same access pattern to be approved in different ways across similar services.

It also creates hidden operational overhead. Teams duplicate vendor due diligence, legal review, privacy assessment, and security testing for each pilot, but still fail to build a central inventory of what has actually been deployed. The result is not only more work, but weaker assurance, because duplicated effort can mask the absence of consistent policy enforcement.

How to govern AI across many buying paths

The practical fix is to govern the control pattern first and the product second. Standardise the minimum approval set for any AI use case, define the logging and data-access baseline once, and require exceptions to be explicit, time-bound, and reviewable. Procurement should then attach to that standard rather than recreate it for each department.

In government, the most useful test is whether a central team can compare deployments without reinterpreting local contract language. If the answer is no, the organisation does not have a scalable governance model yet. A central inventory, common log requirements, and a shared data-classification decision are usually more important than adding another review layer.

Where AI tools touch sensitive records or regulated workflows, procurement should also force alignment between contract terms and operating evidence. If the supplier cannot support the logging, retention, access control, or exit obligations the agency needs, the procurement path is already signalling an operational governance gap.

Risk and Threat Considerations

Fragmented procurement increases the chance that the same AI use case will be deployed under weaker controls in one part of government than another. That creates uneven exposure, makes audit and incident response slower, and gives adversaries more room to exploit local exceptions, shadow pilots, or poorly governed data-sharing paths.

Failure mechanism: A decentralised buying process produces different approval criteria, telemetry standards, and data-access rules for similar deployments, so control objectives cannot be enforced or evidenced consistently across the estate.

Impact: Agencies may not detect unsafe deployments quickly, may be unable to prove comparable controls across programmes, and may inherit inconsistent records when they need to investigate misuse, leakage, or vendor failure.

Practitioner Guidance

What to prioritise: Set a single minimum control package for AI procurements before individual teams negotiate with vendors. The package should cover approval authority, logging, data-access rules, and exit requirements, because those are the points that most often fragment across programmes.

What to verify: Check whether two similar procurements would produce the same evidence trail. If one pilot cannot be compared with another using the same control checklist, the organisation is managing projects, not governance.

Common mistake: Treating procurement as a commercial step rather than the point where governance becomes enforceable. By the time the contract is signed, it is much harder to recover missing logging rights, inconsistent data limits, or unclear ownership.

Practitioner takeaway: The central question is not how many AI pilots exist, but whether they can all be governed against the same control objectives without rewriting the rules for each department.

Related resources from NHI Mgmt Group

• Why do legacy procurement processes make public-sector AI harder to secure?
• Why do fragmented identities make AI access risk harder to govern?
• How should security teams govern API keys used for generative AI access?
• Why does fragmented IAM make NHI and AI agent governance harder?