A group of professionals collaborate around a laptop in a bright modern office, representing how strong data foundations connect human insight, governed collaboration, and machine intelligence — the essence of enterprise AI readiness.

The Data Layer Is the Strategy: A Conversation on Enterprise AI Readiness

As AI moves from pilot projects into core business infrastructure, firms face a more consequential set of questions than most anticipated. And while the tools are evolving quickly, the underlying data foundations aren’t keeping pace. In this Q&A, Introhive’s VP of Product James Spere and Lead Machine Learning Engineer Marcus Smith share what firms should consider before they scale, what the adoption of agentic AI means for data governance, and why the decisions firms make about their data layer today will determine how far their AI investments go.

Q: AI is introducing new expectations around data accessibility, interoperability, and context. As organizations evaluate whether to build internally or adopt external platforms, what are the biggest risks they tend to underestimate?

James: The first step is understanding what problem you’re actually trying to solve. AI is an extremely noisy space right now, and if you follow the news, it feels like everything is “set it and let AI do it for you.” That’s not the reality. If you’re using AI to polish documents or find information from the internet, the technical requirements are low. But if you’re looking at AI to access your most intimate records, you need to ask harder questions around how you work, how you think, and how you operate. Where does the data go to be actioned on? How do you get access within your own infrastructure? How do you ensure you’re not exposing information you’re not permitted to expose, whether by your own internal standards or by industry, country, or regional requirements? How do you maintain that complexity as your data evolves?

In essence, buy versus build in AI is no different from any other technology decision. It comes down to speed and what you want to take responsibility for. Partnering with an organization like Introhive, one that has solved data governance, data protection, and data residency requirements over the last 15 years, means those obligations transfer. The question every firm should be asking is: what am I the expert in, and what are the other players the expert in? When the underlying data is this critical to your business, the question isn’t whether to partner. It’s who you trust to get it right.

Marcus: I’d add that AI is really a communication layer on top of the underlying business knowledge a company holds. It’s accelerating time to value and changing how people interact with systems, but the business context itself, the underlying data, is what determines the quality of everything the AI surfaces. ChatGPT or Claude can tell you what happened in World War II for example, but what they can’t do is reason on your specific business context without it being provided. That’s the part many firms underestimate. 

Q: Many firms are layering AI onto data foundations that still rely on fragmented systems or manual processes. As those AI workflows become more embedded in day-to-day operations, where do you see the biggest risks?

James: The biggest risk is data exposure, and that’s a broad statement. It covers who can see the data, how you maintain your permissions model, and how that scales as AI shifts from answering questions to executing actions. Early AI was largely chatbot-style: you ask a question, you get an answer, and you needed to know how to ask the right question with the right context. As AI evolves toward agentic outputs, meaning outcome-driven, automatic alerts, automatic execution, the stakes around data access become significantly higher. Who is allowed to see what’s being exposed? Who will be impacted by that execution? For firms just getting into this, that’s a complex and consequential problem to solve.

The second risk is data staleness and data relevancy. Where’s your data coming from? How fresh is it? How trustworthy is it? AI won’t fix bad data, it’ll act on it. Data exposure and data quality are two things that come up in nearly every customer conversation we have. Freshness, quality, and access control are things Introhive has built over 15 years. That’s why we’re increasingly either part of a customer’s AI solution, or the entire foundation of it.

Marcus: On the quality and freshness side, AI is grounded by the context it’s given. If you want to know what happened last quarter in a client engagement, the AI will interpret that in many different ways depending on what it has access to. There’s also a rising challenge around governing not just what your users can access, but what your AI agents can access. For example, a marketing agent building a contact list should have very different permissions than a RevOps agent analyzing your forecast. That’s a new kind of access layer that needs to be both auditable and isolated, giving each agent a clear and governed boundary around what it can see and act on.

Q: Most firms are still connecting systems through APIs and custom integrations. Is that approach sufficient for an agent-driven future, or does it create new risks?

James: APIs, MCPs, and static data extracts all have value. The approach a firm takes really depends on what your data strategy is trying to accomplish. If you’re building a static data snapshot or a data lake, extracts are probably the right tool because you’re building up a holistic, more stable view. If you’re looking for real-time, unified context exposure in the flow of work, MCPs are the right answer. APIs fall somewhere in the middle.

What we’re finding with our customer base is that MCP announcements are what trigger the conversations, but in reality, most firms are still working out what their data strategy should be. MCPs solve part of it, APIs address part of it, and extracts still have a role. That’s where partnership with Introhive carries real value, because we’re seeing this at scale across our entire customer base. We’re gaining the experience many of our customers are still building.

I would say that the most important step in any AI strategy is problem definition, which is especially true when you think about agents. Agents don’t come off the shelf ready to run. In reality, you build them, train them, navigate them, and deploy them and they won’t be able to solve a problem they don’t understand.

Marcus: The shift that MCP enables is significant. A traditional API exposes data. It gives the AI raw JSON or raw responses. What MCP does differently is provide the AI with business context alongside the data: what this data represents, why it matters, and how it should be interpreted. That’s a meaningful difference. What we’re moving toward is a world where context is inseparable from the data. So whether a customer connects via extract, API, or MCP, the interpretation stays the same, because it’s established alongside the data before the AI ever sees it.

Q: AI systems can only operate on what they can see. As firms connect more enterprise systems to AI, what risks emerge when those systems expose incomplete or inconsistent context?

James: A useful way to think about it is this: if a human given unlimited time couldn’t piece together the data, your AI platform won’t either. AI won’t question missing context and, unfortunately, it’s exceptionally good at filling in voids, whether the filler is accurate or not. That’s the risk.

Consider what happens when you give an AI access to your CRM without visibility into meetings, calendars, and relationship history. You’ve given it half a picture. It won’t flag what’s missing. It will work with what it has. The connective tissue between your data sources matters enormously here because AI can’t figure out on its own that Jane Smith and ID 105 are the same person unless something connects them. The reconciliation has to happen before the data reaches the AI because it can’t do that work for you.

At Introhive, that connective tissue is central to what we do. We bring relationship information into a shared context that can blend with other data sources we’ve indexed against. And this has to extend to governance and permissions. The scenarios we increasingly hear about, and that firms need to plan for, involve AI surfacing information to people who were never meant to see it, because the permissions were never properly defined. A junior administrator gaining access to executive compensation data because an internal AI chatbot wasn’t properly permissioned is not a hypothetical. It is a real risk, and it is an expensive one to remediate.

Marcus: The other piece worth naming is consistency. You could give AI all of your emails and meetings and have it define relationship signals or health scores, but a purpose-built algorithm abstracting that context is what gives you something reliable to reason on. 

For example, here are my important relationships and here are the contacts that matter. Consolidating that context is what produces consistent, trustworthy outputs. It’s a misconception to expect that if you give AI everything, it will surface the right answers. What we’re seeing instead is that the answer may come back differently each time it’s calculated, and when that happens, people lose trust in the outputs entirely.

Q: What do you think firms are underestimating most about what it will take to support AI at scale over the next three to five years? And what capabilities will they need from their underlying systems and architecture to support that future effectively?

James: A few things come to mind. The first is vendor lock, or what some are now calling AI platform lock. The models are improving every single day, and a principle worth keeping front of mind: today is the worst day these models will ever have, because they only get better from here. That means the vendor landscape will keep shifting. 

Picking one model and building everything around it is a trap. We have a preferred stack right now, but six months from now that may look completely different. The firms that build flexibility into their architecture today, the ones that can swap models without rebuilding from scratch, are the ones that can keep pace with a landscape that won’t sit still.

The second consideration is around token cost and scaling economics. We hear no end of stories about someone who built a great internal AI solution over a weekend, and it works beautifully for ten people. Then the question becomes: how does this scale when you add a hundred people? How does it scale through a merger? Those scaling factors aren’t obvious unless you’ve done this before.

The third, and I feel strongly about this, is human in the loop. I believe there will always be a human in the loop and that firms treating junior talent as a cost to be offset by AI tools will feel that tradeoff in three, four, five years. Judgment is developed through experience. Through decisions made, mistakes absorbed, and instincts built over time. AI can support that process, but it cannot replicate it. When junior talent stops doing the thinking, they stop developing the capability that senior decisions eventually depend on. AI produces confident outputs regardless of whether those outputs are correct. Catching that requires experienced people who have developed the judgment to know the difference.

The fourth is your data architecture. Our own strategy is what we call headless, meaning we focus on how our relationship intelligence flows into any ecosystem: MCPs, APIs, extracts. But six months from now there could be another protocol we haven’t named yet, and we have to be ready to meet it. We’re a data and insight provider, but more importantly, we’re an outcomes provider. We help teams identify things they didn’t even know they should be asking. That means continuously exposing intelligence into the flow of work, in whatever form that takes. Our internal mantra is to meet you in the flow of work because you shouldn’t have to redesign how your professionals work.

On the headed side, our UX runs on the same endpoints we expose to customers. We hold ourselves to the same standard we ask customers to meet. That gives us genuine expertise in the integration challenges they face, because we face them too and I think it’s a reasonable expectation to have of any potential partner.

Marcus: When I reflect on the last two years, the clearest lesson has come from watching our own product evolve. Through every iteration of Ask Introhive, what’s stayed constant is the tooling and the data layer. The models have changed. The interfaces have changed. The harness has changed. But the business context, the underlying relationship data, is the one thing the models never had and can never generate on their own. They can’t be trained on it, nor can they reason on it unless you bring it to them. That’s been the common denominator every evolution we’ve been through.

The same principle applies across the firms we work with. What we’re seeing is that firms making this investment now are the ones that won’t have to redo it later. You can keep updating the framework around your AI, but the data layer, how you govern it, how you enrich it, how you expose it, is the thing that doesn’t change. Build that foundation now, build it correctly, and you retain the ability to iterate quickly as the technology evolves. Wait, and you’re backed into expensive remediation while your competitors are already operating at the next level.

Introhive’s MCP Server connects your AI assistant directly to your firm’s relationship intelligence in real time, giving it the context it needs to turn conversations into client opportunities. To learn more, book a demo with our team.

James Spere is an innovative technology leader and executive specializing in software engineering, product strategy, and data systems. With extensive experience steering technical organizations through rapid growth and digital evolution, he is dedicated to empowering engineering teams, optimizing product delivery, and architecting sustainable, high-impact software solutions.

James Spere

VP of Product, Introhive

James Spere, VP of Product, Introhive

Marcus Smith is a machine learning engineer at Introhive, where he leads the team building the production platform behind the company’s AI products. He specializes in moving AI from working prototype to production system: the evaluation and reliability work that turns a promising demo into something a business can depend on. He previously ran Introhive’s data engineering, building the foundations the AI now runs on.

Marcus Smith

Lead Machine Learning Engineer, Introhive

Introhive | Marcus Smith | The Data Layer Is the Strategy: A Conversation on Enterprise AI Readiness

Share

Slide 3 Heading
Lorem ipsum dolor sit amet consectetur adipiscing elit dolor
Click Here
Slide Heading
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.
Click Here
Introhive computer

Sign up for our newsletter today for the best
client intelligence insights.