An AI assistant inside the intranet: what it solves and where it should stop

A corporate AI assistant, set up correctly, becomes the most used component of an intranet; set up wrongly it turns into an untrustworthy guessing machine. Three decisions separate the two: which sources it answers from, whose eyes it sees through, and what it is allowed to do.

Sources: documents instead of invention

A general-purpose language model doesn't know your company's leave procedure. If it answers as though it does, the result is a plausible but wrong text — and that costs more than no answer at all.

The right architecture grounds the answer in the organisation's own content: the question is matched semantically against uploaded documents, published announcements and other company content, the retrieved passages are given to the model as context, and the model is instructed to answer only from that context. If it isn't in the context, "I don't have that information" is not a defect but correct behaviour.

That has a consequence: the assistant's quality is capped by your document quality. If your policies aren't current, neither is the assistant. The good news is that this is a visible gap — the questions left unanswered write your content plan directly.

Permissions: whose eyes does it see through?

This is the most critical design decision. If the assistant reads data with administrator privileges, it can leak information the user would never see: an announcement targeted at another department, someone else's performance rating, an ethics report.

The correct approach is for every read to happen with the caller's own identity. That way the assistant cannot reach any data the user couldn't reach themselves; isolation stops being a separate checklist and becomes the rule the database already enforces. We detail that principle on our security page.

The same logic applies to flows that require confidentiality: ethics reports, pulse survey answers and performance data should never enter the assistant's knowledge base at all.

Actions: where should it stop?

"Create a leave request for me" is an attractive feature. But an assistant that silently creates records produces a trust problem that is hard to undo.

There are two defensible models. The first is a confirmation card: the model proposes an action, the user sees it and approves, and only then is it executed — and again with the user's own permissions, so the assistant can't do anything the person couldn't. The second is a read-only assistant: it never writes, and points the user to the right screen.

We run both: the action agent with confirmation cards lives in Ask HR, while the WeAI assistant that opens on every screen is deliberately read-only. Rather than implementing the same capability half-way in two places, we kept the boundary sharp — and the assistant states that boundary to the user up front.

A third model should never be accepted: an assistant that says "I've created it for you" while doing nothing.

Citing sources

A good assistant lists the documents behind its answer and lets you reach them in one click. That has two benefits: the user can verify, and the source of a wrong answer can be found and fixed quickly. An assistant that can show beats one that says "trust me".

In-app help

The least discussed but most used function of an assistant is questions about the product itself, not company data: "how do I send this announcement to one department only", "where do I see my leave balance". Those answers aren't in documents; they live in knowledge about how the application works.

So the assistant's knowledge base should include what each module does and which screen each job belongs to. One extra rule: modules that are switched off must be excluded from that knowledge — describing a feature the user's organisation doesn't have is promising something that doesn't exist.

Measurement and cost

Three things to watch: which questions are asked, which went unanswered, and usage volume. The first two produce a content plan; the third keeps cost predictable, because model calls are billed per use.

Reviewing unanswered questions regularly is the only practice that makes the assistant better over time — not by swapping the model, but by writing the missing document.

Where to start

Don't switch the assistant on from day one. The document centre needs to be organised and current first; an assistant wired to an empty knowledge base loses trust within three questions. We cover document structure in our documents article and rollout order in the 90-day plan.