A colleague of mine, someone whose judgment on technology and business I trust deeply, said something recently that has stayed with me. Speaking to a room of senior consultants, he put it plainly:
“How we architect data, how we store it, how we use it is now 50% different than what we would have done five years ago because of the intelligence layer. Now I say that, but if somebody says to me, ‘Can you pin me down or can you explain to me exactly why it’s 50% different?’ I can maybe go half a layer more and then that’s it. I’m out of my league.”
He is not out of his league. He is describing, with admirable honesty, a gap that exists across the industry right now. The intuition is ahead of the language. Leaders can feel that the relationship between data and intelligence has fundamentally changed, but the frameworks for explaining that change, and for acting on it, have not caught up.
The natural response when leaders sense a shift like this is to build a roadmap. Map the current state, define the target, close the gap. That instinct is common practice, and for this particular shift, it is in my opinion a wrong one. I will show you why further down in this post, and what to do instead.
For context, allow me to recap the first four posts of this series titled “Talking to Data.”
What We Have Built So Far
Over the previous four posts, the argument has moved through a deliberate progression.
It started with architecture. The first post made the case that open protocols like MCP shift AI integration from proprietary connectors to governed orchestration. The technology question is not “can we connect?” but “can we control how that connection scales, adapts, and remains vendor-neutral?” That post established a principle: the organization should own the bridge between data and intelligence, not the vendor.
The second post shifted from infrastructure to interaction. It showed what happens when the bridge is in place and a business user sits down to follow a thread of inquiry across multiple data sources in real time. No pre-built reports. No intermediaries. The analytical initiative moves from IT to the person asking the question. That post introduced the concept of walking through data and argued that traditional BI still owns operational reporting, but it no longer owns the strategic conversation.
The third post addressed the question that immediately follows: if you are querying across multiple sources conversationally, how does the AI know what “revenue” actually means? Semantic contracts, explicit and machine-readable agreements about what business terms mean, emerged as the governance bridge that separates a useful conversational AI from an expensive guessing machine. Research from Sequeda, Allemang, and Jacob demonstrated that without semantic grounding, AI gets enterprise questions wrong systematically, not occasionally.
The fourth post turned the lens on the human side. The technology performs. The bottleneck is us. Productive data conversations follow identifiable patterns: starting broad, sharpening progressively, naming what caught attention, crossing source boundaries deliberately, and knowing when to ask the synthesizing question. The failure modes are equally identifiable: vague openers, context collapse, overloaded questions, and confident misinterpretation. This is a new competency that almost nobody is training for.
Each of these posts answered a question raised by the one before it. Together, they describe something larger than any individual piece.
The Shift Nobody Has a Name For
My colleague said it is 50% different. I think he is directionally right, but the percentage is less important than the nature of the change. It is not that we need 50% better infrastructure, or 50% more data, or 50% faster pipelines. The change is structural. It is about the relationship between the data layer and the intelligence layer, and it operates at a level that traditional data architecture vocabulary was not designed to describe.
Here is what I mean.
In the old model, data architecture and intelligence were separate concerns handled by separate teams on separate timelines. Architects designed schemas. Engineers built pipelines. Analysts consumed what was delivered. Intelligence, meaning the act of deriving insight, happened at the end of a long chain, and it happened within the boundaries of what had been pre-built.
The intelligence layer was, functionally, a consumer. It ate what it was served.
What has changed is that the intelligence layer is no longer just a consumer. It is a participant in the architecture itself. When an LLM connected through MCP can query across sources, interpret business meaning through semantic contracts, follow threads of inquiry that nobody anticipated, and even enrich and persist data back through APIs it generates on its own, the boundary between “data infrastructure” and “intelligence” blurs in ways that our existing frameworks do not account for.
The data layer does not just feed the intelligence layer. The intelligence layer changes what the data layer needs to be. That is the shift my colleague can feel but cannot yet fully articulate. And it is why the old debates about lakes versus warehouses versus lakehouses versus mesh are increasingly beside the point. Those debates assume that data architecture is a settled problem to which intelligence gets bolted on at the end. The reality emerging now is that architecture and intelligence co-evolve.
Why Roadmaps Will Not Get You There
When organizations sense a shift like this, the instinct is to build a roadmap. Map the current state. Define the target state. Identify the gap. Build a phased plan to close it.
That instinct is a common approach, and for this particular shift, it is wrong.
A roadmap assumes the destination is a more sophisticated version of where you already are. Better infrastructure. Smarter tools. More automation. It assumes linear progress along a known path. But the change I have been describing is not linear. It is a reorientation. The destination is not “better BI.” It is a fundamentally different relationship between people, data, and intelligence.
A more useful metaphor comes from navigation. Not a road map but a navigational chart. A navigational chart does not prescribe a route. It describes terrain. It marks hazards. And it identifies waypoints, points of confirmed orientation that tell you whether your heading is sound.
The difference matters for how organizations approach this shift. A roadmap produces the question “what is the next step?” A navigational chart produces the question “where are we in the space, and are we reading our position correctly?” Those are fundamentally different conversations, and they lead to fundamentally different kinds of organizational clarity.
Five Waypoints for the Shift
If I distill this series into navigational waypoints, they look something like this.
The first waypoint is architectural independence. The organization owns the bridge between its data and any intelligence layer it chooses to deploy. This is not a vendor selection decision. It is a governance decision. If swapping one AI model for another requires re-engineering integrations, you have not reached this waypoint. MCP and open protocols are the mechanism. Vendor neutrality is the confirmation.
The second waypoint is semantic clarity. The organization has explicit, machine-readable agreements about what its key business terms mean, independent of where the underlying data lives or how it gets processed. This is not a metadata project. It is a business governance discipline. If two executives can still look at different revenue numbers and not know why they disagree, you have not reached this waypoint. Semantic contracts are the mechanism. Trustworthy answers are the confirmation.
The third waypoint is conversational capability. Business users can follow a thread of inquiry across multiple data sources in real time, without pre-built reports, and arrive at strategic insight. This is not a tool deployment. It is a shift in who holds the analytical initiative. If exploratory analysis still requires a two-week turnaround from the BI team, you have not reached this waypoint. MCP-connected conversational interfaces are the mechanism. Autonomous inquiry is the confirmation.
The fourth waypoint is human readiness. The people using conversational data tools can distinguish productive patterns from failure modes, can maintain analytical threads, can verify results, and can recognize when the AI is confidently wrong. This is not a training program checkbox. It is an emerging competency. If business users are accepting every AI-generated answer at face value, you have not reached this waypoint. Practiced, skeptical inquiry is the mechanism. Consistent insight quality is the confirmation.
The fifth waypoint is adaptive architecture. The organization treats data architecture not as a fixed structure but as an evolving system that co-develops with the intelligence layer. Schemas adapt. Semantic contracts get revised. New data sources get connected as the questions demand them rather than as IT projects deliver them. This is not a technical capability. It is an organizational posture. If your data architecture can only change through quarterly release cycles, you have not reached this waypoint. Continuous co-evolution is the mechanism. Architectural responsiveness is the confirmation.
These waypoints do not need to be reached in order. An organization might build strong conversational capability before it has formalized its semantic contracts. It might have architectural independence but lack human readiness. The waypoints are not a checklist. They are reference points that let you assess your position honestly, recognizing both where you are strong and where you are exposed, without forcing the fiction that every organization follows the same sequence.
The Advisory Gap
My colleague’s observation points to something the market has not yet caught up with.
There is a growing population of technology leaders who can feel this shift happening, who know their current investments in data infrastructure are not quite pointed at the right target, and who cannot find advisors who can explain why. The consulting market is full of experts who can optimize your data warehouse, implement your BI tools, or build your AI proof of concept. It has far fewer people who can sit across from a CTO and say: here is how the relationship between your data layer and your intelligence layer has changed, here is what that means for where you invest, and here is how to read your position as you navigate through it.
That gap is real, and it is widening. The organizations that close it first, either by developing internal clarity or by finding external guides who can provide it, will have a meaningful advantage. Not because they will adopt AI faster, but because they will adopt it in a way that compounds rather than fragments.
So, now what?
This series has covered architecture, interaction, governance, human capability, and organizational orientation. It has not covered everything. There are threads I have been exploring that are not yet ready for publication, including questions about whether the analytical dimensions we use to slice data are as fixed as our systems assume them to be, and what it means when the intelligence layer can shift between dimensional frames fluidly in ways that pre-built reports never could.
Those ideas need more development before they are ready to share responsibly. But they point in a direction that I believe will matter: the structures we built to organize data were shaped by the limitations of the tools that consumed it. As those tools give way to intelligence that can navigate more freely, the structures themselves may need to become more fluid.
For now, the practical takeaway is this: the shift my colleague described is real, it is structural, and one that can be navigated. The organizations that treat it as a technology upgrade will be disappointed. The organizations that treat it as a reorientation, one that requires new governance, new skills, and a new relationship between people and data, will find that the 50% difference is an understatement.
The conversation is not over. It is just getting to the interesting part.
This is the final post in the “Talking to Data” series exploring how AI and conversational interfaces are reshaping data architecture and business intelligence. The conversation continues at insightsindata.com.
© 2026 Paul Nevill / Insights in Data
