Artificial intelligence has become remarkably easy to try.
A team can open an AI assistant, connect a model to a few documents, create an internal prototype, or automate part of a workflow in days rather than months.
That accessibility is valuable. It is also one reason organizations can mistake experimentation for implementation.
The difference matters.
An AI demonstration proves that something can work under certain conditions.
A working system has to survive real users, real data, permissions, exceptions, business rules, changing information, imperfect inputs and the consequences of being wrong.
That is a much higher bar.
Recent research illustrates the gap. McKinsey reported in 2025 that 71% of surveyed organizations were regularly using generative AI in at least one business function. Yet more than 80% said their generative-AI efforts were not producing a tangible impact on enterprise-level EBIT. The same research found that redesigning workflows was the organizational practice most strongly associated with bottom-line impact. McKinsey & Company
The lesson is straightforward:
The value does not come simply from having access to AI. It comes from changing how useful work gets done.
That requires moving deliberately from opportunity to operation.
At Montorox, we think about that journey in five connected stages:
Discover → Design → Build → Integrate → Improve
It is not a rigid methodology. Some organizations enter with a clearly defined use case. Others begin with a business problem and no idea whether AI is even the right answer.
But the questions behind these five stages provide a useful way to distinguish an interesting AI experiment from a system capable of doing useful work.
1. Discover: Start with the work, not the model
A common way to begin an AI initiative is:
“We need to use AI. What can we do with it?”
A better starting point is:
“What work are we trying to improve?”
That shift sounds small, but it changes the entire project.
Instead of searching for somewhere to insert a technology, begin with a task, process, decision or information flow.
For example:
- Employees spend too long searching internal knowledge.
- Customer inquiries require repetitive classification and drafting.
- Analysts repeatedly extract the same information from documents.
- Marketing teams recreate similar research for every campaign.
- Managers have information spread across systems but no practical way to retrieve it.
- A workflow contains several predictable handoffs that consume time without adding much judgment.
These are operational problems before they are AI problems.
The discovery stage therefore asks questions such as:
What needs to improve?
Is the goal speed? Accuracy? Capacity? Consistency? Better access to information? Reduced repetitive work?
Who actually performs the work?
A process viewed from an executive dashboard can look very different from the same process experienced by the employee doing it every day.
What information does the work depend on?
AI cannot reliably operate on information that is unavailable, poorly structured, contradictory or inaccessible.
What happens when the system is wrong?
The tolerance for an imperfect internal brainstorming assistant is very different from the tolerance for a system that influences financial, legal, medical or customer-facing decisions.
The objective at this stage is not to force an AI project into existence.
Sometimes the right conclusion is that a conventional software workflow, better data organization, or a simpler automation is more appropriate.
Good AI implementation starts with permission to reach that conclusion.
2. Design: Map the workflow before automating it
Once a worthwhile opportunity is identified, the next question is not simply which model to use.
The bigger question is:
How should the system fit into the work?
This requires designing the workflow around both technology and people.
Consider a customer-support process.
An AI system might:
- read an incoming request,
- classify the issue,
- retrieve relevant information,
- draft a response,
- identify whether escalation is needed,
- update another system,
- present the result to a human.
Technically, it may be possible to automate every step.
That does not mean every step should be automated.
Some actions may be low-risk and reversible. Others may affect a customer relationship, money, privacy, contractual obligations or reputation.
Design therefore needs to define:
- what the AI can see,
- what actions it can take,
- which systems it can access,
- what information it may rely on,
- when a person reviews the output,
- when the system must stop,
- how exceptions are handled,
- and how success will be measured.
This becomes even more important as organizations adopt AI agents.
Microsoft’s 2026 Work Trend Index reports rapid growth in agent use, but it also highlights an organizational divide. Teams further along in AI adoption are more likely to document workflows, human handoffs and quality standards rather than simply giving agents greater autonomy. Microsoft
The most useful question is therefore rarely:
“Can an agent do this?”
It is:
“What is the right division of work between the system and the people responsible for the outcome?”
3. Build: Create the smallest system that can prove something useful
Once the workflow is understood, implementation should usually become narrower before it becomes larger.
The goal of an initial build is not to recreate the entire organization around AI.
It is to test the smallest meaningful version of the idea.
Suppose the long-term vision is an AI system capable of managing a complex research workflow.
The first implementation might do only three things:
- gather information from a defined set of sources,
- organize findings using an agreed structure,
- generate a draft for human review.
That may sound less ambitious.
It is often more useful.
A focused implementation allows a team to test questions that presentations and prototypes cannot answer:
- Are the inputs reliable enough?
- Does the system understand the task consistently?
- Where does it fail?
- Does it actually save time?
- Do users trust it appropriately?
- Does the output fit downstream work?
- What needs human review?
- Is the cost reasonable?
- What should be measured?
This is where organizations move from demonstrations to evidence.
BCG’s 2025 research illustrates why that matters. In a study of more than 1,250 firms, only 5% were classified as generating AI value at scale, while 60% reported little or no material value despite significant investment. BCG Global
The implication is not that AI lacks value.
It is that deploying technology and creating organizational value are different problems.
A focused build helps determine whether the second is actually occurring.
4. Integrate: Connect AI to real operations
This is where many promising projects become difficult.
A prototype often lives in isolation.
A working system rarely does.
It may need to interact with:
- document repositories,
- CRM systems,
- internal databases,
- publishing platforms,
- communication tools,
- APIs,
- authentication systems,
- permissions,
- customer records,
- analytics,
- or existing software.
But technical integration is only one part.
Operational integration matters just as much.
Who owns the system?
Who notices when it behaves incorrectly?
Who updates its instructions?
Who approves access to new data?
What happens when an upstream system changes?
Who reviews its performance?
How does an employee know when to trust the result and when to investigate?
These questions determine whether a system becomes part of the organization or remains an impressive demonstration sitting beside it.
McKinsey’s more recent 2026 work makes a similar point: increasing individual AI use does not automatically produce enterprise value when the surrounding organization and operating model remain unchanged. McKinsey & Company
Integration means changing the surrounding system of work—not merely inserting an AI tool into it.
5. Improve: Treat launch as the beginning of the evidence
Traditional software sometimes encourages the idea that a project moves from requirements to development to launch.
AI systems make that mental model even less adequate.
Outputs can vary.
Models change.
Users discover unexpected uses.
Information sources evolve.
Edge cases emerge only after real usage.
The environment changes.
That makes improvement an operational requirement, not a post-launch luxury.
A useful AI system should create signals that help answer:
- What is working?
- Where are users correcting the system?
- Which tasks produce poor results?
- Where are human escalations occurring?
- Which information sources create problems?
- Has the workflow actually improved?
- Are costs changing?
- Are users finding new applications?
- Have risks appeared that were not obvious during design?
Improvement does not necessarily mean adding more AI.
Sometimes it means narrowing the system.
Sometimes it means adding stronger human review.
Sometimes it means improving the underlying information.
Sometimes the right decision is to automate one part and return another part to a person.
The objective is not maximum autonomy.
The objective is a better working system.
Human oversight is part of the architecture
There is a persistent assumption that a mature AI implementation is one in which people eventually disappear from the process.
That is not a useful definition of maturity.
For many workflows, human involvement is an important feature of the system.
NIST’s AI Risk Management Framework and its Generative AI Profile emphasize managing AI risks in ways that reflect the organization’s goals, context and priorities rather than treating every AI system as equivalent. NIST
The appropriate level of oversight depends on the work.
A system generating internal ideas may require very little review.
A system interacting with customers may require clear escalation mechanisms.
A system contributing to consequential decisions may require substantial human verification.
The design question is therefore not whether humans remain involved.
It is where human judgment creates the most value and protection.
What good AI implementation looks like
A successful AI project does not necessarily have the most sophisticated model.
It does not necessarily use agents.
It does not necessarily automate the largest number of tasks.
And it does not necessarily begin with a major transformation program.
A good implementation has more practical characteristics.
It addresses a worthwhile problem.
Its users understand what it is for.
Its information sources are appropriate.
Its outputs can be evaluated.
Its permissions match its responsibilities.
Its human handoffs are deliberate.
Its failures are manageable.
Its performance can be observed.
And someone is responsible for operating and improving it.
That may sound less exciting than announcing an “AI transformation.”
But it is how technology becomes useful.
The shift from experimentation to implementation
Organizations are unlikely to stop experimenting with AI. Nor should they.
Experimentation is how teams learn what new technology can do.
But the next stage of AI adoption will increasingly be defined by a different capability:
the ability to turn what works into systems that fit the organization.
Microsoft’s 2025 research described organizations progressing from individual assistants toward agents and eventually toward redesigned human-agent workflows. Its 2026 findings suggest that the difference between organizations moving ahead and those struggling is increasingly about the environment around the technology—leadership alignment, repeatable processes, quality standards and the ability to embed AI into actual work. Microsoft
That is ultimately the implementation challenge.
The model matters.
The software matters.
The data matters.
But so do the workflow, the people, the permissions, the controls and the operating model around them.
An AI opportunity becomes valuable when all of those pieces begin working together.
The goal is not simply to use AI.
The goal is to make useful work work better.
Have an AI opportunity worth building?
Montorox helps organizations move from AI opportunity assessment through workflow design, implementation and integration.
Talk to Montorox →