Short answer
Buy when the process is common, the product fits without heavy workarounds and your data is allowed to go where the vendor processes it. Build when the process is specific to your operation, depends on your own data and rules, must integrate deeply with in-house systems, or must meet hosting and audit requirements a product cannot. Many good solutions combine both: commercial models or platforms as components, with custom logic and integration around them.
Every operations or IT leader looking at AI faces the same choice. There are products for almost every task, and there are teams who will build to order. Both can be right. The mistake is choosing by habit, or by the most convincing demonstration, rather than by the fit with your process and constraints.
Here are seven questions that make the decision clearer.
1. How specific is the process?
Email drafting, meeting notes and generic document search work in similar ways across companies. Products in these areas are mature, and building your own rarely pays off.
A permit-to-work process across your sites, an SMS run to your manual, or an inspection rule for your parts is different. A product will either fit closely, which is worth checking carefully, or it will need workarounds that cost time every day. The more your process reflects your own rules and experience, the stronger the case for building.
2. Where must the data stay?
Many AI products process data in the vendor's cloud, sometimes in a region you do not control. For safety reports, patient information, engineering data or commercially sensitive documents, check:
- Where data is stored and processed, and under which jurisdiction.
- Whether your data is used to train or improve the vendor's models.
- Whether the product can run in your cloud tenant or on your servers.
If the answers do not meet your rules, a custom solution running on your infrastructure may be the only option.
3. How deep is the integration?
AI rarely creates value on its own screen. It needs to read from and write to the systems people already use: ERP, CMMS, document management, historians, HR systems. Ask how a product connects to each of them, and who maintains the connection when either side changes. Deep or unusual integrations favor a custom build, or a product with a strong, documented API.
4. What does the regulator or auditor need?
Regulated activities need evidence: who did what, when, based on which information. Check whether a product provides the audit trail, access control and record retention your auditors expect, and whether you can explain how its AI outputs were produced. Under the EU AI Act, some uses carry specific obligations for providers and deployers, which you need to be able to meet whichever route you choose.
5. What is the cost over several years?
Compare total cost over a realistic period, not the first year. For products, include per-user or usage fees as adoption grows, add-on modules and integration work. For custom builds, include development, hosting, model usage, support and the cost of changes over time. A product is often cheaper to start. A custom solution can be cheaper to scale, particularly when pricing depends on the number of users.
6. How fast do you need it?
A product can be running in weeks if it fits. A custom solution takes longer to reach first use, though a focused build on one process can produce a working version quickly. If the need is urgent and the fit is good, buy now and revisit later.
7. Who owns it afterwards?
With a product, the vendor decides the roadmap, pricing and support life. With a custom build, you own the code and the data, and you need a partner or internal team to maintain it. Consider which risk you are more comfortable carrying.
Summary
| Factor | Points to off-the-shelf | Points to custom |
|---|---|---|
| Process | Common across companies | Specific to your rules and operation |
| Data | Can be processed by the vendor | Must stay in your environment |
| Integration | Few systems, standard connectors | Several in-house or unusual systems |
| Audit | Product meets your record and access needs | You need control over logs and evidence |
| Cost | Low usage, short horizon | Many users, long horizon |
| Time | Needed in weeks and fits well | Worth a few months for a better fit |
| Ownership | Comfortable with vendor roadmap | Need control of code and data |
The combined route
The choice is rarely all or nothing. A common pattern is to use commercial language or vision models as components, accessed through private endpoints, and build the parts that make the solution yours: the workflow, the rules, the integrations, the interface and the audit trail. This gives you the quality of leading models without giving up control of the process.
Questions to ask any vendor or builder
- Can we run a trial on our own data and questions, and see the results in full?
- Where is our data processed and stored, and is it used for training?
- How do we see why the system produced a given output?
- What happens to our data and configuration if we leave?
- How are changes to the underlying models tested before they reach us?
Whichever route you choose, start with one process, a clear owner and a way to measure the result on your own data.