Sourcing and Third-Party Management

Why it exists

Most organisations that adopt AI do not build it; they buy it. Let that fact decide where you concentrate your effort. When you buy an AI solution instead of building it, you are not only outsourcing the work — you are handing another company control over the parts of the system that matter most: the model itself, the data it learned from, how often it changes, and the ways it can go wrong. You will not see inside any of them. Treat the choice of whether to buy at all, and of which supplier, as governance decisions in their own right, not as a procurement formality to be settled by whoever moves first.

Decide whether you will build or buy before you speak to any supplier, because that decision does more than choose a vendor: it fixes what you are responsible for. If you buy a finished AI service and use it as delivered, you are a consumer, and your obligations are mainly about choosing and overseeing the provider. If you take someone else’s model and integrate, configure, or connect it into your own systems, you are a deployer, and you become responsible for how it behaves in your context. If you train a model, or adapt one substantially to your own data — the activity usually called fine-tuning — you are a developer, and you carry the full weight of building AI, including responsibility for the training data and for the model’s behaviour. Write down which of the three you are. Teams slide from buying into fine-tuning without noticing they have become developers, and at that moment every safeguard that assumed they were only a buyer quietly stops applying.

Your existing supplier checks were written for ordinary software and will not protect you here. They ask whether the vendor is financially stable, holds security certifications, and will sign an acceptable contract. None of that tells you whether the provider is quietly using your data to improve its model, where your data is actually processed at the moment the model answers, or whether the provider can replace the model overnight and change how it behaves. Those are the questions that decide your real exposure. Ask them before you sign, not after an incident forces you to.

Weigh six things before you decide to build or buy

No single factor settles the decision; the balance among these six does, and they often pull against each other. Work through all six and record where they land.

• Count the total cost of ownership, not the headline price. The comparison is not a licence fee against a salary. Buying carries recurring running costs, the cost of the safety checks and monitoring you must place around a system whose inside you cannot see, and the eventual cost of leaving. Building carries the far larger and less visible costs of gathering and cleaning data, hiring scarce specialists, running the infrastructure, and — the part most build decisions forget — keeping the model working long after launch, because a model must be retrained as the world it was built for changes. A plan to build that looks cheap per use usually stops looking cheap once these are counted.
• Be honest about whether you have the data, the skills, and the time to build. Building is only a real option if you already hold data of good enough quality and quantity, employ the specialists who can turn it into a model, and can wait for that investment to pay back. Most organisations overestimate all three. An honest answer often removes building from the table — which is a good outcome, because it stops an organisation without the means from taking on the heavy obligations of a model builder it cannot meet.
• Compare the regulatory exposure of each path, because it is not the same. Buying can inherit the provider’s compliance position: reassuring if the provider is well run, dangerous if its data practices or the sources it trained on are unclear or disputed. Building makes you directly answerable for the lawfulness of your training data, the defensibility of your model’s decisions, and the completeness of your own evidence to a regulator. The easier path to engineer is frequently the harder path to defend. Weigh both, not just the one you find easier.
• Check that the choice fits how your organisation actually runs. A model you build but have no team to operate, or a service you buy but cannot connect to your existing controls and identity systems, is the wrong choice whatever it costs. Judge the decision against how your organisation works today, not against an ideal future state you may never reach.
• Compare the privacy exposure of each path. Buying usually means sending data — including, unless you prevent it, personal and confidential data — to an outside party whose retention and reuse of that data you must limit by contract and by technical means. Building keeps the data inside, but gathers a large and sensitive store in one place and creates its own duties around lawful use, keeping only what you need, and deleting on request. ‘Internal is safer’ is not the answer; assess both exposures on their merits.
• Price the vendor lock-in and the cost of leaving. Building your operation around a single AI provider is cheap to start and expensive to escape: your prompts, your adaptations, your testing, and your staff’s know-how all gather around one provider’s model until moving away becomes impractical. Some organisations are already required to plan for this. Financial firms subject to the European Union’s digital operational-resilience regime (DORA), for instance, must keep a documented exit strategy and an exit clause for their critical technology providers, precisely so that the failure or withdrawal of one supplier cannot strand them. Even where no law compels you, adopt the same discipline whenever an AI capability comes from a single provider: agree, before you commit, how you would move away and what that would cost. A lock-in accepted without pricing the exit is a liability the board owns, not the team that signed the contract.

Know what your chosen path obliges you to do

Once the decision is made, the path you chose imposes a fixed set of guarantees. These are not preferences to weigh; they are the minimum you must secure.

• If you buy, secure these before go-live. Confirm the provider will not use your data to improve its model unless you explicitly allow it. Establish, and accept, where your data is processed when the model runs. Obtain a contractual right to be warned before the model changes. Establish how you would get your data and settings back out, and what leaving would cost. Confirm who owns whatever the service produces for you and on what terms you may use it. And put the provider under ongoing oversight for as long as you depend on the service.
• If you build or substantially adapt a model, your own team must secure these. Confirm the data you train on is lawful to use and its origin is documented. Ensure you can explain and defend the decisions the model makes. Confirm you have the people and the budget to run and maintain the model after launch, not merely to build it — the cost that is most often underestimated. And accept, in full, the security and testing duties that fall on anyone who builds AI (set out in the Technical Security domain).

Assess the provider before you buy — put the questions in writing

Do not rely on the provider’s sales material or on a generic security form. Assess the governance, security, and data handling of the product you are about to acquire, and do it by putting specific questions to the provider in writing and recording the answers. Ask, at a minimum, whether they train on your data, where your data is processed, whether and how they will warn you of a model change, how they test the model against attack, and how you would leave. The example below shows the shape such a questionnaire can take; treat an evasive or missing answer as a finding in its own right, not as a box left blank.

An example AI supplier due-diligence questionnaire. Issue it to any provider of an AI product, model, or service before onboarding, and keep the responses on file.

Put the model-change warning in the contract, and do not let it be dropped

A provider can replace the model behind the same connection without telling you, changing how it answers while nothing in your own systems has changed — reopening a weakness you had closed, or breaking a check you had validated. Require, in writing, that the provider warn you in advance of any replacement or material change to the underlying model, so that the change becomes an event you can prepare for and re-check, rather than a surprise your users discover for you.

Bring free models and marketplace agents inside the same checks

A model you download at no cost, or an autonomous ‘agent’ you obtain from an online marketplace, is still a supplier — with an origin, a licence, and an integrity you cannot take for granted — even though no salesperson was ever involved. Before you use one, establish where it came from, what its licence permits you to do, and that it has not been tampered with. Do not let the absence of a contract place it outside your supplier governance.

• If you use AI exactly as delivered, own its settings. A service you did not build still has settings that decide what happens to your data and when the model underneath it changes. Set them deliberately, and keep watching the provider’s notices: for a consumer, that is where most of the control actually lies.

Controls

Evidence

The recorded data settings per service and the log of provider change notices; Build-versus-buy decision records showing the chosen role; completed due-diligence questionnaires; contracts and data-processing terms including the model-change and exit clauses; provider risk assessments; supplier-monitoring records.