Internal AI Assistant: Build vs Buy, With Real Costs and a Decision Tree [2026]

An internal AI assistant is an AI system that answers employees' questions from company data and, in its useful form, also acts in company tools: it looks up the order in the ERP, drafts the reply in the mailbox, creates the ticket. The build-vs-buy decision is not about the chat window, which any team can stand up in an afternoon. It is about the four things behind the window that decide whether the assistant is still in use in twelve months: live connections to your systems, permissions on every row it reads, approval gates before it writes, and logs an auditor accepts.

This guide gives you a real cost model for three paths (build from scratch, assemble from open source, buy a platform), an honest list of what the open-source path does not include, and a decision tree by team size and regulation. It deliberately skips the part everyone else covers first, the retrieval pipeline: we did that in how to build an AI knowledge base.

The dividing line is whether the assistant can reach your data with your permissions, and whether it can act. A chatbot with a system prompt and a PDF upload is a demo. An internal AI assistant reads from the CRM, the ticket system, the wiki and the shared mailbox, shows each person only what they may see, and completes tasks with a confirmation step. That second definition is what the AI operating system article calls the six components, and it is the definition that makes build-vs-buy a real question, because the first three components are easy and the last three are where in-house projects stall.

It matters because the demo is where most build decisions are made. The prototype impresses in week two; the permission model, the approval flow and the audit log are still open in month six. kapa.ai's build-vs-buy analysis puts it plainly: teams get 70% there and the remaining 30% is the part that never ships.

Build means your developers write the assistant on top of model APIs: retrieval, connectors, permissions, agent logic, interface. Assemble means you run open-source components (Open WebUI or LibreChat as the chat, n8n for workflows, a vector database for retrieval) and write the glue. Buy means a managed platform that ships the six components and you configure connectors, roles and agents.

The honest summary: build wins only at very high volume or with a hard requirement no vendor meets; assemble wins when you have a platform team and a regulatory need for on-premise operation; buy wins for almost everyone below about 500 people, on total cost and on time to a usable assistant. The table gives the numbers behind that claim.

The assemble path is the most underestimated of the three, because the first week goes so well. Open WebUI or LibreChat give you a polished chat in an afternoon; n8n gives you a workflow that reads a mailbox and writes a Slack message by the end of the day; a vector database and an embedding model give you search over your PDFs. What you have at that point is the demo. The list below is what you still have to write yourself, and each item is a multi-week piece of work with an owner. Our comparison of Open WebUI, LibreChat and AnythingLLM and the real cost of self-hosted AI go into the operating side.

Building is the right call in three situations, and it is worth naming them so the rest of the article does not read as a sales pitch. First, volume: at roughly a million conversations a year for a complex, multi-system agent, the three-year cost of a dedicated team drops below platform pricing. Second, a hard regulatory requirement for air-gapped operation with no managed component, which rules out every cloud platform including ours. Third, the assistant is your product: if you sell it, you own it.

Outside those three, the evidence points one way. McKinsey's 2026 survey has about a third of organisations choosing to build with agentic coding tools, which means two thirds buy, and the ones that build are overwhelmingly large. For a 40- to 500-person company the AI strategy for small business argument holds: spend the engineering on your product, not on rebuilding a permission model.

Connect the systems where questions are asked and answered today, not the systems with the most data. For most companies that is chat (Slack or Teams), the ticket or CRM system, and the document store; the calendar comes fourth because it turns the assistant from reactive into proactive. The ERP, the one everyone names first, comes later: its data is structured, its questions are narrow and its integration is the most expensive. The data silos article explains why the integration project is where build budgets vanish.

Run a short anonymous survey before you decide: where do people look things up, whom do they ask, what can they never find. The answers name your first three connectors, and they are rarely the ones IT would have picked.

Whichever path you take, the rollout decides adoption more than the technology. The pattern that works: one department, three connectors, thirty real questions as the acceptance test, a restricted-user permission test before anyone else gets access, then one supervised agent (a weekly report or a stalled-deal reminder) so the assistant does something visible without being asked. Widen to the second department after four clean weeks. The pilot-to-production article covers the failure modes in detail; the short version is that pilots die from missing owners and missing permissions, not from missing features.

Teamo AI is the bought-platform path with the six components included: live connectors to Slack, Teams, Jira, Notion, HubSpot, Pipedrive and your calendar, the 7-ring permission model with per-row access, standing agents with approval gates, three audit logs, and a swappable multi-LLM model layer (OpenAI, Anthropic, Google, Mistral, Aleph Alpha). Integrations install from the chat in minutes and agents are described in the same chat, so the 90-day rollout above is typically a two-week one. EU-hosted, no seat minimum, self-hosting optional if the regulator later demands it.

Where it is not the answer: air-gapped operation with no managed component, or an assistant you intend to sell. For those, the assemble path with a multi-LLM base is the honest recommendation, and the self-hosted cost breakdown is where to start.

Build vs buy is rarely the first AI decision a company makes, and it should not be the last. Most teams arrive here after a ChatGPT or Copilot licence disappointed: the ChatGPT Enterprise vs Copilot comparison explains why both are chat tools without company context, which is the gap an internal assistant is meant to close. Whichever path you take, the thing you are building or buying is an AI operating system for companies: context layer, permissions, model layer, agents, audit logs. That article carries the price table and the EU buyer checklist this one deliberately leaves out.

Three neighbours complete the picture. If the assistant is supposed to act, not only answer, read what an agentic operating system is before you size the build: approval gates and idempotency are the part self-built stacks skip. Below 500 people, the AI platform decision guide for small business narrows the buy options by seat floors and EU hosting. And whatever you deploy needs rules for the people using it: the AI policy template for companies is the two-week document that goes with the rollout. The concept underneath all of them is the AI context layer.