The first week after an AI assistant goes live over a company's documents almost always produces the same incident. Someone asks about "the pay structure" and gets a neat summary of the whole department's salary sheet.
Internal AI search is a language model that answers employee questions from the company's own documents: SharePoint, network drives, the DMS, the wiki. It first retrieves the relevant passages and then writes an answer from them. That makes everything an employee can technically open findable, including things they'd never have stumbled on by hand. Permissions that sat too wide for years, unnoticed, become visible on day one.
Why does internal AI search expose oversharing?
AI doesn't create oversharing. Years of "just share it with everyone" do, along with folders that inherit permissions from an overly broad parent and team sites that nobody owns any more. As long as search was manual, none of that showed. Nobody scrolls through 40,000 files looking for a salary overview.
An AI assistant does the scrolling for them. Microsoft says so plainly in its documentation on data, privacy and security for Microsoft Copilot (formerly Microsoft 365 Copilot): Copilot only surfaces organisational data to which the user has "at least view permissions". Google says the same about Gemini in Workspace: if you don't have access to a document, Gemini won't retrieve it. That sounds reassuring, and it's exactly the problem. The assistant respects the permissions, and the permissions are wrong.
Microsoft has built a dedicated report for it. The data access governance reports look for sites, folders and files that are "effectively public" because they've been shared with the built-in group "Everyone except external users". That group automatically contains every internal user. An HR folder that was once shared with it is open to last week's intern.
Is it a data breach if a colleague sees an HR file through AI?
A colleague seeing an HR file through AI is a personal data breach under the GDPR's definition. Article 4(12) of the GDPR defines a personal data breach as including "unauthorised disclosure of, or access to" personal data. The Dutch data protection authority, the Autoriteit Persoonsgegevens (AP), describes a breach on its page wat is een datalek as access "without permission or without it being intended", and its own example is a medical file viewed by an unauthorised employee.
Whether you must notify the regulator within 72 hours is a separate question. On its page about whether to report a breach, the AP lists "the wrong colleague or department within your own organisation" as a trusted recipient, which can reduce the severity. The same page lists health data and information about work performance as high-risk categories. A sick-leave file or a performance review landing with the wrong colleague isn't an edge case.
Two things always apply. You record every breach in your own internal register, even when you don't report it. And the overly wide permissions are themselves a problem under GDPR Article 32, which requires appropriate security against "unauthorised disclosure of, or access to" personal data. Neither the AP nor the EDPB has ruled specifically on AI assistants surfacing overshared content. The reasoning above is ours, built on the definition.
What does Microsoft's standard fix solve, and what doesn't it?
Microsoft's deployment guidance starts with "Remediate oversharing": an assessment of sites with oversized audiences, broken inheritance and no owner, followed by access reviews per site. That's sound advice, and it's also just work. Someone has to decide, site by site, who gets in.
Because that takes time, Microsoft offers a stopgap called Restricted Content Discovery, which removes sensitive sites from Copilot's results. The documentation is candid about its limits: it "doesn't change existing permissions", it's designed as a "temporary governance control", and on sites with more than 500,000 items a change can take more than a week to show up in Copilot. You hide the content from the assistant. An employee who opens the file directly still sees it.
| Measure | What it does | What it doesn't do |
|---|---|---|
| Restricted Content Discovery (Microsoft) | removes sites from Copilot results | fix permissions; it's temporary |
| Access review per site | fixes the permissions themselves | scale without site owners |
| Labels and DLP (Purview) | excludes labelled content from Copilot | find old, unlabelled files |
| Your own search layer with an allowlist | indexes only sources you explicitly switch on | fix oversharing inside those sources |
How does a search layer enforce access rights?
A search function built on retrieval-augmented generation, or RAG, splits documents into chunks and stores them in a search index. Enforcing access rights means storing, for every chunk, which groups may see it, and filtering on the asker's groups at query time. Microsoft describes the pattern for Azure AI Search as a filter applied "to every query". Elastic, OpenSearch and Qdrant each have their own version. The OWASP Top 10 for LLM applications lists the absence of it under LLM08, Vector and Embedding Weaknesses and recommends "permission-aware vector and embedding stores".
Simple on paper. In projects, it goes wrong in three places.
Permissions in the index go stale
Permissions are copied at indexing time. If someone changes a folder's permissions afterwards, the index only learns about it at the next sync. Microsoft's documentation on document-level access control says changes are reflected only "after that metadata is synchronized to the index", and that changes inherited from a parent scope "require an explicit refresh". A worked example: sync permissions once a night, remove a departing manager from the Board group at 9:00, and they can still retrieve board papers until the next morning. That's 21 to 24 hours. Fine for most documents. Not for a restructuring file.
Chunks don't inherit their document's permissions by themselves
A 60-page document easily becomes 150 chunks. If permission data lives only at document level and isn't copied onto every chunk, the search layer filters nothing. Microsoft warns about this itself: without that projection, "chunk-level references aren't filtered". It's an easy bug to ship in a home-built prototype, because a single-user demo never shows it.
The asker's groups
Fetch the user's group memberships live from Entra ID or Active Directory at query time, not from yesterday's copy. That keeps one side always current. The other side, the permissions on the documents, still depends on how often you sync.
Time saved
Save 4 hours per week on searching for policies, procedures and past case files
Why a local search layer?
Your own search layer doesn't fix oversharing. It inherits the same permissions as the source systems, and a wrongly shared folder stays wrongly shared. The difference is in three design choices that an off-the-shelf assistant doesn't give you.
You start from an allowlist instead of everything. An off-the-shelf assistant indexes the whole tenant by default, and you carve out exceptions afterwards. Your own layer indexes only the sources you switch on: quality manuals and procedures first, project folders later, and HR and finance folders never, or only for the groups that already belong there.
You log every retrieved passage. Which user saw which chunk from which document, with which permissions at that moment. That's the evidence you need when someone asks whether a breach took place, and our guide to AI audit trails and logging covers how to set it up.
And the questions themselves never leave your network. People type things into internal search that they write down nowhere else: colleagues' names, client problems, questions about dismissal procedures. With an open-weight model on your own hardware or in a European private cloud, both the documents and the questions stay inside. The technical setup is covered in implementing an on-premise LLM.
When is Copilot with SharePoint Advanced Management the better choice?
Copilot with SharePoint Advanced Management is sometimes simply the better choice. If your organisation works entirely in Microsoft 365, already has Copilot licences, and keeps its sensitive documents on a small number of well-defined sites, Microsoft's route is faster. According to Microsoft, SharePoint Advanced Management is included with the Copilot licence, and the assessment points you to the problem sites. Building your own search layer doesn't pay off there.
The balance tips when documents live outside Microsoft 365, in a DMS, network drives, an ERP or a case management system. Or when the questions are sensitive in themselves. Or when you need to prove which passage was shown to whom. Either way, start with the same step: run a report of everything shared with "everyone", and clean it up before go-live, not after. For broader security of AI systems, see AI and data security. For the choice between an off-the-shelf tool and a custom build, see setting up an AI knowledge base, and the wider trade-off is in our guide to local AI for business.