The conversation about AI readiness in B2B commerce circles around a few common concerns. Cleaning up product data is the most discussed: accurate catalogs, structured attributes, consistent taxonomy, no duplicate records, no orphaned SKUs. And to be fair, AI can genuinely help with that work too, surfacing inconsistencies, suggesting enrichments, and accelerating what would otherwise take teams months.
A close second is the organizational side: whether teams have the willingness and capacity to adapt, adopt new ways of working, and absorb the structural changes that come with it.
Both concerns are legitimate, and the effort to address them is worth doing. But the conversation is still incomplete. There is a third kind of AI readiness that almost nobody in our industry is talking about. And I think it may be the most consequential of the three.
Key Takeaways
- There are two kinds of data AI depends on: product data (catalogs, attributes) and operational data (the real-time state of execution).
- Most organizations focus exclusively on product data readiness and have never built a system to capture clean operational data.
- AI does not create clarity, it amplifies whatever exists. In an unclear execution system it produces faster noise, not better decisions.
- The real AI readiness gap is in the execution system, not just the data infrastructure, few organizations measure it.
- Building an execution system that captures intent and reconciles it against outcomes puts an organization in a fundamentally stronger position to leverage AI.
Two kinds of data AI depends on
AI in B2B commerce depends on two kinds of data: product data (catalogs, attributes, pricing, inventory) that most organizations are already racing to clean up, and operational data, the real-time state of execution, which almost nobody is building a system to capture. Both are necessary; only one is getting attention.
When most organizations think about AI and commerce, they think about the data that flows into their commerce systems as inputs: product information, customer records, order history, inventory, pricing. That is the data everyone is racing to clean up. But there is a second kind of data that AI depends on, and it lives in a completely different place.
I call it operational data. The real-time state of execution. What is actually being built right now. What it is actually costing. What the genuine risks are. Who owns what decision. What has been decided and why. What was tried before and how it turned out. What is on track and what is quietly slipping. This is the data that determines whether execution is predictable or chaotic. It is the data that makes leadership possible rather than reactive. And it is the data that AI needs to accelerate execution rather than accelerate confusion.
There are two kinds of data AI depends on. Everyone is focused on the first kind. Almost nobody is focused on the second.
Why most organizations do not have clean operational data
Most organizations lack clean operational data not because they have not tried, but because their tracking is structural rather than intentional: status reports summarize after the fact, budgets get reconciled at the end of a phase, and risks get escalated only once they become crises, so none of it reflects real-time reality.
It is not because they have not tried. Most organizations running complex commerce environments have some version of project tracking. Status reports sent weekly. Budget spreadsheets updated at key milestones. Risk logs reviewed in steering committee meetings. The problem is structural, not intentional.
Status reports get written after the fact, by someone summarizing what they believe is true, for an audience they are trying to keep comfortable. They reflect a version of reality, not reality itself. Budget numbers get reconciled at the end of a phase, not tracked in real time as decisions are made. By the time the budget report says you are over, you have been over for weeks. Risks get escalated when they become crises, not tracked systematically from the moment they appear. Decisions live in someone's memory, or buried in an email thread that no longer surfaces in anyone's inbox, or in a meeting note that nobody goes back to read.
The result is that the operational data of the organization exists, but it is fragmented, delayed, and filtered through so many interpretive layers that it no longer reflects the actual state of things. And when AI enters that environment, it does not fix the problem. It amplifies it.
What AI does in each environment
When execution is unclear
- AI produces faster status reports that still do not reflect reality, because the inputs they are generated from were never accurate.
- It generates budget forecasts from data that was already out of date when it was entered, compounding the inaccuracy with the appearance of precision.
- It surfaces risks that were already visible in meeting notes two weeks ago, because that is where the risk data lives.
- It makes recommendations based on patterns from previous projects, but cannot tell you which patterns apply to this specific situation because the decision history does not exist in a form it can read.
The result is faster noise. The same underlying confusion, produced more efficiently.
When execution is designed for clarity
- AI can predict when a project is likely to go over budget before it happens, because scope, progress, and cost are tracked in real time against a model that is updated as work occurs.
- It can surface risks before they become blockers, because risks are tracked systematically from the moment they appear, not escalated when they become crises.
- It can recommend decisions based on what was decided in similar situations before and what the outcomes were, because decision history is captured in a consistent, structured form.
- It can give leadership a genuine, unfiltered view of the state of execution at any moment, because that view is built from live data, not from someone's interpretation of it.
The result is better execution, moving faster, with less cognitive overhead.
AI does not create clarity. It depends on it. If execution lacks clarity, AI accelerates confusion. If execution is clear, AI accelerates everything above it.
The AI readiness gap nobody is measuring
If you asked most B2B commerce organizations today whether they are AI ready, many would answer in terms of their data infrastructure: PIM completeness, ERP data quality, CRM integration, platform API coverage.
Very few would answer in terms of their execution system. How visible is the real state of execution to leadership right now? How quickly do risks surface? How consistently are decisions captured? How accurately does the budget picture reflect what is actually happening?
Those questions are harder to answer. Not because the information does not exist, but because most organizations have never built a system designed to make it visible. The organizations that build that system now are not just improving their execution today. They are building the foundation that AI needs to genuinely accelerate execution over the next several years. The organizations that do not, will spend the AI era producing cleaner status reports that still do not reflect reality.
What an execution system designed for this actually looks like
An execution system designed for AI readiness captures scope, progress, budget, risks, and decisions as work happens rather than in after-the-fact summaries, and it records why each decision was made so the connection between effort and outcome stays visible by default. This is the kind of architecture-first, governed system we build for clients.
But the deeper requirement is harder. The system has to capture not just what is being done, but why. What outcome each decision was meant to produce. Whether the result matched the intent. The connection between effort and outcome has to be visible by default, not reconstructed in retrospect.
This is what separates an execution system from a project tracker. A project tracker captures activity. An execution system captures intent and reconciles it against reality.
A system like this also accumulates institutional knowledge across engagements, so that when a new project starts it benefits from every similar project that came before it: the decisions that were made and why, the risks that emerged in comparable situations, the patterns that predicted success or failure. Over time, the system becomes the place where the organization's collective experience lives.
Building this kind of system is not easy, and few organizations have. But the ones that do are in a fundamentally better position to leverage AI than the ones that focus exclusively on product data quality. Because when AI enters an environment where intent, decisions, and outcomes are already connected, it has something real to learn from. When it enters an environment where they are not, it has nothing to work with except activity logs and assumptions.
What to actually focus on
Focus on both kinds of data readiness at once: clean your product data through structured product data and PIM work, and in parallel, build the operational visibility that makes your execution trustworthy enough for AI to learn from.
Clean your product data. That work is worth doing on its own merits, and the engineering effort it requires is real.
But also ask a different question. Is the real state of your commerce execution visible right now, without asking anyone to prepare a report? Do the risks that exist today surface as they appear, or do they emerge in meetings two weeks after they became relevant? When a decision is made, is its rationale captured in a way that future decisions can learn from it? Can you tell, looking back, whether the work you invested in actually produced the outcomes it was meant to?
If the answer to those questions is no, the product data work alone will not get you what you are hoping AI will deliver. Both kinds of data matter. The product data is what AI uses to reason about your customers and your catalog. The operational data is what AI uses to reason about your execution. Most organizations are working hard on the first and have not started on the second.
Build both. The product data work and the operational data work are different problems, and they both compound when done together.
Radu Munteanu
Founder & CEO, Luminos Labs