Every company has the same complaint about its internal documentation, and it is never that there is too little of it. It is that nobody can find anything, half of what turns up is three versions out of date, and the person who actually knew the answer left in 2023.
AI has changed what is possible here more than in almost any other back office function. Retrieval systems that read across your entire document estate and answer a question in plain language genuinely work now, in a way keyword search never did.
They also introduce a problem that most teams do not see coming, and it is worth stating up front: an AI search tool is only as safe as your permissions are accurate. It will find things. Including the things that were technically accessible to everyone and practically invisible because nobody knew where to look.
Why keyword search failed and retrieval works
Traditional intranet search matched strings. If the policy said “expense reimbursement” and you searched “getting paid back for a flight,” you got nothing, so people stopped searching and asked a colleague instead. That is the actual cost of bad knowledge management: it converts a two second lookup into an interruption for two people.
Retrieval augmented generation changes the matching from words to meaning, then writes an answer with a citation back to the source. The citation is the part that matters. A system that answers without showing you which document it came from is not a knowledge management tool, it is a plausible sounding guess, and it will eventually be confidently wrong about something like a leave policy.
Make source attribution a hard requirement in any evaluation. If you cannot click through to the paragraph the answer came from, the tool is not fit for this purpose.
The realistic tool categories
Platform native assistants. If your content already lives in Microsoft 365, the assistant built into that ecosystem has an advantage that is difficult to overcome: it already understands your permission model, so it will not show a user something they could not otherwise open. For most companies on Office 365 this is the correct starting point, and the SharePoint estate is usually where the content actually sits. Similar arguments apply within the Google and Atlassian ecosystems.
Dedicated enterprise search. Tools such as Glean, Guru, and their competitors index across many systems at once: your wiki, your ticketing system, chat history, shared drives, and your CRM. The value is real when knowledge is genuinely scattered across five platforms, which is common. The cost is that you are now maintaining a second permission surface, and that is the part teams underestimate.
Purpose built support knowledge bases. If the primary use is customer facing agents answering repeat questions, a support specific tool will beat a general one. The workflows around suggested responses and article gaps are built for that job.
Documentation assistants. A quieter category and often the highest return. Tools that draft documentation from existing material, flag pages that contradict each other, and identify what has gone stale. Most knowledge bases fail from neglect rather than absence, and this is the category that addresses neglect.
The permissions problem, stated plainly
Here is the failure that shows up within weeks of a rollout.
Companies accumulate documents on shared drives with permissions that were set casually years ago. A salary band spreadsheet in a folder shared with the whole company. Board material in a directory that was opened up for one meeting and never closed. Legal correspondence in a shared inbox archive. None of this was secure, but it was safe in practice because finding it required knowing it existed.
An AI retrieval system removes that protection completely. It reads everything it has access to and answers questions from it. Ask about compensation philosophy and it may quote the spreadsheet. Nothing was breached. The tool did exactly what it was bought to do.
This is why a permissions audit is not an optional preliminary. It is the project. Budget for it accordingly, and treat the AI rollout as the thing that happens after.
Two related points. First, restrict scope at the start rather than indexing everything on day one. Begin with content that is genuinely meant to be broadly readable. Second, decide what the tool does with material it should not surface: silently omit it, or say that a restricted document exists. Both are defensible and the choice should be deliberate.
The underlying discipline is the same one covered in managing access to your systems, applied internally rather than to vendors.
What determines whether this actually works
Content quality sets the ceiling. A retrieval system over contradictory, outdated documentation will confidently return outdated answers with a citation, which is worse than no answer because the citation makes it look verified. If three documents describe the same process differently, fix that first or the tool will amplify the confusion.
Ownership has to be real. The single strongest predictor of success is whether named people own defined content areas. Without that, quality decays and adoption follows within two quarters.
Adoption depends on the first week. People try a search tool a small number of times. If early answers are wrong or unhelpful they revert to asking colleagues and do not come back. Launching to a narrow, well curated area beats launching across everything.
Measure deflection, not usage. Query volume tells you people are curious. What matters is whether the questions that used to interrupt a colleague have stopped. If your internal help channel is as busy as before, the tool is not working regardless of its dashboard.
Teams already getting value from Microsoft 365 in daily work tend to adopt fastest, because the content is already somewhere consistent.
Where your content should live before you index it
A retrieval tool inherits the structure underneath it, so the shape of your document estate matters more than the tool you pick.
Two patterns cause most of the trouble. The first is content spread thinly across personal drives, where a document that half the company relies on sits in one person’s storage and disappears when they leave. The second is the opposite: a single enormous shared library with no hierarchy, where permissions were set once at the top and inherited by everything since.
Consolidating onto a properly structured platform before indexing is worth the delay. If that platform is SharePoint, the structure and governance decisions are the ones that determine whether search results later look sensible or chaotic. Chat history is a related question, because a great deal of real institutional knowledge now lives in conversations rather than documents, and whether you index it is a genuine policy decision rather than a technical one. The tradeoffs there overlap with how teams choose their collaboration platforms in the first place.
A rollout sequence
- Inventory where knowledge actually lives. Usually more places than anyone expects, including personal drives and chat threads.
- Audit permissions before indexing. The unglamorous step that prevents the embarrassing one.
- Pick one high value area. Onboarding, IT support questions, or a policy set. Narrow and well maintained.
- Require citations and test them. Verify that answers point at the correct source, including for questions where the documentation is ambiguous.
- Assign owners before launch, not after. Content without an owner is content that will be wrong in six months.
- Expand by evidence. Add the next area when the first is demonstrably deflecting questions.
Where the technology genuinely falls short
Being honest about this saves disappointment.
These systems answer questions that documentation already answers. They cannot tell you what nobody wrote down, and the most valuable organizational knowledge is frequently undocumented: why a decision was made, which client dislikes a particular approach, what was tried in 2021 and failed. A retrieval tool will not surface that, and it may create an illusion of completeness that discourages people from asking the colleague who knows.
They also struggle with contradiction. Given two conflicting policies a model will usually pick one and present it confidently rather than flagging the conflict. Some tools now detect this, and it is worth asking about specifically.
And they do not fix a culture where people do not write things down. Retrieval makes existing knowledge findable. Creating knowledge is still a human habit, and no tool installs it. The broader pattern of AI in data management is the same: the technology improves access to what exists and cannot manufacture what does not.
Where Mindcore fits
Matt Rosenthal, Mindcore’s CEO, has a consistent observation about tools that read across a company’s data: the technology is rarely what causes the problem. What causes the problem is deploying it on top of an access model nobody has looked at in years, and finding out what that model actually permits by watching a search result.
That is where our work sits. Which knowledge platform suits your organization is your decision, and it depends on where your content already lives and how your teams work. What we handle is the layer underneath: auditing permissions across SharePoint and shared storage before anything indexes it, confirming the retrieval tool inherits those permissions rather than working around them, and keeping the result reviewed as content and staff change. For teams who need the human side as well, our Microsoft 365 training covers the habits that keep a knowledge base alive after launch.
Frequently Asked Questions
Will an AI search tool expose documents people should not see?
It will surface anything it has access to, which in most companies is more than intended. The tool is not the problem, the accumulated permissions are. Audit access before indexing and start with a restricted scope rather than the whole estate. This is the most common and most avoidable failure in these rollouts.
Should we use the assistant built into Microsoft 365 or a dedicated tool?
If most of your content is already in Microsoft 365, start with the native option, because it understands your permission model and requires no second access surface. Dedicated tools earn their place when knowledge is genuinely spread across many unrelated systems.
What if our documentation is out of date?
Fix the worst of it first, at least in the area you launch with. Retrieval over stale content produces confidently wrong answers with citations attached, which is more damaging than no answer because it looks verified. Start narrow and well maintained rather than broad and neglected.
How do we measure whether it is working?
Track whether questions that previously interrupted colleagues have decreased, not how many searches were run. Deflection is the outcome you bought. Usage numbers can rise while the underlying problem is untouched.
Can AI write our documentation for us?
It can draft from existing material, flag contradictions, and identify stale pages, and that is genuinely useful. It cannot document knowledge that only exists in someone’s head, which is usually the most valuable knowledge you have. Capturing that remains a human task.
Ready to find out what an AI search tool would surface?
Before deploying anything that reads across your document estate, it is worth knowing what that estate currently permits. That review is straightforward and it is considerably more comfortable to run before a search tool does it for you.
If you want a clear picture of your access model and what it would expose, book a free strategy call with our team.
