What 'AI-Powered' on Slide Three Actually Means for a GM

Vendor decks move fast. By slide three the room is usually nodding, the logo wall has done its work, and the phrase 'AI-powered' lands without friction. That frictionlessness is the problem. General managers carry budget authority and operational accountability, but most vendor presentations are built for a buyer who will not have to live with the implementation. This post is a field guide for the GM who will.

What are the four things 'AI-powered' actually describes?

Break the phrase down and you find a short list of what vendors genuinely mean. Understanding the list does not require a data science background.

Type 1: A rules engine with a new label. Conditional logic, decision trees, and threshold-based alerts have existed for decades. Vendors increasingly describe them as AI because the outputs can look intelligent even when the underlying mechanism is a series of if-then statements written by a developer. These systems are not inherently bad. They are often reliable and auditable. The problem is misrepresentation: a rules engine cannot learn from new data, cannot generalize to edge cases, and will not improve without manual reconfiguration.

Type 2: A licensed third-party model. Many vendors wrap OpenAI, Anthropic, Google, or open-source models and present the wrapper as their own AI. The model is doing the work; the vendor is managing the API call and, ideally, the prompt engineering around it. This arrangement can deliver real value, but the GM should understand that the vendor's competitive moat is thin. If the underlying model changes its pricing or terms, the product changes with it. Ask: 'Is the model you are using proprietary to you, or is it a licensed API?'

Type 3: A genuine ML layer trained on proprietary data. This is the rarest and most defensible form. The vendor has accumulated domain-specific data, trained or fine-tuned a model on it, and the system improves as it processes more of your operational data. This type of AI is worth paying a premium for, but only if the vendor can explain what data the model was trained on, what the model is actually predicting, and how accuracy is measured over time.

Type 4: A roadmap item presented in present tense. This happens more than most buyers realize. The AI feature exists in a prototype or internal test environment and will ship 'in the next two quarters.' The slide does not say that. Discovery questions surface it.

Why does the distinction matter operationally for a GM?

Because the failure modes are different and the recovery costs are real. A rules engine that mislabels an edge case creates a support ticket. A licensed LLM that hallucinates a customer communication creates a liability event. A roadmap feature that ships six months late creates a gap in the workflow you restructured to accommodate it.

The GM is not just buying software. The GM is reorganizing how work gets done around an assumption about what the software will do. That assumption needs to be stress-tested before the contract closes, not after the go-live.

For a practical orientation to how these questions fit into a broader evaluation process, the AI reality check framework provides a structured starting point before you engage a vendor's sales cycle at all.

What questions should a GM ask in the room?

The goal is not to embarrass the sales team. The goal is to get a clear answer on record before budget is committed. These questions are calibrated to produce useful information without requiring technical expertise from the GM asking them.

• 'Walk me through what happens when a new input arrives. What does the AI component do with it, step by step?'
• 'Is the model trained on data from customers in my industry or my operational context?'
• 'What does the system do when it encounters something it has not seen before?'
• 'Who maintains the model after implementation, and what does that cost?'
• 'Can you connect me with a customer who has been live for at least twelve months?'
• 'What is on your AI roadmap that is not yet in production?'

A vendor with a real product answers these questions directly. A vendor with a rules engine or a roadmap item will deflect, generalize, or pivot to a demo feature. The quality of the answer is data.

How do legitimate AI capabilities actually show up in operations?

When AI is real and well-implemented, the operational signature is specific. Forecasting models reduce manual re-entry of demand assumptions. Classification models route customer issues without a human reading every ticket. Anomaly detection flags variance before it becomes a reportable problem. The common thread is that the system is doing a cognitive task that was previously done by a person, and doing it faster and at higher volume.

The research literature on ML in operations is extensive. MIT Sloan Management Review has published practical analyses of where machine learning creates durable operational advantage versus where it creates complexity without return. The McKinsey Global Institute has similarly documented that AI value in enterprise settings tends to concentrate in a small number of high-frequency, high-data-volume workflows rather than spreading evenly across a business.

If a vendor's AI is not attached to a high-frequency, high-data-volume workflow in your operation, the ROI case deserves scrutiny. That is not a reason to reject the product. It is a reason to size the investment correctly.

For operators who want to apply this thinking to their own lead and customer data specifically, the lead intelligence diagnostic outlines where AI classification tends to add signal versus where it adds noise in a typical commercial operation.

What does a reasonable vendor disclosure look like?

A vendor who is confident in their AI capability will give you a one-page technical summary without being asked. It will name the model type, describe the training data source, state the performance metric and its current value, and describe how model drift is monitored. You do not need to evaluate that document yourself. You need to confirm it exists and can be reviewed by someone with the appropriate background before the contract is finalized.

If the vendor does not have this document, that is diagnostic information. It does not automatically mean the product is bad. It does mean the AI claim is not yet mature enough to carry the weight being placed on it in the sales process.

For GMs who want a structured walkthrough of these questions applied to a specific vendor they are evaluating, the diagnostic call process is designed for exactly that use case.