An internal knowledge base that answers, instead of another wiki

Four files called FINAL, and the question still comes to you

Open the product folder on the shared drive and read the filenames out loud. Mk3-Datasheet-v4-FINAL.pdf. Mk3-Datasheet-v4-FINAL(2).pdf. Mk3-Datasheet-revC-DO-NOT-USE.pdf. A Notion page called "Mk3 spec — source of truth", last edited fourteen months ago. An installation manual that only exists as an email attachment from your contract manufacturer.

None of that is a documentation failure. You've got proper datasheets, revision control on the drawings, and an installation manual somebody actually proofread. The failure is retrieval. So the message lands with your senior product engineer instead: "Does the Mk3 take the same gland as the Mk2, or did that change at rev C?" She knows. She answers in ninety seconds. She does it eleven times a week, and four of those come from the same two people.

Type "internal knowledge base for engineers" into Google and you'll be pitched two things. A free assistant that has never seen your datasheets and will cheerfully invent an IP rating. Or a platform with a six-month rollout, an implementation partner and a procurement cycle longer than your product development cycle. Neither of those is the thing.

The thing is an AI knowledge base: your existing manuals, datasheets and Notion pages imported into one place, asked in plain English, with every answer citing the document and section it came from so you can check it before you act on it.

Why the internal knowledge base for engineers you already have stopped working

Every fix for this problem so far has been "write it down better". Another wiki. A tidier Notion hierarchy. A naming convention nobody follows past week three.

Slite looked at roughly 900,000 live docs in its own workspaces between May 2024 and May 2026 and found that 76% of registered users never create a single doc, and that the top 1% of contributors produce 47% of all content [1]. Fewer than one in twenty docs in an active knowledge base ever gets updated [1].

Which matches what you already know. Your knowledge base is one person's hobby, and that person is the same one answering the gland question. The documents themselves are usually fine. Nobody can find the right paragraph inside them, because a 90-page installation manual is not searchable by anyone who doesn't already know what's in it. Search "gland" and you get 40 hits across four revisions.

Do this first, before you evaluate anything: open the channel or inbox where people ask your product expert questions, scroll back a month, and write down the ten questions that recur. Real wording, not tidied up. That list is your test set for everything that follows, and it takes about fifteen minutes to make.

“76% of registered users never create a single doc. The top 1% of contributors create 47% of all knowledge base content. Fewer than 1 in 20 docs in an active knowledge base gets updated. Based on anonymized, aggregated Slite workspace telemetry across roughly 900,000 live docs, May 2024 through May 2026.”

Slite

Knowledge base statistics — how knowledge bases actually behave in production, 2026

The false choice: free toy or six-month build

The reason this decision stalls is that both options on the table are bad, so doing nothing looks rational.

Forrester put the enterprise end of it bluntly this year: "Three-quarters of enterprise leaders tell us they're adopting agentic AI. Only a small minority have it running in meaningful production beyond 'agentish' chatbots." [2] Big budgets, long programmes, pilots that never leave the pilot.

The free end fails differently. A general assistant with no access to your documents will answer your gland question with something plausible about industry-standard M20s, and your field crew will believe it, because it sounds exactly like the answer your engineer gives.

There's a third option that nobody pitches loudly because it isn't a programme: scope one AI knowledge base to one product family, import the documents that already exist, gate it to your team, and put it in front of people this week. Small enough that a wrong answer is caught in an afternoon. Cheap enough that you don't need a business case.

Pick your scope now and write it down in one line. "The Mk3 and Mk4 ranges: datasheets, installation manuals, and the spares list." Not "engineering". Narrow scope is the difference between an assistant that's right and one that's vaguely helpful.

The ten-minute build, step by step

Nothing here needs a developer, and none of it needs your documents moved.

One: connect the sources. The product folder in Google Drive or Dropbox, the Notion space, the manuals sitting as PDFs on someone's desktop, and the product pages on your own website by URL. Import them as they are. No migration, no reformatting, no naming convention.

Two: choose who gets in. Your whole team joining automatically with their @company.com email is the simplest option and needs no seat admin. If you want it tighter for a first run, an email allowlist of the five people who ask the most questions. If your installers need it too, a public link.

Three: brand it and publish it to a hosted URL, or point your own domain at it. This matters more than it sounds for a field crew — an unbranded link in a group chat gets ignored.

Four: run your ten questions. Click through to the cited page on every single one. If an answer cites the rev C datasheet when it should cite rev D, remove rev C from the sources and re-run.

Five: post the link in the exact channel where people currently ask your engineer, and reply to the next question with the assistant's answer rather than your own.

Grupo Bimbo's internal audit team did a much larger version of the same thing, grounding agents in their own methodology and templates, tuned to reference up to 10 or 11 documents per query. A risk and control matrix that took "around two full days of work" now comes back as an initial version "in seconds", refined "in less than half a day", and planning-phase completion time fell by around 20% [3]. You are not Grupo Bimbo and you don't need to be — the transferable part is the grounding, not the scale.

LESSON ONE: Ground the assistant in your own controlled documents and nothing else, then measure the time saved on one recurring task rather than the whole department.

Citations are the part your team will actually judge you on

Your colleagues aren't asking out of curiosity. They're about to torque something, quote a lead time, or tell a customer the enclosure is rated for washdown. An answer they can't verify is an answer they'll ring your engineer to confirm, which leaves you exactly where you started with an extra step.

TeamViewer's 2026 research with Sapio, across 4,200 respondents in nine markets, found 56% often or always verify AI outputs before relying on them, spending an average of two hours a week checking AI-generated work, and 51% say they don't always know when to trust AI and when to verify [4]. That instinct is correct and you should design for it, not around it.

Which means citations have to be real and clickable, down to the document and section. Test that properly: ask something you know the answer to, open the citation, and check the paragraph says what the assistant claimed. Do it on five questions. Researchers behind the CITETRACE dataset found citations frequently misrepresent what they point at [5], so the click-through is not a formality.

“Users of search-augmented LLMs rely on citations as evidence that responses are grounded in real sources, and rarely verify the cited pages themselves. Across our pool, 30.6% of citations distort their sources and 27.1% originate from domain-inappropriate sources; at the response level, up to 96% of users encounter at least one structurally misleading citation.”

Seo, Jeong, Kim, Jang & Lee

Verified Misguidance: Measuring Structural Citation Failures in Search-Augmented LLMs, arXiv:2605.28565, 27 May 2026

What to watch out for before you hand out the link

The honest limit first: an internal knowledge base for engineers can only answer from what's written down. If the reason rev C changed lives entirely in your engineer's head and in one Teams call, no import will surface it. Fixing that is a twenty-minute conversation and a page of notes, and you should do it before you blame the tool.

Superseded revisions are the real hazard. Import rev C and rev D of the same datasheet and you've built a machine that confidently cites the wrong one. Import only what's current, and put the obsolete files somewhere the importer never sees.

Ask any vendor how updates get in. Imports are point-in-time, so when a manual is revised, someone has to re-import it. Put that in the engineering change process as a line item, the same way you'd update the printed pack.

Then check who can see it before you share anything. Datasheets are usually fine to publish; internal cost breakdowns, supplier terms and unreleased specs are not. One assistant per audience is cheaper than one leak.

Your next move is small: take the ten questions you wrote down, import one product family's documents, and see how many come back with a citation you'd be happy to send to a customer. You'll know by the end of the afternoon whether this is worth the second product family.

Sources

[1] Slite, Knowledge base statistics — how knowledge bases actually behave in production, 2026 — https://slite.com/learn/knowledge-base-statistics

[2] Forrester, The State Of Agentic AI In 2026: Companies Are Chasing, Few Are Catching, 2026 — https://www.forrester.com/blogs/the-state-of-agentic-ai-in-2026-companies-are-chasing-few-are-catching/

[3] Microsoft Customer Stories, Grupo Bimbo, 2026 — https://www.microsoft.com/en/customers/story/26762-grupo-bimbo-microsoft-365-copilot

[4] TeamViewer / Sapio Research, Path to the Autonomous Digital Workplace, 2026 — https://www.teamviewer.com/en/global/company/press/2026/ai-workplace-autonomy-global-research/

[5] Seo, Jeong, Kim, Jang & Lee, Verified Misguidance: Measuring Structural Citation Failures in Search-Augmented LLMs (arXiv:2605.28565), 27 May 2026 — https://arxiv.org/abs/2605.28565