Buy or configure a product when the workflow is common and the product meets your control and integration needs. Build only when a valuable requirement is genuinely distinctive and your organization can own the system. Use ordinary software or process improvement when AI adds uncertainty without enough benefit.
The direct answer
For most business workflows, begin with the software you already own, then evaluate a packaged product or a focused integration. A custom build is justified when the workflow creates meaningful differentiation, available products fail a material requirement, and the business can fund evaluation, security, monitoring, maintenance, and change after launch.
Build versus buy is not a permanent binary choice. Configure, integrate, and do not use AI are valid options. Make the smallest reversible commitment that can test the important assumptions with representative work.
Use this decision table
| Option | Choose it when | Main tradeoff | Evidence required |
|---|---|---|---|
| Improve the process or use ordinary automation | Rules can express the decision, inputs are inconsistent, or the problem does not require interpretation | Less flexibility, but easier testing and operation | A stable process map, baseline, and rule coverage |
| Configure software you already use | An existing product supports the workflow, permissions, and data | Fastest path, but bounded by its roadmap and license | Representative trial, admin controls, terms, and total recurring cost |
| Buy a packaged AI product | The workflow is common and vendor capabilities satisfy material requirements | Lower delivery burden, but vendor dependency and limited differentiation | Product evaluation, security and legal review, integration test, export and exit terms |
| Integrate AI into the current workflow | A bounded AI step adds value while existing systems remain the source of truth | More fit and control, but integration and monitoring become your responsibility | Pilot across normal cases, exceptions, permissions, latency, and operating cost |
| Build a focused custom capability | Proprietary data or workflow creates advantage and products fail an important requirement | Maximum fit, with the highest ownership and maintenance burden | Validated architecture, evaluation set, controls, staffing, lifecycle budget, and exit plan |
Include the non-AI option
AI is not automatically better than a clearer form, a policy change, a search index, a rules engine, a queue, or a conventional integration. If the work is predictable, deterministic software is usually easier to explain, test, secure, and maintain.
If the process has no accountable owner, reliable inputs, measurable outcome, or safe review path, fix those conditions first. That readiness work applies whether the eventual choice is buy, build, integrate, or stop.
Test the failure cases before the happy path
Evaluate each option against failures that matter in the real workflow:
The acceptable response may be to refuse, fall back to a deterministic path, preserve the current process, queue work for a person, or stop an action. A polished demonstration that omits these cases is not decision-quality evidence.
- Missing, stale, conflicting, malicious, or out-of-scope input.
- Unsupported claims, incorrect extraction, biased treatment, or a plausible answer with no reliable source.
- Wrong-user access, excessive permissions, sensitive-data exposure, or an action outside the approved boundary.
- Vendor, model, API, network, or upstream-system outage and degraded behavior.
- Low-confidence cases, unusual volume, duplicate actions, and a person overriding or correcting the result.
- A model or product update that changes quality, cost, latency, retention, or available controls.
Define human control before selecting a product
Human review is not an effective control when approval is automatic, the reviewer cannot inspect the basis for an output, or volume makes careful review impossible. The workflow and staffing model must make oversight practical.
- Name the person accountable for the workflow outcome and ongoing operation.
- Specify which outputs are advisory, which require approval, and which actions are prohibited.
- Give reviewers the source context, time, authority, and skill needed to make a real decision.
- Provide a visible way to correct, override, escalate, pause, and audit the system.
- Require qualified review before decisions affecting rights, safety, employment, money, contracts, or regulated obligations.
Compare switching cost and lock-in
Before committing, identify what must move if the vendor, model, price, terms, or business requirement changes. Consider data and configuration export, prompt and evaluation portability, identity and integration dependencies, proprietary workflow logic, contract length, deletion support, and the time required to operate an alternative.
Buying can create contractual and data lock-in; building can create code, talent, infrastructure, and model dependency. Neither option eliminates lock-in. Prefer documented interfaces, owned evaluation cases, retrievable logs and business data, replaceable model boundaries where practical, and a tested offboarding plan proportional to the consequence of failure.
Use a staged decision instead of a permanent bet
- Write the outcome, current baseline, non-negotiable controls, and unacceptable failures.
- Shortlist the non-AI, existing-product, packaged-product, integration, and build options that could meet them.
- Run the smallest representative evaluation using the same cases and measures for each credible option.
- Compare total cost over the same horizon, including internal time, licensing, integration, review, monitoring, support, switching, and retirement.
- Choose a reversible pilot, assign an owner, and set an explicit expand, change, replace, or stop decision date.
Questions about this topic
When should a business build AI instead of buying it?
Build when a valuable workflow or proprietary information creates meaningful differentiation, available products fail a material requirement, and the business can own evaluation, security, monitoring, maintenance, and future changes. Otherwise, configuration, purchase, or integration is usually the smaller commitment.
What is the non-AI alternative to an AI workflow?
The alternative may be process simplification, clearer forms and policies, deterministic rules, search, ordinary workflow automation, or no project. Use AI only where interpreting uncertain information adds enough value to justify its additional evaluation and control burden.
How can a business reduce AI vendor lock-in?
Keep business data and evaluation cases retrievable, document integrations and configuration, understand export and deletion terms, avoid unnecessary proprietary dependencies, use replaceable interfaces where practical, and define an offboarding test before the system becomes critical.
Does human review make an AI workflow safe?
Not by itself. Review must occur before consequential action, and the reviewer needs adequate context, time, authority, and a way to correct, escalate, pause, and audit the system. Some uses also require qualified legal, security, compliance, or domain review.
Sources and further reading
These primary and authoritative references informed the decision frameworks in this article.
- Artificial Intelligence Risk Management Framework (AI RMF 1.0)National Institute of Standards and Technology
- AI RMF Generative Artificial Intelligence ProfileNational Institute of Standards and Technology
- Managing technical lock-in in the cloudUK Government Digital Service
- OECD AI PrinciplesOrganisation for Economic Co-operation and Development