Buying and running AI

Where an organisation configures a tool centrally, including who has access, what is retained and which controls are enforced.

How far a tool has actually been taken up in daily work, as opposed to how many people were given access to it.

A small central team that sets standards and supports AI work across an organisation, rather than owning every project itself.

What an AI investment returns against what it costs, counted honestly enough to include the time spent adopting and maintaining it.

The set of AI tools an organisation actually runs together, chosen to cover its work rather than bought as one vendor's suite.

An organisation's stated plan for where AI is worth using and where it is not, which mostly earns its keep by ruling things out.

One specific job you intend AI to do, defined narrowly enough that you could tell whether it worked.

The written argument for spending on something, setting out the cost, the expected return and what has to be true for it to hold.

The plan for keeping essential work running when a system is unavailable, which for a tool people now depend on daily means having a defined fallback.

The choice between paying for a finished tool and assembling your own, usually decided by whether the capability is core to you.

The person in a team who takes a tool up first and brings others with them, usually worth more to adoption than training does.

The work of getting people to actually use a new tool, which is where most of the difference between a successful and a failed rollout sits.

The tier where a vendor's data handling, security and support terms usually change, which is why it is compared separately from features.

An outside firm engaged to set a tool up and make it work in your context, common where a product is capable but not self-explanatory.

A company that runs other people's models as a service, competing on price, speed and which models it carries rather than on the models themselves.

Paying someone else to run a system for you on an ongoing basis, rather than buying the software and operating it yourself.

The company that trains and owns a model, as distinct from the many products that resell access to it.

A limited live trial with real users and real work, the step where most of what a proof of concept missed shows up.

The gap between a promising trial and something the organisation runs, where a large share of AI projects quietly stop.

The formal process of getting a purchase approved, which for AI tools often takes longer than the evaluation that preceded it.

An AI system people depend on for real work, which brings expectations about reliability, support and cost that a trial never faces.

The paid setup, configuration and training a vendor sells alongside its product, often a material share of first-year cost.

A small build to test whether an idea works at all, deliberately short of production quality and often mistaken for it.

Taking a tool from a working pilot to everyone who should have it, which is a communication and training job more than a technical one.

Buying through conversations with a vendor's sales team, which is how enterprise terms, security review and custom pricing are reached.

One named person's access under a plan, the unit most software is still sold in and the one AI pricing is moving away from.

Buying and starting on your own with a card, without talking to anyone, which suits small teams and rarely fits regulated work.

Staff using AI tools the organisation has not approved, usually with good intentions, and the reason many first policies get written.

The document defining what an engagement will deliver, by when and for how much, and the thing to fix in detail before work starts.

A firm whose business is connecting products that were not designed to work together, usually engaged for larger or older estates.

How long it takes before a tool is genuinely paying back, the measure that separates a quick win from a long programme.

Everything a tool costs over its life, including setup, training, integration and the staff time to run it, not only the licence.

A limited window to evaluate a tool in real conditions, worth planning as a test with criteria rather than treating as free access.

How hard it would be to move off a tool later, worth weighing while switching is still cheap rather than when it is not.