“Should we build our own AI solution or buy one?” sounds like a technology question. For leadership, the harder question is which decisions the organization must be able to make, verify and change after the system goes live.
Start with the control the work requires. Then choose the simplest delivery route that can provide it and that your team can sustain. A custom application is not automatically more controllable. A packaged product is not automatically less suitable. The answer depends on what each option actually lets you do.
The VORTA framework places tooling choices alongside operational readiness, ownership and adoption. Its tooling comparison includes build versus buy, platform versus API, observability, data control and vendor lock-in. The questions below develop that comparison into a practical leadership decision.
Define what “build” and “buy” mean for this decision
The choice is rarely between creating everything from scratch and accepting a completely fixed product. Separate three realistic options:
- Adopt a packaged product: use a supplier’s application within its supported settings and operating boundaries.
- Configure and connect: combine a product or model service with your own data access, workflow rules and integrations.
- Build a custom application: develop and maintain the application and workflow, potentially using external models, hosting and software components.
Building an application around a model API does not mean building the model or controlling its future behavior. Equally, buying software does not mean outsourcing every business decision. Write down which layers each option covers before comparing them. Otherwise, the proposal that appears cheaper may simply leave more work outside its scope.
Identify the decisions you cannot afford to lose
Turn the business requirement into specific control questions. Avoid broad statements such as “we need flexibility.” Ask what must remain possible when the process changes or an output is challenged.
What information can the system use?
Can the organization choose approved sources, restrict access by role and prevent information from one context appearing in another? Can it remove obsolete material and verify that the change took effect? The relevant requirement may be an access boundary or a source-selection rule, rather than ownership of every technical component.
What can the system decide or do?
Separate generating a suggestion from executing an action. Can the organization limit which actions are available, set approval conditions and disable a problematic function without disabling the entire service? For a task that only needs a draft, purchasing a more autonomous product may add complexity without adding useful capability. This is the same distinction behind matching AI autonomy to the task.
What can the team inspect and change?
Can reviewers see the inputs, relevant sources, output and action history needed to investigate a disputed result? Can the team test an updated configuration before releasing it? Ask for the level of visibility required for the intended use. A dashboard or a log export may be useful, but neither automatically explains why a model produced a particular answer.
What happens when you need to leave?
Identify the records, configurations and unfinished work that must remain usable if the product is replaced. Exporting a file is not the same as restoring the business process elsewhere. Check formats, dependencies and the effort needed to recreate the workflow. Keep this discussion connected to a practical AI exit and continuity plan.
For each essential requirement, record whether the option supports it, how that support has been demonstrated and what remains dependent on a supplier or specialist. An unverified claim should stay unverified rather than receive a confident score.
Treat non-negotiable requirements as gates
A weighted comparison can help with trade-offs such as usability, implementation effort and expected running cost. It should not allow attractive features to compensate for an unacceptable access boundary or a missing approval control.
Separate the assessment into two steps:
- Can this option meet the essential operating conditions? If not, reject it, narrow the intended use or investigate a different design.
- Among the viable options, which offers the best balance of value, effort and sustainable control? Compare them against the same task and quality requirements.
If none of the options meets the conditions, the decision is not automatically to build. The organization may lack the resources to maintain the required controls itself. A smaller scope, a conventional workflow or a delayed commitment may be more credible.
Compare the operating burden, not just the purchase price
Use the same planning period and workload assumptions for each route. Include implementation, integration, data preparation, testing, human checking, support, monitoring, changes and eventual migration. Keep estimates separate from observed costs.
A subscription can still require substantial internal effort. A custom build can create ongoing responsibilities for security updates, incident handling, dependency changes and staff continuity. A hybrid approach can preserve a valuable control while introducing additional integration points to maintain.
Name the person or team that will perform each recurring activity and confirm that the capacity exists. “Our team will manage it” is not a resourcing plan. If the proposal relies on one individual, examine the handover and support arrangements before making that dependency permanent.
Test the assumptions most likely to reverse the choice. For example, would a higher review workload remove the expected saving? Would an integration limitation make the packaged option impractical? The discipline of testing an AI business case’s assumptions applies to the delivery route as much as to the promised benefit.
An illustrative decision: a service knowledge assistant
Consider a hypothetical team that wants an assistant to draft answers from approved service guidance. This is a design example, not a client result. The assistant must enforce access restrictions and show staff the source passage. Staff must approve every reply before it is sent.
A packaged assistant may be sufficient if those conditions can be demonstrated using representative documents and roles. The team would gain little from rebuilding the interface merely to make it feel proprietary.
If the product cannot apply a necessary case-level access restriction, connecting it to more documents is not a solution. The team could investigate a supported integration that retrieves only authorized information. That hybrid route is viable only if the complete access boundary can be tested and maintained.
A custom application becomes a stronger candidate if the required workflow genuinely cannot be supported by the alternatives and the organization can own its ongoing operation. It still needs evaluation of the external model and infrastructure it uses. Custom code does not remove supplier dependence.
The useful output is a decision about the necessary layer of customization, supported by a test of the actual constraint. It is not a general declaration that building or buying is always better.
Keep the first commitment smaller than the uncertainty
Before approving a long contract or a substantial build, ask for a bounded demonstration of the requirement that matters most. Use approved representative data, realistic user roles and the same acceptance conditions across options. Include a difficult case and an attempted action that should be blocked.
Record the chosen route, the alternatives considered, the evidence, the remaining assumptions, the operating owner and the circumstances that would reopen the decision. These might include a material change in workload, supplier terms, required controls or available internal capability.
The NIST AI RMF Playbook, GOVERN 6.1, addresses risks arising from third-party AI systems, data and other dependencies, including open-source and commercial components. Its guidance supports evaluating those dependencies across the lifecycle. The build-or-buy questions in this article are my practical synthesis, not a prescribed NIST scoring method.
Choose the route that preserves the decisions the work depends on, with an operating burden the organization can realistically carry. The best choice may be to buy, configure, build a narrow component or defer. What matters is being able to explain why that choice fits the work.
If you are comparing AI delivery options, schedule a consultation to clarify the essential controls, ownership and assumptions before committing.