Join our Newsletter — 33% off our NHI Course

AI Procurement

AI Procurement is the process of selecting and contracting for AI products or services with security, privacy, legal, and operational requirements built in. Buyers should assess data handling, model update practices, access controls, auditability, and exit terms before purchase. Weak procurement can lock an organisation into opaque tools with unmanaged risk.

What AI Procurement Actually Covers

AI procurement is not just vendor selection, it is the point where security, privacy, legal, and operational requirements are translated into contractual and technical obligations. The procurement decision determines what data the supplier can touch, how the model can change, and what recourse exists if the product becomes unsafe or opaque.

That makes procurement a control surface, not a paperwork exercise. A well-specified purchase can reduce later exposure; a weak one can leave the organisation dependent on a tool it cannot inspect, govern, or exit cleanly.

Why AI Procurement Is a Security and Governance Decision

AI products often arrive with embedded assumptions about data use, logging, model updates, subcontractors, and customer support access. If those assumptions are not reviewed before purchase, they become defaults that are difficult to unwind later.

Procurement therefore shapes the organisation’s exposure to sensitive data handling, vendor-side model training, retention terms, and who can administer or observe the service. Those issues are especially important when the product is connected to business workflows, employee data, or regulated information.

What Buyers Need to Verify Before Contracting

Buyers should confirm how the vendor handles training data, retention, access by vendor personnel, audit logging, and change notification for model or platform updates. They should also check whether the service can support role-based access, data segregation, exportability, and documented deletion or offboarding.

The most important question is often not whether the tool is capable, but whether the buyer can govern it after purchase. If procurement does not establish clear boundaries for data handling and operational control, the organisation may inherit hidden dependencies that are expensive to monitor and difficult to replace.

  • Security terms should define who can access the system and under what conditions.
  • Privacy terms should define what data may be processed, retained, or reused.
  • Operational terms should define update cadence, notice, support, and service continuity.

How AI Procurement Reduces Lock-In and Posture Drift

AI procurement should also test exit terms, portability, and the vendor’s ability to disclose meaningful audit evidence. Without those terms, the buyer may be unable to move data, rebuild workflows, or verify whether the service still matches the original security posture.

For third-party AI tools, that concern often overlaps with vendor due diligence and supply chain governance. NHIMG’s Third-Party AI Risk Guide is a useful reference for scoping AI vendors, reviewing contract clauses, and checking how supplier risk shows up in procurement decisions.

Risk and Threat Considerations

AI procurement risk comes from buying into a service whose data paths, access model, and update behaviour are not fully visible at contract time. Poorly written terms can create long-lived exposure through retained data, overbroad vendor access, and dependence on a provider that can change functionality or policies after deployment.

Failure mechanism: The buyer accepts opaque defaults, then discovers too late that the vendor can retain data, alter model behaviour, or limit exit and audit options.

Impact: Sensitive data can be exposed, compliance obligations can become harder to meet, and the organisation can become operationally dependent on a tool it cannot confidently govern or replace.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST CSF 2.0 GV.SC-01 — Cybersecurity Supply Chain Risk Management AI procurement depends on supplier risk and contract governance.
GV.RM-01 — Risk Management Strategy AI procurement must align buying decisions with enterprise risk appetite.
PR.AA-05 — Identity Management, Authentication and Access Control AI procurement must require access controls for vendor and customer use.
Recommendation — Apply GV.SC-01 to assess vendor AI risk and contract terms before purchase. Use GV.RM-01 to define acceptable AI procurement risk thresholds and approval criteria. Enforce PR.AA-05 so purchased AI services support least-privilege access controls.
NIST SP 800-53 Rev 5 SA-9 — External System Services Procured AI is an external service whose terms and controls must be specified.
RA-3 — Risk Assessment AI procurement requires assessing supplier, data, and operational risks before acquisition.
Recommendation — Apply SA-9 to contractually define security obligations for the AI service provider. Use RA-3 to evaluate AI vendor risks before committing to purchase.

Practitioner Guidance

Why practitioners should care: AI procurement is where many downstream controls are either made possible or quietly undermined. The purchase terms should be treated as part of the security design, not as an administrative afterthought.

What to watch for: Pay close attention when a vendor refuses to explain data use, will not commit to deletion or audit rights, or makes updates and subcontracting too opaque for the buyer to assess risk. Those are often the earliest signs that the organisation is being asked to accept governance it cannot enforce.