A board asks for “an AI strategy.” An engineering team hears “build a model.” A procurement lead hears “buy a platform.” Each is solving a different problem, and the gap between them is where most AI initiatives quietly stall. The phrase AI in business is doing a lot of work — and most of the time it is hiding the one decision that actually matters: which kind of AI, applied to which decision, changes which number. The useful reframe is this. “AI” is not a single capability you adopt; it is a family of distinct techniques, each suited to a different shape of problem. Treating it as one thing is how organizations end up with a generative-text pilot when what the business needed was a forecasting model, or a recommendation engine when the real bottleneck was a manual classification step buried in an operations team. What Type of AI Is Used in Business? There is no single answer, and the honest version of the question is “which technique fits the decision I am trying to improve?” In practice, business deployments cluster into a handful of recognizable families. Naming them precisely is the first act of strategy, because the technique you pick determines the data you need, the failure modes you inherit, and the team you have to build. AI technique Shape of problem it fits Typical business decision it serves Predictive / regression models Estimate a continuous number from history Demand forecasting, pricing, churn risk Classification models Sort inputs into known categories Fraud flags, defect detection, lead scoring Computer vision Extract meaning from images or video Quality inspection, inventory counts, safety monitoring Recommendation systems Rank items for a specific context or user Cross-sell, content surfacing, next-best-action Generative models (LLMs, diffusion) Produce new text, code, or images Drafting, summarization, support deflection Optimization / planning Choose the best option under constraints Scheduling, routing, resource allocation The mistake we see most often is technique-by-fashion: a team adopts whatever was in last quarter’s headlines rather than whatever fits the decision. Generative models, for instance, are extraordinary at producing plausible text and weak at producing correct numbers — so anchoring a forecasting decision to a large language model inverts the tool’s strengths. A predictive model trained on your own transaction history will almost always beat a general-purpose generative system at a numeric prediction task, because that is the problem it was built to solve. Two named techniques worth separating cleanly: a classification model and a generative model can look similar in a demo and diverge sharply in production. Classification gives you a bounded set of outputs you can audit; generative output is open-ended and harder to validate. The first is the right home for a defect-detection workflow built on something like a fine-tuned vision model in PyTorch or an ONNX-exported classifier; the second is the right home for drafting and summarization, where a human reviews before the output matters. Confusing the two is one of the most common — and most expensive — early errors in adoption, in our experience across early-stage AI engagements. What Are the 7 Elements of Strategy? When people ask for “the 7 elements of strategy,” they are usually reaching for a checklist that turns a vague mandate into something a team can act on. There is no single canonical list, but the elements that consistently matter for an AI initiative are these: Objective — the specific business outcome, stated as a number that can move (a cost, a conversion rate, a cycle time), not “become AI-driven.” Scope — which decision, which process, which part of the org. Narrow scope is a feature, not a limitation. Differentiation — what you can do that a generic vendor tool cannot. Usually this lives in your proprietary data, not the model. Resources — data availability, engineering skill, compute budget, and the time horizon before the number must move. Constraints — regulatory limits, latency requirements, accuracy thresholds, and the cost ceiling per decision. Sequencing — what you build first, what depends on it, and where the early proof point lives. Measurement — how you will know it worked, defined before you start, against a baseline you have actually recorded. Strategy, in this framing, is mostly about constraints and measurement — the unglamorous elements. The technique you choose is downstream of them. An objective stated as a movable number is what lets you choose between a classifier and a forecaster; a measurement plan defined against a real baseline is what stops a pilot from becoming a permanent science project. A strong objective and a missing baseline is the single most common reason a technically successful model never gets credited with business value. Where Most AI Strategies Quietly Fail The failure is rarely the model. It is the mismatch between the technique chosen and the decision it was meant to improve — and the absence of a baseline that would have revealed the mismatch early. A team ships an accurate model that answers a question nobody was asking, or improves a metric that does not connect to a P&L line anyone owns. A simple diagnostic, before any engineering budget is committed: Can you name the single decision this AI will improve? If the answer is a category (“customer experience”), it is not yet a strategy. Do you know the current baseline for that decision? Without it, you cannot prove improvement, only assert it. Does the technique match the decision’s shape? A numeric prediction needs a predictive model, not a chatbot. Who owns the metric this is supposed to move? If no one does, the project has no destination. What is the cost per decision at scale? A model that is cheap in a pilot can be uneconomic at production volume. If a project cannot pass the first three, more compute will not save it. This is where the strategy work pays for itself: the cheapest model to build is the one you correctly decided not to build. For organizations that want the technique selection done in service of a defined outcome rather than a technology mandate, our view on custom AI development scoped to business growth starts from the decision, not the model — and the same discipline applies whether the build is AI-specific or sits inside a broader custom software development effort tied to a growth objective. FAQ What type of AI is used in business? There is no single type — business deployments use a family of distinct techniques, each suited to a different shape of problem. Predictive and classification models handle forecasting and categorization; computer vision handles images and video; recommendation systems rank options; generative models draft text and code; optimization handles planning under constraints. The strategic act is matching the technique to the specific decision you are trying to improve, rather than adopting whatever technique is currently in the headlines. What are the 7 elements of strategy? There is no single canonical list, but for an AI initiative the elements that consistently matter are objective, scope, differentiation, resources, constraints, sequencing, and measurement. The most decisive of these are usually constraints and measurement: an objective stated as a movable number lets you choose the right technique, and a measurement plan defined against a real baseline is what lets you prove the initiative worked rather than merely assert it. The harder question is not “should we use AI” but “which decision, measured how, would actually change if we did.” Get that one right and the technique selection follows almost mechanically. Get it wrong and even a flawless model lands in the same place every other unmoored pilot does — technically complete, strategically orphaned.
