How much does an enterprise AI knowledge base cost?

It depends on how many source systems it connects to, how complex the permission model is, and how much clean-up the source material needs first. A single-system deployment with straightforward access rules sits at the lower end; a system spanning several platforms with layered permissions sits above it. We scope every engagement and agree a clear price before any build work starts.

How long until it's live?

Most knowledge systems are answering real questions within weeks. We typically start with the source systems that matter most rather than indexing everything on day one, because a smaller system answering well teaches us more than a large one still being tuned. Coverage expands once the first slice is proven.

How do you handle permissions and sensitive documents?

The retrieval layer checks the same access rules your source systems already enforce before it decides what it can even search, so a person only ever sees what they were already allowed to see. We do not build a separate permission system that has to be kept in sync by hand — it inherits the one you already run.

What happens if our documentation is outdated or contradictory?

The system surfaces what it finds, including the conflict, rather than quietly picking a version. Part of scoping the project honestly is checking whether your source material can support a good answer; if a documentation clean-up needs to happen first, we will tell you and scope that separately rather than build on top of it.

Can it connect to the tools we already use?

Almost always. Most business tools — wikis, shared drives, CRMs, support platforms, contract repositories — expose an API or a reasonable export we can index against. Bring the list of what you run to the first call; ten minutes is usually enough to tell us what is realistic and what needs a workaround. Bring the document or system your team searches most and still cannot find an answer in fast enough. Thirty minutes is enough for us to tell you whether a knowledge system is the right shape for it, roughly what it would take, and whether the documentation needs work first.

Enterprise AI Knowledge Base Systems

What "grounded" means, and why it's the whole point

Ask a general-purpose AI assistant a question about your own business and it will answer anyway — confidently, fluently, and sometimes completely wrong, because it is guessing from patterns in public text rather than reading anything you actually wrote. Ground the same assistant in your material and the behaviour changes: it searches your documents first, finds the passages that actually answer the question, and only then writes a response, built from what it found, with the source attached.

That search-then-answer pattern has a name in the industry — retrieval-augmented generation, or RAG — but the name matters less than the mechanism. It is the difference between a colleague who has read every file in the company and one who is confidently making things up from memory. Our RAG glossary entry goes deeper into the mechanics if you want them; for a buyer, the point that matters is simpler. An ungrounded system is a liability wearing the shape of a feature, because it sounds exactly as certain when it is wrong as when it is right.

Who needs this before anything else gets built

A knowledge system earns its cost when three things are true at once:

The answer already exists somewhere, but finding it costs real time. Spread across a wiki, a shared drive, old email threads and someone's memory, the same question gets asked and answered from scratch every week.
The material changes often enough that people stop trusting the copy in their head. Pricing, policy and process pages that were accurate in March and wrong by June are exactly why people ask a colleague instead of searching.
Different people are allowed to see different things. A support rep, a finance lead and a new hire should not get the same answer to the same question if the underlying documents were never meant for the same audience.

If none of that is true — if the answer genuinely lives on one page everyone already reads — you need better navigation, not an AI system, and we will say so on the call.

What Calfy builds

The shape changes with the source material, but most engagements land in one of five patterns.

Support and account knowledge assistants

A support rep or a customer types a question and gets an answer sourced from your actual manuals, past tickets and account history, not a rewritten help article that may be a version behind. When the retrieval layer sits behind a support agent, the agent can resolve the ticket itself instead of handing back a paragraph for someone else to paste.

Internal wikis, SOPs and onboarding search

Every company has a wiki nobody searches, because search never finds the right page. We index the material that actually matters — Confluence, Notion, SharePoint, shared drives, PDFs sitting in an old folder — so a new hire's question about how a return gets handled pulls the current procedure, not whichever version someone half-remembers writing.

Sales and proposal knowledge

Reps ask for the latest case study, the correct pricing exception, or how a similar deal was handled last quarter, and get an answer built from your actual collateral and deal history rather than a hallway guess. The AI knowledge base search use case walks through a version of this in more detail.

Compliance and policy lookup

Policy and regulatory questions need an answer that points back to the specific clause it came from, not a paraphrase a reviewer has to go re-verify by hand. We build these to cite the source passage every time, because "probably right" is not good enough when the question is a compliance one.

Research and document intelligence

Contracts, reports, filings and technical documentation that would take a person days to work through, searchable and summarisable in minutes. Good for assembling a briefing pack or checking a clause across two hundred contracts. Not a substitute for a professional's judgement on what any of it means.

Permissions mirror the ones you already have

The fastest way to turn a useful system into a liability is to let it answer from documents the person asking was never supposed to see. We do not solve that by asking the system to be careful. We solve it structurally — the retrieval layer checks the same permissions your existing systems already enforce, the folder, the workspace, the CRM record, before it decides what it is even allowed to search.

Practically, that means a support rep's question never surfaces a document scoped to finance, and a contractor's question never surfaces an internal-only policy, because the system checks identity and access before retrieval happens, not after. If your source systems already have a permission model — and almost every business tool does — the knowledge layer inherits it rather than reinventing it. Where permissions are genuinely a mess in the source systems themselves, that gets fixed first, because no retrieval design can safely paper over broken access control. Every retrieval is also logged against the identity that made it, so if a sensitive document does surface somewhere it should not, there is a clear trail back to why.

Keeping the index current

An index is a snapshot, and a snapshot goes stale the moment the underlying document changes. A knowledge base that answers confidently from a policy that was replaced last month is worse than no knowledge base at all, because it is wrong with total confidence.

We build the update path in from day one. Documents added, edited or removed in your source systems flow into the index on a schedule that matches how often the material actually changes — near real-time for anything that shifts daily, a nightly or weekly sync for anything that does not need to be that fresh. Retired documents come out of the index, not just off the page someone happened to be looking at, so an old version cannot quietly resurface in an answer six months later. We also watch the sync itself, so a broken connector fails loudly instead of quietly leaving months of changes unindexed.

What this doesn't fix

A retrieval system is only as good as what it retrieves. If your documentation contradicts itself — one wiki page says thirty days, a PDF from two years ago says sixty — the system will find both and either flag the conflict or hand it back unresolved, and no amount of engineering makes that decision for you. If the answer to a question was never written down anywhere, the system cannot invent it responsibly, and a well-built one will say so rather than fill the gap with something plausible.

Part of scoping any engagement honestly is looking at whether your source material can support a good answer before we build anything on top of it. Sometimes it can. Sometimes the real project is a documentation clean-up before any retrieval system is worth building, and we will tell you which one you are looking at before you pay for the wrong one.

How the work runs

Four stages, and you know the price before the build starts.

Discover. A free 30-minute call, then a look at what you actually have — which systems hold the source material, how current it is, and who should see what. Our pricing page explains how these engagements are structured.
Design. A written scope: which sources get indexed, how permissions map across them, how freshness is handled, what it costs, and how long it takes. Clear pricing agreed before any build work starts.
Build. We index your real material, not a sample set, and you see the system answering real questions from week one rather than a staged demo.
Run. Once live, we monitor what people ask, what the system could not answer, and where the source material itself needs attention, then keep the index current as your business changes. The full process is written out step by step, and the full range of services covers what else we build alongside it.

Knowledge systems that answer from your own documents