Enterprise AI Procurement: 5 Ways Traditional ICT Procurement Falls Short

Enterprise AI procurement differs from traditional ICT procurement in ways that standard procurement frameworks are not designed to surface. This guide identifies five structural differences and explores what procurement teams may consider adjusting.

The procurement team runs a process it has run before. Requirements are gathered. Vendors are shortlisted. An RFP goes out. Responses are scored. A contract is signed. The process is familiar. The templates are proven. The scoring model has worked for every major technology platform the organisation has ever bought.

Twelve months later, the problems that surface are ones the process was never designed to catch. The model the organisation evaluated has been deprecated. The cost profile has shifted in ways the budget model did not anticipate. The governance requirements that seemed like an afterthought during vendor selection are now consuming executive attention. The integration with internal systems that appeared straightforward in the vendor demo turns out to carry data handling implications nobody flagged.

None of these are necessarily vendor failures. They are often procurement process failures. Specifically, they are the result of applying a procurement framework designed for deterministic, stable software to a category that is neither deterministic nor stable.

This article is written for procurement professionals, IT leaders, and business decision-makers in Australian organisations who are sourcing enterprise AI platforms and want to understand where the traditional ICT procurement playbook may fall short, and what may warrant a different approach.

1. The Product Changes After You Buy It

Traditional ICT procurement assumes a stable product. An organisation evaluates a software platform, confirms it meets defined requirements, signs a contract, and deploys. The platform that was evaluated is the platform that is deployed. Updates are incremental. Major version changes are infrequent and usually backward-compatible.

Enterprise AI does not work this way.

The underlying models that power enterprise AI platforms are updated, retrained, and deprecated by the vendor as a matter of course. In 2025 and 2026, major providers have released new model generations at a pace that makes traditional software versioning look glacial. Each new model generation can change output quality, response behaviour, and cost profile in ways that are material to the organisation's operations.

This means the platform an organisation evaluated during procurement is often not the platform it is running six or twelve months later. A vendor may upgrade the default model tier, deprecate the model that was tested during the pilot, or change how the model handles specific task types. These changes often do not involve the organisation's approval in most standard contracts. They are covered under the vendor's general right to update the service.

The procurement implication is specific. Evaluation is not a point-in-time exercise. Some enterprise AI contracts in the market address model stability windows, notification periods before material model changes, version pinning availability, and staging environment access for testing updates before they reach production. Others do not. These are not standard SaaS contract provisions. They are specific to enterprise AI, and the terms available vary significantly by vendor and tier.

Organisations that treat the vendor evaluation as a one-off assessment, rather than the beginning of an ongoing model governance relationship, are the ones most often caught off guard when the product they bought quietly becomes a different product.

For a detailed treatment of how model governance provisions vary across enterprise AI contracts, see the guide to enterprise AI contract terms.

2. You Cannot Write a Fixed Specification

In traditional ICT procurement, the RFP defines requirements and vendors respond with how they meet them. The evaluation is a matching exercise: does the vendor's product do what the specification says the organisation needs?

Enterprise AI breaks this pattern because its outputs are probabilistic. The same prompt, given to the same model, can produce different results depending on context, model version, data grounding, and configuration. There is no fixed output to specify. Performance is not binary. A vendor's platform does not simply "meet" a summarisation requirement or "fail" a document generation requirement. It performs across a range, and that range varies by use case, data quality, and how the system is configured.

This has two consequences for procurement teams.

First, traditional RFP scoring matrices do not capture what matters. A vendor can answer "yes" to every functional requirement in an RFP and still deliver a platform that underperforms in the organisation's actual operating context. The disconnect is not dishonesty. It is that enterprise AI capability is context-dependent in ways that a requirements table cannot express.

Second, some organisations address this by including live testing against their own use cases, with their own data, in conditions that approximate real operating environments. Vendor demonstrations, reference architectures, and capability statements alone often prove insufficient. A pilot or proof of concept can serve as a more reliable evaluation method for testing how the platform performs in the organisation's specific context.

Procurement teams accustomed to scoring vendors on paper may consider adjusting their evaluation methodology to include structured pilots with defined success criteria. The criteria may also account for the probabilistic nature of AI output: acceptable accuracy ranges, consistency thresholds, and failure-mode definitions rather than binary pass/fail requirements.

The enterprise AI vendor evaluation scorecard provides a framework for structuring this kind of assessment.

3. The Cost Model Is Not Static

Per-seat pricing looks familiar to procurement teams. It follows the same structure as most SaaS agreements: a defined number of users, a per-user-per-month fee, an annual commitment. The budget model writes itself.

Except that in enterprise AI, the per-seat price is often not the total cost, and the total cost is often not stable.

Enterprise AI cost structures in 2026 are shifting. Major vendors are moving toward hybrid pricing models that combine a seat fee with consumption-based charges. As vendors release more capable models with better reasoning, longer context windows, and multimodal capabilities, the compute cost of running those models increases. Hybrid pricing passes that increase through to the customer. An organisation that budgets based on a per-seat quote may find that actual spend increases as users adopt newer capabilities or as the vendor upgrades default model tiers.

Beyond consumption, the total cost of ownership for enterprise AI includes cost categories that do not exist in traditional ICT procurement: data preparation and ongoing data quality maintenance, integration with internal systems, governance infrastructure, change management and training, and the operational overhead of monitoring AI output quality across the organisation.

For organisations that choose to build on AI APIs rather than buy a packaged platform, the cost model is even less familiar. Token-based API pricing is variable by design. Costs scale with usage volume, prompt length, response complexity, and model tier. Without careful modelling, organisations that build custom AI applications frequently discover that production-scale token consumption exceeds development-stage projections by a significant margin.

In either case, the procurement discipline required is different from traditional ICT procurement. Budget certainty does not come from the licence price. In many enterprise AI deployments, it is driven by consumption modelling, active usage monitoring, and commercial structuring that accounts for variable cost components. None of these are standard practice in traditional software procurement.

The enterprise AI pricing and total cost of ownership framework covers these cost structures in detail, including how to model and contain them.

4. Data Sovereignty and PII Exposure Require Procurement-Stage Decisions

In traditional ICT procurement, data handling is typically addressed through standard contractual clauses covering data storage location, backup, and breach notification. These are important but well-understood provisions that most procurement teams handle routinely.

Enterprise AI introduces data handling risks that are structurally different.

When data enters an enterprise AI platform, it is not simply stored and retrieved. It is processed by the model to generate outputs. Depending on the vendor's configuration and contract terms, that data may be retained beyond the session, used for model improvement, or processed in jurisdictions outside Australia. The default position in many vendor contracts is either opt-in for training use or silent on the question entirely.

For Australian organisations, this creates specific exposure. The Australian Privacy Principles govern how organisations handle personal information, including how it is disclosed to overseas recipients. Enterprise AI platforms frequently process data through infrastructure located in multiple jurisdictions. Where that processing involves personally identifiable information, the organisation's privacy risk does not reduce simply because the data was processed by a third-party AI system. Organisations may wish to seek advice on how their privacy obligations apply when data is processed through AI platforms operating across multiple jurisdictions.

The procurement-stage decisions that matter are specific.

Training exclusions. Some enterprise AI contracts include explicit exclusions stating that the organisation's data will not be used for model training, benchmarking, or any purpose beyond delivering the contracted service. Others default to opt-in or are silent on the question. An opt-out that asks the organisation to locate and activate a setting is not the same as a contractual exclusion.

Data residency. Where data is processed and where it is stored are not always the same thing. Some vendors store data in one jurisdiction but process it through models running in another. Residency provisions in enterprise AI contracts vary in whether they address processing location separately from storage location. For organisations with privacy obligations that may affect offshore data handling, this distinction can be material.

Sub-processor transparency. Enterprise AI vendors frequently use third-party infrastructure providers in delivering their service. The identity and jurisdiction of those sub-processors affect the organisation's risk profile. This is a procurement-stage question, not a post-deployment discovery.

Data retention and deletion. What happens to input and output data after the interaction concludes? How long is it retained? Can the organisation enforce deletion? At contract termination, what are the timelines and mechanisms for data retrieval and removal?

These are not peripheral compliance considerations. They are typically among the procurement-stage questions that determine whether the organisation can operate the platform within its existing risk and regulatory framework. In practice, these questions are often harder to resolve after a contract is signed than before.

Organisations operating in regulated sectors, or handling significant volumes of personal information, may wish to seek legal advice on how their specific privacy obligations interact with the data handling practices of any AI platform being evaluated.

5. Vendor Lock-in Is Deeper, and Offboarding Is Harder

Traditional software lock-in is primarily a data portability question. If you can export your data in a usable format, switching vendors is an operational project with a known scope.

Enterprise AI lock-in operates at multiple levels simultaneously, and several of them are invisible during procurement.

Workflow embedding. Enterprise AI does not sit alongside existing processes. It changes how work gets done. Teams redesign workflows around the platform's specific capabilities. Over time, the platform becomes load-bearing infrastructure. Replacing it means redesigning the workflows it enabled, not just migrating the data it stores.

Prompt and configuration investment. Organisations that have spent months developing prompt libraries, custom instructions, governance configurations, and system prompts have made investments that do not transfer between platforms. These are operational assets embedded in a specific vendor's environment. Rebuilding them elsewhere is a material effort that most exit cost models do not account for.

Agent and automation dependency. In 2026, enterprise AI platforms are increasingly offering agentic capabilities: AI-driven workflows that take multi-step actions, interact with connected systems, make decisions within defined parameters, and execute tasks with limited human intervention. Organisations deploying agentic AI are building automation layers that are deeply coupled to the vendor's orchestration framework, tool integrations, and agent configuration model. These integrations often connect the AI platform to core business systems including CRM, ERP, HRIS, finance, and document management platforms. The coupling is not superficial. Agent configurations define how the AI interacts with these systems, what permissions it holds, what data it accesses, and what actions it is authorised to take. Migrating agentic workflows to a new vendor does not mean reconfiguring a few settings. It means redesigning the automation architecture, rebuilding the integration layer, re-establishing permissions, and retesting every workflow end to end. For organisations that have embedded agentic AI into operational processes, the exit cost is closer to a systems re-implementation than a software migration.

Interfacing systems and integration complexity. The deeper an AI platform is integrated with internal systems, the more significant the switching cost becomes. Enterprise AI platforms in 2026 connect to an organisation's data layer through APIs, connectors, and custom integrations. These connections are not standardised across vendors. An integration built for one platform's connector framework does not transfer to another. The cost of rebuilding these integrations, re-certifying data flows, and re-validating security configurations is often underestimated during procurement because the integration work has not yet been done.

Offboarding complexity. Exiting an enterprise AI vendor is not the reverse of onboarding. It typically involves data extraction in usable formats, decommissioning integrations without disrupting dependent systems, managing the transition period where both old and new platforms run in parallel, retraining users on a new interface and workflow, and rebuilding governance and monitoring infrastructure for the replacement platform. For organisations with agentic deployments, the offboarding scope extends to dismantling automation workflows that may be processing hundreds or thousands of actions per day across multiple connected systems. The operational risk during transition is significant, and the timeline is typically longer than organisations anticipate.

The build vs buy dimension. The enterprise AI build vs buy decision directly affects lock-in exposure. Organisations that buy a packaged platform accept vendor dependency in exchange for faster deployment and reduced engineering burden. Organisations that build on APIs gain portability (the ability to switch underlying model providers) but create lock-in at the application layer: the custom code, infrastructure, and operational processes built around a specific architecture. Neither path eliminates lock-in. Each shifts it to a different layer.

The procurement implication is that lock-in exposure is largely determined before the contract is signed, not when the organisation decides to leave. Enterprise AI contracts vary in how they address data portability, configuration export, termination assistance, and transition support periods. So does the depth of platform embedding, which directly affects what exit would actually cost.

For a detailed breakdown of how exit costs accumulate in enterprise AI contracts, see the guide to enterprise AI vendor lock-in and exit costs.

What This Means for the Procurement Function

The five differences outlined above are not edge cases. They are structural features of enterprise AI that can affect most procurement processes, regardless of the vendor, the platform, or the use case.

The common thread is that enterprise AI procurement often involves decisions earlier in the process, about things that traditional ICT procurement does not typically surface. Data sovereignty is a procurement-stage question, not a legal afterthought. Cost modelling extends beyond the licence price into consumption, integration, and ongoing operational overhead. Lock-in analysis may consider workflow embedding, agent automation, and integration complexity, not just data portability. And evaluation may benefit from live testing, because the product being procured does not behave the way traditional software does.

Organisations that recognise these differences and adjust their procurement approach accordingly are not adding complexity for its own sake. They are avoiding the specific, predictable failure patterns that emerge when a procurement framework designed for one category of technology is applied to a fundamentally different one.

The procurement function is not expected to become an AI function. But it may benefit from understanding where the assumptions that served it well in traditional ICT procurement no longer hold, and from building a process that accounts for the differences.

For a comprehensive treatment of the enterprise AI procurement process, including the seven structural fault lines that most commonly determine success or failure, see the definitive guide to enterprise AI procurement in Australia.

This article provides general commercial and procurement commentary only and does not constitute legal, financial, or professional advice.