Ask Claude, ChatGPT, Copilot, or Gemini to find a slide from a deck your firm made two years ago, and the honest answer is: it probably can't. Not because the model isn't capable — it's because of what stands between the assistant and your archive, and what that archive actually looks like once you get there. Both are worse than most people assume.
The assistant has no default access
Every general-purpose AI assistant starts a conversation with no memory of your files. Claude, ChatGPT, and Gemini have no ambient connection to your SharePoint, OneDrive, or Google Drive — that's a deliberate design choice, not an oversight. Access has to be built: a file upload, a connector, an MCP server, a Graph API integration. Copilot is the exception in that it ships pre-wired into Microsoft 365, but even there, "wired in" only means it can query Microsoft Search — it doesn't mean the underlying archive is actually searchable in a useful way.
That distinction matters, because giving an assistant access to your files and giving it the ability to find the right one are two different problems. Solving the first doesn't solve the second.
What "access" actually gets you
Once an assistant can reach your files — through a connector, an MCP integration, or a native product like Copilot — what it can do with them is bounded by how those files are indexed underneath.
For PowerPoint archives on SharePoint or OneDrive, that indexing is built on Microsoft Search: a text index over file contents and metadata. It extracts the words on a slide, the title, speaker notes, filename, author, and modification date. Query matching runs against that extracted text, with a semantic layer on top that's a real improvement over old exact-keyword search — it can match on related wording, not just identical terms.
What it cannot do is read the slide the way a person does. Four gaps show up consistently.
1. Slides communicate visually, and that's invisible to a text index
A margin-compression chart, a maturity-stage matrix, an org chart drawn as a pyramid of names, a person icon next to a gear meaning "engineer" — none of this is text. It's layout, iconography, and chart structure carrying the actual insight. A text-based index sees whatever caption sits nearby, if there is one, and nothing else. If the meaning lives in the visual, it's outside the index entirely.
2. Retrieval returns files, not slides
Search a SharePoint-grounded assistant for a specific slide and you get a deck back — the whole file. If that deck runs 60 or 100 pages, you've traded "which of 800 decks has this" for "which of 80 slides in this deck is it," which is a smaller problem but still the same problem. Slide-level granularity generally isn't there.
3. Metadata isn't context
Filename, author, and folder tell you where a file lives, not what it means. An "engineer" on a telco engagement and an "engineer" on a mechanical industrials engagement are different concepts wearing the same word, and interpreting either correctly depends on the project behind the slide — the client, the sector, the phase of work. That context typically lives in people's heads or scattered across a few conversations, not in any field an index can query.
4. Duplicates multiply the noise instead of resolving it
Because projects run in parallel and the same analysis gets rebuilt by different teams who never find each other's version, most archives end up with several copies of essentially the same slide — same chart, same framework, slightly different formatting or a quarter's difference in the numbers. A text index has no concept of "the same content, filed twice." It returns each copy as an independent hit, so a search that should point to one answer comes back as five near-identical ones, with no signal for which is current, which is the trusted version, or which one to actually cite.
Why the archive itself makes this worse
Even a perfect retrieval layer struggles against how these archives actually exist inside firms. Slides get built in one project, saved to a personal folder, occasionally copied into a shared drive, and rarely tagged consistently on the way. Naming conventions vary by team. None of this is a model problem — it's an archive that was never structured with retrieval in mind, built up over years by people optimizing for shipping the deck, not for finding it again later.
Stack an unstructured archive underneath a text-only index, hand the result to an AI assistant, and the assistant's language ability doesn't change the outcome. It can only work with what retrieval hands it.
What actually fixes it
Closing this gap takes more than a better connector. Four things have to be true at once:
The retrieval layer has to read the visual, not just the text. That means processing charts, diagrams, and layout as content, not skipping straight to captions.
Results have to resolve to the slide, not the file. A person asking a question wants the one slide, not a deck to scroll through.
Retrieval needs the surrounding context. Which project, which client, which engagement a slide came from changes what its content means, and a system that ignores that will misread slides that are otherwise identical on the surface.
Duplicates need to be recognized as duplicates. Similar slides scattered across the archive have to be grouped as the same content, not returned as separate, undifferentiated hits — otherwise retrieval trades one kind of noise for another.
None of the general-purpose assistants are built to do this by default — it isn't their job. It's a retrieval problem that sits underneath them, and it has to be solved before an assistant's language ability is worth much against a firm's actual archive. Dedicated retrieval systems built specifically for slides — ones that index the visual, the text, and the context together — are what closes that gap. Connecting a capable assistant to an under-indexed archive just moves the search problem one layer deeper without fixing it.