Enterprise AI Knowledge Management: Choose and Pilot

An employee asks which refund policy applies to a customer. The answer comes back fast, sounds right, and cites a document.

It can still be wrong. The document might be out of date. It might belong to another team. Or it might describe a policy this employee isn't allowed to use.

That's the real problem with company knowledge search. For a forward-deployed engineer, the job is to connect the right sources, settle who's allowed to see what, and prove the answers still hold up when the business changes. The nice search box is just the part people see.

This guide compares four starting points using official documentation, checked September 17, 2026. The pilot and the pass-or-fail tests at the end are a proposal you can run with a customer. They aren't results from a shared vendor benchmark.

Choose the operating model first

Start with one team and one decision they make over and over.

"Search all company knowledge" hides a lot of arguments: who owns what, what's sensitive, and which version of a document is the real one. "Help support staff find the refund policy that applies, with a citation they can check" gives the project a clear goal.

Treat these as guesses about fit. They don't rank answer quality, how fast each one is to set up, or total cost.

Some teams need something else entirely. If the problem is pulling data out of a pile of documents, look at an extraction pipeline. If the system needs to change business records, you'll need an agent execution platform on top of search.

Glean: inspect the connector, not just the platform promise

Glean is worth a look when the knowledge is spread across several systems the company already uses. Its connector docs tell you more than any count of supported apps.

The Notion connector shows why. Glean describes a shared index of the pages the integration has been given. That index doesn't copy each page's Notion permissions. Anyone in Glean who can use the connector can see what's in it.

There's also a separate path that searches as each user, using that user's own Notion login. Those are two very different ways of deciding who sees what. See the Glean Notion overview.

Here's what that means in practice. Give the indexing integration access to a private team page, and you may have just widened who can read it. Before you connect anything sensitive, check which pages are selected, whether child pages come along, and who can see the connector.

A search that works for an admin doesn't test permissions at all.

The docs also don't fully agree with each other. Glean's overview describes an admin turning on Live Mode. Its troubleshooting page says there's no switch for how search works during setup, indexing is required, and each user authorizes tools on their own. See Notion troubleshooting. Before you design around live-only search, confirm which settings this customer's account actually has, and whether indexing can be turned off.

In the pilot, have the team show three things using the exact connector setup being proposed: a restricted document, a user whose access was removed, and a deleted page. Record how long each change takes to show up in results. Don't assume one connector behaves like the rest.

Guru: decide who owns the access policy

Guru offers two ways to control who sees content from connected sources. See How sources work in Guru.

• Guru Groups. An admin picks which groups can use content pulled in through the connecting account.
• Inherited permissions. For supported sources, access follows whatever the original app allows.

The first option can show information to people who don't even have an account in the original app. Sometimes that's the point. Either way, it needs a deliberate business decision.

That's handy when a knowledge team wants to hand-pick approved information for a wider audience. It's also easy to miss if everyone assumes connecting an app keeps every permission intact.

Name an owner for each source, pick the permission model, and test with an ordinary reader's account. Then test upkeep:

• update a policy,
• move a file out of the synced folder,
• remove the connecting account, and
• check the sync status.

Guru says how fast updates show up depends on the source and how much content there is. It also warns that moving a file out of a synced folder can take time to drop it from search. Agree on what happens during that gap before launch.

A hand-picked knowledge base only works if someone cleans up outdated and conflicting material. Give that job to a named person. An AI answer doesn't replace someone owning the source.

Notion: keep search scope and source freshness visible

Notion Enterprise Search comes with Business and Enterprise plans. It can search the Notion workspace and connected apps together. Users can pick which sources to search and turn web search on or off. See Notion Enterprise Search.

That matters for testing. An answer pulled from the public web is not the same as one based on the customer's internal policy.

Notion describes permission checks and matching accounts across connected apps. It also says permissions sync on a schedule, and the schedule depends on the connector. Its security page talks about delays after permissions change or content is deleted.

That page also describes when deleted content stops showing up in two different ways. So don't read it as a promise that removal is instant. Check the specific connector, and agree with the vendor on what behavior you need. See Search security and privacy.

For the pilot, lock the list of sources, use one account that's allowed and one that isn't, and save the IDs of the documents each answer cites.

A citation helps a reviewer check an answer. It doesn't prove the cited text actually supports the answer, or that a later access change has taken effect.

Notion is a sensible pick when the team already works there. Whether it fits still comes down to which sources it covers, which formats it handles, and what controls it gives admins.

Microsoft: verify the configured visibility model

Microsoft 365 Copilot connectors bring outside content into Microsoft's search. They come in two kinds. Synced connectors copy content into an index ahead of time. Federated connectors fetch it live when someone searches. Availability and setup differ, so name the exact kind in the proposal. See the connector overview.

The access setting is the big decision. Microsoft offers one option that follows the original source's permissions, and another that makes connected content visible to everyone in the organization. It warns that the second can overshare sensitive information.

The same guide says that changing this choice currently means rebuilding the connection. Settle it in the design review, before you load a lot of content. See Manage access permissions.

The index browser shows each item's status, when it was last refreshed, its properties, and who can access it. Use it when an answer is missing, or when someone sees something they shouldn't. Start by checking whether the item was indexed with the right details and permissions. See Validate indexed content.

A company already on Microsoft may find ownership and admin simpler. That won't fix documents that were shared too widely to begin with, or a connector set up for the wrong audience.

Run a pilot that exposes the hard parts

Start with fake documents. Set up two teams: a support reader and a policy owner.

Give the reader access to three things: the current refund policy, an older version of it, and a general support article. Keep a fourth document, an exceptions policy only managers should see, locked away from them.

Before you ask each question, write down which source should come back and what a good answer looks like. For every try, save the account, the question, the connector setup, the state of the source, the citations returned, the answer, and the time.

Here's a good starting set of tests:

This is a plan for what to check. It doesn't claim every product shows you every one of these details. If a product doesn't let you see something, that's a question for the vendor. Stick to test accounts and harmless documents until you understand how access works.

Measure usefulness without hiding serious failures

Split your questions into two groups: ones the system should answer, and ones it should refuse or leave alone. Then report three numbers:

• how many answerable questions got a supported answer,
• how many unanswerable ones were correctly declined, and
• how many times someone saw something they weren't allowed to.

Never fold a permission leak into an average satisfaction score.

Have someone from the business judge whether each answer actually lets them make the decision. Finding a relevant document and solving the customer's question are not the same thing.

When an answer is rejected, write down why: outdated source, missing context, wrong audience, a guess the sources don't support, or a citation nobody can use.

Compare time spent and review effort against how the team works today, using the same tasks. Note the sample size and conditions. A small pilot with fake data checks your method and finds problems. It doesn't prove the whole company will get faster.

Hand off a maintainable knowledge service

The handoff should include:

• a list of every source and its owner,
• which account each connector uses,
• who each source is meant for,
• how syncing works and what happens on deletion,
• the test cases, and
• who to call when something breaks.

Decide who settles conflicting policies, and who can switch off a connector when an access test fails.

Estimate the full cost: licenses or usage fees, loading content, building it, reviewing answers, keeping sources up to date, and handling incidents. Ask what happens when the content grows, a new team joins, or a contract ends. Without those answers, no cost comparison across vendors means much.

A good place to start is whichever platform the customer can run with the least extra complexity, as long as it passes the source and access tests. The best demo isn't a perfect answer. It's a team that can explain a correct answer and a planned failure, then show how they'd fix it.

If you're delivering this for a customer, read the forward-deployed engineering playbook next.

Related Guides

• Build a Small RAG Pipeline and Measure What It Misses
• Companies Hiring Forward-Deployed and GTM Engineers
• Forward Deployed Engineers for Enterprise AI: Why the Model Works