Somewhere between approving an AI project and starting it, a lot of companies get talked into building a data lake first.
The pitch makes sense on its face. AI needs data, your data is spread across the ERP, the CRM, a handful of SaaS tools, and some spreadsheets, so centralize it, clean it up, and then the AI has something to work with. Every vendor in the data space will agree with you, because they sell the middle part.
Then a year goes by. You have got pipelines, a warehouse, an orchestration tool, and a consultant who knows how it all fits together, and the quoting tool you approved in the first place still is not built.
I have watched this happen to companies that had no business building any of it. The reason is almost always the same: nobody asked what data the actual use case needed.
A quoting tool needs a few dozen comparable jobs. A support assistant needs last year's tickets. A system that pulls decisions out of meeting transcripts needs the transcripts. Each of those lives in one or two systems, and it is a corner of your data, not all of it.
For work like that, calling the source system directly beats piping everything into a lake. The ERP already has the data and keeps it current, and it already knows who is allowed to see what. Every copy you make goes stale, and each one comes with a permissions model you now have to rebuild.
A lake is not wrong for these companies — it is early, and early is expensive. The months of plumbing come out of the same budget and the same patience that were supposed to fund the AI work. Leadership approved a quoting tool and got a data engineering program instead, and that is usually how the project loses its sponsor.
There is a version of this where you do need it. You have got a case for centralizing when the questions you are asking cross several systems and none of them can answer alone.
So the test is not company size — it is whether the question spans systems. A 200-person company with a cross-source reporting problem should build it. A 2,000-person company whose AI use case reads support tickets should not.
Give every project its own point-to-point integration and in three years you have got forty of them, nobody remembers which ones matter, and you have rebuilt the mess you were avoiding — just spread out. That is a real cost. The way through it is to build integrations on purpose and keep a list, and when the same two or three systems keep showing up in every new project, that is when centralizing has earned its budget. You are letting usage tell you what to build instead of guessing up front.
Write down the three questions you want AI to answer this year, in plain language — the way the person who needs the answer would say it. For each one, figure out where that data lives today and count the systems.
More often than not, the first question comes back as one system and a week of integration work.
What are your three questions, and how many systems does each one really touch?