AI in Business: The Real Blocker Isn't the Model, It's Access to Your Data

You saw the demo. Someone connected a model to three documents, asked a question, and got back a clean answer. Everyone in the room decided the matter was settled. Six weeks later the project has stalled, and nobody can really say why. The technology worked, after all. In the demo.

I see this moment come back on almost every business AI project. The misunderstanding is always the same: people think the job is to pick the right model. In reality, the model has become the easy part. The real work, the part the demo hides, is access to your data.

Why the model is no longer the problem

Two years ago, the choice of model carried real weight. The quality gap between two providers was visible to the naked eye, and a bad choice could sink a use case. That is no longer the situation.

Today's general-purpose models can summarize, classify, extract, rephrase, and answer at a level that is more than enough for most of a company's needs. The difference between two serious providers no longer shows up on your real cases. It shows up on technical leaderboards that look nothing like your daily work.

The direct consequence: when an AI project fails, it is almost never because the model was not good enough. It is because the model was given the wrong data, dirty data, or no reliable data at all. The model always answers something. If it answers off target, look first at what you gave it to read.

Where projects actually stall

The demo succeeds because it cheats, without meaning to. You pick three documents that are clean, recent, well written. You ask a question whose answer you already know. Everything works. Moving to scale reveals what the demo avoided.

First break: volume. Three documents become three thousand, spread across a file server, an inbox, a business tool, and two spreadsheets nobody opens anymore. The model does not know where to look, because nobody told it where the truth was.

Second break: the state of the data. Your internal documents contradict each other. Three versions of the same procedure live side by side, two different prices sit in two files, the last update dates back to someone who left a year ago. The model does not arbitrate. It hands back the mess you gave it.

Third break: permissions. The moment the tool leaves the scope of a single person, the access question blows up. Who has the right to see what? An AI assistant that answers everyone with HR or sales data from across the company is not a productivity gain. It is an incident waiting to happen.

The four layers of an AI project, from the most visible to the most decisive

The demo plays out on the first two rows. The real project is won or lost on the last two. That is the exact opposite of the attention they get at the start.

How to frame data access before plugging in AI

The good news is that this work can be framed. It does not require rebuilding your information system. It requires answering a few precise questions before writing the first line of code. This is the heart of the Scan phase in the S3 method.

Which source is authoritative for each piece of information. For the use case in question, list the information the model needs, and for each one, name a single place that holds the truth. If two systems carry a product's price, decide which one wins. That decision is worth more than the choice of model.

What state those sources are in. Before automating, look at reality: duplicates, outdated versions, unreadable formats, empty fields. A targeted cleanup limited to the data for that use case is often enough. There is no need to tidy the whole company to start one specific project.

Who has the right to see what. Define access scopes before connecting anything. The tool must respect each user's existing permissions, not bypass them in the name of a smoother experience.

Who is accountable over time. A data source is alive. Someone has to stay responsible for its freshness and quality once the project is in production. Otherwise the tool quietly degrades and nobody notices until the first bad answer in front of a client.

The mistake that costs the most

The classic mistake is to switch models when the project disappoints. You move from one provider to the next, hoping the next one will understand better. The result does not move, because the problem was never there.

As long as your data is scattered, contradictory, and without a clear owner, the best model in the world will faithfully hand back your mess. The reverse is also true: once data access is framed, even a modest model produces results your teams actually use. The lever is not in the engine. It is in what you give it to read.

Frequently asked questions

Do I need a big data governance project before doing any AI? No. That is the surest way to never start. The framing happens at the scope of the use case, not at the scale of the whole company. You prepare the data this specific project needs, nothing more, and you expand later if the next case justifies it.

How do I know if my data is ready for AI? Ask yourself the question of authoritative sources. If, for each piece of information useful to the use case, you can name a single place that is up to date and reliable, you are ready. If not, you already know what is left to do before plugging in the model.

So the choice of model does not matter at all? It does, but far less than people think, and later in the process. Start with a serious general-purpose model, focus your effort on data access, and only revisit the choice of model if a precise need justifies it, for example a sovereignty or cost constraint.

How long does it take to frame this access? On a well-bounded use case, the diagnosis takes a few days, not a few months. The goal of the Scan phase is precisely to deliver this framing within 48h of a first audit, so you know whether the project holds up before committing to any development.