TLDR
- Choose an AI sourcing route by deciding which rights the organisation must exercise under surprise, then place ownership, contracts, architecture and operating capability around those rights.
- The supplier then retires the version on which their returns system was evaluated.
- Retailer A has prompts embedded in a proprietary workflow, no replayable test set and no contractual transition period.
- Retailer B stores decision policy separately, logs inputs and outcomes, and can route the same bounded task to another model.
- Board papers often frame AI sourcing as four mutually exclusive doors: build, buy, partner or adopt open source.
Build, Buy, Partner or Open Source: A Strategy of Control
Choose an AI sourcing route by deciding which rights the organisation must exercise under surprise, then place ownership, contracts, architecture and operating capability around those rights.
Two retailers license the same high-performing model. Both negotiate a favourable first-year price. The supplier then retires the version on which their returns system was evaluated. Retailer A has prompts embedded in a proprietary workflow, no replayable test set and no contractual transition period. Retailer B stores decision policy separately, logs inputs and outcomes, and can route the same bounded task to another model. Both bought. Only one retained practical control.
Board papers often frame AI sourcing as four mutually exclusive doors: build, buy, partner or adopt open source. That makes the choice look like a comparison of products and project costs. It is more consequential. Contracts cannot specify every future model change, security incident, regulatory interpretation, workload spike or strategic adaptation. The organisation is therefore choosing who may decide when an unspecified event arrives, who bears the cost of acting, and whether an alternative remains credible.
Choose the governance route that places each material control right with the party best able and motivated to exercise it, while preserving a tested exit from rights that should not become captive. This changes the executive question. Instead of asking whether a model should be owned, ask which future decisions would become dangerous, expensive or strategically impossible if another party controlled them. Then judge whether ownership, contract, alliance, open artefacts or architecture can place those decisions correctly.
This is not a plea to build more. Internal ownership can create delay, technical debt and false confidence. Nor is it an argument that open models are inherently safer or cheaper. It is a strategy of selective control. The aim is to hold only the rights that carry strategic consequence, and to make every claimed right exercisable in operation.
Part IWhat does control mean when the contract runs out?
Ronald Coase explained firm boundaries by comparing the costs of market exchange with internal organisation. Oliver Williamson later sharpened the governance problem around asset specificity, uncertainty and frequency. Property-rights theory adds a useful insight for AI: ownership matters because it allocates residual rights of control over assets in states that an incomplete contract did not describe. None of these theories tells an executive to integrate every important activity. They ask where adaptation and bargaining will work with the least destructive friction.
AI increases the number of unspecified states. Model behaviour changes across versions. A supplier may alter a safety policy, price unit, region, context window, retention rule or supported interface. A regulator may place a new duty on the deployer. Domain knowledge may shift faster than the supplier’s release cycle. A new model may make an earlier architecture uneconomic. A security event may require immediate isolation. The glossy sourcing comparison usually prices the known workload and treats these changes as risks around the edge. In fact, they determine the value of control.
Seven rights that should not be collapsed into ownership
Substitution is the ability to replace a provider, model, runtime or integrator without reconstructing the whole decision system. Data control covers permitted use, location, access, lineage, retention, deletion and proof that deletion occurred. Adaptation means changing behaviour through policy, retrieval, tools, fine-tuning, orchestration or weights. Observation means seeing enough input, output, trace, cost and outcome evidence to evaluate the system. Recovery covers rollback, isolation, degraded service and human recourse. Capacity control covers latency, throughput, priority and exposure to price or hardware scarcity. Legal-use control covers licence scope, intellectual-property allocation, documentation and the ability to keep operating after a commercial relationship ends.
These rights come from different instruments. Asset ownership can support adaptation and recovery. A contract can establish deletion evidence, transition assistance and service priority. Modular architecture can make substitution credible. An evaluation set can protect observation when a model is opaque. A partnership can give both parties a voice over a jointly specific interface. An open licence can permit modification and redistribution. An operating team turns formal permission into usable control.
The distinction prevents two costly errors. The first is paper control: a contract promises portability, but data schemas, embeddings, fine-tunes and evaluation evidence cannot move within the business continuity window. The second is possession without capability: the organisation can download weights but cannot patch the runtime, reproduce training choices, investigate an incident or obtain enough accelerators to serve the workload. Formal rights matter, but strategy depends on rights that can be exercised.
Thought experiment one: the unlisted eighth event
Imagine a procurement team that writes a remarkably complete contract. It covers seven events: outage, data breach, material price rise, model retirement, acquisition of the supplier, regulatory change and failure to meet an accuracy threshold. For each event it assigns notice, remedy and liability. One month after launch, an eighth event occurs. A competitor discovers a new class of prompt injection that does not produce an outage or breach, but makes the service unsuitable for a small, high-value workflow. The supplier considers the remaining service compliant and schedules a fix for the next quarter. The buyer needs a change this week.
Who decides? The answer exposes the residual control structure. If the buyer can isolate the workflow, inspect traces, change routing and invoke a tested fallback, it retains operational control without owning the model. If it can only raise a ticket, the supplier controls adaptation despite a sophisticated contract. If the buyer owns code and weights but its only two serving engineers are unavailable, internal ownership does not produce a faster remedy. The unforeseen event, not the ordinary day, reveals the boundary.
This is why the control ledger should be written as decisions under surprise: “within four hours of a material integrity signal, who can see the evidence, stop the affected action, route a safe alternative and authorise recovery?” A noun such as “ownership” or “portability” hides that sequence. A tested verb makes it governable.
Part IIWhen does each route earn its burden?
Build when residual adaptation is specific and affordable
Build is justified when the system depends on organisation-specific assets, future adaptations cannot be contracted reliably, and internal control will materially improve those adaptations. The relevant asset may be a decision policy, proprietary outcome data, a simulation environment, a safety case or a deeply embedded workflow. It is rarely the frontier base model. Training a general-purpose model competes with specialised firms on data, compute and research talent. Building the domain layer can still be strategic when it changes quickly, carries private knowledge or determines a consequential action.
The burden is continuing, not one-off. Internal teams must operate the system, patch dependencies, evaluate model changes, manage security, retain skills and account for opportunity cost. A bespoke component that was differentiating in year one may become a commodity in year two. Build therefore needs a sunset test: if external alternatives meet the control requirements and the internal component no longer creates learning or bargaining leverage, can the organisation retire it?
Buy when outcomes can be specified and exit remains credible
Buy is efficient when several suppliers can meet a stable requirement, the service is not tightly coupled to a unique asset, performance can be measured, and switching costs remain proportionate. The organisation benefits from a vendor’s scale, release cadence and pooled expertise. Buying also concentrates accountability for a defined service. It should not be treated as a transfer of the deployer’s duties. NIST’s generative AI profile explicitly calls for risks in the value chain to be documented and for contingency processes around high-risk third-party systems.
A good purchase contract is joined to an exit architecture. It specifies data use and deletion, change notice, evaluation access, incident communication, service continuity, intellectual-property responsibilities and transition support. The architecture keeps prompts, policy, retrieval, identity, outcome records and business rules separable where the decision permits. The operating team actually rehearses substitution. Competition helps only when the buyer can move.
Partner when both sides bring indispensable complements
Partnership earns its complexity when value requires complementary assets that neither party can simply purchase from the other. A model provider may bring research and serving infrastructure; a manufacturer may bring equipment telemetry, engineering knowledge and field access. Both must invest in an interface whose value depends on the other. A simple supplier contract can invite underinvestment if each side fears that the other will renegotiate after the asset becomes specific. A partnership can create shared governance, staged commitments and reciprocal access.
Shared governance is not shared ambiguity. Decision rights, background and foreground intellectual property, data permissions, model-improvement use, publication, exclusivity, commercialisation, incident authority and dissolution must be explicit. Alliances also carry coordination and bargaining costs. If a deliverable can be specified and competed, a partnership may be an expensive label for procurement. If one party owns every scarce complement, “partnership” may conceal dependence.
Use open source for freedoms you can operate
The Open Source Initiative’s Open Source AI Definition distinguishes an open-source AI system from a release of weights alone. It centres the freedoms to use, study, modify and share, supported by access to the preferred form for making modifications. The distinction matters because “open” is often applied to models with use restrictions, undisclosed training information or missing code. The Linux Foundation’s Model Openness Framework likewise treats openness as a graded set of model artefacts, not a single availability flag.
Open artefacts can strengthen adaptation, audit, local hosting and supplier diversity. They can also move integration, security and lifecycle work to the adopter. CISA’s 2026 open-source security guidance notes that model files and weights can be manipulated, extending familiar software supply-chain concerns into AI artefacts. Provenance, integrity checks, safe serialisation, dependency management and patch ownership are therefore part of the route. Open source removes some permissions and bargaining constraints. It does not remove operating cost or risk.
A right becomes strategic only when it survives a drill
Portability has three levels. Contractual portability gives permission and obliges a supplier to assist. Architectural portability separates the assets needed to move, such as policy, data schemas, evaluation cases and interfaces. Rehearsed portability proves that an alternative can meet a defined minimum service inside the allowed time. The first level without the other two may improve a legal claim after failure but not continuity during it. The third level without the first can breach licence, confidentiality or data duties. Control needs all applicable levels.
The substitution drill should be small enough to repeat and hard enough to expose coupling. Freeze a representative input set, success threshold, latency bound and cost basis. Route it through the incumbent and a credible alternative. Count the assets that need translation: prompts, tool descriptions, policy rules, retrieval indexes, fine-tunes, safety filters, identity mappings and output parsers. Record which differences are acceptable and which change the decision. Do not demand identical outputs from probabilistic systems. Demand preserved outcome and authority boundaries.
A deletion drill traces a synthetic record through logs, caches, vector indexes, backups, model-improvement pipelines and support systems. The test is not whether a delete button exists. It is whether the organisation can identify every relevant copy, invoke the required action, obtain evidence and explain residual retention. Where a supplier cannot expose its internal path, the contract must define the attestation or audit evidence that substitutes for direct observation. If that evidence is inadequate for the use, the workload cannot proceed on trust alone.
A recovery drill begins with a disabled model route, corrupted retrieval source or unsafe output class. The team should detect the condition, restrict authority, move to a degraded mode, notify the right owner and restore service from a known state. Building or self-hosting usually increases the number of steps the internal team owns. Buying may shorten the technical recovery while lengthening dependence on supplier response. Partnership can improve shared diagnosis but requires one party to hold immediate stop authority. The valuable route is the one whose recovery chain fits the consequence clock.
Finally, run a cost shock. Reprice inference, storage, egress, human review and specialist labour under higher volume and one plausible supplier change. Include the cost of maintaining an unused fallback. A supposedly portable design can be irrational to switch, while an internal build can be captive to scarce accelerators and employees. Exit leverage is not free. Its premium is justified when the expected loss from captivity, including strategic delay and bargaining weakness, exceeds the cost of keeping the option alive.
These drills turn abstract governance into evidence. They also allow proportionality. A low-consequence drafting aid may need an annual replay through another service and a verified off switch. A safety-related edge system may require continuous integrity checks, dual-region capacity and regular human recovery exercises. The purpose is not maximal control. It is to know which claims remain true when the ordinary route is unavailable.
Part IIIHow does the choice change at different scales?
Worked example one: a small claims correspondence team
A thirty-person specialist insurer wants to draft routine correspondence from adjuster notes. The draft never determines coverage or payment. It contains personal data, must preserve approved wording and needs an audit trail. Volume is modest. Three reputable services meet the quality threshold, and the insurer has two application engineers but no model-serving team.
The first impulse is to self-host an open-weight model because the data is sensitive. That confuses one control right with the whole system. Local hosting may improve data-path control, but it creates patching, capacity, evaluation and recovery obligations that the team cannot yet discharge. Training a model internally is still less defensible. The task is not differentiating, the output is reviewed, and the requirement can be specified.
The selected route is buy with a portable control envelope. The insurer contracts for no training on its inputs, regional processing, defined retention, deletion evidence, change notice and incident cooperation. It keeps approved clauses and decision rules outside the model, stores a replayable synthetic evaluation set, and routes through a thin internal interface. The team tests a second provider quarterly. It can stop drafting without stopping claims. The buyer therefore accepts supplier control over base-model research while retaining data, observation, substitution and recovery rights relevant to the workflow.
Suppose annual volume doubles and the supplier raises price by 40 per cent. The fallback test shows that moving the bounded drafting function requires four engineer-days and no historical fine-tune. That result does not compel a move. It creates credible bargaining and prevents the price change from becoming an emergency. If the organisation later adds coverage recommendations, the control ledger must be rewritten because consequence, evidence and recourse have changed.
Worked example two: a global equipment-maintenance system
A multinational manufacturer wants to reduce unplanned stoppages across 180 plants. It has decades of maintenance records, several generations of sensors and deep engineering knowledge. An equipment supplier understands failure modes in its machines. A cloud provider has the streaming and model-serving estate. Local teams need low-latency recommendations during poor connectivity. A false alarm wastes labour; a missed critical failure can create safety and production loss.
No single route carries the whole problem. Buying a generic predictive-maintenance product underuses the manufacturer’s outcome data and decision policy. Building the full stack duplicates cloud and equipment expertise. Giving one equipment supplier exclusive control would make cross-fleet learning captive. Downloading an open model does not solve sensor semantics, field validation or action authority.
The defensible answer is layered. The manufacturer builds the asset registry, cross-fleet ontology, decision thresholds, outcome ledger and safety-authority layer because these encode its operations and compound learning. It partners with equipment suppliers on failure signatures and validation, with explicit rights to use derived learning across the fleet. It buys elastic training and non-critical managed services where interfaces are contestable. It uses open components for an edge inference runtime and selected models where licence, integrity and hardware tests pass. A common evaluation harness judges all routes.
The programme does not claim complete portability. Some optimisations will remain cloud-specific and some diagnostic knowledge supplier-specific. It prices those dependencies and sets break conditions. A cloud exit drill proves that the minimum safe service can run elsewhere within ninety days, not that the entire estate can move overnight. A partnership board governs new failure categories, but plant safety officers retain stop authority. The strategy places control where response time and accumulated learning make it valuable, while buying the scale whose internal replication would be wasteful.
Negative control: the commodity assistant
Consider an internal assistant that rewrites non-confidential meeting notes into a chosen tone. It makes no decision, stores no enduring knowledge, uses no customer data and can be disabled without interrupting work. Several products satisfy the requirement. A team proposes a self-hosted open model to avoid lock-in.
This is a negative control for the thesis. There is little asset specificity, low consequence and a cheap manual fallback. Model substitution and deletion still matter, but they can be covered by ordinary procurement and a small test. Building or self-hosting would create more obligations than control value. The appropriate answer is a short, non-exclusive purchase with no material integration. Not every dependency is strategic, and paying to eliminate a trivial dependency can itself be bad strategy.
Part IVWhat could overturn the control thesis?
The strongest rival explanation: capability and speed dominate governance
The strongest rival says that model markets move too quickly for property-rights reasoning to guide AI strategy. Superior capability, fast learning and access to scale determine outcomes. A firm that spends months allocating control rights may lose to one that buys the best available service, ships, observes users and switches later. Internal builds anchor the organisation to yesterday’s architecture. Partnerships slow change. Open models trail the frontier in some tasks. The winning strategy is therefore optionality through rapid adoption, not control through governance.
This explanation is sometimes right. When a task is separable, suppliers compete, interfaces are stable, data and evaluation assets are portable, consequences are bounded and manual recovery is cheap, market capability should dominate ownership. Buying the frontier can be the most reversible choice. The control thesis would be weakened if organisations with light contracts and simple abstraction consistently switch at low cost after material provider changes, while control-heavy peers move slower without better outcomes or resilience.
The rival does not eliminate the question. It changes which right matters. Rapid switching is itself a control right, supported by architecture, evidence and commercial alternatives. “Use the best model” is executable only if the organisation can identify best for its local decision, move the surrounding assets and absorb behavioural change. When those conditions hold, buy lightly. When they do not, speed at entry can create slowness at exit.
Thought experiment two: the open vault with no key-holder
A hospital receives an open-weight clinical language model, inference code and a commercially permissive licence at no charge. The artefacts sit in its repository. A proprietary supplier offers the same quality through a managed endpoint, with monitoring, security response, capacity and contractual support. Which route gives the hospital more control?
Now vary one fact. In the first world, the hospital has an experienced model-platform team, signed artefact provenance, a validated deployment recipe, accelerators in two regions, a clinical evaluation harness and an on-call rota. In the second, it has one data scientist, no secure serving environment and no ability to patch a critical runtime vulnerability within a week. The licence and weights are identical. Effective control is not.
In the second world, the managed endpoint may provide more reliable recovery and observation, even though it grants less modification authority. The hospital should not call that dependence harmless. It should contract and test the rights it needs. Nor should it call the repository strategic sovereignty. The thought experiment separates permission from competence. Open source expands the feasible set; organisational capability determines whether those freedoms become control.
The explicit failure boundary
The method fails if the decision boundary is drawn around “AI” as one object. A deployed system contains models, data, identity, policies, tools, interfaces, infrastructure, human authority and outcome evidence. They have different markets and failure times. One route for the whole stack either over-integrates commodity layers or outsources strategic ones.
It also fails when a claimed right cannot be tested. A vendor may promise deletion without providing evidence; an open licence may not cover required data; a fallback model may fail latency or safety thresholds; an internal team may own code without staffing recovery. Treat each unexercised right as an assumption, not an asset. Where law, public safety or national-security obligations impose a particular control structure, this commercial instrument cannot override them.
Do not use the method to justify frontier-model training without an independent economic and technical case. Residual control over an asset has value only if the organisation can create and operate that asset at acceptable cost. Do not use it to claim that modularity eliminates lock-in. Performance tuning, fine-tunes, proprietary safety behaviour and cloud-specific services can make components inseparable. The honest objective is bounded dependence with known break conditions, not a fantasy of zero dependence.
Finally, ordinal control scores cannot settle questions of legality, safety, fairness, labour impact or financial return. Those require domain evidence and authorised review. The instrument below chooses a governance hypothesis for the next test. It does not approve a system for use.
Decision instrumentThe Control Rights Allocation Test
This instrument produces a route for the next bounded commitment: buy, build the differentiating layer, partner around complements, operate verified open artefacts, or use a staged hybrid. Score one system layer and one decision horizon at a time. The result should be tested against real contract terms, artefacts, staffing and failure exercises.
Control Rights Allocation Test
Use observed evidence where possible. “High” means the factor changes the strategic outcome, not merely that stakeholders care about it.
Assumptions, test cases, implications and limits
- Assumptions: scores refer to one separable system layer and one horizon; a control right is credited only if it can be exercised; internal capability includes security, evaluation and recovery; and open artefacts have been inspected rather than inferred from branding.
- Positive test: a compounding organisation-specific decision layer faces frequent adaptation, material consequence and weak supplier exit; the organisation has proven lifecycle capability. It should return “build the differentiating layer”, while still permitting purchased models beneath it.
- Negative test: a commodity writing aid has low consequence and specificity, several tested suppliers, no mutual complement and high value from rapid access. It should return “buy with a light exit envelope”.
- Implications: build permits a bounded internal investment; partner permits negotiation of joint governance before asset-specific spend; open-source self-host permits a deployment trial only after provenance and recovery tests; hybrid requires a written boundary for each route.
- Limits: the result does not establish legality, safety, fairness, technical performance, net present value or model suitability. Ordinal scores can be gamed. Independent domain, security, procurement and financial review remains necessary.
How to use the result without turning it into a label
Buy with a light exit envelope means specify the service, isolate it from strategic assets, preserve data and evaluation evidence, and rehearse substitution in proportion to consequence. Build the differentiating layer means retain the residual decisions and learning that make the layer specific. It does not mean train a foundation model. Partner around complements means no party should make irreversible specific investment before reciprocal rights, contributions and dissolution are governed.
Operate verified open artefacts means inspect licence, provenance, integrity, documentation, runtime, security and staffing before claiming autonomy. Staged hybrid is not permission for uncontrolled complexity. It requires a layer map that says what is bought, built, shared and open, who responds when an interface fails, and which minimum service survives exit.
Record the scores, evidence and dissent. Run the deletion, substitution, recovery and cost-shock tests before the commitment becomes difficult to reverse. Repeat the allocation when model economics, regulation, internal skills or strategic specificity changes. A sound route can become unsound without any component failing technically.
References and source notes
- Coase, R. H. (1937). The Nature of the Firm. Economica, 4(16), 386–405.
- Williamson, O. E. (2002). The Theory of the Firm as Governance Structure: From Choice to Contract. Journal of Economic Perspectives, 16(3), 171–195.
- Grossman, S. J., & Hart, O. D. (1986). The Costs and Benefits of Ownership: A Theory of Vertical and Lateral Integration. Journal of Political Economy, 94(4), 691–719.
- Geyskens, I., Steenkamp, J.-B. E. M., & Kumar, N. (2006). Make, Buy, or Ally: A Transaction Cost Theory Meta-Analysis. Academy of Management Journal, 49(3), 519–543.
- Dyer, J. H., & Singh, H. (1998). The Relational View: Cooperative Strategy and Sources of Interorganizational Competitive Advantage. Academy of Management Review, 23(4), 660–679.
- West, J. (2003). How Open Is Open Enough? Melding Proprietary and Open Source Platform Strategies. Research Policy, 32(7), 1259–1285.
- National Institute of Standards and Technology. (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0).
- Autio, C. et al. (2024). Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1.
- US Federal Trade Commission. (2025). AI Partnerships & Investments 6(b) Staff Report. The report documents control, consultation, exclusivity and cloud-spend provisions in major AI partnerships.
- Open Source Initiative. (2024). The Open Source AI Definition, version 1.0.
- Center for Research on Foundation Models. (2025). The 2025 Foundation Model Transparency Index. The index evaluates disclosures rather than proving model safety or quality.
- European Commission. (2026). Guidelines for providers of general-purpose AI models. GPAI provider duties applied from 2 August 2025, with Commission enforcement powers applying from 2 August 2026.
- European Commission. (2026). Data Act. The Act has applied since 12 September 2025 and includes measures concerning switching between data-processing services.
- Cybersecurity and Infrastructure Security Agency. (2026). Open Source Software: Security Principles and Practices. Includes software and AI model artefact supply-chain considerations.
ConclusionHold the rights that change the future
Build, buy, partner and open source are not identities. They are ways of allocating decisions that a complete specification cannot settle in advance. The strategic work is to identify those residual decisions, value them against their burden, and place them with a party that has the incentive and competence to act.
Ownership can support adaptation but cannot manufacture expertise. A contract can create duties but cannot make a technically captive system portable. A partnership can mobilise complementary assets but can also hide asymmetric dependence. An open licence can grant meaningful freedoms while leaving the adopter responsible for provenance, security, infrastructure and recovery. Each route is useful when its control mechanism fits the layer.
The practical answer is often deliberately mixed. Buy rapidly changing commodity capability. Build the decision policy, evidence and unique learning that compound. Partner where both sides must invest in specific complements. Operate open artefacts where modification or local execution matters and the organisation can carry the lifecycle. Keep human authority and recovery explicit wherever consequence demands it.
The final decision is not which door to enter. It is which rights would be ruinous to discover missing during an incident, renewal or strategic change. Name those rights as actions, exercise them before commitment, and accept dependence everywhere else only with known economics and a credible break condition. That is the difference between choosing a supplier and designing control.