Decide who owns the decision before you choose the tool
Procurement is the easy part. The hard part is naming the person whose judgement the model is meant to sharpen.
Most AI programmes begin with a question about tooling. Which platform, which model, build or buy. It is a reasonable place to start, because it is the part of the problem that has vendors attached to it, and vendors are good at making themselves easy to talk to.
It is also the wrong place to start, and the cost of starting there does not show up for two or three quarters.
What a model actually does
Strip away the language and a deployed model does one thing: it changes the information available at the moment a decision is made. It might make a recommendation, surface an exception, draft a first version, or rank a queue. In every case the value is realised at the point where a person or a process acts differently than they would have.
That is the whole mechanism. Which means the first question is not "what can we build" but "which decision are we trying to make better, and who makes it today".
Ask that in a room of senior people and you will often find three answers, none of which agree. The decision is made in a committee that meets monthly. Or it is made by whoever the request lands with. Or it was delegated three years ago to a team that has since been reorganised, and the delegation was never revisited. This is not dysfunction. It is what happens to any decision that nobody has had a reason to look at closely.
A model deployed into that is not an improvement. It is a fourth opinion.
The four things an owner has to hold
Naming an owner sounds like an org-chart exercise. It is not. The owner has to be able to answer four questions, and if they cannot, the ownership is nominal.
What is the decision, stated as a choice between options? Not "improve pricing" but "for this quote, do we hold, discount, or decline". A decision you cannot state as a choice is a topic, and a model cannot improve a topic.
What information is authoritative? When two systems disagree about a customer's contract terms, which one wins? Teams that cannot answer this end up building consensus logic into the model, which is a way of encoding an unresolved argument in a place nobody can see it.
What happens when the answer arrives? Does it flow into a workflow, or into someone's inbox? Does it have an SLA? Is anyone allowed to overrule it, and is that recorded? An answer that arrives with no route into action is a report, and organisations already have enough reports.
What is the owner accountable for afterwards? If the decision gets better, which line in the operating plan moves? If nobody can name it, the benefit will be argued about rather than booked, and the programme will be defended on activity rather than result.
Why this has to come first
There is a practical reason for the sequence, beyond tidiness.
Every one of those four answers constrains the technical choice. Authoritative data determines what has to be integrated and what can be left alone. The route into action determines latency, and latency determines architecture far more than model selection does. The override rule determines what you have to log, which determines a good deal of the governance work. The accountable line determines what you have to measure, and therefore what you have to instrument before go-live rather than after.
Start with the platform and you will make all of those choices anyway — by default, invisibly, in the order the implementation happens to require them. Then you will discover the constraints during delivery, when changing them is expensive.
What this looks like in practice
The work is not long. For a given candidate use case it is usually a few days: a conversation with the person closest to the decision, a look at where the data actually lives rather than where the architecture diagram says it lives, and a short written statement of the four answers that the accountable executive signs.
The output is a page. It is not impressive to look at. But it is the thing that lets you say, in month nine, exactly what changed and what it was worth — and that is the conversation that determines whether there is a second wave.
The uncomfortable version
Sometimes this exercise ends the use case. The decision turns out to be made well enough already, or the data that would improve it does not exist, or the route into action would require a change nobody is willing to sponsor.
That is a good outcome, delivered early and cheaply. The alternative is finding out the same thing after a platform commitment, a delivery team and eighteen months.
The programmes that scale are not the ones that picked the best model. They are the ones that knew, before they built anything, whose judgement they were trying to improve and what would move if they succeeded.
All insights