AI procurement: buy a change process as well as a feature

A procurement approval usually describes a product at a moment in time. An AI-enabled product also depends on choices the supplier may change later: the model handling a request, the information sent to it, the features enabled for users and the way customer data contributes to product improvement.

For the technology procurement lead, those changes belong in the commercial relationship. If nobody owns their review after signature, the organisation can keep paying for a service whose behaviour no longer matches the approval. The immediate cost may be a rushed reassessment, an unplanned upgrade or an interruption to a workflow that has already become important.

The product name is too broad an approval boundary

Define the approved feature and its permitted use. A document summariser used by a small internal team presents a different decision from an assistant that retrieves customer records or executes actions. Establish what information enters the feature, what systems it can reach and where a human remains responsible for the result.

Then identify which supplier choices can change that boundary. A new retrieval connector may expose more information than a model upgrade. A new action capability may turn an advisory tool into something that modifies records. A change to data-use settings may matter even when the visible feature appears unchanged.

Atlassian’s AI trust documentation illustrates why procurement should ask about the actual service configuration. The company describes dynamic routing across Atlassian-hosted and third-party models. It says eligible Cloud Enterprise organisations can request use of Atlassian-hosted models only. That is a concrete purchasing consideration: an organisation requiring that boundary must establish its eligibility and configuration, rather than assuming one model arrangement applies to every customer.

A documented change is a reason to assign an owner

In its data contribution FAQ, Atlassian says changes to eligible customer-data use and its customer terms took effect on 17 August 2026. It describes new settings initially covering Jira, Confluence and Jira Service Management, including specified platform apps. Available controls and exclusions depend on the organisation’s circumstances and plan.

The company’s support documentation distinguishes metadata and in-app data, and describes de-identification and aggregation safeguards. These details matter more than a blanket question about whether a supplier “trains AI on our data”. The review needs to distinguish the SaaS provider’s uses from those of its model providers, then inspect the applicable settings.

This example does not establish that a particular customer should accept or reject the service. It demonstrates why an approval needs a continuing owner. A procurement contact must route a notice to someone who can assess the data implications and someone who can change the tenant configuration. An unread notification or an assumed default is not an implemented control.

Negotiate the decisions you will need to make

Ask suppliers how material changes are communicated, how much time the customer has to respond and which controls exist in the edition being bought. Treat the following as points to establish in the agreement and operating process, rather than rights every supplier already provides:

• Change visibility: which changes to data processing, model dependencies, permissions and feature behaviour trigger a notice, and where it is delivered.
• Assessment time: whether the customer can test the changed feature before it affects production, and what happens if testing identifies a material regression.
• Control: who can disable the relevant feature, restrict its scope or prevent automatic activation, without unnecessarily stopping the underlying service.
• Evidence: what logs, configuration information and investigation support are available when an output or action is challenged.
• Exit: how business records, configurations and required evidence can be recovered if the approved use can no longer continue.

Some suppliers will not disclose every model identifier or offer a veto over model replacement. In that case, decide whether outcome testing and feature controls provide enough assurance for the proposed use. If the business depends on a capability that cannot be tested or disabled within its risk tolerance, record that as a purchasing constraint, not an issue for a future administrator to solve.

Model retirement turns governance into a delivery obligation

Anthropic’s model deprecation policy says requests to retired models fail and that customers with active deployments receive at least 60 days’ notice before retirement of publicly released models. It also distinguishes partner-operated platforms, which set their own retirement schedules. Procurement should establish whose schedule and notification route apply to the service being purchased.

Consider a hypothetical supplier that replaces the model behind an approved classification feature. The replacement may be more capable overall while handling an important local exception differently. The business owner needs representative acceptance cases; the technical owner needs a test environment or controlled rollout; procurement needs an escalation route if the supplier’s timetable leaves insufficient time. Those responsibilities should be agreed while the purchase is being negotiated.

Budget for reassessment as operating work. A contract that obliges a supplier to notify you still leaves your organisation responsible for reading the notice, testing the change and making the decision. Assign cover when the named owner leaves, and revisit the process at renewal.

An RFP built around outcomes and acceptance tests can establish the starting standard. Before approving the AI feature, make the next step a feature-specific review of provider data controls, with those findings carried into the agreement and the change process. That is how procurement keeps an approval meaningful after the first release.