AI use cases come in two basic flavours

Buying AI tools for staff is just one approach

Management consultants love a two-by-two matrix. This one is odder than most, because the part that matters is a diagonal.

• AI tools sit in the top-right corner: assistants for research, writing, coding and analysis, used mainly by individuals and teams doing knowledge work.

• Decision systems are in the bottom-left are: mechanisms that help run processes across a business and shape choices made by senior managers. Both may use similar AI models. Almost everything else about deploying them is different.

Two deployments

An AI tool usually arrives as an addition to work. A company buys licences, checks security and data permissions, selects a group of users and teaches them how to ask better questions. Vendors can do much of the heavy lifting. Their chatbots already sit in email, office suites, or platforms for different functions; their playbooks cover readiness, pilots, champions, training and usage dashboards. Microsoft’s own guidance, for example, reduces the technical rollout to familiar administrative acts such as preparing the tenant, assigning licences and monitoring adoption.

That does not make success automatic. A tool creates value only when people use it often and sensibly. Managers must choose worthwhile tasks, protect confidential information, explain when human judgement should prevail and stop employees from treating plausible prose as settled fact.

Yet the organisational value is modest. Most jobs, reporting lines and decision rights remain intact. The chief problem is adoption: helping people work better without asking them to work in an entirely different system and, of course, shadow AI often means that staff are already ahead and using their own chatbots.

Technology vendor’s incentives are reasonably well aligned with this task. It wants seats activated and users engaged. It can supply training material and technical support at scale. A competent IT team, backed by security, legal and a network of enthusiasts, can therefore spread a general-purpose tool without undue disruption. The exercise resembles the introduction of a better office suite, albeit one with different kinds of risk and learning curves.

A different trade-off

A decision system is not an accessory to work. It is an effort to change how work is done. Consider pricing. A useful system must combine demand, inventory, customer terms, competitors’ moves and margin targets; recommend an action; route exceptions; record who overrode it; and learn from the result. That reaches across sales, finance, supply, logistics, data, risk and compliance. It may shift discretion from a local manager to a central rule, or in the other direction. The difficult questions are therefore centred on policy and operational processes before they are technical.

This is why decision systems require a different deployment craft. Process designers must map the flow of work and remove redundant steps. Decision design must define objectives, constraints, and trade-offs. Data engineers must make measures consistent across functions. Product managers must turn all this into a service that improves with use. Governance must set thresholds, audit trails and fallbacks, and escalation for the human in the loop. Change leaders must renegotiate roles, incentives and authority. Senior executives have to settle disputes that no algorithm can resolve, because the disputes concern whose target matters.

Evidence from corporate AI programmes supports the distinction. McKinsey’s 2025 survey found that 88% of respondents’ organisations used AI regularly in at least one function, but only about a third were scaling it across the enterprise; 39% reported an enterprise-level effect on earnings. Its earlier survey identified workflow redesign as the factor most associated with an effect on operating profit. BCG likewise argues that value rises when firms move from deploying aids to reshaping work end to end. Tools can spread widely while the business beneath them changes very little.

The platform boundary

Platforms complicate matters. Most are excellent within a discipline. A customer platform knows leads, accounts and campaigns. An enterprise-resource system knows orders, materials and ledgers. A workforce platform knows shifts, skills and pay. Each has rich data, mature controls and a vendor eager to extend it with AI. This makes the platform a natural home for tools that help its own users.

However, a consequential decision rarely lives entirely within just one platform. A promise to a customer may depend on production capacity, supplier risk, transport, working capital and the value of the relationship. No departmental platform sees the whole choice. Even a broad suite reflects the boundaries of its modules, licensing and data model.

The answer is not necessarily a single universal platform, or that elusive single point of truth. In reality there should be single points of truth. That’s an architecture that allows several strong centres of excellence to contribute to a decision. Shared definitions, reliable event streams, identity, permissions and APIs matter more than a grand interface.

The decision logic should sit where it can draw on cross-business data, expose its reasoning, send actions back into operational systems and preserve an audit trail. Gartner’s idea of a composable enterprise is pertinent: capabilities bought or built as modules can be assembled around business outcomes, but doing so demands unusually close collaboration between business and technology teams.

Choose the work

Companies usually need both categories, but recognise the differences and are not best delivered as one programme. The tools portfolio should favour breadth, safe defaults and fast learning. Buy where possible, use vendor services, train by role and measure repeated use alongside time saved and quality. Withdraw licences that produce little value. Competition among vendors will improve the tools faster than most firms could do for themselves.

The decision-systems portfolio need to be more focused and demanding. Select a few decisions whose improvement would materially alter revenue, cost, cash or risk. Give each an executive owner with authority across functions. Fund a durable product team containing process, data, engineering, control and change skills. Measure the business outcome, not model accuracy alone. Roll out in stages, compare recommendations with actual decisions and make overrides informative rather than shameful. Make sure that each outcome delivers learning that improves the next.

The most tempting error is to manage a decision system like a tool rollout. A vendor demonstration then becomes a substitute for process design; a pilot proves that a model works but not that the organisation will act on it. The reverse error is to burden a simple assistant with a transformation office, months of workshops and an impossible demand for enterprise-wide returns before anyone has learnt to use it.

The diagonal in the diagram is, therefore, less a technology spectrum than a change spectrum. Towards the top right, the firm is helping people perform familiar work and adoption is the constraint. Towards the bottom left, it is rebuilding the machinery by which the firm acts and redesign is the constraint. An AI licence can be bought in an afternoon. Agreement on who may change a price, move stock or refuse a customer is not sold by the seat.