Why SharePoint Isn't Enough in the Age of AI

Why SharePoint Isn't Enough in the Age of AI

September 2026

Agilis

Before you use AI to read your repository, consider what's in it.

Nearly all my conversations with ingredient and material suppliers about AI start with their extensive collection of documents, hosted on SharePoint. These files include safety data sheets, technical data sheets, certificates of analysis, and various certifications, such as kosher and halal certifications, as well as allergen statements and regulatory declarations. Generally, the idea is that an AI system could query data from the documents, since it's already readily available; all the AI would need to do is read it and surface answers.

This framing is wrong, and I'll explain exactly why.

The framing misidentifies the information as a search problem, when the real question is what we are searching through. That shift in vantage point turns the AI question into something completely different.

What's actually in there?

SharePoint is a file store, and it does that job well. Over a decade of normal business, however, a lot of content accumulates in one, which brings several challenges.

Here are a few.

1. Every version of every document is live at once

Separate files make up the collection, such as Citric-Acid-SDS.pdf, then Citric-Acid-SDS-v2.pdf, then Citric-Acid-SDS-SupplierA.pdf, then Citric-Acid-Kosher-SDS-SupplierB.pdf.

They're all present and indexable, with no indication of which one is the current version for AI.

2. A flat hierarchy carrying no relationships to other systems.

A folder structure only shows where someone filed something in the past; it doesn't show relationships between items, like how the SDS applies to eleven child SKUs or ERP across three grades. The folder structure also doesn't reflect that two of those grades were discontinued. And this relationship may exist only in someone's head, a spreadsheet, or nowhere at all.

3. Filenames that don't match the content inside them.

Filenames often get renamed to fit a certain convention, but their contents are revised without a corresponding name change. It's common for someone to save a supplier's document under an internal product name. So the connection between a file's name and its actual contents deteriorates over time, often without being noticed.

4. Revisions too small to notice.

Small changes can deal a huge blow to your commercial agility. A concentration range narrows, impurities differ based on the manufacturing process, or regional applicability changes. At first glance, the document appears unchanged. It doesn't raise any red flags. The two named versions are listed together, and there's no visible distinction between them unless one carefully reviews the entire document. 

Point an AI at that, and it reads everything with equal confidence, giving you an answer. This answer may come from the current document or its predecessor, and there's no clear way to tell which.

The duplication problem is bigger than people expect

Recently, a distributor shared their story towards AI readiness. They reviewed their ingredient SKUs and documents, which initially contained roughly 12,000 documents. After determining what was current and duplicated, or obsolete, they ended up with around 4,000.

About two-thirds of the document repository was noise.

Their decision to do the cleanup first isn't surprising, given that a decade of keeping extra copies can lead to this kind of situation. What really caught my attention, though, was the reasoning behind it. They knew each redundant document would cost time and money to process, even with AI. And it wouldn't help build user trust or stay consistent long enough to support future AI ambitions.

The cleanup happened beforehand, before any AI involvement. 

They understood that a clean document set was a prerequisite for AI applications, not something AI would deliver autonomously. This isn't to say AI wasn’t leveraged in the process, but it wasn't left to make critical decisions about what applies and what doesn't. 

My position is straightforward: AI has a lot to offer in this area.

People aren't good at comparing two versions of a document to find the one changed clause. Models are. This is the failure mode where nobody catches the revision. Manually diffing 12,000 PDFs isn't something people do. AI can classify documents by type and sub-type, pull out issue and expiry dates, flag near-duplicates, extract attributes from an SDS into structured fields, and propose which product a document belongs to. It makes all this dramatically faster.

I distinguish between two approaches: using AI to create a structured layer, where experts verify the content, and relying on AI to analyze an unstructured file store without human oversight in production. These projects have distinct risk profiles and requirements.

The first risk is the one a demo never shows you: what this actually costs once you're past a clean subset of documents.

The first risk: a cost that doesn't show up until scale.

PDFs are one of the most expensive things you can feed a model, and chemical documentation is the worst case. Anthropic's own documentation puts it plainly - a PDF page typically consumes 1,500 to 3,000 tokens, because every page gets processed as an image as well as extracted text. Seven times the cost of the same content as plain text.

Run these numbers against a real portfolio and the number moves fast. 10,000 SKUs sitting on around 40,000 documents works out to roughly 120 million tokens per pass. "Per pass" is the word to hold onto - documents change constantly here, so every revision and every new certificate triggers it again. This never closes out the way an implementation line item does.

So does the model still work at full portfolio scale in year three, with the document count still growing? A pilot on a clean 250-SKU subset won't tell you.

So the real question isn't about AI.

The question is whether SharePoint or other repositories are the right system to launch AI on indiscriminately.

It isn't, because SharePoint was never designed for this purpose. It's a file storage system, not a product or document management tool. SharePoint doesn't understand what a product is, or which document is the current version. It also doesn't know that a document may apply to multiple SKUs. It doesn't have a concept of a certificate expiry date. Relying on AI to infer all this information from filenames and folder paths, for every query, is essentially asking it to recreate a system of record that was never established.

Expensive and unreliable: that's what this gets, and it happens in exactly the places you won't be watching. It demos well, though. 

Something has to exist first.

This is why we at Agilis build the asset and data layer first, before any downstream use case or digital/AI applications, because I think sequencing matters more than the technology itself.

One record per document type per product, that's the goal. A single, current version and a history of changes, rather than multiple files like "final draft" or "latest version". If a document is outdated, it should be marked as superseded, so it doesn't show up in search results alongside its replacement. Meanwhile, the document is clearly mapped to a SKU or product record in the Product Information Management System.

Your existing systems, such as ERP and CRM, remain in place, and the document systems stay intact. The asset layer connects to these systems. It becomes the key to making documents usable across all of them.

Something worth noticing happens when that's done: many AI uses are no longer needed.

Properly structured data makes finding the right halal certificate for a specific grade a simple matter of filtering and sorting, which is instantaneous, exact (i.e., deterministic), and auditable. As someone who builds AI solutions, I can attest that for many document retrieval tasks, relying on AI is like using a sword to stitch.

The second risk: paying that price forever

Go back to the 120 million tokens from a single pass. For global enterprises with hundreds of thousands of documents and a global user base, that token count for indexing documents and querying data grows exponentially. It repeats on every revision and every query. We don’t count them due to the subsidized costs of running these tokens. AI is living in an Uber moment, and the costs will be transferred to enterprises at some point. A well-built, structured data and document foundation is your hedge against paying frontier prices for the same answer twice. It's often faster, cheaper, and more accurate, because it's deterministic rather than inferred.

Where this leaves you

Three questions are worth asking before anything else when someone's selling AI capability on top of SharePoint or any document repository.

  1. How does the system know which version is current? If the answer involves filenames or upload dates, it doesn't.
  2. What does this cost scale-up look like for the complete portfolio in year three? Not pilot cost. Steady-state cost, with document count growing and re-indexing continuous.
  3. When it's wrong, how do we find out? If there's no record to audit, only files and a model reading them, you won’t know when your teams, and perhaps customers, receive wrong information.

Everyone's AI works on day one. The demo is on a clean subset, the documents are current, the questions are the ones it was tested on.

The question is what it's right about on day 400, when nobody's been watching the folder.