Should you build, buy, or partner for enterprise AI?

Build, buy and partner are choices for each AI layer

Enterprise AI should be built, bought and partnered one layer at a time, with every layer assigned an owner and an exit cost. A whole-system choice hides the terms that determine whether the buyer can change course after signing.

A buyer can purchase a source model, commission a partner to build the workflow, retain control of the data and user experience, and operate the service internally. That is not indecision. It is a deliberate allocation of responsibility.

The contract should make that allocation visible across the source model, data, workflow, integration, evaluation, experience and operations. For each layer, establish who decides, who maintains it, what the supplier must prove, what the buyer receives, and what it takes to transfer it.

The constraint map turns a slogan into contract terms

“Build versus buy versus partner” is useful only after the capability has been separated into parts that can be owned and moved independently. The map below is a procurement artifact, not an architecture diagram. It gives the person signing the contract a way to test whether a supplier’s offer leaves the organisation able to operate, change or replace the service.

The buyer does not need to own every layer. A supplier may own reusable components or managed operations where that is commercially sensible. The point is to avoid implied ownership.

Data and intellectual property require separate clauses. Government guidance instructs buyers to retain ownership of intellectual property in their products and services, while separately retaining ownership of and access to data held by third parties. Those are different assets, and a clause covering one does not automatically cover the other. ¹

For example, a supplier can give the buyer an export of application data while retaining the evaluation set, labeling rubric and workflow configuration that make the export useful. The buyer has technically received its data but cannot demonstrate equivalent performance with a replacement provider. The evaluation layer exposes that gap before it becomes an exit negotiation.

Whole-system contracts trade coordination for control

An all-build arrangement concentrates responsibility with the buyer. It can suit a layer that changes frequently, carries distinctive business rules, or must remain under direct organisational control. The buyer then needs internal capability to maintain that layer through upgrades, incidents and retirement.

An all-buy arrangement concentrates responsibility with the supplier. It can reduce the number of commercial relationships the buyer manages. It also makes the supplier’s contract, transition duties and access commitments more consequential, because the supplier controls more of the path from daily operation to replacement.

A partner arrangement can place delivery responsibility with a specialist while preserving buyer ownership of selected assets. Picture a specialist retained to build a document-intake workflow: the arrangement only holds up if the contract requires that specialist to hand the buyer's own engineers an evaluation pack they can rerun themselves, not a reassurance during the sales process that transition will be smooth.

Splitting layers across suppliers also has a cost. The buyer becomes responsible for deciding which party resolves failures that cross an integration, workflow and operations boundary. A constraint map does not make that coordination free, but it makes the cost explicit enough to compare against the cost of accepting a more concentrated supplier relationship.

The full cost is not the licence, statement of work or initial build quote. Purchasing guidance says the cost horizon includes building or buying, upgrading, continuous improvement planning and retirement. ² The map gives procurement a place to record those costs as obligations rather than leaving them in a business case that expires at go-live.

Commercial lock-in is also a contract problem. Long, inflexible contracts can prevent an organisation changing its technology strategy when circumstances change. ¹ A low termination fee does not cure a contract that withholds data, documentation, access or transition support.

Turn each layer into an acceptance test before signing

Use the map during evaluation, not after selection. The following sequence converts it into a buying procedure.

1. Name the buyer owner for each layer. Ownership can mean decision authority, maintenance duty, intellectual property rights, data rights, or all of them. State which meaning applies. “The customer owns the solution” is not an answer.

2. Ask the supplier for the transfer package now. Require the actual export specification, operating runbooks, interface inventory, evaluation pack, change record and training material. Scottish procurement guidance says buyers should require access to everything the organisation will need to maintain the service itself. ³

3. Run one transition-oriented acceptance test. Ask the supplier to demonstrate a bounded change, such as swapping the source model for an alternative and rerunning the evaluation pack against a recent batch of cases, or moving the workflow layer to a buyer-controlled environment. The result should show what is transferred, what remains supplier-operated, which assumptions fail, and who performs the work.

4. Price the exit work by layer. Record supplier transition services, buyer staff time, temporary parallel running, data validation, replacement integration and retraining. Update that record at material changes, because exit cost grows as dependencies accumulate. Guidance recommends monitoring commitments early where switching costs could become disproportionate as development continues. ¹

5. Make transition performance a continuing obligation. The supplier should continue providing the service at the agreed level through the transition period. ³ The contract should also state which party owns supplier-produced work and who transfers it. ³

A bad answer sounds polished but cannot be tested: “Our platform keeps everything in one place,” “you can export your data,” or “we will support transition if needed.” Ask what data, which configuration, what documentation, whose staff, under what deadline, and with what continuing service obligation.

The supplier’s evidence should be proportionate to the layer it controls. What proof should an AI engineering partner provide? explains the evidence to request. Can another team operate what your AI vendor built? addresses the operational test that determines whether a handover is real.

The map does not remove technical lock-in or regulatory duties

A contract can preserve commercial exit rights without creating the skills needed to exercise them. The availability of skills and knowledge is a common cause of technical lock-in. ¹ A transition pack is therefore necessary, but it is insufficient if nobody on the buyer’s side can interpret, run and change what was transferred.

The map also does not decide whether a system is high-risk under the EU AI Act. That classification must be assessed for the intended use. For high-risk systems, deployers must take appropriate technical and organisational measures to use the system according to its instructions for use. ⁴

A buyer can also cross from deployer to provider status by substantially modifying a high-risk system that remains high-risk. ⁴ Provider obligations include maintaining a quality management system compliant with Article 17. ⁴ The source-model, workflow and evaluation rows should therefore identify who approves material changes and who carries the resulting obligations.

The map will not eliminate integration cost or make a multi-supplier arrangement cheaper. It gives the buyer a way to decide which dependencies are worth owning, which can be delegated, and what evidence proves that the arrangement can be changed without discovering its real cost during exit.