Part 3: In a Crowded AI Market, Three Questions Change the Conversation

Note: This is Part 3 of a planned 3-part blog series on artificial intelligence (AI). 

Parts 1 and 2 of this series made the case for deliberateness, in how you prioritize AI investments and in how clearly you understand the cost of building before you commit. This is the natural conclusion of that argument: once you have decided to buy, how do you evaluate what you are actually buying?

Enterprise AI spend is growing at roughly 75% year over year and it has moved decisively from innovation budgets into core IT and business unit spending. Every vendor leads with AI. The language is largely indistinguishable around intelligent automation, trusted outputs, enterprise-grade, domain-specific. The demos are genuinely impressive. And most of them do not tell you what you most need to know.

Building AI products is hard, and the market is moving fast. But it does mean that the standard evaluation questions around explainability, accuracy benchmarks, and audit trails have become baseline answers that every serious vendor can provide. They are necessary but no longer sufficient.

The questions that lead to a more productive conversation are the ones that go deeper: into the architecture, into the data model, into what the path to value actually looks like for an organization at your stage of readiness. These are not gotcha questions. They are the ones that help both sides figure out whether there is a genuine fit.

Question 1: Does the Solution Have an Opinionated Data Model — or Does It Work With Whatever You Have?

This is worth asking early because the answer shapes everything else. There are two fundamentally different approaches to building AI for complex product environments, and they produce fundamentally different results.

The first approach connects to your existing systems and applies AI on top of the data you already have. This is faster to get started with and easier to demo. It also inherits whatever is fragile, inconsistent, or incomplete about your current data which, as Part 2 of this series described, is often quite a lot. The AI reasons over what is there, confidently, and the quality of the outputs reflects the quality of the foundation underneath.

The second approach starts from an opinionated data model, one that defines what a specification is, how ingredients relate to formulas, how formulas relate to finished goods, how regulatory claims attach to products, how supplier data propagates across a portfolio. That model was not designed generically. It was built in collaboration with domain experts who understand how these workflows actually operate — what the relationships are, what the exceptions look like, and what the system needs to handle reliably over time.

Neither approach is inherently wrong. But they represent very different bets about where the work of getting to reliable AI outputs actually lives. The first puts that work on your organization. The second has already done much of it.

A useful question to explore with any vendor: how does the solution handle a scenario where the same data exists in multiple systems with conflicting values? How does a change to a single ingredient propagate across a large product portfolio? The specificity of the answer will tell you a great deal about how deeply the data model has actually been thought through.

Question 2: Where Is the AI and Where Is the Deterministic Layer?

This is an architectural question, and it is one of the most useful conversations you can have with a vendor about how their solution actually works.

A large language model grounded in structured, connected data with well-engineered context and domain-specific prompting can handle most interactions in a complex product environment reliably. Retrieving relevant specifications, surfacing ingredient relationships, synthesizing regulatory context, recommending options: these are tasks where AI, properly grounded, performs well and gets better over time as the data foundation matures.

But not every output in a regulated environment can be left to probability. Calculations with direct compliance consequences like nutrition labeling math, claims validation against specific regulatory standards, formula compliance checks against jurisdiction-specific thresholds need to have defined correct answers. For this class of problem, a deterministic rules engine is the right tool. It encodes the actual regulatory math, validates the output against the correct standard, and ensures the result is correct before it reaches a user. The AI reasons over the problem. The rules engine certifies the answer.

The distinction matters because it reflects a deliberate architectural decision about which tasks require guaranteed correctness and which do not. A solution that has made that decision thoughtfully  and can articulate clearly where the boundary sits  has been designed by people who understand the domain at a level that goes beyond building a capable interface.

A useful question to explore: for outputs that have direct compliance or regulatory implications, how does your system ensure correctness? What is handled by AI and what is validated by rules? A vendor who can walk you through that architecture specifically has thought through the problem at the right level of depth.

Question 3: What Does the Path to Business Outcomes Actually Look Like From Where We Are Today?

Every vendor will show you what the solution looks like at its best. The more valuable conversation is about what it takes to get there from where your organization actually is,  not from a clean data environment with a motivated pilot team, but from the reality of your current systems, your current data quality, and the organizational change that any new solution requires.

There are two parts to this conversation worth having explicitly.

The first is about outcomes. Not AI activity metrics like queries answered, documents processed, time saved on individual tasks but around focused business outcomes. How much faster can your organization respond to a regulatory change? How does the solution reduce the cycles between identifying a supply chain disruption and understanding its product impact? What decisions can your team make in hours that currently take weeks? Vendors who have been in production at scale in environments like yours can answer these questions specifically. The specificity of the answer is itself informative.

The second is about what it honestly requires from your organization to get there. Data readiness, integration effort, change management, timeline – not the optimistic version but the realistic one. A vendor who is direct about this is not discouraging. They are telling you that they have been through enough real deployments to know where the work actually lives. That is a signal of experience, not a red flag.

This conversation also surfaces something important about fit. Organizations at different stages of data readiness have different starting points and the right solution for an organization with a well-structured data foundation is not necessarily the right solution for one that is still working through that foundation. A vendor who can diagnose where you are and propose a realistic path from there is a different kind of partner than one who proposes the same approach to every prospect.

The Right Conversation Leads to the Right Decision

These three questions are not a scorecard. They are the start of a more substantive conversation than the standard vendor evaluation tends to produce. The answers will not always be clean as good solutions have real constraints, honest vendors have genuine limitations, and the right fit depends on where your organization is as much as what the solution can do.

What these questions surface is depth. Whether the data model reflects genuine domain expertise or generic architecture. Whether the AI has been deployed with appropriate architectural guardrails or left to operate on its own reliability. Whether the vendor understands what value creation actually requires in your specific context.

This series started with the observation that in the AI era, the winners are choosing their battles, being deliberate about where to invest, honest about what building requires, and rigorous about what buying actually delivers. That deliberateness does not end with the purchase decision. It is the standard you hold every AI investment to, from the first conversation with a vendor to the moment your organization is actually using the solution every day.

The AI advantage will not go to the fastest movers. It will go to the organizations that got the fundamentals right — the problem selection, the data foundation, the architecture. Those decisions compound. The shortcuts do not.

In the meantime, download my latest AI Executive Brief to learn more about my perspective on why most AI projects fail or contact our team to learn more about our spec-first approach.