AI knowledge base for business: should a 20-50 person company buy one or build one?

What is an AI knowledge base, and how is it different from a wiki or a search box?

Three different machines get confused for each other. A wiki is a place people write things down. A search box returns a list of files and leaves the reading to you. An AI knowledge base answers the question in sentences and shows you the passage it took the answer from.

The mechanical difference is grounding. Your content gets ingested, split into passages, indexed for both keyword and semantic matching, filtered against your permissions, and only then handed to a model that is instructed to answer from those passages and nothing else. A good one says "I don't have that" when the answer genuinely isn't in your corpus. A chatbot bolted onto a wiki says something confident instead.

You will see the same product sold under several names: AI knowledge base, AI-powered knowledge base, enterprise AI search, and the framing we use elsewhere on this site, a second brain for a business. Vendors pick whichever word their buyer types. Underneath, they are all doing retrieval over your content.

A wiki stores answers, a search box finds files, and an AI knowledge base answers the question and shows its receipt.

Do you actually need one at 20-50 people?

Run one test before you shop. Write down the last ten questions someone asked inside your company, the real ones about a pricing exception or a client's history or why a decision went the way it did. Then mark how many were answered by interrupting a specific person. If it's two, you have a documentation habit and you don't need software. If it's seven, the knowledge is in people, not in systems, and that is what an AI knowledge base is for.

Three events reliably tip a company at this size into buying: someone senior left and took context with them, onboarding a new hire eats a week of a manager's time, or support and sales are opening five tools to answer one customer. Absent one of those, wait.

The trigger isn't document count, it's how often a human is the only index.

Should you buy an off-the-shelf AI knowledge base or have one built?

Buy, unless one specific thing is true. The decision rule we use on discovery calls: list every system that holds knowledge you would want answered from, then check which of them the tool connects to. If the list is covered, buy seats and stop reading. If the single most valuable source is your internal admin tool, your practice management system, or a database somebody built in 2019, no vendor is going to add that connector for a 35-seat account.

Pricing and product details checked against each vendor's own pages on 23 August 2026: notion.com/pricing, dashworks.ai/pricing, getguru.com/pricing, glean.com/pricing. Vendors change prices; re-check before you sign anything.

If everything you know lives in Slack, Drive and Notion, buy a tool and don't hire an agency. That includes us.

What does it cost, buy versus build?

Do the per-seat arithmetic before anything else, because it is the number that decides most of these. Thirty-five people on a $12 seat is $420 a month, roughly $5,000 a year, and it goes up every time you hire. A custom build is a fixed fee from around $8,000 for a first production scope, then infrastructure and model usage rather than licences. Year one, buying wins at this headcount. It usually takes until year two or three, or a doubling of headcount, before the maths flips.

The number nobody quotes you is the run cost of the thing you built. Embeddings on re-index, inference per question, and any scheduled job you forgot to bound. We watched this go badly on an adjacent project: a 20-50 person company gave every employee an always-on personal agent with its own token budget, spend hit roughly $3,000-$5,000 a month, and the programme was dead inside two months. That was an agent rollout rather than a knowledge base, but the mechanism transfers exactly. Idle loops and unbounded re-indexing bill you whether anyone asks a question or not.

So set a monthly ceiling and an alert on day one, cache aggressively, and route the cheap retrieval-only queries to a cheap model. This is boring and it is the difference between a $70 month and a $700 one.

Buying is a subscription that grows with headcount; building is a capital cost plus a usage bill you have to actively cap.

Why do AI knowledge base answers come back wrong, and what fixes it?

Almost always because retrieval failed, not because the model made something up. Barnett and colleagues catalogued seven distinct failure points in production RAG systems across three real deployments (Barnett et al., 2024), and several of them happen before the model writes a single word. The content was never captured. The right document ranked too low. The passage got cut off. The answer was in a table whose header was split away during chunking.

Four specific failures account for most of what we get called in to fix. Employees ask using internal acronyms and product codenames, and pure vector search misses exact strings, which is why hybrid keyword-plus-vector retrieval keeps winning in systematic RAG benchmarking (Wang et al., 2024). Tables and spreadsheets get chunked away from their headers, so a price appears with no label. Scanned PDFs never got OCR'd and are invisible. And the outdated policy outranks the current one because it is longer and better written.

None of that is fixed by a better model. It is fixed by an evaluation set: thirty real questions your team asked last month, with the correct source document written next to each one, run against the system every time anything changes. That paper's own conclusion is blunt about it, that validation of a RAG system is only feasible during operation.

If a vendor cannot show you retrieval quality on your own thirty questions, you are buying a demo.

Why does everyone say RAG chatbots are only 30-75% accurate?

Because that is what you measure when you point retrieval at documents that were never fit to retrieve from. The number gets repeated in IT communities with real scar tissue behind it. In a 114-comment thread in 2026, a systems administrator put it at "about 30-75% accurate in technical and procedural lookups" and said that just doesn't cut it for the work his team does. He is right about the range. He is describing his corpus, though, not the technology.

Put that next to the first number at the top of this page and the two explain each other. If three in four companies arrive with knowledge that is stale, contradictory or never written down, a system that retrieves faithfully from a corpus like that will be right somewhere between a third and three quarters of the time. It is answering the documents you gave it. Swapping the model changes almost nothing, which is why the teams who upgrade to a bigger one and see the same accuracy usually conclude the whole category is broken.

Two things move that number, and neither is a model. The first is treating the citation as the product rather than the answer. Every response shows the passage, the document it came from and when it was last touched, so a support rep who knows the domain spots a wrong answer in about two seconds. A knowledge base that answers without receipts is asking staff to trust a claim they cannot check, and after the second bad experience they stop asking it anything.

The second runs upstream of retrieval entirely: ownership and versioning before indexing. One named owner and one winning document per money topic, every duplicate archived or pointed at the winner. That is the work the contradiction section below is about, and it is the work that actually moves accuracy out of the range that sysadmin is quoting.

Accuracy scores measure your corpus, not the model. Fix the corpus and the number moves.

How do permissions work, and can it show the salary doc to an intern?

It can, if permissions are asked for in a prompt instead of enforced at retrieval. Instructing a model to "only answer HR questions for HR staff" is not access control; it is a suggestion. The design that holds is that every indexed passage carries the access rules of the document it came from, and the retrieval step filters on the identity of the person asking, so nothing can surface that the asker couldn't already open.

Two things catch companies out, and neither is a software bug. The first is that your Drive is more open than you think. Search is what converts "technically shared with everyone" into "found by everyone", and plenty of teams discover their real permission state on the day they index it. The second we learned the hard way.

Credit where it is due: the seat-based tools are good at this inside their own territory. Dashworks lists document-level access control with instant permission updates on its pricing page, and permission mirroring is central to Glean's enterprise pitch. What none of them can do is enforce permissions in a system they have no connector for, because they cannot see it. That gap is the honest argument for a build, and it is the only one we make.

Permissions belong in the retrieval filter, never in the prompt. Ask any vendor which one they do.

Can we put sensitive company documents into an AI knowledge base at all?

Yes, on one condition: permission mirroring has to be a design constraint from the first connector, not a setting somebody enables in month four. Every passage carries the access rules of the document it came from and the retrieval step filters on the person asking. If a vendor cannot describe that mechanism in plain language, the answer for your contracts, HR files and client records is no, and it stays no however good the demo was.

The one time a client came to us asking for an AI policy, this is what had happened: an employee had access to something they should not have had, and that access led to publishing something that was a problem. An access-control failure at the edge of a system, then external publication. Nothing in that sequence required AI. What indexing changes is the speed at which reachable information gets found, which is why the audit belongs before the connector rather than after the incident.

The clause almost everyone skips is ownership of the boundary. There need to be named stakeholders for each piece of information going out of the platform and coming in, and in most companies nobody owns either direction. Two names, written down, before you connect a drive. Our AI agent security and governance guide covers the wider version of that boundary once agents, not just people, are doing the asking.

Practitioners who evaluate retrieval systems for a living have a blunt way to test all of this: score permission leakage as an automatic fail. Not a point deduction, not a percentage. One passage returned to somebody who should not see it and the entire evaluation run is a failure, however good the other twenty-nine answers were. Copy that into your own pilot. And keep the hardest classes out of phase one anyway, meaning payroll, board material and live legal matters, not because the design can't hold them but because you want a month of evidence before it has to.

Score permission leakage as an automatic fail. One leaked passage voids the run, it doesn't cost it a point.

What sources can it actually connect to?

The mainstream set is well covered by everyone: Slack, Microsoft Teams, Google Drive, Notion, Confluence, SharePoint, Gmail and Outlook, HubSpot, Salesforce, Zendesk, Jira, Linear, GitHub. Glean advertises more than 250 connectors. If your list is a subset of somebody's connector catalogue, that is your answer and this section is over.

The interesting sources are the awkward ones. Meeting recordings, which need transcription first. Scanned contracts, which need OCR. Your practice management system, your booking system, the internal admin tool a contractor wrote. Anything with an API or a readable database can be indexed, and that is usually the actual reason a company stops shopping and starts scoping a custom knowledge layer.

Whatever you pick, connect two or three sources first, not twenty. A knowledge base covering three sources that people trust beats one covering twenty that they don't, and the first wrong answer costs you more adoption than the tenth right one earns.

The source that decides buy-versus-build is nearly always the internal system you forgot to put on the list.

What breaks after go-live, and who notices?

Connectors die quietly. A token expires, an admin revokes a scope, a vendor changes an endpoint, and the index stops updating while the assistant keeps answering cheerfully from last month's documents. No error. Nobody finds out until somebody quotes a superseded price.

We read 25 negative reviews of n8n, Zapier, UiPath and Intercom on the review platforms in August 2026, looking for complaints about AI quality. Not one review said the AI got the answer wrong. Every single complaint was about the business layer wrapped around it: silent breakage, usage pricing nobody could predict, support that went quiet, and nothing to watch the thing with. One Zapier reviewer described the failure exactly: "all our zaps just were not running and no alert was presented" (Zapier review, 5 stars, 7 August 2026).

So put one question to every vendor you shortlist, and put it to us too: who notices when a connector dies, and how fast? Make them show you the alert rather than the dashboard. A weekly index-freshness check and a sync-failure alert costs almost nothing to set up and is the difference between a stale answer caught on Tuesday and one caught by a client in November.

Plan for the connector that stopped six weeks ago and told nobody. That is the failure that actually shows up.

How long does it take to set up?

Off-the-shelf: an afternoon to connect OAuth to your main tools, then about a week of real use before you know whether it is any good. Do not evaluate on day one; the index is still backfilling and every early answer is unfair to the tool.

A custom build runs around four weeks to first answers in production on a deliberately narrow first scope, with two or three sources connected and permission-aware retrieval working. Additional sources and deeper permission models come in later phases.

Neither of those numbers is the real timeline, because indexing is not the long pole. A company-wide rollout is a couple of months of back-and-forth after the first department goes live: skills and configuration per department, choosing or building the connectors nobody sells, training people who have never asked software a question in a sentence, and rearranging what the system does as usage shows you what people actually ask about. The three-month adoption figure at the top of this page is what the end of that period looks like when it goes well.

Two weeks to a working system, three months to a habit. Plan the second number.

How do you know it's working, and what should you measure?

Not queries per day. That number tells you people opened it, which is the metric every vendor dashboard shows because it is the one that always goes up. Four numbers are worth collecting, and all four are cheap.

• Questions that stopped being asked. Count "does anyone know" messages in your busiest channel for two weeks before launch and two weeks after. This is the only number that maps to money.
• Citation accuracy. Hand-check twenty answers a week: does the cited passage actually support the claim? Below roughly 90% and people stop trusting it, which is unrecoverable without a relaunch.
• Refusal rate. If the system never says "I don't have that", it is guessing. A healthy internal assistant refuses regularly, because plenty of internal questions genuinely have no documented answer.
• Active users at three months. Around 30% of staff is what a good rollout looks like in our deployments. Treat that as the target, not as a shortfall.

One pattern worth stealing. In team deployments, nobody touched the generic assistant until we built configuration specific to each department. Adoption followed specificity, every time. A knowledge base marketed internally as "ask it anything" gets tried once; one introduced as "this answers pricing and contract questions for sales" gets used.

Measure trust, not traffic. One confidently wrong answer costs more adoption than ten right ones earn.

What happens when two of your documents contradict each other?

Nothing visible, which is the problem. Retrieval pulls both passages, the model reconciles them into one fluent paragraph, and you get a third version of the policy that was never true. No error, no warning, no flag. Somebody quotes last year's rate to a client six weeks later and that is how you find out.

This is not a retrieval problem and no tool solves it for you. In our second-brain work, ownership and versioning had to be fixed before AI was connected to anything: one named owner per money topic, one document that wins, every duplicate archived or pointing at the winner. That work is unglamorous and it is most of the project. Our AI knowledge readiness audit is the five-check version you can run yourself this week, free, before you spend anything.

If you are buying rather than building, Guru's verification workflow is the closest an off-the-shelf tool gets to handling this, because it forces a named human to re-verify a card on a schedule. It still needs the human.

AI doesn't fail loudly on contradictory documents. It fails fluently, which is worse.

Can your AI agents use the same knowledge base?

Only if it exposes an API or an MCP server, and this is where seat-based tools get thin. They are built for a human typing in a chat window. Agents need programmatic retrieval, per-agent identity so permission filtering still applies, and rate limits that assume machine traffic.

It matters more than it sounds. Once you run a sales agent, a support agent and an ops agent, each one ends up carrying its own half-right copy of company knowledge, and they drift apart at different speeds. One index that every agent queries is the fix. We treat it as the memory tier of a company's agentic OS, and if agents are where you are heading, our guide on how to implement AI agents covers the rollout side.

Ask the vendor for API and MCP access before you buy, even if you have no agents yet.

Who should not buy an AI knowledge base, and when should you not hire us?

Four groups, and we say all of this on discovery calls. A team of ten with one tidy Notion workspace should buy the Notion AI tier or nothing at all; you will pass the readiness checks in an hour and learn nothing. Any company whose knowledge genuinely lives inside Slack, Drive and Notion should buy seats from one of the vendors above and not commission a build, and we will tell you that rather than scope one.

Third: companies where almost nothing is written down. Indexing empty drives returns an empty assistant. What you have is a management problem with a management fix, and it has to come first. Fourth: if you have an engineer with real spare capacity and two or three source APIs, build it yourself. The pipeline is well documented and you will understand your own retrieval better than any vendor explains theirs.

The failure mode we would most like you to avoid is the flat rollout. Access for everyone on day one, an all-hands demo, and then a slow fade. That is exactly how the $3,000-$5,000-a-month agent programme we mentioned earlier died inside two months. What we do now is start with one department that has a specific, repetitive, expensive-to-answer question, and expand only after that department stops asking it.

We would rather lose the build than sell you the wrong row of that table.

Frequently asked questions

Related reading

• AI knowledge readiness audit — the five pass/fail checks to run on your documents before you connect anything to them.
• Company second brain — what we build when off-the-shelf tools can't reach the systems that matter.
• All Cognio guides — agents, costs, security, and knowledge, written from deployments rather than press releases.