Internal company chatbot: what to lock down before you launch one

The internal company chatbot keeps coming up in HR and IT director searches: the pitch is simple — a conversational assistant that answers employees straight from the company knowledge base (collective agreement, IT procedures, expense policy) instead of one more email piling up in a shared contact@ or support@ inbox. The usual reflex is to subscribe to a market platform billed per user. That is often the right place to start — but before stacking up licenses, it is worth checking what this assistant actually needs to know, and who is allowed to ask it what.

Scripted chatbot, conversational agent, or both?

The question an internal chatbot raises is no different from the one a customer-facing chatbot raises: a decision tree with a handful of branches does not need the same architecture as an assistant that has to cross-reference several documents and rephrase an answer in plain language. We laid out how to settle that choice for a customer chatbot elsewhere on this blog; the same grid applies internally, with one nuance — an employee forgives a wrong answer about their remaining leave balance far less readily than an anonymous visitor forgives an approximate answer about a product.

The technical base: a knowledge base, not a fixed script

We built exactly this kind of base for an educational chatbot: a knowledge base fed from existing documents, a classification step that routes each question to the right sub-workflow, and a test harness that checks answers before they reach production. For internal use — HR, IT, employee support — the only real difference is the source material: collective agreements and internal procedures instead of course content. The conversational layer itself is often built on models such as Claude, able to rephrase an answer rather than reciting a document word for word.

HR data is sensitive: what to lock down at design time

• →EU hosting and restricted access to conversations, exactly as for any processing of HR data under GDPR — an internal assistant that reads HR documents is handling personal data, not just static text.
• →A defined retention period for conversation logs, not an unlimited history kept by default.
• →A clear line between what the chatbot can consult (procedures, shared documentation) and what it must never surface — a colleague’s individual file, payroll figures, disciplinary records.
• →Cost follows the same logic we detailed for a custom-built HR AI diagnostic elsewhere on this blog: a usable first scope most often starts in the same range, well below the cumulative cost of stacked per-seat subscriptions once adoption grows past a few dozen employees.

How to start without rebuilding everything

Start narrow: one team, one source of truth (leave policy, or IT onboarding, not both at once), and a visible way for an employee to say the answer was wrong. Measure how many questions the assistant actually resolves without escalation before extending its scope to a second team or a second document set. An internal chatbot that tries to answer everything on day one is the most common way this kind of project stalls — the ones that stick start with one well-documented, high-volume question, exactly like the customer-facing case studies in our project catalogue.