Should You Build, Buy, or Borrow AI? Three Questions That Cut Through the Noise
How to think about building, buying, or partnering on AI - before someone else decides for you
Picture a leadership team in a room. Three vendor demos are lined up for the afternoon. The IT lead wants to build something internally. Finance is nervous about licensing costs. The CEO read a case study on a flight and is now half-convinced there’s a platform that does everything. The meeting ends with a follow-up scheduled, and nothing decided.
The instinct is understandable. The landscape moves fast, the competitive pressure feels real, and buying looks like the path of least resistance. But the choice of how to acquire AI capability is itself a strategic decision, one that shapes what your organisation learns, what it controls, and what it becomes dependent on for years ahead.
The question behind the question
The build-buy-borrow decision looks like a procurement question. It is really a capability question: which AI competences do you want to own, and which are you comfortable renting?
When an organisation buys an agent from a vendor, it gains access to the output - the results the agent produces. But the understanding of how that agent works, how to improve it, how to govern it, and how to replace it if the vendor changes course - that stays with the vendor. You learn to use a tool; you do not build the institutional muscle to understand AI systems.
The organisations that will navigate AI complexity well over the next decade are those building internal judgment - the ability to evaluate, iterate, and govern AI continuously - alongside any tools they deploy.
That judgment doesn’t develop from using a vendor’s product. It develops from the decisions made around it. As AI moves from peripheral experiment to operational infrastructure, this distinction matters more than it ever has.
Three paths, and what they actually cost
Building in-house is the right path when the process is a genuine source of competitive advantage, when the data is too sensitive for a vendor to handle, or when no off-the-shelf solution comes close enough to adapt. The cost is real and ongoing.
Buying a prebuilt agent from a vendor is often the right choice for functions that are not differentiators - routine HR processes, standard invoice handling, common customer queries. A vendor who has already solved the problem well is a better choice than building from scratch. The risks are less visible than the savings, though: KPMG notes that as agent ecosystems mature, commoditisation becomes inevitable - a solution that feels distinctive today may feel generic within two years.
Borrowing, or co-developing with a partner, is the most underrated of the three paths. It works best when an organisation needs to move faster than a full build allows but wants to retain more learning and control than a pure purchase provides. The value is not just the agent that gets built, it is the internal capability that develops through the process of building it together.
The tensions the frameworks don’t name
The conventional wisdom around this decision contains several internal contradictions worth naming directly.
Company size is a poor guide to the right decision. The more useful variables are capability density - do you have the people to build and govern this, durably? - and strategic stakes - does ownership of this function actually matter to your position?
A 50-person company with three ML engineers and a clear proprietary data advantage might be exactly right to build. A 5,000-person company running generic HR workflows should almost certainly buy. The number of employees is rarely the relevant variable.
Three questions before the framework
Before any comparative evaluation of vendors or build options, three questions tend to cut through most of the complexity. They should be answered in order, each one narrows the decision space before the next is applied.
Question 1: Is this process a source of competitive advantage, or a cost of doing business?
If yes (differentiator) → Build or co-develop. Ownership of the capability matters. A vendor’s roadmap will not align with your strategic priorities.
If no (cost of doing business) → Buy from a vendor. The problem is general enough that a proven solution exists and there is no strategic value in rebuilding it.
Question 2: How sensitive is the data flowing through this agent?
If highly sensitive or regulated → Build, or partner with very specific contractual data controls. Patient records, financial models, and trade secrets require full architectural control.
If standard business data → A reputable vendor is viable. Verify their data handling, residency, and compliance posture - but this is not a blocking constraint.
Question 3: Do you have - or are you actively building - internal AI governance capacity?
If governance is in place → Evaluate build vs. buy on economics and speed. You have the internal infrastructure to govern whatever you deploy.
If governance is not yet established → Borrow first. Use a co-development partnership to build that governance muscle before committing to build or scaling a vendor relationship.
The KPMG comparative framework is excellent for confirming a direction once these three questions have pointed you toward one. But applying the matrix before clarifying these fundamentals often produces the wrong conclusion, because it optimises for the wrong variables.
At Zeroto100, we have found that leaders who struggle most with this decision are often treating it as a one-time choice. The more useful frame is a recurring evaluation. What made sense to buy at an early stage of AI maturity often becomes worth building once the organisation has developed enough internal capability to do it well. And what seemed worth building in isolation often becomes a candidate for partnership once the maintenance burden becomes clear. The decision is not a destination, it is a posture you revisit as the organisation and the landscape evolve together.
What this means in practice
For leaders facing this decision in the near term, several principles hold regardless of the path chosen:
Governance cannot be retrofitted. Whether you build, buy, or borrow, the mechanisms for monitoring, evaluating, and iterating on AI agents need to be designed alongside the deployment, not added afterward when something goes wrong.
The path is rarely pure. Even organisations with strong build mandates typically co-develop with technology partners on significant components. Planning for a hybrid from the start is more honest than assuming clean separation.
Vendor lock-in is a long-term cost, not a short-term concern. The economics of buying often look attractive in year one. Model the dependency risk over three to five years before committing to a deep integration.
The most valuable thing you build may not be the agent. It is the institutional habit of evaluating AI continuously, knowing what it is doing, why, and whether it is still the right approach. That habit outlasts any individual tool decision.
Company size does not determine the right path. Capability density and strategic stakes do. Assess these honestly before letting organisational scale drive the conclusion.
Closing reflection
As AI becomes operational infrastructure rather than optional capability, the question of what your organisation owns, rents, and governs may matter more than any single tool it deploys. Looking at your most strategically important AI initiative today: if the system behind it were no longer available tomorrow, would your organisation know how to rebuild it, or would you find yourselves starting from zero?