Internal assistant: a tool for teams, not customers
Definition
An internal assistant is a conversational assistant for an organisation's own teams: it answers on procedures, case files and in-house tools. It differs from a customer-facing assistant in what it is allowed to know, and that difference is a design choice, not a permissions setting.Two products, not two settings
People often assume one assistant can serve both teams and customers, with different rights depending on who is talking. It is a false economy, and the bill arrives with the first incident.
The internal assistant may know margins, exception procedures, the full history of a case, the name of the colleague who handled it. The customer-facing one must know none of that. Making both live in one system means resting confidentiality on a switch, when it should rest on a separation.
Two distinct assistants, each with its own sources and scope, cost barely more and remove a whole class of problems.
What an internal assistant does well
- Answer on procedures: what we do in this case, who approves what, which document to use.
- Find scattered information: the kind living in an old shared folder, a meeting note or a memo nobody can locate.
- Save newcomers time: first-week questions are always the same, and they always land on the same people.
- Prepare a piece of work: gather what is known about a case before a meeting, without writing in the human's place.
Where it disappoints
An internal assistant does not replace a decision, and it does not replace a procedure that does not exist. If nobody in the organisation knows how to handle a case, the assistant will not know either: it will produce a plausible answer, which is worse than silence.
That is the useful paradox of these projects: they reveal very quickly where company knowledge is written down nowhere. Many organisations find more value there than in the assistant itself.
The internal trust question
An assistant reading company documents worries teams, and rightly so. Two principles defuse most of it: nobody should see through the assistant what they could not see without it, and individual use must not become a way of measuring someone's work.
Both rules are set at the start of the project. Set afterwards, they convince nobody.
Where to start
The best first scope is the one that wastes everyone's time without being sensitive: internal procedures, administrative questions, tool documentation. Measure real usage for a few weeks, then widen where the questions cluster.
A custom assistant is judged on how spontaneously it gets used, not on how many sources it has ingested.
For two weeks, write down the questions teams ask each other, before starting any project. That list beats any specification, and it often shows a well-written document would be enough.
Frequently asked questions
A conversational assistant for an organisation's own teams: it answers on procedures, case files and in-house tools. It differs from a customer-facing assistant in what it is allowed to know, and that is a design choice, not a permissions setting.
It is possible and inadvisable. The internal one knows margins, exception procedures and case history, none of which the customer-facing one should ever see. Two distinct assistants cost barely more and remove a whole class of problems.
The one that wastes everyone's time without being sensitive: internal procedures, administrative questions, tool documentation. Measure real usage for a few weeks, then widen where questions cluster.
Related terms
At KERN-IT
We build assistants that answer from your documents, cite their sources and know when to hand off.
→ Enterprise AI assistant: on your documents, in your tone