Skip to main content

Procurement & Vendors

Why this function belongs in the AI Operating Model

The build / reuse / buy decision almost always contains a "buy": an external LLM, a cloud platform, a vendor AI service. Procurement and vendor management turn this choice into a managed contract rather than an ad-hoc subscription on a corporate card. This matters especially for cost economics: the cost of inference and tokens grows imperceptibly, and without procurement control the AI portfolio quickly becomes expensive and opaque.

The function works in tandem with architecture (what we buy and why this specifically), InfoSec and legal (on what terms regarding data and rights), and finance (how much it costs and how to control it).

Where it engages

AI Operating Model stageRole of procurement and vendor management
Product selection (build/buy)Qualifies vendors, gathers terms and prices
Before the pilotSets up the contract/subscription accounting for InfoSec and legal requirements
Delivery / productionLocks in SLAs, support, the pricing model
In supportControls costs, renegotiates contracts, manages dependency

What the function receives as input

  • Solution requirements and the architectural choice (what exactly we're buying).
  • InfoSec and legal opinions on data processing and rights.
  • A consumption forecast (volume of requests, tokens, users) to estimate cost.

What the function delivers as output

  • A contract with terms on data, rights, SLAs, and support.
  • An agreed pricing model and a spending cap.
  • A dependency management plan: an exit strategy, reducing vendor lock-in.

Key touchpoint artifacts

  • Vendor card — terms, risks, SLAs, data rights.
  • Solution cost model — a forecast of inference/license costs and caps.
  • Lock-in reduction plan — alternatives and an exit strategy.

Anti-patterns

  • Shadow subscriptions. Teams buy AI services bypassing procurement — no control over rights, data, and costs.
  • Costs without a cap. Token/inference consumption grows without limits or alerts.
  • Hard lock-in. The architecture is tied to a single vendor without an exit strategy.