How to build an internal company AI that people trust

Internal knowledge AI has an unusual adoption curve. People try it early because it is new, then abandon it permanently the first time it answers confidently from a superseded document. Trust is spent quickly and rebuilt slowly, which means the engineering priorities are not the obvious ones.

Retrieval is the product

Answer quality is bounded by retrieval quality. If the right passage is not retrieved, no model will produce the right answer — it will produce a fluent wrong one. Most of the work in a knowledge system is upstream of the model: deciding what is authoritative, resolving versions, deriving metadata, chunking sensibly, and evaluating retrieval against real questions from real users.

Permissions must be enforced at retrieval

Filtering after generation is not a permission model — the content has already been read by then, and a well-phrased question can surface it in paraphrase. Access has to be applied when documents are selected, using the organization’s existing entitlements rather than a second model maintained inside the AI system.

Refusal is a feature

A system that says 'the policy does not cover this — escalate to HR' is more valuable than one that infers a plausible answer, because the first can be relied on and the second cannot. Grounding the answer strictly in retrieved passages, citing the clause and the effective date, and declining when coverage is absent are what make the system usable in situations that matter.

The questions your system refuses are a map of where your documentation is genuinely incomplete. Log them.

Scope it to a function first

A company-wide assistant has to be good at everything, which usually means it is convincing at nothing. A copilot scoped to one function — HR policy, commercial terms, field procedures — has a bounded corpus, a definable evaluation set, and an owner who can tell you when it is wrong. Get one of those genuinely trusted, then extend.