Should we build or buy AI for our business?

Buy first if the work is drafting, summarising or searching documents that already live in one suite, and a person checks every output. Build, or more often buy the model and build the integration around it, when answers need data from several systems, must cite a verifiable source, must respect detailed permissions, or must be logged for an auditor or regulator. Test the bought tool against your real questions before deciding.

Is Microsoft Copilot or ChatGPT Enterprise enough for company data?

Often, for documents, email and chat inside the suite they are built for. Microsoft says its Copilot only surfaces data a user already has permission to view, so it is as safe as your existing permissions and no safer. These tools are weaker when the answer needs live ERP records combined with contract text, row-level permissions, or an audit log you control and can show an inspector.

How much does it cost to build a custom LLM application?

The main cost drivers are the number of systems you integrate, the number of distinct question types you must answer well, and how strict the permission and audit requirements are. Integration and evaluation usually cost more than the model work. Running costs scale with usage and with how much context each query sends. A narrow first version scoped to one workflow keeps both under control.

What is the hybrid approach to building AI?

The hybrid approach means buying a frontier model through an enterprise API or an existing assistant, and building only the layer that connects it to your business: retrieval over your documents, connectors to your ERP and CRM, permission filtering, citations, evaluation and logging. You own the part that encodes your data and rules, and the model stays a replaceable component you can swap when a better one appears.

Do we need to train our own AI model?

Almost certainly not. Training a foundation model is out of reach and unnecessary for a mid-size company, and fine-tuning is rarely the right way to give a model your company's knowledge. Retrieval, where the system looks up the relevant records and passages at question time, keeps answers current, citable and permission-scoped. Building an AI system in practice means building the integration around a model you buy.

Build vs Buy AI: When Custom LLM Apps Pay Off

The decision you are actually making

For most mid-size companies the honest default is to buy first. Off-the-shelf assistants are good and cheap to trial, and a bought tool that people use beats a custom one that is still being scoped. Building is justified when your important questions cross systems, need a checkable source or sit under audit. Even then you rarely build the AI itself. You build the layer that connects a bought model to your business.

“Build” scares people for the wrong reasons. Nobody sensible at a company of 200 or 2,000 people is training a model. The real options are:

Buy a general assistant: ChatGPT Enterprise, Claude Enterprise, or Microsoft’s Copilot inside Microsoft 365.
Turn on the AI features in software you already pay for: the assistant inside your ERP, CRM or helpdesk.
Buy the model and build the integration: retrieval over your documents, connectors to your systems, your permission rules, your logging.
Build a dedicated application on top of that integration, with its own interface and workflow.

The question that decides it is whether a bought tool can reach the data and meet the rules your important questions require.

There is evidence that buying is the safer first move. MIT’s NANDA initiative reported in 2025 that AI tools bought from specialised vendors, together with partnerships, succeeded about 67% of the time, while internal builds succeeded about a third as often (Fortune). The researchers noted that companies were reluctant to share their failures, so treat the exact figure with care. Note also that working with an outside specialist counted on the “buy” side. The weakest option was an in-house team building from scratch.

What off-the-shelf AI does well

Bought tools are strong when the work is reading, drafting and summarising, the material lives inside one suite, and a person reviews every output. For many teams that is the whole requirement.

Microsoft states that its Copilot “only surfaces organizational data to which individual users have at least view permissions”, and that prompts and the data it reads are not used to train foundation models (Microsoft Learn). Pricing is per seat: as of October 2026, Microsoft’s Copilot Business add-on lists at $21 per user per month (Microsoft). That is cheap enough to trial on real work.

A bought tool is probably enough when:

The questions are about documents, email and meetings rather than records in a database.
The person who asked uses the answer and can see whether it is right.
A wrong answer costs a few minutes, not a customer, a fine or a bad payment.
Your permissions are already sound, because the tool will respect them exactly as they are.

That last point is easy to miss. A tool that respects your permissions also inherits their mistakes. If a folder of salary reviews is shared with the whole company, an assistant that searches everything you can open will find it. Clean up your sharing first, which you would also have to do before building anything.

Where bought tools run out

Bought tools fall short when the answer needs more than one system of record, must point to its exact source, depends on permissions finer than “can open the file”, must be logged for someone outside the company, or has legal or financial consequences. If two or more of these describe your important questions, building starts to pay off.

The answer lives in more than one system

“Which contracts expire next quarter, and which of those customers are behind on payments?” needs contract text from a document store and payment status from the ERP, joined on the customer. A general assistant can read the contracts and the ERP’s own AI can read the ledger, but neither combines the two under your rules. It is the most common reason companies outgrow bought tools, and mostly a data-engineering problem.

The answer has to cite something checkable

“According to the contract” is not a citation. A useful one names the document, clause and page, or the specific ERP record, so anyone can verify the answer in seconds. Retrieval systems do this well, as covered in our guide to RAG, fine-tuning and prompting, but only when designed to. They also need a rule for when no source is found: say so, rather than produce something plausible.

Permissions are finer than file access

Rules like “account managers see only their own clients” or “this region’s figures are restricted” often live in the ERP’s role model, not on any folder. A bought assistant enforces the permissions of the systems it is plugged into. If your real rules sit somewhere else, someone has to build the filter.

Someone outside the company will ask what the system said

Regulators, auditors and courts care about who asked what, what the system answered, and which data it used. In 2024 the tribunal in Moffatt v. Air Canada held the airline liable for its chatbot’s wrong answer about a bereavement fare, rejecting the argument that the chatbot was responsible for its own statements. The company owns what its AI says, so it needs a log it controls and can produce.

The workflow is regulated or consequential

When an answer feeds a filing, a payment, a client report or an approval, it needs a review step, a refusal path, and an evaluation set that proves it works on your hardest inputs rather than on a demo. A bought tool lets you configure some of this, rarely all of it.

The hybrid middle: buy the model, build the layer

Most companies that outgrow a bought assistant end up here: a frontier model bought through an enterprise API or an existing assistant, and only the connecting layer built. They own the part that encodes their data and rules, and the model stays replaceable.

The integration layer usually contains:

Retrieval over your document stores, with content cleaned and indexed so the right passage is found and cited.
Tool connectors that let the model query the ERP, CRM or warehouse through controlled, read-only calls instead of copying data somewhere new.
A permission filter applied before anything reaches the model, using your actual access rules.
Logging and evaluation: every query recorded, and a fixed test set re-run whenever anything changes.

Connectors have become much easier to standardise. The Model Context Protocol, introduced by Anthropic as an open standard for connecting AI applications to external systems, is now governed by a Linux Foundation body co-founded with OpenAI and Block, and Anthropic reports that ChatGPT, Gemini and Microsoft Copilot have adopted it (Anthropic). A connector you build to your ERP once can serve the assistant you already bought, a custom application, or both. The hybrid can extend the bought tool rather than replace it.

The same layer is what makes AI agents safe to deploy later: an agent is only as trustworthy as the tools it can call and the permissions those tools enforce.

An example of when building is justified

Lacre, a platform WizardsLabs built for Argentine trust companies, shows each of these signals. Its value comes from answering questions that combine ERP records with contract text, citing the source for every answer, with each query checked against permissions and logged.

In a typical trust company, the books live in Odoo, contracts and deeds in Google Drive or shared folders, deadlines in spreadsheets and instructions in email. “Which trusts expire next quarter, and which renew automatically?” needs dates and statuses from Odoo and the term clause from each contract, at the same time.

Lacre connects to those sources where they already are, so documents never move. It answers in natural language and cites the document, clause and page, or the Odoo record, and when it finds no backing it says so. Every search is filtered by the user’s permissions before relevance, and every query is logged for audit, which matters for firms that answer to Argentina’s anti-money-laundering authority. A general assistant can read a contract and Odoo can report a balance. Joining the two with permissions, logging and citations is the part that had to be built.

What drives the cost in each direction

Bought tools cost per seat, so the bill grows with headcount. Built systems cost mostly integration and evaluation up front, plus running costs that follow usage. The useful comparison is what each option costs to answer your important questions to the standard you need.

On the buy side, count:

Seats for everyone who needs access. At the list price above, 200 users is $4,200 a month before any usage-based extras.
Permission clean-up before deployment, which is real work either way.
The cost of the gap. If the tool handles the easy questions and people still assemble the important ones by hand, the expensive work has not gone away.

On the build side, the drivers are:

Number of systems to integrate. Each connector is ordinary engineering, and integration is usually the largest single cost.
Number of distinct question types. Each needs test cases and tuning, so a narrow first version is far cheaper than an all-purpose one.
Strictness of permissions and audit. Row-level access rules and long log retention add design work.
Inference. Every query costs money, more as context grows. Good retrieval keeps it small.
Maintenance. Someone has to own the evaluation set, the connectors and model upgrades.

Neither column is reliably cheaper. For a large workforce drafting emails, buying wins. For a small team asking hard cross-system questions, seats do not buy the missing capability, and a build can cost less than the gap it closes.

Lock-in, both ways

Buying ties you to a vendor’s suite, roadmap and pricing; building ties you to your own codebase and whoever maintains it. You cannot avoid lock-in, but you can choose what you own and keep the rest swappable.

Own the index and the evaluation set. They capture what your system knows and what “correct” means for you. With them, everything else can be rebuilt.
Put the model behind an interface, so switching to a better one means re-running the evaluation suite, not a migration.
Prefer open protocols for connectors. An MCP connector to your ERP works with more than one assistant.
Read the data export and training terms before signing, whether you are buying a tool or hiring a team.

The decision table

If this describes your main questions	Lean towards	Why
Drafting, summarising and searching documents in one suite	Buy	Bought assistants are strong here and cheap to trial
Questions that stay inside one ERP or CRM	Buy (vendor AI feature)	The product already holds the data and permissions
A person checks every answer before it is used	Buy	A wrong answer is cheap to catch
Answers need ERP records combined with documents	Hybrid	Needs connectors and retrieval joined under your rules
Every answer must cite a verifiable source	Hybrid or build	Citations and “no source found” must be designed in
Permissions finer than file access (by client, region, role)	Hybrid or build	Someone has to implement your real access rules
An auditor or regulator may ask what the system said	Build	You need a log you own and can produce
Answers feed filings, payments or client reports	Build	Needs review steps, refusal paths and evaluation on hard cases
Large workforce, simple tasks, no integration	Buy	Per-seat pricing wins at volume for simple work
Small team, hard cross-system questions	Hybrid or build	Seat costs do not buy the missing capability

How to make the decision in a month

Decide with evidence, not vendor demos: collect your real questions, try a bought tool against them, and build only for what it cannot answer.

Collect twenty to fifty real questions from operations, finance or compliance, including the ones that currently take an afternoon.
Tag each one by the systems it touches, the cost of a wrong answer, and who may see the answer.
Run a bought tool against them on a trial licence, with real data, scored by the people who ask those questions.
Sort the failures. Missing data, cross-system joins, citations and permissions are your build scope. Prompting problems mean fixing the prompts and keeping the tool.
Scope the build to the gap: one workflow, one or two systems, an agreed accuracy bar, then expand.

Sometimes this shows you do not need to build anything, which is a good result.

Where we sit

We build AI systems in the hybrid middle: bought models, with retrieval, connectors, permissions and evaluation built around them so they work on your data and stand up to an audit. We will also tell you when a bought tool covers the need. That answer earns us less, which is why you should expect a vendor to be willing to give it.

If you are weighing a Copilot or ChatGPT rollout against something custom, bring the questions your team actually asks. The initial consultation is free, and we reply within 24 hours.

Build vs buy AI: when an off-the-shelf tool is enough, and when it is not