AI expectations can outpace business results when organizations invest in tools before defining the outcome, the work required, and the responsibilities and costs of delivering it. The ambition may be reasonable: improve productivity, serve customers better, or help the business grow. Impressive AI results shared online can reinforce the sense that those gains should be within reach, and a broad ambition can quickly become an expectation that buying and using AI will produce a meaningful business result.
The tools can be remarkably capable, but the organization still needs to decide what should change, how the work will happen, and what it will take to sustain the improvement. Technical limitations matter, and some use cases simply won't justify the investment. When the operating model is left undefined, even capable tools can fall short of the outcomes leaders expect.
A mandate to “use AI” gives people a technology to explore without giving them a clear problem to solve. That can be useful for learning, as long as everyone understands the purpose. It becomes harder to evaluate when the same activity is expected to deliver financial or operational results. Teams can adopt tools, generate more material, and automate individual tasks while the original business problem stays largely unchanged.
Consider a hypothetical support team aiming to reduce the cost of resolving routine questions without increasing repeat contacts. Producing answers more quickly is an output. To assess the business outcome, the team would track cost per resolved question, repeat-contact rate, and human review time, alongside whether customers actually get their questions resolved. A faster draft may contribute to the outcome, but it doesn't establish it.
Examples of intended outcomes, not guaranteed results from adding a feature.
Defining the outcome gives the team a basis for making decisions. It can establish the current cost and resolution quality, choose a manageable category of questions, and agree on what improvement would justify expanding the effort. That is a much more useful starting point for evaluating technology than a general request to find somewhere to use it.
An AI operating model defines how people, information, technology, and oversight work together to deliver a business outcome. In practical terms, it explains where people begin, which information the system can use, what actions it may take, and which decisions need approval. It also assigns responsibility for results, costs, and responding to change. Those decisions connect a tool's capabilities to work the business can rely on.
Start with the actual work by answering a few practical questions:
Will an employee begin in an existing business application, a shared AI workspace, or a separate interface?
Will the system suggest an action, prepare it for review, or carry it out?
Which actions require approval, and what happens when a request falls outside the agreed boundaries?
These choices affect the usefulness of the experience as much as the quality of AI-generated content.
Then consider the knowledge behind that response. Instructions, policies, research, and lessons from previous work need an appropriate home, with a clear understanding of which sources are trusted. Internal data governance becomes practical here: who can access the information, who can update it, and how conflicting or outdated guidance gets resolved. Connecting every available system adds little value if the organization hasn't decided what information is needed and who is accountable for its quality.
The outcome determines which context the technology needs to do useful work.
The model also needs to accommodate change. A policy may be revised, a tool may behave differently after an update, or a workflow may move to another team. Someone must be responsible for detecting the change, checking its effects, and deciding whether to adjust or pause the AI-enabled work. Without that responsibility, a workflow that worked well during a test can gradually become unreliable.
Measure AI's full cost by adding the platform subscription and usage charges to implementation, integration, maintenance, and the human time needed to achieve an acceptable result. The total will depend on the approach and volume of work. Tools the business already owns have costs and limits too, even when using them avoids another purchase.
The iceberg illustrates cost categories, not their relative size.
The useful question is what it costs to achieve an acceptable result at the expected volume. In the support example, that means looking beyond the cost of generating an answer to include review, escalation, and repeat contacts. Leaders should agree on an acceptable range of spending and decide who will be notified when usage or support costs exceed it. That makes it possible to evaluate whether an apparent efficiency gain survives real operating conditions.
Existing investments can change that calculation. The organization may already have research, approved content, established workflows, and enterprise AI capabilities that support the use case. Reusing them can reduce duplication and preserve knowledge the business has already paid to develop. The goal is to identify what is useful and what genuinely needs to be added, rather than assume that every new AI initiative requires a new collection of systems.
Once these questions have answers, the technology conversation becomes more concrete. A suite-led approach may provide a common roadmap, coordinated support, and fewer setup decisions when its way of working fits the business. Leaders still need to understand dependencies, overlap with existing tools, and how easily their knowledge and workflows could move later.
An approach built around separately chosen components may allow the organization to reuse investments and connect only what the work requires. It also leaves the organization with more responsibility for how those pieces fit together, change over time, and receive support. Either approach can include vendor or implementation support. The important issue is whether responsibilities are explicit and whether the business can sustain the arrangement.
These are decisions about fit. They give leaders a way to judge a proposal against the outcome they want, the capabilities they already have, and the work they are prepared to own. They also help expose a solution looking for a problem before enthusiasm becomes a purchasing commitment. Don’t let the technology become a solution in search of a problem.
None of this requires an exhaustive governance program before anyone can begin. The aim is to make enough decisions to run a bounded test with real work:
Choose one meaningful outcome and establish a baseline.
Define the inputs, permissions, and responsibilities needed for that use case.
Set an initial spending limit.
Agree on how the team will evaluate the result.
Then test the complete path to that result. Watch what people actually do, where they need help, what requires correction, and how much the work costs. Include exceptions and changes that are realistic for the process. The findings should help the team decide what to improve, whether to expand, or whether this particular use of AI deserves less investment.
This approach can support progress because it gives experimentation a purpose and makes the next decision easier. An organization can learn quickly without pretending that a promising tool answers every operational question. As evidence improves, it can expand the work and refine the operating model alongside it.
Closing the gap between AI expectations and business results starts with being specific about the change the business needs and the conditions required to deliver it. If your organization is working through those decisions, we'd welcome a conversation about AI readiness and strategy for the outcome you're pursuing. Schedule a strategy call here: