AI Procurement and the Cost of Choosing One Ecosystem

The AI proposal arrives with a familiar commercial argument. We already use the supplier. The product fits into our existing software. There is a discount if we commit now, and another vendor would mean another review, another contract and another implementation.

Those are legitimate considerations. An integrated product can be easier to deploy and better value. Procurement should give those benefits proper weight.

The difficulty comes when convenience becomes the whole evaluation. A decision about one useful feature can gradually determine which other products the business can afford to use, which providers can reach its information, and where the next round of spending must go.

For Australian in-house Legal and Procurement teams, the practical question is whether the organisation is deliberately choosing that dependence, with the costs understood, or acquiring it one approval at a time.

Why this deserves attention now

On 16 October 2026, the UK's Competition and Markets Authority proposed designating Microsoft as having strategic market status in its business software ecosystem. Its proposed areas for further investigation include software bundling and whether customers can choose competing AI tools effectively. CMA announcement.

The distinction matters: this is a proposed designation, not a final decision or a finding that a particular AI purchase is unlawful. As at 25 October 2026, consultation remains open, with a final decision due by 13 February 2027. This is a UK process, not a new Australian procurement obligation. CMA consultation.

Australia has its own relevant warning. When releasing its final Digital Platform Services Inquiry report on 23 June 2025, the ACCC identified potential competition risks where cloud providers bundle, tie or favour their own generative AI products. It also noted that AI developers and deployers generally require significant cloud computing resources. ACCC release.

These developments give procurement teams a reason to examine how an offer affects future purchasing choices. The following approach is a practical evaluation framework, rather than a statement of regulatory requirements.

Start with the layers behind the supplier name

A shortlist of three vendors can look competitive while leaving important dependencies unchanged.

For example, imagine three hypothetical document-analysis products. They have different interfaces, support teams and prices, but all depend on the same external model service. Choosing two could diversify application support without diversifying that model dependency.

That does not make the shortlist useless. Different providers can add genuine value around the same underlying technology. It means the evaluation should identify what is different rather than counting logos.

Ask each shortlisted vendor for a short description of:

• The organisation providing and supporting the application.
• The model providers used for the proposed service.
• The infrastructure dependencies relevant to delivering it.
• Any separate platform, licence or marketplace relationship the customer must maintain.
• Which of those arrangements the customer can choose, and which the vendor controls.

The CMA's earlier foundation-model work identified concerns across critical inputs, routes to market and partnerships, while recognising that partnerships can also support competition. A supplier relationship should be assessed on its actual effect, rather than treated as a problem simply because it exists. CMA foundation-model review.

Keep the mapping proportionate. Procurement needs enough detail to understand purchasing constraints. It does not need to reconstruct every subcontracting relationship.

Also be precise about the risk. Sharing a cloud provider does not, by itself, prove that two products have identical outage exposure. Commercial dependence, operational resilience and application quality are separate questions requiring different evidence.

Define the job before buying the ecosystem

“We need an AI platform” is a difficult requirement to compete fairly.

It allows one supplier to demonstrate a broad suite while another demonstrates a specialist product. The organisation then compares feature lists without agreeing which work matters most.

Start with a small number of priority outcomes. For a procurement team, that might be preparing a first-pass comparison of supplier proposals. For Legal, it might be identifying departures from an approved clause position.

Describe the current process, the people involved, the information required and the acceptable output. Include the administrative work around the task, such as assigning access and getting the result into the existing approval process.

Then ask suppliers to show how their proposed configuration handles the same work.

A broad platform can still win. It should win because its breadth delivers useful value, rather than because the evaluation quietly expanded to include everything it happens to sell.

Keep future ambitions separate. Record attractive additional capabilities as options, with their own costs and implementation assumptions. Avoid turning an untested possibility into a reason for an organisation-wide commitment.

Price the bundle honestly

The phrase “already included” can end a discussion before anyone examines the numbers.

Sometimes the commercial conclusion is straightforward. The organisation already holds a licence, the AI feature requires no additional payment, and the feature meets the requirement. Using it may be the sensible decision.

Sometimes access requires a higher tier, a larger minimum commitment or an extension of the wider agreement. Those costs belong in the comparison, even if the AI line item is presented as discounted.

Ask for three configurations where commercially available:

1. The existing service without the proposed AI expansion.
2. The supplier's preferred bundled configuration.
3. The existing service alongside a separately purchased AI product.

Compare the actual incremental cash cost over the same period. Include implementation, administration, required licences and realistic usage charges. Identify existing commitments that cannot be reduced during that period, rather than pretending they disappear when an alternative is selected.

For example, assume an alternative costs A$40,000 a year and a bundle upgrade costs A$25,000 on the same tax basis. The alternative is not cheaper merely because its standalone functionality scores better. The additional A$15,000 needs a business justification. Equally, the upgrade is not an A$25,000 decision if obtaining it also requires additional seats or an extended minimum commitment.

Use low, expected and high adoption scenarios. A per-user product and a consumption-based product can change places as the better-value option when usage changes.

The CMA's October roadmap records customer perceptions that bundled products can feel already paid for, while also recognising that customers see value in bundles. Both observations deserve consideration in a purchasing decision. CMA roadmap, section 3.

The aim is a fair comparison of value, including convenience, without letting the structure of the quote make the decision for you.

Test whether products can work together today

“We integrate with your existing systems” needs a more useful follow-up than a tick in the questionnaire.

Ask the vendor to demonstrate the specific combination the business wants to use. That might be a specialist AI application working with the organisation's document system and identity controls while the existing productivity suite stays in place.

Use approved test material, not live confidential documents supplied casually during a sales demonstration.

Check practical details:

• Which information can the product access in the proposed configuration?
• Does it respect the access restrictions the organisation already applies?
• Can users complete the workflow without repeatedly exporting, uploading or re-entering information?
• Are required connectors included, separately licensed or subject to usage limits?
• Who supports the connection when something changes?

A product that connects technically may still create enough manual work to make the combined solution unattractive. That friction should be recorded as a cost, not dismissed because the architecture diagram shows a line between two boxes.

The CMA's October roadmap proposes examining whether rival AI tools can integrate with, work alongside and be accessed from Microsoft's ecosystem. It also records Microsoft's position that third-party providers can obtain substantially the same organisational-data access through available APIs. Those positions remain matters for investigation. CMA roadmap, paragraphs 1.11 and 4.16.

For a buyer, a demonstration of the actual configuration is more useful than adopting either side's general claim.

Keep the commitment aligned with the evidence

An organisation may have enough evidence to approve one team and one use case. That does not automatically support a three-year commitment across every business unit.

Match the commercial commitment to what has actually been established.

For an early deployment, consider a defined user group, a bounded usage commitment and expansion options with transparent pricing. A supplier may charge more for flexibility. That is a trade-off to assess, rather than a reason to leave the cost of commitment unexamined.

Look closely at how spending arrangements influence the next purchase:

• Does using a different provider reduce a discount on unrelated services?
• Must credits be consumed within a narrow period or product family?
• Is the minimum based on named users, active users or consumption?
• Can additional teams join on the agreed rates without extending every existing service?
• Does a pilot purchase count towards a larger commitment, and on what terms?

Get the answers reflected in the commercial documents. A presentation about flexibility will not resolve an order form that ties several services together.

Where a supplier will not offer the preferred structure, record the consequence plainly. The decision-maker may accept it because the product is sufficiently valuable. What matters is that the dependence is visible when the commitment is approved.

Give purchasing choice a place in the scorecard

If the scorecard measures only functionality and headline price, the evaluation will struggle to explain why dependence matters.

Add a small number of evidence-based criteria alongside the ordinary security, legal, operational and performance requirements:

1. Ability to buy the required scope without unnecessary adjacent services.
2. Ability to operate with other approved products in the intended workflow.
3. Clarity of pricing as adoption and consumption change.
4. Visibility of significant underlying supplier dependencies.
5. Flexibility to allocate future spending without disproportionate commercial consequences.

Agree their importance before the demonstrations. Otherwise, an evaluation can look reverse-engineered to justify whichever supplier a stakeholder preferred at the beginning.

Avoid giving an automatic high score to a small supplier or an automatic low score to an incumbent. A smaller vendor may have substantial dependencies of its own. An established provider may offer a strong combination of service quality, workable integrations and competitive terms.

Require a short explanation and supporting evidence for each material score. “Open platform” and “strategic partner” are descriptions, not findings.

Accept concentration when the reasons are good

Buying from several suppliers creates work of its own. Someone must administer access, manage the contracts, support users and reconcile the different commercial arrangements. A second subscription that nobody uses adds cost without creating meaningful choice.

The evaluation should therefore explain where concentration is acceptable and where a separate option would earn its place.

Imagine a business selecting one integrated product for routine internal work, while retaining a specialist application for a small team with materially different requirements. That can be a sensible outcome. So can selecting the integrated product for both groups if it meets their needs and the combined offer remains good value.

The important distinction is whether the specialist requirement was examined properly. “Everyone else is using it” does not explain whether it works for this team.

If concentration is accepted, record the reason, the scope and the trigger for reconsidering it. A material change in pricing, required licences or supported integrations might justify another assessment. This keeps the decision tied to observable conditions rather than a permanent label such as “preferred ecosystem”.

There is no need to manufacture vendor diversity for its own sake. Preserve room for a different decision where the business case supports one.

Make one person responsible for the combined picture

Separate business units can make reasonable decisions that create an unreasonable overall concentration.

Legal buys one application. Finance expands an existing suite. Procurement commits to a marketplace spending target. Each approval looks manageable, but together they may narrow the organisation's next set of choices.

Assign an owner to bring those commitments together before a material AI expansion. Procurement can coordinate, with Finance checking the spending assumptions and IT checking technical dependencies.

Keep the approval summary short: what is being bought, why this configuration is preferred, what other spending it constrains, and which assumptions need to remain true for it to represent good value.

Revisit that summary when the scope materially expands. A successful pilot should inform the next decision, without becoming permanent permission to buy every adjacent product.

For the next AI purchase, start with the business job, request genuinely comparable offers and make the cost of dependence explicit. If you are also evaluating your contracting approach, you can book a demo with Contract Cloud.

Sources

1. Competition and Markets Authority, CMA takes first steps to ensure choice in business software, 16 October 2026.
2. Competition and Markets Authority, Proposed decision: SMS investigation into Microsoft's business software ecosystem, 16 October 2026.
3. Australian Competition and Consumer Commission, Regulatory reform in digital platform markets is needed to improve competition and consumer outcomes, 23 June 2025.
4. Competition and Markets Authority, CMA outlines growing concerns in markets for AI Foundation Models, 11 April 2024.
5. Competition and Markets Authority, Roadmap of possible interventions, 16 October 2026, particularly section 3 and paragraphs 1.11 and 4.16.