Buying AI

Which kind of AI are you buying?

"AI" on a product sheet covers three different machines. Predictive machine learning learns from your history to score and forecast: arrears risk, fraud, demand, churn. Generative AI, the main subject of this course, produces text and media: answers, drafts, summaries. And a great deal of what ships under the label is neither: rules and optimisation, exact, auditable logic for eligibility, pricing, and scheduling. A real product is almost always a blend of all three behind one interface, and the course has already shown the poles: Wrenholme's arrears model is predictive; Harwick's assistant is generative; both lean on rules for anything that must be exact.

The kinds fail differently, so they are checked and bought differently. Predictive components need their outcomes measured across the groups they affect (Module 5 taught why) and monitoring for model drift, the quiet decay of a model as the world moves away from the history it learned. Generative components need the gates and groundedness of Module 4. Rules need testing once and auditing forever, and they remain the right home for anything where the same input must always produce the same answer. Ask a supplier to decompose their product by kind; a good one can do it instantly, and the layers below show why you should ask.

Layers: G · Generative P · Predictive R · Rules Dataflow

Generative tissue

The letter writer produces text, so it can produce fluent wrongness. It needs the input and output gates, groundedness against the claim facts, and the drafting-only autonomy of Module 4. Supplier questions four to seven apply here.

Predictive tissue

Intake and the fraud scorer learned from history, so they inherit history's habits and decay as the world moves. Ask for outcomes measured across the groups the decisions affect, and for drift monitoring with alerting, not assurance.

Rules skeleton

The policy engine is deliberately not AI: the same claim must always produce the same decision, auditable line by line. Exact work belongs here, and a supplier who proposes generative AI for it has confused the fashion with the job.

Data supply

Every component feeds on Module 3's foundations: the form, the claims history, the policy tables. Residency, permissions, and the no-training clause apply to each flow, not to "the product" in general.

Where should the model run?

Three arrangements, not two. Buying access means calling a supplier's service and paying per use: the frontier on tap, no infrastructure, and your data passing through someone else's estate under a contract. Renting dedicated capacity means choosing an open-weights model, one whose weights are published for anyone to download, and having a platform run it for you on compute reserved for your use in a region you name. Running models yourself means those same open weights on infrastructure your own people administer: complete authority over where data goes and when behaviour changes, paid for in hardware, scarce engineers, and a capability tier that trails the frontier.

Most discussions skip the middle arrangement. A team told that confidential work means racking hardware and hiring a platform group will conclude the whole idea is beyond them, and hand the work back to whichever service they were trying to avoid. Rented capacity removes the hardware and most of the group. The model runs in a named region on machines reserved for you rather than shared, and the platform keeps those machines running. What you take on is the model choice, the evaluation, and the bill for capacity you have reserved whether or not you use it.

The honest default for most organisations is still access, because the operational cost of running anything is routinely underestimated and the frontier is only sold as a service. Open weights, rented or racked, make sense in three situations:

• Data that may not leave your estate under any contract.
• Volumes so large and steady that the arithmetic beats per-use pricing.
• Tasks a trailing model demonstrably passes, proven by your own evaluation rather than hope.

Many organisations land on a mixture: confidential or high-volume work on weights they chose, frontier judgement bought as a service.

Holding the weights has a consequence beyond where the data sits. Any habit you train onto a model you hold stays available for as long as you keep the files, while the same work done against a supplier's hosted model ends when that supplier retires it. Module 1 covers when training a habit is worth doing at all, which is less often than suppliers suggest.

Plenty of organisations find this question half-answered before they ask it. An estate standardised on one cloud, with an assistant licence already bundled into the productivity suite, has a path of least resistance running straight through that supplier. Often that path is defensible: the contract exists, the residency question is settled, and the identity system already knows who may see what. The part worth holding on to is that it remains a decision rather than a given. The same cloud will usually rent you dedicated capacity for open weights as well, so the supplier you have already chosen and the arrangement you run a model under are separate questions.

Text description of this diagram

A decision flowchart. Start: you need model capability. First question: may the data leave your estate, with the right contract in place? If no, run open-weights models on compute reserved for you, either rented from a platform or running on your own hardware. If yes: does the task need the frontier? If yes, buy access, because the frontier is only sold as a service. If no: are volumes large and steady enough to beat per-use pricing? If yes, open weights can cost less, rented or self-run, and the sums deserve redoing yearly as prices fall. Otherwise, buy access using the smallest model tier that passes your evaluation.

Will the supplier train on your data?

The question behind most board hesitation, and it has a clean answer: this is settled by contract, not by trust. Reputable enterprise agreements now exclude training on customer data by default; consumer and free tiers frequently do the opposite, which is why the same product name can carry two entirely different answers. The rule is to ask explicitly, receive it in writing, and check the scope: prompts, uploaded documents, retrieved passages, and outputs all count as your data. Anything a supplier may train on can surface, in some form, for someone else. This is also the sharpest argument against shadow use from Module 5: staff pasting client material into free tools answer this question by accident, in the wrong direction.

Where does your data live, and whose law applies?

Data residency is where your data is stored and processed geographically, and whose courts and regulators can reach it there. For UK organisations the practical questions are few: can the supplier commit to UK or European processing, which jurisdictions could compel access, and does anything, including support access and model-improvement telemetry, quietly route elsewhere. The architecture from Module 3 makes the conversation concrete: residency applies to the corpus, the vector store, the logs, and the prompts, and a supplier should answer for each, not for "the service" in general.

What does it really cost?

Rate cards understate. The visible price, per user or per token, sits on top of the costs this course has already taught: the checking overhead of Module 4, retries from the regeneration loop, the evaluation discipline of Module 5, the data work of Module 3 that no supplier can do for you, and the people who own all of it. A worked estimate at your volumes, with those overheads itemised, is a reasonable demand of any serious supplier, and declining to provide one is information too.

Text description of this diagram

The diagram shows costs stacked either side of a dashed line. Above the line, marked "what the invoice shows", sits one amber block: the rate card, per user and per token. Below the line, marked "what the budget carries", sit four larger blocks: checking overhead (the two gates, retries, and regeneration from Module 4), evaluation and monitoring (the golden question set run on a schedule, Module 5), data readiness (definitions, pipelines, and ownership, Module 3), and people (owners, gate-tuners, approvers, reviewers). A closing note observes that the below-the-line costs stay with you whichever supplier wins, which is why a cheap rate card settles less than it seems to.

How do you avoid lock-in?

Lock-in in AI is quieter than in most software, because the switching cost hides in accumulated tuning: prompts written for one model's habits, thresholds calibrated to one supplier's checks, workflows shaped around one interface. The defence is knowing which assets are portable and keeping them so. Your corpus, your golden question set, your prompt library, and your audit history belong to you and move with you; re-embedding a corpus for a new supplier is the routine build step Module 2 described, not a migration project. The evaluation habit is also the exit enabler: an organisation that can measure quality against its own questions can compare suppliers in a week. One that cannot is loyal by default.

Text description of this diagram

The diagram shows two columns. The left, marked "yours, moves with you", holds four highlighted blocks: corpus and documents (re-embedding is routine), the prompt library (versioned, in your control), the golden question set (which compares suppliers in a week), and audit history (exported in open formats). The right, marked "theirs, stays behind", holds four dashed blocks: their models, their infrastructure, their checking stack, and their interface. The closing note: keep the left column portable and the right column is replaceable.

The ten questions to ask any AI supplier

The course, compressed into a procurement meeting. Open each question for why it matters and what a good answer sounds like; a supplier comfortable with all ten is rare and belongs on the shortlist. Questions one to three and ten apply to any AI purchase whatever the kind; four to seven assume generative components. For predictive components, swap in two of their own: show me outcomes across the groups this affects, and show me how you monitor drift.

1. 1 Will our data be used to train your models?

   Why it matters. The single most consequential clause in the contract. Anything used for training can surface, in some form, for other customers.

   A good answer sounds like. A contractual no by default, in writing, covering prompts, documents, and outputs alike.

2. 2 Where is our data stored and processed, and under whose law?

   Why it matters. Residency decides which regulators and legal powers reach your data, and your own obligations may require a specific answer.

   A good answer sounds like. Named regions you can choose, and a straight answer on which jurisdictions can compel access.

3. 3 What leaves with us when we leave?

   Why it matters. The corpus, the prompts, the evaluation results, and the audit logs are yours in principle; exit is where principle meets format.

   A good answer sounds like. Export in open formats, a defined exit period, and certified deletion afterwards.

4. 4 Which models sit underneath, and can we choose the tier per task?

   Why it matters. Module 1 taught the tiering discipline; a supplier that hides the model choice hides the biggest cost and capability lever.

   A good answer sounds like. Named model tiers, a route to smaller models for routine work, and no silent substitution.

5. 5 What happens when you upgrade the model underneath us?

   Why it matters. Behaviour shifts on upgrade. Without notice and a test window, your users discover the change before you do.

   A good answer sounds like. Advance notice, a parallel test period, and the ability to pin a version while you evaluate.

6. 6 What checking runs on inputs and outputs, and can we see the numbers?

   Why it matters. Module 4 taught the two gates. A supplier who cannot describe theirs does not have them.

   A good answer sounds like. A description matching the two-gate shape, plus visibility of refusal and override rates.

7. 7 How do we evaluate quality before go-live and after every change?

   Why it matters. Vendor benchmarks measure the vendor’s questions. Only your golden question set measures yours.

   A good answer sounds like. Support for running your own question set, and acceptance criteria written into the contract.

8. 8 What will it cost at our volumes, including the checking and the retries?

   Why it matters. Per-seat and per-token prices understate reality: defensive checking, regeneration, and evaluation all consume budget.

   A good answer sounds like. A worked estimate at your volumes with the overheads itemised, not a rate card.

9. 9 Does retrieval respect our permissions, per user and per query?

   Why it matters. Module 2’s warning made concrete: an assistant that ignores access control is a data breach with a chat interface.

   A good answer sounds like. Permission-aware retrieval demonstrated, not promised, against your identity system.

10. 10 When it goes wrong, what does the audit trail show and who acts?

    Why it matters. Module 5’s question, pointed at the supplier: incidents will happen, and the contract decides whether you can investigate them.

    A good answer sounds like. Complete logs you can access, defined incident duties, and a named route into their team.

When should you walk away?

• The answer to training on your data is vague. "We take privacy seriously" is not a clause. If the written answer needs a follow-up meeting, the real answer is unwelcome.
• The demonstration cannot run on your questions. A supplier who insists on their own script is showing you their golden question set instead of letting you apply yours.
• Exit is an afterthought. No export formats, no deletion commitment, no exit period: the price of leaving is being set while you watch, before you have even signed.
• The urgency is theirs, not yours. Expiring discounts and quarter-end pressure are pipeline management. The architecture this course describes rewards the buyer who evaluates at their own pace.

End of the course. Six modules, one argument: know what the machine is, ground it in your documents, stand it on data you trust, bound what it may do, own the whole, and buy with your eyes open. Return to the course overview.