Decide whether to build or buy an AI tool

Leads are rarely asked about AI in the abstract. More often, three offers arrive at once: the AI feature in a suite the team already uses, a specialist vendor, and an internal team that offers to build. Start from the work, not the products: the outcome you need (for example, invoices posted correctly and on time with less keying), the volume, and who will use the tool.

The three kinds of option usually bring different strengths and costs:

A model API is a service that runs a provider's AI model on request and charges per use.

Fix the order of work before any results arrive: hard gates, then a pilot on your own documents, then three-year cost on one basis, then a weighted score, then contract terms and an exit plan. Name who decides and by when, so the comparison ends in a decision rather than a longer list.

A gate is a requirement the company will not trade for any price or score. An option that fails a gate is out until a written change fixes it. Five gates are common for a tool that handles company documents:

• Data region: where data is stored and processed, including any AI provider the vendor uses behind the scenes.
• No training on your data, written in the contract. An FAQ page or a sales email can change without notice and does not bind the vendor; a term in the signed contract does.
• An independent security report whose scope covers the service. One example is a SOC 2 Type II report (also written Type 2): an auditor reports whether the vendor's security controls actually worked over a period, often several months. A Type I report only checks how the controls were designed, on one date. Another example is an ISO/IEC 27001 certificate, which certifies a company's information security management system; its scope must include the service you will use.
• Single sign-on (SSO): staff sign in with the company login, so IT can remove access in one place.
• Full export and deletion: original files, extracted data, and the audit trail (the record of who changed what, and when), plus deletion when you leave.

Record each gate twice: as offered, and after a signed change. A fix that exists only in another contract tier changes the price, so price the option at that tier.

Building does not skip the gates. The model provider is an outside company that receives your data, so read its terms as you would a vendor's. As of November 2026, for example, one large provider's page says API data is not used for training by default and offers in-region processing in some regions only (see sources). The build itself must also deliver SSO, an audit trail, and export before go-live.

When a vendor processes personal data on your behalf, data protection law may require specific contract terms; in the EU, Article 28 of the GDPR lists them. Check with counsel which terms apply. Nothing here is legal advice.

Each row is evidence a vendor might send. Decide whether it meets the gate as written in the previous section. The rows are generic and are not part of the scenario below.

Vendor demos use clean samples. Draw your pilot from the real mix (scans, phone photos, credit notes, multi-page bills) and add known problem cases you caught before, such as duplicates.

Keep the test fair: the same sample, the same answer key (what was actually posted), and the same scoring for every option, with a bar set before any results arrive.

Four habits keep the reading honest:

• Count at the document level. Field accuracy can be high while many documents still need a person: one wrong field means the whole document needs a fix. The share of documents needing a fix is what drives staff time.
• A document with no result is a failure, not a row to drop. Dropping it makes the tool look better than it is.
• Do not tune on the test. If someone adjusted an option while looking at the pilot documents, its results are best case until it is tested on documents it has never seen.
• Small counts are rough. With a dozen known cases, one case moves the rate by about 8 points.

Compare options over three years. One-time setup spreads out, contracts run for years, and a build's maintenance only shows up after launch.

Put every option on the same lines:

Price internal hours at a loaded rate: the full cost of an hour of someone's time, including salary, benefits, and overhead. That way an engineer's week counts like a vendor's invoice.

Then work out cost per document: the three-year total divided by the documents processed. It makes options with different price shapes comparable.

Two more checks. Model what a price rise at each renewal would add, and what a cap would limit it to. Leave out lines that are the same for every option, and say that you did.

Every estimate leaves something out. Ask for each one on the same lines as the others, with a named owner for maintenance.

What build estimates often leave out:

• Features vendors already include: SSO, an audit trail, export, and checks against history such as duplicate detection.
• Maintenance: supplier formats change, bugs appear, and security updates and access reviews recur.
• Model migrations. Providers retire models on their own schedule, and each move means re-testing and adjusting. As of November 2026, for example, one provider's published policy promises at least 60 days' notice before it retires a publicly released model (see sources).
• On-call cover in the busiest weeks, key-person risk on a small team, and the team's other work that waits.

What buy estimates often leave out:

• Price rises at renewal, minimum terms, and long notice periods.
• Integration hours and the time it takes to manage the vendor.
• The vendor's own AI provider, and changes to it.

Building is the right call when the work sets you apart from competitors, when no vendor passes the gates, or when volume and fit justify a team that owns the tool for years.

Before signing, read six things: the minimum term; the notice period before renewal; the price-change clause (and ask for a cap); the data terms (no training, deletion at exit); notice of changes to the vendor's own subcontractors; and the export format and any fees.

An exit plan answers one question: how would we leave within the notice period? It needs:

1. An export tested before signing, not only promised.
2. The manual or alternative route, documented and kept working.
3. An owner for the switch.

Turn each risk you found into a condition: something to sign, something to test before signing, or a trigger that lets you leave. "The vendor may change subcontractors" becomes a notice clause; "nobody has tried the export" becomes a test before signing.

The NIST AI Risk Management Framework, a voluntary US guide, makes the same point. Its GOVERN 6 category asks for policies and procedures for AI risks from third-party software and data, and for contingency processes to handle failures or incidents in third-party data or AI systems deemed high-risk.

A weighted score helps compare options that may all be chosen. It cannot rescue an option that fails a gate.

• Score only options that may be chosen, and score an option that needs a signed change at the changed price.
• Fix weights and scoring rules before the results. A common rule: the best option on a criterion scores 10, and the others score 10 times their value divided by the best (or the best divided by their value, when lower is better, as with cost or weeks).
• Do not count the same thing twice. If accuracy is already in the cost as fix time, a separate accuracy criterion counts it again.
• Check sensitivity. Would a reasonable change in the weights flip the winner? If so, say which weight decides, so the people choosing argue about the right thing.

Write the weights down with their reasons. "Cost 40% because the budget is fixed" is easier to defend than a number that appeared after the results.

Use the scenario and the pilot results.

Use the cost inputs, cost rules, planning rules, and scoring rules.