Enterprise software. Thoughtful delivery.
Perspective

Bring AI review into the buying process

Procurement is a useful point to ask who owns an AI use case, what data it needs and how its outputs will be used.

Most organisations write an AI policy some months after their staff started using AI. The policy describes a situation that has already moved on, and it is enforced, if at all, by asking people to read it. There is a better lever, and it is one every organisation already operates: procurement.

Adoption does not wait for permission.

By the time a governance conversation is scheduled, people are drafting with assistants, summarising documents, and pasting things into tools they chose themselves. Some of those tools are free, which means nobody purchased them, which means no review happened. A policy written as though adoption has not started is answering last year's question.

The first useful act is not a policy. It is an inventory: what is being used, by whom, on what data, and to do what. It is usually uncomfortable and always more than expected.

Buying is where the leverage is.

Almost every meaningful AI capability arrives attached to something being bought or renewed: a new application with an assistant in it, a module added to a platform you already run, a contract coming up for renewal with new terms about model training. Those moments already have a process, a form and somebody whose job it is to ask questions.

Adding a small number of AI questions to that process reaches more of the organisation than a policy document ever will, because it is enforced by the purchase not being completed rather than by goodwill.

Five questions worth adding.

What data does this feature see, and does that include personal data or anything commercially sensitive? Is our data used to train a model that other customers benefit from, and can that be switched off in writing? Where is the processing done, and does that satisfy the obligations we already carry? Can the feature be disabled per user or per tenant, and by whom? And what does the vendor log, so that we can answer a question about a decision six months later?

None of those requires an AI specialist to ask. All of them are the kind of thing procurement already asks about hosting and data residency, extended by a sentence.

Classify on the effect, not on the tool.

The distinction that matters is not which vendor built it. It is what the output touches. Summarising a public document is not the same as ranking job applicants, setting a price, or deciding who gets contacted first. The first needs a light touch. The others need a person accountable for the decision, a record of what the system suggested, and a route for somebody affected to ask why.

A classification with two or three grades, written in plain language, gets applied. A taxonomy with eleven categories and a decision tree does not.

Advisory is a design property, not a promise.

It is common to be told that a feature is advisory and that a human always decides. That is worth very little as a sentence in a brochure and quite a lot as an architectural constraint. The useful question is what the system is capable of doing on its own: can it move a record, send a message, or change a status without a person confirming? If it can, the assurance depends on configuration that somebody may change.

Ask for the answer in the contract or in the documentation rather than in a meeting.

Make saying yes fast, or people will route around it.

A governance process that takes six weeks produces shadow adoption, and shadow adoption is the outcome the process existed to prevent. A registration route that takes days, with a light path for low-risk uses and a real review for the ones that touch people, keeps the inventory current because using it is easier than hiding.

Put a review date on every approval. Capabilities change under the same product name, and an assessment from eighteen months ago describes software that no longer exists.

The point is not caution.

None of this is an argument for going slowly. It is an argument for the decisions being made by people who can see what is being decided, at the moment when changing the answer is still cheap. That moment is the purchase, and it is already on somebody's desk.

What would a better working day look like?

Bring us the process you want to improve. We’ll explore the product, technology and delivery work it needs.