Most enterprise AI systems are assembled from purchased and custom layers. A company may use hosted models, build proprietary evaluation and workflow software, buy observability, and operate data connectors internally.
The decision should be made layer by layer according to differentiation, risk, switching cost, integration, and ownership.
Buy commodity capability
Managed models, infrastructure, identity, and common workflow components can shorten time to evidence. Buying is strongest when requirements are standard and provider constraints are acceptable.
Build differentiated workflow and evidence
Custom work is justified when proprietary data, unique operating logic, user experience, evaluation, or integration creates advantage. The workflow and acceptance system often matter more than training a foundation model.
Price switching and control
Evaluate data portability, model substitution, export, API limits, pricing volatility, regional availability, security, and the cost of reproducing behavior elsewhere.
Prototype the boundary
Test the highest-risk vendor assumption and the highest-value custom layer. Maintain an abstraction only where credible alternatives exist; unnecessary portability can add complexity without reducing risk.
Decide by layer
Separate foundation model, retrieval, orchestration, evaluation, data services, user experience, integrations, security, and operations. A company may buy commodity inference while building workflow logic and evaluation that encode its advantage. The binary question obscures where differentiation and risk actually live.
Classify each layer by strategic uniqueness, switching cost, internal capability, time sensitivity, compliance, and operating burden. Buy where the market offers a mature capability with acceptable control. Build where proprietary data, workflow, or experience produces material advantage and the company can sustain ownership.
Include exit design. Export formats, interfaces, data portability, model abstraction, and evaluation suites determine whether a provider can be replaced. Multi-provider architecture has a cost, so reserve it for dependencies where concentration risk justifies the complexity.
Compare total capability cost
Buying includes integration, configuration, governance, vendor management, usage, and adaptation to product limits. Building includes discovery, engineering, security, operations, and opportunity cost. Compare the cost of an accepted operating outcome over several years, not license price against developer salary.
Revisit the decision as volume, regulation, product maturity, and provider capability change. An early managed service may accelerate learning; later, a high-volume or differentiating component may justify internalization.
Executive decision record
The decision is which architecture layers should be owned, purchased, or abstracted based on differentiation, control, maturity, switching cost, and internal capacity. Write that decision before selecting a model, vendor, framework, or implementation pattern. A written boundary keeps technical exploration connected to the operating outcome and makes it possible to explain why the organization advanced, revised, or stopped the work.
Approval should depend on layered capability map, workload benchmarks, total ownership model, provider diligence, exit requirements, and a time-bound reevaluation. The evidence does not need to remove every uncertainty, but it should address the uncertainty capable of changing value, architecture, risk, or ownership. Record the baseline, assumptions, unresolved questions, and the person accepting the next stage.
Failure boundary and operating ownership
The central failure to guard against is making one ideological choice for the entire system or comparing license price with salaries while excluding integration and operations. Treat that condition as a testable scenario. Define how the system detects it, what users experience, which action is prevented or reversed, and what evidence reaches the person responsible for recovery.
Long-term accountability sits with the product and technology leaders accountable for strategic differentiation and sustainable operating capability. Supporting specialists can provide platforms, research, review, or delivery capacity, but they cannot substitute for an owner who controls policy and operating change. Name that owner before production and include the ownership path in release evidence and incident procedure.
A practical 90-day application plan
During the first 30 days, convert layered capability map, workload benchmarks, total ownership model, provider diligence, exit requirements, and a time-bound reevaluation into a bounded evidence plan. Assign each artifact to a named contributor, identify the representative inputs required, and agree on the comparison baseline before implementation expands. The objective of this period is to expose the assumption most likely to invalidate the work while the cost of changing direction is still low.
During days 31 through 60, build or instrument the smallest complete workflow that can support the decision about which architecture layers should be owned, purchased, or abstracted based on differentiation, control, maturity, switching cost, and internal capacity. Include the real data and authorization path where feasible, record exceptions, and review difficult cases with the people who own the underlying process. Resist adding breadth until the team can explain the measured behavior of this narrow slice.
During days 61 through 90, test the boundary represented by making one ideological choice for the entire system or comparing license price with salaries while excluding integration and operations. Exercise degraded dependencies, ambiguous inputs, recovery, and handoff rather than demonstrating only successful cases. End the period with a written advance, revise, or stop decision that cites evidence, residual exposure, expected operating cost, and the next authority boundary.
The review should be accepted by the product and technology leaders accountable for strategic differentiation and sustainable operating capability. That group should confirm not only that the system can work, but that ownership, support capacity, monitoring, and change control are credible. If those conditions are absent, the responsible outcome is another bounded learning stage rather than an unsupported production commitment.
Practical checklist
- Strategic differentiation by layer
- Data and integration requirements
- Risk and control needs
- Provider switching feasibility
- Three-year operating cost
- Internal ownership capacity
- Evidence from a thin end-to-end slice
Engagement scenario
A professional-services firm buys hosted model access and identity infrastructure, builds permission-aware retrieval and a specialized review experience, and keeps evaluation data portable across model providers.
Continue reading
- [AI use-case prioritization](/ai-use-case-prioritization-framework)
- [AI development RFP](/ai-development-rfp-checklist)
Sources and further reading
- [NIST AI RMF](https://www.nist.gov/itl/ai-risk-management-framework)