AI Tool Procurement vs Traditional Software Procurement

A procurement process for enterprise resource planning software or a project management platform will take a purchaser part of the way through an AI purchase before starting to struggle. The typical steps remain in place: define the need, compare vendors, verify security, reach agreement. What differs is what each step must cover, due to the variance in how AI tools operate, the differences in cost and the risk factors not addressed by traditional software reviews.

This comparison highlights where the two processes intersect and where AI purchasing requires extra attention, to allow a company to adapt an existing approach rather than building a parallel system that will be ignored.

What Stays the Same

Many elements of good procurement are agnostic as to the technology being bought. There is still a defined business need, an owner for the purchase, a budget and criteria agreed for vendors to present to. References, contracts and the ability to deliver ongoing support after the sale should still be checked.

If a company has an existing disciplined approach to software buying, this should remain the framework upon which additional requirements are layered, in order to identify where AI-specific checks are needed.

Predictability

Traditional software is deterministic in its operation. The same input will produce the same output every time it is tested, and a payroll tool will either correctly calculate a deduction or it will not. AI tools, particularly those built around generative models, are often probabilistic; the same prompt may produce subtly varied results, and quality may vary with the phrasing if a request or the nature of the data.

This alters how features should be tested. A demonstration is no longer sufficient, since the tool is at its best when presented with ideal prompts. A vendor should be asked to work through a meaningful amount of the purchaser's data, including the awkward items, to establish what accuracy is acceptable for the task, and whether any errors on a particular type of prompt are tolerable. The same tool producing internal emails for a meeting note can be permitted to occasionally miss an edge case, but should not show the same weakness when generating customer-facing legal language.

Testing and Evaluation

Conventional software testing is concerned with whether a particular feature performs as specified. Testing AI tools is concerned with assessing how well they operate on a given task, and how consistent their output is. This can be seen in the request for a structured pilot with sample data, specific success measures and judges who understand the domain well enough to pick up on subtleties in the output.

It also requires ongoing evaluation, since models may be updated by the vendor and behaviour can change without any direct action by the purchaser. Questions should be raised as to how the vendor communicates model changes, and whether it is possible to fix on a certain version of a model. Where a traditional release note might clearly show what has changed, an AI product's changes may be less obvious.

Data Handling

Every software purchase involves some element of data risk, but the issues specific to AI tools demand closer examination. The data a purchaser feeds into a tool may be passed on to a third party model provider, held for a period and potentially reviewed by humans for quality assurance or used to refine the vendor's models, depending on the vendor and the plan selected.

None of these are inherently unacceptable, but each requires a written confirmation from the vendor. Vendors should be asked where data is processed, which subprocessors are used, whether the purchaser can opt out of training use and how data is deleted at the end of a contract. Particular attention should be paid if staff will be prompted to paste confidential documents or customer information into the tool, since this can introduce exposure at the user level that will not be apparent from a feature list.

Which regulations apply will depend on the industry and the type of data, so a legal or compliance review of the vendor's answers is preferable to a general assurance of compliance.

Pricing

Traditional software is often priced on a per-seat or per-module basis, and costs are predictable. AI tools introduce usage-based billing, with costs rising according to the volume of text processed, the number of calls made or other factors. Adoption by a wider audience may push costs up sharply, and a pilot running with ten users will give little indication of the spend when rolling the tool out to five hundred.

Estimates should be requested from each vendor for spending at pilot and full scale, and any opportunities to cap or monitor use should be explored. Extra charges should be scrutinised, such as fees for using a premium model or for extra storage. If a tool is being bought for a US-based team to see how regional variations in pricing and availability are represented, the page Buy AI Software in the US shows what kind of detail should be requested from any vendor.

Vendor Landscape

The traditional software market contains many established vendors with long histories. The AI market contains a mixture of larger players and younger companies, some of which are built on top of another company's model. A tool bought today may rely on a model provider that changes its terms, or the vendor itself may be acquired or shut down.

These dependencies should be investigated. Vendors should be asked what models underpin their product and what the implications are if they change providers, and what options are open if the company is sold. Data export rights and notice periods are more significant when the product category is still evolving.

Sourcing methods are also different. AI tools can be found in marketplaces and directories, as well as direct outreach from vendors. A review of the Top 10 AI Tools Marketplaces provides an overview of how many platforms exist and how they structure their listings, which is useful contextual information when considering a purchase. A listing is only a starting point, and the same due diligence should be applied regardless of how a tool reaches a shortlist.

Contracts

Traditional contracts for software focus on uptime, support and the scope of the license. AI contracts require additional attention to whether outputs belong to the purchaser, whether the vendor can use the data, limitations of liability for incorrect output and responsibilities around IP claims. Terms in this area are still emerging, and vendors can vary significantly, so the contract should be examined closely and counsel should be brought in for large purchases.

Responsibility also changes within the purchaser organisation. Conventional IT tools often have a review owned by the IT function, but AI tools should see security, legal, compliance and business users working together from the start, due to the variety of risks involved.

Ongoing Governance

Once a traditional application has been deployed, it often exists in the background. AI tools require continued monitoring of output quality, review of usage, and instruction for employees about what can be entered. A register of AI tools used in the organisation, including owners, cost, data and renewal dates, should be kept and reviewed periodically. If a tool stops delivering value, having a comparison such as these Exomatter Alternatives can make evaluating a move much simpler.

A practical first step is to take a current software procurement checklist and add four items: output testing on the purchaser's data, data training and retention terms, estimates of usage-based cost and notification of model change. This will cover most of the difference between the two processes.