The procurement conversation for agentic AI is unlike any technology procurement the enterprise has conducted before. It is not software licensing, where the risk is misalignment between the feature set and the business requirement. It is not infrastructure, where the risk is capacity and availability. It is a procurement of systems that will act in the world on behalf of the enterprise, using data the enterprise owns, with consequences the enterprise will be held accountable for. The contract clauses that govern this relationship need to reflect that reality — and most standard SaaS agreements do not.
Buy, build, or rent
The make-or-buy decision for agentic AI has a third option that does not exist in traditional software: rent-by-inference, where the enterprise pays per API call to a frontier model provider without committing to infrastructure or a vendor relationship. The choice between buy (an enterprise platform with a licence), build (a bespoke agent on open-source infrastructure), and rent (API access to a hosted model) is not a one-time decision; it applies separately to each layer of the stack — model, orchestration, evals, observability, identity.
The general principle is: build where the competitive differentiation lives, buy or rent where it does not. A retailer's competitive advantage is not in a better prompt engineering framework; it is in the retail data and the domain expertise that shapes how the agent uses that framework. The framework itself should be rented or bought. The data integration, the business logic, the eval set that captures what "good" looks like for this retailer's customer service agent — these should be built and owned.
The risk profile of each option differs materially. Renting from a frontier model provider introduces model-version risk: the provider updates the model, the agent's behaviour changes, the evals dashboard flags a regression, and the enterprise is now in a negotiation with a provider about when a pinned version will stop being supported. Buying an enterprise platform introduces vendor concentration risk: the platform acquires the orchestration market, raises prices, and the enterprise discovers its entire agent estate runs on a single vendor's proprietary APIs. Building on open-source introduces maintenance risk: the framework version falls behind, a critical security patch is delayed, and the team that built the agent has moved on.
Model provider contracts
The contract with a frontier model provider is the most consequential procurement document in the enterprise's AI stack, and it receives the least scrutiny. Standard terms from major providers typically include clauses that most enterprise legal teams, reading quickly, treat as boilerplate. They are not. Four clauses deserve particular attention.
Data usage for training: does the provider use enterprise data — prompts, tool-call logs, completions — to fine-tune or improve the model? Most enterprise agreements include an opt-out; most enterprise customers do not read carefully enough to invoke it. For any agent handling confidential business data, customer data, or regulated information, the opt-out must be explicitly invoked and confirmed in writing.
Model version pinning: can the enterprise pin to a specific model version, and if so, for how long? Model providers retire versions on schedules that are driven by their roadmap, not their customers' stability requirements. An enterprise agent that has been validated against model version X may produce materially different outputs on version Y. The contract should specify the minimum notice period for version deprecation — ninety days is a reasonable floor — and the enterprise's right to extend access to the pinned version for the duration of a re-validation cycle.
Incident notification: what is the provider's obligation to notify the enterprise if the provider discovers that the model has been producing systematically biased or harmful outputs? Most current agreements are silent on this. For enterprises operating under the EU AI Act's incident reporting obligations, the absence of a provider notification clause creates a compliance gap.
Liability for model outputs: the standard position of all frontier model providers is that the enterprise is responsible for the outputs of the model when deployed. This is legally defensible for the provider and practically terrifying for the enterprise. The enterprise cannot audit the model; it can only test it. The contract should specify what documentation the provider will supply to support the enterprise's own risk assessment — technical reports, evaluation results, known limitations — and update that documentation when the model changes.
"If you do not negotiate these clauses, you are accepting a contract written by a legal team whose job is to maximise the provider's optionality. That is not a criticism of the provider; it is a description of every contract ever written." — paraphrased from a Forrester enterprise AI procurement briefing.
Orchestration and platform vendors
The orchestration market is consolidating rapidly, and the vendors that win will have significant pricing power over the enterprises whose agent estates are built on their proprietary APIs. The procurement discipline here is the same as for any platform dependency: understand the switching costs before you are inside them. A vendor whose orchestration framework stores agent state in a proprietary format, whose evals harness uses proprietary graders, and whose identity model is tightly integrated with their own identity provider has created switching costs that compound with every agent deployed on the platform.
The contract clauses that matter for orchestration vendors: data portability (can the enterprise export all agent state, logs, and eval results in a standard format?), source-code access (if the vendor is acquired or ceases to operate, does the enterprise have the right to a source escrow?), and API stability commitments (what is the vendor's obligation to maintain API compatibility across major version upgrades, and what is the notice period for breaking changes?).
Building the procurement playbook
The procurement playbook is the document that encodes everything the programme has learned about buying agent-adjacent technology. It includes: a vendor risk taxonomy specific to agentic AI (model providers, orchestration platforms, evals vendors, security tooling, tool providers); a standard contract clause library for each category; a vendor risk assessment process that extends the existing third-party risk management framework to cover agent-specific supply chain risks; and a review cadence that ensures the playbook is updated as the market evolves.
The playbook is a Q4 roadmap deliverable, as described in Chapter 33, because it takes a full year of procurement experience to write it accurately. An organisation that writes its procurement playbook in Q1, before it has negotiated a single model provider contract, will write a document that is theoretically sound and practically useless. The playbook earns its authority from the scars on the contracts that preceded it.