NEW Study: 84% of Companies Have Data Stacks That Won't Work With AI

AI News & Strategy Daily | Nate B Jones
9.6K views • November 09, 2025

My site: https://natebjones.com
Full Story: https://natesnewsletter.substack.com/p/executive-briefing-why-84-of-companies?r=1z4sm5&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true
My substack: https://natesnewsletter.substack.com/
_______________________
What’s really happening inside enterprise AI data architectures?
The common story is that companies are already “data-driven” — but the reality is that most aren’t ready for AI at all.

In this video, I share the inside scoop on building an AI-ready data foundation:
• Why most AI initiatives fail before they start
• How to diagnose weak data systems before deploying agents
• What zero-copy architecture really means for real-time AI
• Where executives and engineers must align to close the perception gap

The winners of the AI era will be the ones who do the boring data work early — before models and agents can do anything smart.

Subscribe for daily AI strategy and news.
For deeper playbooks and analysis: https://natesnewsletter.substack.com/

0:00 This week's executive briefing is all
0:02 about the glamorous subject of AI ready
0:05 data architectures. Why? You might be
0:07 thinking, are we going to do that? The
0:08 reason is simple. Salesforce published
0:10 data this week from 6,000 plus
0:13 enterprise data leaders. 84% said their
0:16 data strategies needed a complete
0:18 overhaul before AI works. And at the
0:20 same time, 63% of executives in the
0:22 survey believe their companies are
0:24 already data driven. In other words, the
0:26 perception gap is why most AI
0:28 initiatives are failing. Leaders walk in
0:31 to these AI conversations assuming they
0:34 are datadriven. And what they find in
0:36 reality is that they're not. Is that the
0:38 data is not ready for the demands of AI.
0:40 And so I ask myself, why is that? I look
0:41 at my own projects I've worked on,
0:43 projects I've worked on with clients,
0:44 and I ask, "What can we learn here that
0:47 will help leaders get over the
0:50 perception gap and be more likely to
0:53 establish a successful AI ready data
0:56 architecture?" So, we're going to go
0:57 through seven principles that separate
0:59 the call it 16% who are successfully
1:02 scaling AI over everybody else. Number
1:05 one, diagnose before you deploy. So
1:09 before you run your AI initiatives, you
1:11 need to be running tests. And there's
1:13 two big ones that come to mind. Number
1:15 one, make sure that your system can
1:19 answer factual questions about your data
1:22 in less than 5 seconds without human
1:26 intervention. Am I making it up as like
1:28 it has to be 5 seconds? Kind of. Yeah.
1:31 But it's a reasonable proxy.
1:32 Essentially, if you cannot put in place
1:35 a system that is able to get a
1:37 performant query that is very simple
1:39 through the system in less than 5
1:41 seconds, you're probably not ready for
1:43 anything more sophisticated. And I'm
1:45 talking really simple like what's our
1:47 inventory for product X in our warehouse
1:50 houses right now. Something at that
1:52 scale. Second, the second test is can
1:54 you assemble a complete customer view
1:58 across sales, support, billing, and
2:00 shipping with no missing data in a
2:02 similar time envelope. And so, you
2:04 notice how I'm asking you about
2:06 performance at the beginning. There's a
2:08 reason for that. If the tests fail, what
2:11 you're finding is that you need
2:13 infrastructure work because your data
2:16 sets are not designed to be performant
2:20 in the era of AI. They're designed for
2:22 slow retrieval, retrieval that might
2:25 take 30 minutes and be one row in a
2:27 large report your data analyst prepares,
2:30 not agentic retrieval that happens on
2:32 the fly very quickly. And so the
2:34 challenge for you is to figure out how
2:36 do you start to change your data
2:38 architecture so that you can actually
2:40 deploy AI agents reliably. So the first
2:44 step just be honest with yourself.
2:46 Diagnose before you deploy. Principle
2:48 number two, zero copy architecture is a
2:52 philosophy. It's not tooling. I'll get
2:55 into what that means. So, traditional
2:57 data warehouses copy data to central
2:59 locations. They clean it up overnight.
3:02 Then they make it available for
3:03 reporting. But depending on your needs,
3:06 Agentic AI cannot wait for overnight
3:09 batch jobs. If you want real time data
3:12 today, that won't work. So agents need
3:16 real time data access to authoritative
3:18 source systems if you want real-time
3:20 conversations with your data. Now if you
3:23 are okay with having day delayed or
3:25 longer data and you just you're fine
3:27 with that and most of your use cases are
3:29 with last week's data or last month's
3:31 data, this gets easier. But even in that
3:34 situation, you still have a lot of work
3:37 to do to make sure that the data sets
3:39 that you prepare of your historical data
3:42 are performant in keeping with principle
3:44 one. The key shift to think about is
3:47 that the behavior of the business user
3:51 is also evolving. So part of why in the
3:54 Salesforce survey, companies were 34%
3:57 likely more likely to succeed if they
4:01 used a zero copy approach, which is
4:02 where you don't copy it to a central
4:04 location. You just tell the AI to query
4:06 the data where it lives in all of your
4:08 different systems. Part of why they were
4:09 more successful is because
4:12 they were able to architect the entire
4:15 system exactly the way they wanted
4:17 without trying to buy from different
4:19 vendors and cobble a system together.
4:21 And so this is in line with other
4:23 surveys we've seen of executive
4:25 leadership that have emphasized that it
4:27 is really important for executives to
4:31 invest in internal capacity for
4:34 architecting systems if you want the
4:36 ability to build and sustain AI long
4:38 term. And so as much as principle number
4:40 two is about, hey, we're not going to
4:42 have copies of our data. We're going to
4:44 be able to query real time and that's
4:45 going to make us more likely to be
4:47 successful because business user
4:49 behaviors are shifting toward real-time
4:50 querying. All of that makes sense. But
4:52 the underlying story that I think that
4:54 is interesting is that that only works
4:56 if you are investing in your ability to
4:59 build those systems internally because
5:02 your own fingerprint configuration of
5:04 data is going to be somewhat unique and
5:06 will require that internal capacity.
5:09 Principle number three, context matters
5:11 more than volume. So 49%
5:15 of organizations draw incorrect
5:17 conclusions because their data lacks
5:18 business context. again drawing from
5:20 this Salesforce survey. So as an
5:23 example, let's say that the data says
5:24 revenue is $2 million and the customer
5:27 is Acme Corp and it's the third quarter
5:30 revenue number, but maybe that
5:31 particular database row or that
5:33 particular fragment retrieved by the AI
5:35 does not specify that the $2 million was
5:38 a one-time contract, not recurring
5:40 revenue, and your agents are now
5:41 inappropriately adding $2 million in ARR
5:44 to your reporting. What I'm saying is
5:46 that is not uncommon and that is a great
5:49 illustration of how the context really
5:51 matters when you are trying to construct
5:54 efficient agentic systems. You have to
5:56 get context that works. So you need
6:00 semantic layers that encode business
6:02 definitions, relationships and logic.
6:05 Asians should be able to understand the
6:07 difference between booking and revenue,
6:10 between gross and net active churn
6:12 customers from universal single source
6:14 definition sources of truth. And if you
6:17 don't have that, if you don't have a
6:19 semantic layer that defines the meaning
6:21 across the top of your data at a high
6:22 level, then the more data you add
6:24 without context just means more
6:26 confidently wrong answers. If you're
6:28 wondering, can you give me an example of
6:30 a semantic layer? I would actually say
6:31 there's vendors that do this and this
6:34 might be a case if you don't have the
6:35 capacity internally where a vendor makes
6:38 sense because in this sense you're not
6:41 asking the vendor to patchwork across
6:42 all of your data. You're just trying to
6:45 put a single lens across the data set
6:48 and interact with it cleanly. And so up
6:51 to you cube is a vendor out there. There
6:52 are other vendors out there as well. The
6:55 principle is not whether you go with a
6:57 vendor or not here. The principle is
6:58 that you need to think about your data
7:00 queries as needing the context that
7:03 comes from executive insight to
7:05 interpret well. If you ask these kinds
7:07 of sophisticated questions and most of
7:09 the time the data that you have encoded
7:12 does not carry that context internally
7:14 in the rows of the database. You have to
7:16 find a way to add it. So if you want to
7:18 build that yourself and find a way to
7:19 add that in that's great. Or this might
7:21 be a spot because there's only one sort
7:23 of one point in the architecture to
7:25 inject this. Maybe it's not irrational
7:27 to add a vendor here. Principle number
7:29 four, governance enables speed. It does
7:32 not slow you down. And so this is one of
7:34 those things where you need to have
7:36 governance framed as accountability
7:39 rather than process. And so governance
7:42 councils at enterprise scale need to be
7:45 accountable to quality metadata
7:47 policies, remediation approaches. And
7:50 your goal is not to push things through
7:52 human processes, but to actually have
7:54 your governance structure encoded as
7:56 automated quality monitoring so that you
7:59 can route data issues through the exact
8:02 same severity model you would use for
8:04 production software outages. This is not
8:06 bureaucracy. This is what lets you move
8:08 quickly if you automate that process.
8:10 The 16% successfully scaling in the
8:13 Salesforce survey are doing so with
8:16 strong governance practices. And there's
8:18 not really a substitute for it. And I
8:20 and I want to emphasize again, if nobody
8:22 owns data quality, the data will not be
8:25 quality. You need someone to care about
8:27 data quality in order to ensure that you
8:30 can actually make the most of the AI
8:32 investment you're making. But the person
8:34 who owns it needs to have an automation
8:37 mindset because otherwise they're going
8:39 to slow things down. And so that's why
8:41 I'm trying to give you the nuance and
8:42 the tension there. So principle number
8:44 five, the honest timeline is not as fast
8:46 as anybody wants. The plan in most
8:48 enterprises is probably 18 to 36 months
8:52 and you're showing progress in phases.
8:54 And so you might be fixing critical
8:56 pipelines. You might be implementing a
8:58 zerocopy architecture for your top
9:00 domains. You might be piloting agents
9:02 where data is trustworthy in year one.
9:04 Year two, you may be expanding toward
9:06 real-time capabilities. You may be
9:07 automating governance year three. Now
9:09 you're scaling agents. This feels really
9:12 slow when vendors are going to promise
9:14 six-month transformations. But those
9:16 timelines assume your infrastructure is
9:18 already ready, which is exactly what
9:20 Salesforce is calling out here. For most
9:22 organizations, it's not. And so the
9:24 disciplined approach is to be honest
9:26 about your shortcomings and fix
9:28 infrastructure while running AI pilots
9:30 that show proof of concept and then
9:32 scale as you see that the foundations
9:34 are actually solid. Principle number
9:36 six, you want to close the perception
9:38 gap between business and technical
9:40 leaders. The fact that 63% of executives
9:43 think they're data driven underlines
9:45 this business technical gap because at
9:47 this rate, business leaders are making
9:49 purchases for vendors selling AI tooling
9:52 on timelines that are completely
9:54 divorced from the reality of the data
9:56 architectures. Business and technical
9:58 leadership need to get on the same team.
10:01 Otherwise, they're going to end up
10:02 blaming each other, blaming AI, or
10:04 blaming their own teams. Misaligned
10:06 expectations here are a leadership issue
10:09 and it's something where technical
10:11 leaders I am convinced need to take the
10:14 lead. Step up, educate your executives
10:17 on the technical realities that are
10:20 constraining AI development in your
10:23 organization. Be really honest. Make the
10:25 infrastructure work visible, not hidden
10:28 beneath the technical teams. This is not
10:29 a time to hide the dirty details from
10:32 leadership. You actually need that to
10:33 avoid writing checks you're going to
10:35 regret and making promises that you
10:37 can't deliver on. Principle number seven
10:39 is all about strategy. The strategic
10:41 choice that you're facing is time bound.
10:45 I keep emphasizing this and I'm going to
10:47 say it again. Data runs on a clock. If
10:50 you are going to have to spend 18 to 36
10:53 months regardless in the middle of the
10:54 AI revolution fixing infrastructure and
10:57 scaling AI, it is better to start that
10:59 clock sooner than later because you are
11:02 going to fall exponentially farther
11:03 behind the longer you wait. This is a
11:05 point I make often, but it's a point
11:07 that we have trouble as humans
11:09 processing. So I feel the need to repeat
11:10 it. We have trouble with exponentials.
11:13 We are living in an exponential from an
11:15 AI capability perspective. And when we
11:18 are living in that space of a curve
11:20 that's accelerating, we have got to be
11:23 okay with making bets assuming that the
11:27 environment is going to continue to
11:29 accelerate. We need to make bets
11:31 assuming AI models are going to keep
11:33 getting better. That means we need to
11:35 frontwate and really prioritize
11:38 investments that unlock that AI
11:39 capability. And I see that willingness,
11:42 but as we've discussed in this video,
11:45 it's often business leaders who are
11:47 overoptimistic about the boring parts of
11:49 the organization, namely the data stack,
11:52 who are saying, "We want AI. We're ready
11:54 to invest. We're buying vendors." And
11:56 that leads to problems. And so the
11:58 strategic choice is now, but technical
12:01 and business leadership need to get on
12:03 the same page to make sure that the
12:05 willingness to invest is aligned with
12:07 where you actually need to put technical
12:09 leverage to drive AI forward in the
12:11 business. The organizations that
12:13 successfully scale AI aren't smarter
12:16 about prompting. They're not smarter
12:18 about model selection. They fixed their
12:20 data infrastructure. They did the boring
12:22 work first. They ran the diagnostics.
12:24 They accepted an honest timeline. They
12:26 did work. And that's how you close the
12:28 perception gap between we're data driven
12:30 and actually our data can't support AI
12:32 and this vendor implementation is doomed
12:34 from the start. That is an execution
12:36 gap. That is something an organization
12:38 can choose to close if it wants to. And
12:41 if you don't close it, you are going to
12:43 regret it. So there you go. That is how
12:45 I read one of the most interesting
12:47 surveys of the year out of Salesforce.
12:49 Good luck with your data architecture.
12:50 We all need it.