Build, buy or configure? A decision framework for enterprise AI

The choice between building and buying AI is usually presented too simply. Most production systems combine purchased models, configured platforms, internal data, bespoke integrations and business-owned controls.

The useful decision is which parts of the capability should be owned, which can be standardised and where configuration is enough.

Define the layers before choosing a route

Separate the proposed solution into layers:

1. Foundation capability: language model, vision model, speech service or optimisation engine.
2. Application: the interface and task-specific experience.
3. Workflow orchestration: rules, approvals, routing and connected actions.
4. Business context: internal data, knowledge, policies and permissions.
5. Evaluation and controls: tests, logs, monitoring, access and fallbacks.
6. Operating model: ownership, support, change and incident response.

A business may buy the model and application, configure the workflow and build its evaluation set and integrations. Calling that choice simply “buy” hides the work that creates production value.

When buying is attractive

Buying suits a common problem with mature products, standard integrations and limited need for unique behaviour.

Typical benefits include faster time to first use, established support, a user interface, packaged security features and predictable implementation patterns. The supplier may spread model, infrastructure and compliance work across many customers.

Buying is strongest when:

• The workflow is broadly standard across organisations.
• Product features cover most requirements without extensive customisation.
• The organisation has limited engineering capacity.
• Speed matters more than unique differentiation.
• Data and integration requirements fit the product’s design.
• Exit and migration are manageable.

The purchase still requires evidence. A generic product demonstration does not prove performance on your data, policies and users.

When building is attractive

Building does not usually mean training a foundation model. It often means creating a task-specific system using external or open models.

Build is more attractive when:

• The workflow creates real competitive or operational differentiation.
• The organisation has proprietary context that shapes the result.
• Existing products force a poor process or weak controls.
• Fine-grained permissions, auditability or integration are essential.
• The business needs to switch models or components independently.
• The capability will support several valuable workflows.

Building offers control, but it also creates continuing responsibility. The team owns evaluation, reliability, security, support, documentation and change management.

When configuring is the best answer

Configuration sits between the two. A platform may provide model access, retrieval, identity, logging and workflow components, while the organisation configures prompts, policies, data sources, evaluations and approvals.

This route can provide speed without accepting a completely fixed product. It works well when the business process is distinctive but the underlying technical capabilities are not.

Watch for configuration that becomes unmaintainable custom code inside a proprietary tool. Confirm how changes are versioned, tested and moved between environments.

Score the decision on eight dimensions

Use a one-to-five score and write the evidence behind each score.

1. Strategic differentiation

Would better performance in this workflow create a durable advantage, or is it a standard support capability? Own more of the layers that embody genuine differentiation.

2. Workflow fit

How closely does each option support the real process, exceptions and approval model? Calculate the cost of changing the product and the cost of changing the workflow.

3. Data and integration complexity

Assess data location, quality, permissions, latency and required system actions. A product may have a connector but still lack the field-level access or audit trail the process needs.

4. Risk and control

Can the organisation enforce scope, human approval, segregation of duties, logging, retention and fallback? Confirm which controls are native, configurable or external.

5. Evaluation evidence

Can the option be tested on representative cases? Will the supplier expose enough outputs, versions and logs to diagnose failures? Can critical evaluations be rerun after updates?

6. Skills and operating capacity

Who will support the system at 9am on a Monday when a dependency fails? Consider engineering, product ownership, domain expertise, security, evaluation and supplier management.

7. Time to usable value

Measure time to a controlled operational outcome, not time to a demonstration. Buying can accelerate setup while data integration, governance and adoption still determine the release date.

8. Lifetime cost and exit

Model implementation, licences, usage, human review, support, future change and migration. Consider volume tiers and the cost of retrieving your data, evaluation records and configuration on exit.

Run due diligence on evidence, not feature lists

Ask suppliers to demonstrate the proposed workflow using representative, appropriately protected examples. Agree the success criteria before the demonstration.

Important questions include:

• Which model and system versions produced the result?
• How are customer data and prompts used, stored and isolated?
• Which sub-processors and regions are involved?
• How are updates communicated and controlled?
• Can the business pin or validate a version before change?
• What logs and evidence are available for an incident?
• How are permissions enforced across connected systems?
• What service levels, fallbacks and recovery processes apply?
• Can the system export configurations and records in usable formats?
• Which claims are contractually supported rather than planned?

The NIST Generative AI Profile calls attention to third-party and supply-chain risk as well as ongoing testing and monitoring. A vendor assessment should therefore cover the lifecycle, not just security certification at purchase.

Keep accountability in the business

A supplier can provide a capable product and useful controls. It cannot own your customer outcome, process design or decision to use the system in a particular context.

The business should retain:

• The approved purpose and boundaries.
• The operational owner.
• The evaluation criteria and release decision.
• The human oversight design.
• Monitoring thresholds and incident authority.
• The right to pause or withdraw the workflow.

The UK Government AI Playbook recommends involving commercial colleagues early and planning for long-term support. Small organisations can apply the same principle by making procurement part of workflow discovery, not a separate purchasing event at the end.

Compare prototypes fairly

If two routes remain credible, run a time-boxed proof using the same evaluation set, workflow and measures.

Compare:

• Task quality overall and on difficult segments.
• Review and correction effort.
• Integration work and failure handling.
• Control coverage and auditability.
• Latency and cost at expected volume.
• User success on real tasks.
• Effort required to change a prompt, policy or data source safely.

Do not allow one option to use curated examples while another faces the full distribution.

Common decision errors

Buying a product before mapping the process. The product becomes the workflow design by default.

Building because the prototype was easy. Production ownership lasts much longer than the first build.

Treating vendor model choice as permanent. Capability, price and risk can change. Design an appropriate level of portability.

Ignoring the human operating cost. Review, exceptions, support and data maintenance may dominate model usage cost.

Assuming configuration is free. Prompts, rules, integrations and evaluations are production assets that need ownership and versioning.

A practical decision pattern

For many small and mid-sized organisations, the strongest pattern is:

• Buy commodity foundation capabilities.
• Configure a secure platform where it fits.
• Build the workflow logic, evaluation evidence and differentiating context that matter.
• Keep permissions and high-consequence actions tightly controlled.
• Maintain an exit plan for critical suppliers.

The goal is not maximum ownership. It is enough ownership to control the outcome, improve the system and avoid dependence where it would become expensive or risky.

If you are comparing routes for a specific workflow, Sorsana can help with strategy, evaluation and delivery. Tell us what you are deciding.