Build vs buy for AI implementation

Almost nobody builds an AI system from nothing. A custom implementation may still use a hosted model, cloud database and commercial monitoring. A purchased product may require custom connectors, policies and evaluation.

The decision is better framed as: which layers should the business own, and which should it rent?

Buy the commodity, examine the workflow

A packaged product is a strong starting point when the task is common, the process can adapt to the product, the data is supported safely and fast deployment matters more than unusual behaviour.

Examples include meeting transcription, general drafting assistance and common help-desk features, subject to privacy and security review.

Buying can reduce initial development, but it does not remove implementation. The business still owns configuration, permissions, training, process change, vendor oversight and the consequences of output.

Build around differentiated work

A custom workflow becomes reasonable when:

• proprietary data or rules create meaningful advantage;
• the task crosses several internal systems;
• generic products cannot enforce the required permissions and approvals;
• the interface must fit a specialized operational role;
• evaluation and traceability need to be controlled closely;
• volume makes manual work or per-unit product pricing material;
• the organization can operate and improve the system after launch.

Building rarely means training a foundation model. It often means composing a model with retrieval, deterministic rules, tools, permissions, evaluation and human review.

Compare six layers

For each option, state who owns:

1. Model: selection, version changes and fallback.
2. Knowledge: ingestion, approval, permissions and freshness.
3. Workflow: rules, tool calls, thresholds and human decisions.
4. Interface: user experience, accessibility and feedback.
5. Operations: logs, evaluation, monitoring, incidents and support.
6. Data: purpose, contracts, retention, export and deletion.

A vendor may manage the model while the business owns the workflow. That mixed architecture is often the practical answer.

Evaluate the purchased product with your cases

Do not buy from a benchmark or demo. Use representative examples, rare failures and real permission roles. Test groundedness, action limits, data handling, export, latency, override and recovery.

Ask the vendor:

• Which model and subprocessors are used?
• Can model or product behaviour change without notice?
• Is customer data used to train shared systems?
• Can we export prompts, configuration, knowledge and audit records?
• How are document permissions enforced?
• What service levels and incident duties apply?
• What happens at termination?

The Government of Canada's agentic AI guide recommends due diligence on vendors, data flows, permissions, monitoring and exit or recovery mechanisms. Government of Canada

Calculate life-cycle cost

For buy, include licences, usage, premium connectors, administration, integration, evaluation, training, migration and exit. For build, include discovery, development, hosting, model usage, monitoring, security, ongoing evaluation, support and changes when vendors or models move.

18F's technology guidance recommends comparing product life-cycle costs and notes that real projects often mix commercial and custom components. It also warns that extensive customization of commercial software can carry the risks of both approaches. 18F De-risking Guide and Technology Budgeting Handbook

Most AI Labs currently publishes $4,000 to $8,000 for an AI Workflow Pilot, $8,000 to $18,000 for a Controlled AI Agent in production, and $18,000 to $40,000 and up for multi-system implementations, with model and third-party usage estimated separately. These are our bounded implementation ranges, not market averages, and exclude many enterprise requirements. The live source of truth is the pricing page.

Price the exit

Vendor lock-in is not only about data export. The business may depend on proprietary prompts, indexes, workflow builders, evaluation history and staff habits. Request a sample export before signing. Identify which components could be replaced and how long the service could operate during a transition.

Custom code also creates dependency if one developer understands it. Require repositories under business control, deployment instructions, configuration records and an operational handoff.

Use a staged decision

1. Map the task and current baseline.
2. Test whether a normal automation solves it.
3. Trial one or two products on an evaluation set.
4. Identify the gaps that matter commercially or for risk.
5. Build only the missing differentiating layer.
6. Pilot with limited data, users and actions.
7. Expand only when measured outcomes justify ownership cost.

NIST's AI Risk Management Framework provides a useful structure: govern the use, map context and harms, measure performance, and manage the remaining risk. NIST AI RMF Core

The right answer is rarely ideological. Buy where the capability is common and acceptable. Build where ownership changes the result. Integrate the two with a clear exit.

Source check

Government guidance supports the risk, vendor and life-cycle principles. Most AI Labs prices are first-party examples and must not be represented as Canadian market averages. Product capabilities and terms require current verification.

Sources

• Government of Canada: Guide on the use of agentic artificial intelligence
• NIST AI RMF Core
• NIST: Generative AI Profile
• 18F: De-risking custom technology projects
• 18F: Technology Budgeting Handbook
• Most AI Labs pricing