AI chatbot development services for internal knowledge

We build assistants that answer from a defined set of your own documents, cite the passage they used, and refuse when nothing in scope supports an answer. Read-only to begin with, always.

Most of the work in a custom AI chatbot happens before anyone types a question: choosing which documents go in, getting them into a shape retrieval can use, enforcing who may see what, and testing for wrong answers rather than fluent ones. That work decides whether the thing still earns its place in month six.

Scope an assistant pilot

Assistant, chatbot, or agent

Three different products get sold under one word, and anyone quoting for AI chatbot development services should say which of them they are building. They differ in the respect that matters most: what each is allowed to change.

TypeWhat it doesWhat it can changeWhen it is wrongWhat it costs to run
TypeInternal assistantWhat it doesAnswers staff questions from an approved document set, with a link to the source passageWhat it can changeNothing. It readsWhen it is wrongAn employee gets a bad answer, sees the citation points at a 2023 policy, and flags itWhat it costs to runQuery costs, plus a few hours a month keeping sources current
TypeCustomer-facing chatbotWhat it doesAnswers a narrower, fully approved public set on your websiteWhat it can changeNothing, but it speaks in your name, which can carry a disclosure obligationWhen it is wrongA customer acts on a wrong delivery term and you hear about it as a complaintWhat it costs to runQuery costs, transcript review, an escalation route into your helpdesk, a named content owner
TypeTask agentWhat it doesReads, then writes: creates tickets, updates CRM records, sends repliesWhat it can changeRecords in live systemsWhen it is wrongA wrong record exists. Someone must find it, reverse it, and work out how many others are wrongWhat it costs to runHighest: scoped credentials, an action log, a rollback path, someone who reads that log

An autonomous agent is almost always the wrong first project. The technology is rarely what breaks. You simply have no evidence yet about how often the retrieval underneath it is wrong, and an agent turns a retrieval error into a database change. Start read-only. Once answer quality is measured rather than assumed, move to draft-only writes, where the assistant prepares the ticket and a person presses send. Autonomous action comes last, on the narrow set of cases where the error rate is known and reversal is cheap.

What the assistant is allowed to read

Source scope is a decision, not a data dump. Point an index at an entire shared drive and it will quote a rejected 2022 proposal with the same confidence as the live price list.

Normally in scope: SOPs and handbook sections carrying a version number and an approval date, product or service specifications where the spec is authoritative rather than a summary of it, policies HR or Operations confirm are in force today, and resolved support tickets stripped of customer names and account identifiers.

What stays out of the index, and why:

  • Superseded policy versionsAn index has no way of knowing a document was replaced, only that it matches the question. Archive them somewhere retrieval cannot reach, rather than in the folder next to the replacement.
  • Personal dataHR records, CVs and disciplinary notes belong in systems with individual access control.
  • Draft or unapproved pricingThe assistant cannot tell a draft from a decision, and a quoted number is read as a commitment.
  • Anything without a named ownerIf nobody is responsible for whether it is still true in nine months, it stays out.
  • Email and chat threadsThey record discussion, not conclusions, and the conclusion is usually in the message nobody indexed.

Preparing documents so retrieval works

This is the unglamorous part, and it sets the ceiling on every answer the assistant will ever give.

An AI knowledge base does not search documents. It searches fragments of them. The pattern is called retrieval-augmented generation, or RAG. The interesting half is the retrieval. Each source is split into passages of a few hundred words, those passages are indexed, and at query time a handful of the closest matches go to the model with the question. The model answers from those passages. If the right passage was not retrieved, the model does not know that. It answers anyway, from whatever it was given.

That is why bad splitting produces confident wrong answers so predictably. A ten-step returns procedure cut between steps four and five produces a passage holding steps five to ten with no context. Ask how to process a return and you get a fluent, well-formatted answer that starts in the middle and omits the warranty check.

What goes wrong, and what fixes it:

  • A 40-page PDF with no headingsNo natural boundaries, so it gets cut on arbitrary word counts. Add real headings, or split it by topic before indexing.
  • TablesFlattened to text, a pricing or compatibility table becomes a row of numbers detached from its column labels. Convert it to labelled sentences, or keep it whole in one passage with the header repeated.
  • Scans and image PDFsNo text at all. They need OCR first, and the output needs reading, because a misread part number retrieves nothing.
  • Near-duplicate versionsTwo policies differing in one paragraph look nearly identical to a retrieval system, which cites whichever scores marginally higher. Remove the old one.
  • Missing metadataEvery document needs a title, an effective date, an owner and a status. Without those fields nothing tells the assistant which of two documents is current, and nothing tells the reader that an answer came from the March 2026 handbook.

We hit each of these putting our own internal documentation and support request handling through the same pipeline. Budget real time for this stage. Expect it to be the longest task in the build, and one you are usually better placed to do with guidance than to hand wholesale to a chatbot agency.

Permissions and who sees what

Proposals gloss over this, so it is worth saying plainly. If the assistant indexes HR files, everyone who can query the assistant can read HR files.

Telling the model not to disclose salary data is not access control. Access has to be enforced at retrieval, before any passage reaches the model, by filtering candidates against the identity of the person asking. Two patterns work:

  • Separate indexes per audienceOne for staff, one for managers, one for finance. Easy to audit, and the right default for a first build. The cost is duplication.
  • Access labels checked at query timeEach document carries a group label, the query carries the user's group from your identity provider, retrieval filters before ranking. More flexible, and it holds only while the labels stay correct.

Citations leak too. A title alone can disclose what the body would have protected, so titles need the same filtering as content.

What counts as a good answer

"It seems to work" is not an evaluation. Fluent output is the one thing these systems produce reliably, including when they are wrong. The method is a fixed evaluation set:

  1. The people who will use the assistant write 40 to 60 real questions in their own words, including the badly phrased ones.
  2. For each, record the correct answer and the document that should be cited.
  3. Include questions that must be refusedOut of scope, unsupported, or deliberately out of date.
  4. Re-run the set after every change to sources, prompt or model, and keep the dated results.

Grade three things separately, because they fail separately. Is the answer correct. Did it cite the right document or a plausible neighbour. Did it refuse when it should have. An answer that is correct but cites the wrong source is a warning. Retrieval missed, and the model filled the gap from general knowledge, which will not hold next time.

Review points and escalation

The assistant needs defined behaviour for the cases where it should not simply answer.

SituationDetectionWhat the assistant doesWho picks it up
SituationNo supporting sourceDetectionNothing retrieved above the similarity thresholdWhat the assistant doesSays the document set does not cover this and gives the escalation route. No general answerWho picks it upSource owner, via the unanswered-questions log
SituationWeak or conflicting sourcesDetectionLow similarity, or top passages carry different effective datesWhat the assistant doesAnswers from the current-dated source, names the date, flags the conflictWho picks it upThe document owner named in the metadata
SituationQuestion outside scopeDetectionTopic matches the exclusion list: pay, contracts, disciplinary, legal, medicalWhat the assistant doesDeclines and routes to the named person for that topicWho picks it upHR, Legal or the relevant lead, by topic
SituationAnswer would reach a customerDetectionThe workflow is customer-facing by definitionWhat the assistant doesProduces a draft only. Nothing sends automaticallyWho picks it upThe support or account owner for that customer
SituationUser disputes an answerDetectionThumbs-down or written flagWhat the assistant doesLogs question, retrieved passages and answer, so the failure can be reproducedWho picks it upMaintenance owner, at the monthly review

The similarity threshold in the first row is an output of the evaluation set above rather than a default copied from someone else's build. Run the must-refuse questions and the answerable ones through the built index, raise the threshold until every must-refuse question is declined, then measure what that costs in good answers now refused as well. Record the value with the date, the model and the document set it was measured against, because it does not carry over to another build.

The last column decides whether any of this holds. Escalation rules with no named person are decoration.

Keeping sources current

Every indexed document has an owner and a review date, both stored in metadata and visible to whoever looks after the assistant.

When a policy is replaced, the superseded version comes out of the index the day the replacement is approved. Removing something always feels riskier than leaving it where it is, which is why this is the rule to write down and hold people to. The archive still exists. It is simply not searchable.

Re-indexing runs nightly, with a manual run when someone approves a document in a hurry. Then a monthly review, and thirty minutes is usually enough: read the unanswered-questions log, read the disputed answers, re-run the evaluation set. That log is a ranked list of what your organisation has not documented, written by the people who needed it.

Maintenance needs one named owner. A committee or "the ops team" means nobody. If that role is empty at handover, the source set drifts out of date and the answers degrade quietly, because nothing announces the day a document stopped being current.

When an assistant is the wrong answer

Some answers live in a database rather than in documents. Order status, stock levels and invoice totals want a query, a report or an integration. Putting a chatbot in front of exported spreadsheets adds uncertainty to something that had an exact answer.

If a question comes up four times a year, write the page and put it where people look. Retrieval infrastructure is a poor substitute for one well-placed document. And if your documents contradict each other, fix that first. An assistant does not resolve contradictions. It picks one and states it confidently.

If being wrong carries legal, financial or clinical consequences, this is not the tool for the final answer. It can help someone find the relevant clause faster. It should not be what decides. And if nobody will own maintenance, do not build it at all. An assistant over stale sources is worse than none, because people stop checking the original.

FAQ

How long before real users can test something?

It depends on the state of your documents. Current, structured, exportable sources make for a short first build. Scanned PDFs, contradictory policy versions and knowledge that exists only because somebody remembers it make source preparation the bulk of the work. We assess that before quoting, because it is what moves the schedule.

Can it read our SharePoint or Google Drive as they are?

It can connect to them. Whether it should read all of them is a different question, and the answer is normally no, because shared drives accumulate superseded documents, personal data and drafts. We scope named folders with named owners, then expand once the evaluation set shows the assistant is stable.

What stops it inventing answers?

Restricting it to retrieved passages rather than general knowledge, requiring a citation with every answer so unsupported claims are visible, and defining a refusal path when nothing relevant is retrieved. Together those reduce fabrication substantially. They do not eliminate it, and any supplier saying otherwise is selling something.

Do we need to run the model on our own infrastructure?

Not for most builds. A hosted model API is the normal answer, and the thing to compare is the contract rather than the benchmark scores: what the provider commits to on retention, and whether inputs on your particular plan are used for training. Those terms differ by plan and change over time, so they are worth reading rather than assuming. Self-hosting matters when contractual or sector rules require it, and it changes the cost profile, since you are then running and monitoring GPU infrastructure. We worked through that trade-off in detail using one frontier model as the example in can Kimi K3 be self-hosted on a private server, including the three different things people mean by "private". Where hosting genuinely is needed, our sister company YNVAR covers it and we handle the application layer.

Can one assistant serve the whole company?

It can, but a first build should not try. A single-department assistant with 30 documents and a real evaluation set teaches you more in a month than a company-wide index does in six.

What are the ongoing costs?

Model query costs, which scale with usage and the length of retrieved context. Re-indexing and storage, small at typical volumes. And maintenance time, which is the cost people forget and the one that decides whether the system still works next year. Figures depend on volume and model choice, and go in the proposal.

Next step

Start with the process, not the tool

Describe one task your team repeats and you get a straight view on whether it is worth changing.