--- title: "Why Enterprise AI Needs an Analytics Layer, Not Just an LLM" url: "https://ctosync.com/insight/why-enterprise-ai-needs-an-analytics-layer-not-just-an-llm/" author: "Maurice Sikkink" published: "2026-09-25" updated: "2026-09-25" --- # Why Enterprise AI Needs an Analytics Layer, Not Just an LLM One of the most impressive things about modern AI is how easy it makes difficult things look. Connect an LLM to company data, ask, “Why did sales drop last week?”, and seconds later you can get a confident, well-written explanation. That creates a problem. In enterprise AI, a convincing answer and a correct answer are two very different things. I've spent years building analytics technology, and this distinction has become increasingly important as we've connected AI assistants directly to business data. Giving an LLM access to more data doesn't automatically give it more understanding. Enterprise AI needs something between the language model and the raw data: an analytics layer. ### Access to data isn't the same as understanding it Consider a seemingly simple ecommerce question: Why did sales drop last week? Answering it properly may require much more than querying total revenue. Did traffic decline? Did conversion change? Was the decline concentrated in new or returning customers? Was one product category responsible? Did customers continue viewing products but stop adding them to their carts? Did checkout behavior change? And there's another possibility: perhaps nothing is particularly wrong with the store. Maybe demand for that product category declined across the wider market. An LLM can generate SQL to investigate some of these questions. But SQL generation alone isn't analysis. The system still needs to understand which questions should be investigated, which methodology is appropriate and how the results relate to one another. That's the role I think the analytics layer increasingly needs to play. ### Give AI analytical tools, not just database access We've taken this approach with [Stormly](https://www.stormly.com/?utm_source%3Dchatgpt.com). When someone asks a business question through an MCP-connected AI client, the system doesn't simply expose a database and hope the language model writes the right query. If an established analytical report can answer the question, it can use that methodology. If the question requires something different, the system can generate SQL to investigate it. It can also incorporate external market-trend data when that context is relevant. The distinction might sound subtle, but I think it's fundamental. Imagine asking why repeat purchases declined. A language model with database access can produce a query. An analytics system should first understand what constitutes a repeat purchase, which customer cohorts should be compared, whether the time periods are comparable and which behavioral changes might explain the result. The difficult part isn't getting AI to query data. It's getting AI to ask the right questions of that data. ### More context isn't always better context There's another misconception I see as companies adopt AI: if the model isn't performing well enough, give it access to more information. More isn't necessarily better. Connecting an agent to your analytics, CRM, support platform, product catalog, email and every internal database creates an enormous context surface. It also creates more opportunities for the AI to misinterpret data, combine things that shouldn't be combined, or reach conclusions using the wrong source. The better architecture is often to give AI the right context for the decision being made. For analytics, that might mean behavioral events, product and SKU information, transaction data and relevant external trends. For another task, the appropriate context will be completely different. This has a second advantage: permissions become easier to reason about. If an agent needs to analyze ecommerce performance, it shouldn't automatically need permission to change product prices or email customers. Access and action are different things. As AI systems become more agentic, I think that separation will become increasingly important. ### Auditability matters more as AI becomes autonomous There is also a practical consequence of allowing AI to decide how to investigate a question. A user may ask one thing, but the system might perform several analytical steps before producing the answer. We shouldn't solve this by asking the user to approve every query. That would defeat much of the purpose of an AI agent. But businesses should be able to reconstruct what happened. Who initiated the analysis? What data was available? Which analytical approach was used? Where did the conclusion come from? For enterprise AI, that chain will matter increasingly because decisions can have financial consequences. ### The LLM should be the interface, not the entire system LLMs are extraordinarily good at turning natural language into an interface for complex systems. That's one of the reasons I'm excited about them. But I don't think enterprises should mistake the interface for the underlying intelligence architecture. If you're building AI around important business decisions, I'd ask three questions: - Does the AI have access to the right context, or simply more context? - Does it have analytical methods it can rely on, rather than generating every analysis from scratch? - Can you trace a conclusion back to the data and analysis that produced it? Enterprise AI will become dramatically easier to use as natural-language interfaces improve. The harder challenge is making sure that underneath that beautifully simple chat box, the analysis is something the business can actually trust. --- Maurice Sikkink is CTO & Co-Founder of [Stormly](https://www.stormly.com/). Maurice builds AI-powered analytics technology that connects behavioral, product and market data with AI-driven analysis and natural-language access.