Build, Buy, or Assemble? The AI Decision Has Changed

AI Strategy Series | Article 8 of 20

Building the Intelligent Enterprise

For decades, enterprise technology leaders have confronted a familiar question:

Should we build the software ourselves or buy it from a vendor?

The decision traditionally involved evaluating development costs, implementation timelines, available functionality, internal expertise, vendor reliability, and long-term maintenance obligations.

Those considerations remain relevant.

But artificial intelligence has fundamentally changed the choices available.

Organizations can now combine commercial foundation models, open-weight models, managed AI services, enterprise applications, proprietary data, reusable integration components, and internally developed business logic.

They can purchase complete AI-enabled applications.

They can develop proprietary AI capabilities.

Or they can assemble solutions from components supplied by multiple providers.

Increasingly, the third option deserves serious consideration.

The enterprise AI sourcing decision is no longer simply whether to build or buy. It is which capabilities the organization should own, which it should control, and which it can responsibly obtain from external providers.

That distinction changes the economics, architecture, and strategic implications of AI investment.

It also introduces a more demanding responsibility for enterprise technology leadership.

The objective is not to select the most sophisticated model or the fastest development approach.

It is to establish an AI capability that delivers business value while preserving the architectural flexibility, operational reliability, and strategic control the enterprise requires.

Why the Traditional Build-versus-Buy Model Is Incomplete

Traditional enterprise software sourcing generally presented two primary options.

An organization could develop a custom application to satisfy its requirements.

Alternatively, it could purchase commercial software and configure it to support its business processes.

The decision often reflected a tradeoff between differentiation and standardization.

Custom development offered greater control but required more investment and maintenance.

Commercial software accelerated implementation but constrained flexibility.

AI introduces a more granular sourcing environment.

An enterprise can use a commercial model without purchasing a complete application.

It can purchase an AI-enabled application while retaining control over its underlying information.

It can assemble an agentic workflow using external inference services, internal business rules, existing enterprise APIs, and proprietary orchestration logic.

It can also deploy open-weight models within infrastructure it controls.

These possibilities separate capabilities that were previously bundled together.

The intelligence layer can be sourced independently of the application.

The application can be developed independently of the model.

The information architecture can remain under enterprise control.

The execution environment can combine internal and external services.

And the organization can decide which components warrant proprietary investment.

This creates flexibility.

It also creates architectural complexity.

AI sourcing is becoming a portfolio of component-level decisions rather than a single application procurement decision.

Three Sourcing Models, Three Different Strategic Implications

Although enterprise AI solutions can take many forms, three broad sourcing approaches provide a useful starting point.

1. Buy: Acquire a Complete AI-Enabled Application

The most straightforward approach is to purchase a commercial application that incorporates AI capabilities.

Examples include AI-enabled customer service platforms, enterprise productivity suites, financial applications, cybersecurity products, and industry-specific software.

The vendor typically supplies the application, underlying AI integration, operational infrastructure, and much of the associated maintenance.

This approach can offer substantial advantages.

Implementation may be faster.

The organization may require fewer specialized AI engineers.

The vendor may provide established integrations, operational support, and product enhancements.

For standardized business functions, these benefits can outweigh the value of custom development.

But buying an AI-enabled application also introduces dependencies.

The vendor may determine which models are used.

It may control how AI capabilities are updated.

It may limit customization.

It may establish proprietary data structures or workflow mechanisms.

And the enterprise may have limited visibility into how certain AI functions operate.

These constraints are not automatically unacceptable.

The relevant question is whether the capability is strategically important enough to justify greater control.

For a relatively standardized administrative function, a commercial solution may be appropriate.

For a business capability that differentiates the enterprise competitively, the tradeoff may be less attractive.

Buying AI can accelerate adoption, but the enterprise must understand what control it is surrendering in exchange for convenience.

2. Build: Develop Proprietary AI Capabilities

Custom AI development remains appropriate when an organization requires capabilities that commercial products cannot adequately provide.

These may involve proprietary workflows, specialized industry knowledge, unique customer experiences, or strategically important intellectual property.

Building does not necessarily mean training a foundation model.

In most enterprise situations, custom development involves creating applications, services, orchestration mechanisms, evaluation systems, or specialized models around existing AI technologies.

The organization may use external foundation models while retaining control over its business logic and application architecture.

This distinction matters.

An enterprise can develop a proprietary AI capability without attempting to reproduce the infrastructure investments of a major foundation model provider.

Custom development can preserve flexibility and support differentiation.

It can also create substantial obligations.

The enterprise must maintain the application.

It must evaluate model behavior.

It must manage integration dependencies.

It must address operational reliability, security, and scalability.

It must also adapt as models, platforms, and business requirements change.

The decision to build should therefore reflect more than the organization’s technical ability.

The enterprise should build when ownership of the capability creates strategic value sufficient to justify the ongoing investment.

3. Assemble: Combine Internal and External Capabilities

The third approach combines components from multiple sources.

An enterprise might use a commercial foundation model for language understanding.

It might maintain its own information retrieval architecture.

It could use internal APIs to access authoritative operational data.

Business rules could remain within existing enterprise applications.

Workflow orchestration could be developed internally.

Monitoring and evaluation might use a combination of commercial and proprietary tools.

The resulting capability is assembled rather than purchased as a complete product or built entirely from scratch.

This approach can offer important advantages.

The organization can select components according to their strengths.

It can preserve control over strategically important functions.

It can replace individual services without necessarily redesigning the entire application.

It can reuse architectural capabilities across multiple AI initiatives.

But assembly requires disciplined architecture.

Poorly designed component boundaries can create fragile dependencies.

Inconsistent interfaces can increase maintenance costs.

Multiple vendors can complicate operational support.

And responsibility for integration, reliability, and lifecycle management remains with the enterprise.

Assembly creates strategic flexibility only when the architecture is designed to support it.

Otherwise, it simply distributes complexity across more components.

The Strategic Question Is What the Enterprise Must Own

The most important AI sourcing decision concerns ownership of strategically significant capabilities.

Not every component deserves proprietary investment.

Most enterprises gain little competitive advantage from independently developing capabilities that are widely available through commercial platforms.

At the same time, outsourcing every aspect of an AI solution may leave the organization dependent on vendors for capabilities central to its business model.

The challenge is distinguishing between commodity intelligence and enterprise differentiation.

A general-purpose language model may be a commodity input for many applications.

A proprietary customer engagement process may not be.

A commercial document extraction service may provide sufficient functionality.

A specialized decision process incorporating decades of organizational expertise may justify internal ownership.

A vendor-managed agent platform may accelerate implementation.

But the business rules governing financial commitments or customer obligations may need to remain under enterprise control.

This suggests a useful principle:

Own what differentiates the enterprise. Control what determines its operational authority. Source what can be obtained competitively without compromising either.

The principle is not absolute.

Cost, regulation, resilience, talent availability, and technology maturity may justify different choices.

But it provides a strategic foundation for evaluating component-level sourcing decisions.

Foundation Models Are Not Necessarily the Strategic Asset

Organizations sometimes assume that competitive advantage in AI requires owning the underlying model.

For most enterprises, that assumption deserves scrutiny.

Training a frontier-scale foundation model requires substantial technical expertise, computing infrastructure, data resources, and ongoing investment.

Even smaller specialized models require evaluation, maintenance, and operational support.

The question is whether owning the model creates sufficient business value.

In many cases, differentiation comes from what surrounds the model.

The enterprise may possess proprietary information.

It may have unique business processes.

It may understand customer needs better than competitors.

It may have established distribution channels, operational capabilities, or industry relationships that are difficult to reproduce.

AI can amplify those advantages.

But the model itself may be interchangeable within acceptable performance boundaries.

Consider a logistics company developing an AI capability to optimize exception handling across its transportation network.

Its competitive advantage may come from proprietary operational data, established carrier relationships, specialized routing rules, and years of accumulated execution knowledge.

A commercial foundation model might provide the language understanding and reasoning capabilities required to support the application.

The strategically important assets are the information, business logic, integrations, and operational capabilities that make the solution valuable.

The enterprise does not necessarily need to own the intelligence engine to own the business capability it enables.

The Case for Architectural Assembly

Assembling AI capabilities can be particularly attractive when an organization already possesses mature enterprise architecture practices.

The approach allows technology leaders to separate concerns.

Foundation models provide selected intelligence capabilities.

Information services supply authoritative enterprise knowledge.

Integration services connect applications.

Business rules enforce organizational requirements.

Workflow engines coordinate execution.

Identity services establish permissions.

Operational monitoring provides visibility.

Each component has a defined responsibility.

This separation can improve maintainability and adaptability.

It also allows the enterprise to evaluate sourcing decisions independently.

For example, a company may initially use one commercial model provider.

If another provider later offers better performance, economics, or operational characteristics, the organization may be able to evaluate a replacement without rebuilding its entire business application.

However, this flexibility should not be overstated.

Different models may produce different outputs.

Tool-calling behavior may vary.

Prompt designs may require modification.

Evaluation results may change.

Switching providers may require substantial testing.

Architectural modularity reduces certain forms of dependency.

It does not eliminate them.

An assembled AI architecture should be designed for controlled substitution, not based on the assumption that every component is effortlessly interchangeable.

The Hidden Economics of AI Sourcing

Traditional build-versus-buy decisions often compare software licensing costs against development and maintenance expenses.

AI introduces additional economic variables.

Commercial AI services may charge according to token consumption, inference volume, model selection, storage, retrieval operations, agent activity, or provisioned capacity.

An application that appears inexpensive during a pilot may become costly at enterprise scale.

Custom development introduces engineering, infrastructure, evaluation, security, monitoring, and maintenance costs.

Assembled solutions introduce integration and orchestration expenses.

The appropriate economic analysis must consider the complete operating model.

For example, an enterprise may evaluate an AI agent intended to automate customer service activities.

The initial business case assumes that each interaction requires one model request.

In production, the agent may perform several retrieval operations, invoke multiple tools, evaluate intermediate results, and generate a final response.

The actual cost per completed transaction may be substantially higher than the cost of a single model invocation.

The organization must also account for unsuccessful interactions, retries, human escalation, monitoring, and ongoing evaluation.

The correct unit of economic analysis is therefore not necessarily cost per token or cost per model request.

It may be cost per successfully completed business outcome.

AI economics should be evaluated at the business capability level, not merely at the technology consumption level.

This distinction is especially important when comparing commercial applications with custom or assembled solutions.

A higher-priced commercial product may be economically superior if it substantially reduces integration, support, and operational complexity.

Conversely, an assembled solution may provide better long-term economics when reusable components support multiple business processes.

The answer depends on the complete cost structure.

The Vendor Lock-In Question Has Changed

Vendor lock-in is not new.

Enterprise software vendors have long created dependencies through proprietary data models, application interfaces, licensing arrangements, and specialized implementation requirements.

AI introduces additional forms of dependency.

An application may become dependent on a particular model’s behavior.

An agent may rely on proprietary orchestration mechanisms.

A retrieval system may use vendor-specific indexing or embedding services.

An evaluation framework may depend on a particular platform.

A commercial AI application may retain important operational context in proprietary formats.

These dependencies can increase switching costs.

But not all lock-in is equally consequential.

A vendor dependency may be acceptable when the application is inexpensive, easily replaced, and operationally noncritical.

The same dependency may be unacceptable when it supports a mission-critical process or strategically differentiated capability.

Technology leaders should therefore evaluate lock-in according to business consequences.

Can the enterprise retrieve its information?

Can it preserve its business logic?

Can it replace the model?

Can it migrate workflows?

Can it reconstruct operational activity?

Can it continue operating if the vendor changes pricing, product direction, or service availability?

The objective is not to eliminate every dependency.

That would be unrealistic.

It is to ensure that dependencies are understood and proportionate to their strategic importance.

Data Ownership Is Not Enough

Organizations frequently focus on whether contracts establish ownership of enterprise data.

That is important.

But AI sourcing introduces broader questions about practical control.

An enterprise may legally own its data while depending on a vendor’s proprietary structures to interpret or use it.

For example, a commercial AI platform may create embeddings, indexes, workflow definitions, conversation histories, agent state, or specialized metadata.

Those assets may be essential to the application’s operation.

If the organization cannot export or reconstruct them, changing vendors may require substantial redevelopment.

The enterprise should distinguish between legal ownership and operational portability.

It should also consider how information is processed, retained, and accessed.

Can sensitive information be restricted to authorized purposes?

Can the organization determine which systems access it?

Can it preserve authoritative information independently of the AI platform?

Can it maintain required records if the vendor relationship ends?

These questions connect AI sourcing directly to data strategy and information architecture.

As discussed in Article 5, Your AI Strategy Inherits Your Data Strategy, enterprise information must remain trustworthy, accessible, and appropriately governed.

The sourcing model should support those requirements rather than undermine them.

Agentic AI Makes the Sourcing Decision More Consequential

The build, buy, or assemble decision becomes more significant as organizations deploy autonomous agents.

An AI assistant that summarizes documents primarily affects information access.

An agent authorized to execute business processes can affect operational outcomes directly.

Consider an enterprise implementing an AI procurement agent.

The agent retrieves supplier information, evaluates purchasing requirements, checks budgets, recommends suppliers, and initiates approved transactions.

A commercial platform may provide the agent framework.

A foundation model may provide reasoning capabilities.

Internal services may supply supplier records and budget information.

Existing procurement applications may execute transactions.

The enterprise must decide which responsibilities belong to each component.

Should the vendor control workflow orchestration?

Should the enterprise maintain its own authorization services?

Where should business rules execute?

Who controls transaction limits?

How are actions recorded?

What happens when a model behaves unexpectedly?

Can the organization suspend the agent without disrupting unrelated systems?

These are architectural questions with direct sourcing implications.

The enterprise should not assume that a vendor’s ability to execute a workflow establishes that the vendor should control the authority governing that workflow.

The more consequential the decisions delegated to AI, the more important it becomes to separate intelligence capabilities from enforceable business authority.

A Practical AI Sourcing Decision Framework

Enterprise leaders can evaluate AI sourcing decisions across six dimensions.

Decision Dimension	Key Question	Strategic Implication
Competitive Differentiation	Does this capability create a meaningful advantage?	Greater differentiation may justify proprietary development or control.
Architectural Control	Which components must remain under enterprise authority?	Critical business logic, permissions, and integration boundaries may warrant internal ownership.
Implementation Speed	How quickly must the capability become operational?	Commercial solutions may accelerate delivery.
Lifecycle Economics	What is the full cost of development, operation, evaluation, and change?	Initial implementation cost may not reflect long-term economics.
Vendor Dependency	How difficult would it be to replace the provider?	High switching costs may justify modular architecture or contractual protections.
Operational Criticality	What happens if the capability fails or becomes unavailable?	Mission-critical applications require stronger resilience and continuity provisions.

These dimensions should be evaluated together.

A strategically differentiated capability may still be purchased if the commercial solution provides overwhelming advantages.

A standardized capability may still require internal development because of unusual integration or regulatory requirements.

An assembled solution may offer flexibility but become economically unattractive if the enterprise lacks the skills to maintain it.

The framework is intended to support judgment, not replace it.

The CIO Must Become an AI Portfolio Architect

The changing sourcing environment expands the CIO’s responsibilities.

The CIO must evaluate not only individual applications but also the relationships among AI capabilities across the enterprise.

Different business units may purchase AI-enabled applications independently.

Development teams may select different foundation models.

Data teams may establish retrieval platforms.

Operations teams may deploy autonomous agents.

Each decision may be reasonable in isolation.

Collectively, they may produce unnecessary complexity.

The CIO should establish an architectural approach that distinguishes shared enterprise capabilities from business-specific solutions.

This may include common identity services, authoritative information access, integration standards, evaluation practices, operational monitoring, and selected model access mechanisms.

The objective is not to centralize every AI decision.

It is to prevent the enterprise from accumulating a fragmented collection of AI technologies that cannot operate coherently.

The CIO must also determine where vendor independence creates value and where standardization on a provider is economically sensible.

These decisions require understanding business strategy, architecture, operating costs, vendor relationships, and organizational capabilities.

AI sourcing is becoming an enterprise architecture responsibility as much as a procurement responsibility.

The Boardroom Question

Imagine management proposing a substantial investment in an AI platform.

The vendor offers sophisticated capabilities.

The implementation timeline is attractive.

The financial projections are promising.

The executive team believes the platform can support multiple business functions.

A director asks:

“Which parts of this capability will we own, which will we control, and which will remain dependent on the vendor?”

That question should be central to the investment discussion.

It requires management to explain where strategic differentiation resides.

It exposes whether critical business processes depend on proprietary vendor mechanisms.

It clarifies whether enterprise information remains accessible and portable.

It also helps the board understand how the investment affects future architectural flexibility.

A second question follows naturally:

“If we needed to replace this provider in three years, what would we have to rebuild?”

The answer may reveal dependencies that are not visible in the initial business case.

These questions do not imply that vendor relationships should be avoided.

They recognize that enterprise AI sourcing decisions can shape the organization’s technology architecture and operating model for years.

The board should expect management to understand those consequences.

The Executive Imperative

Artificial intelligence has transformed the traditional build-versus-buy decision.

Enterprises can now purchase complete AI applications, develop proprietary capabilities, or assemble solutions from internal and external components.

Each approach offers advantages.

Each introduces different costs, responsibilities, and dependencies.

The correct decision depends on the strategic importance of the capability, the organization’s architectural maturity, available expertise, operational requirements, and long-term economics.

Technology leaders should begin by identifying where competitive differentiation resides.

They should determine which business rules, information assets, integration mechanisms, and operational controls must remain under enterprise authority.

They should evaluate commercial offerings according to their complete lifecycle costs and architectural consequences.

And they should recognize that modularity creates flexibility only when supported by deliberate design and realistic evaluation.

The objective is not to maximize internal development.

Nor is it to outsource every capability that a vendor can provide.

It is to establish the right balance between ownership, control, and external sourcing.

Build where proprietary capability creates strategic advantage. Buy where commercial solutions provide sufficient value without unacceptable dependency. Assemble where architectural flexibility and component specialization justify the additional complexity.

That is the new AI sourcing decision.

And as artificial intelligence becomes embedded in enterprise operations, the consequences of getting it right—or wrong—will extend far beyond the technology budget.

References

International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 42001:2023: Information Technology—Artificial Intelligence—Management System. Geneva: ISO, 2023. https://www.iso.org/standard/81230.html.

National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1. Gaithersburg, MD: U.S. Department of Commerce, January 2023. https://doi.org/10.6028/NIST.AI.100-1.

National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1. Gaithersburg, MD: U.S. Department of Commerce, July 2024. https://doi.org/10.6028/NIST.AI.600-1.

The Open Group. The TOGAF Standard, 10th Edition. Reading, UK: The Open Group, 2022. https://www.opengroup.org/togaf.

Williamson, Oliver E. The Economic Institutions of Capitalism: Firms, Markets, Relational Contracting. New York: Free Press, 1985.

Coming Next

Article 9 — Your AI Vendor Is Becoming Part of Your Architecture

Enterprise software vendors have always influenced technology architecture.

Artificial intelligence is making those relationships more consequential.

Foundation model providers, agent platforms, managed AI services, and commercial AI applications can now influence how enterprise information is interpreted, how workflows are executed, and how business decisions are made.

In the next article, we examine why AI vendor relationships are becoming architectural dependencies, how model and platform choices affect operational resilience and portability, and why enterprise leaders must understand what happens when a vendor becomes embedded in the execution of critical business processes.