Most AI projects do not fail because a team chose the wrong large language model, vector database, or cloud service. They fail earlier, when the organisation has not decided what problem is worth solving, what data can support it, who will own it, and how success will be measured.
Model selection is visible and concrete. Teams can compare benchmarks, attend demonstrations, run a prototype, and produce an architecture diagram quickly. The harder work is less glamorous: agreeing where a business process is genuinely constrained, mapping the data that process depends on, defining the decisions that AI may assist with, and designing the controls that keep the result useful in production.
A capable model placed inside an unclear operating model does not create clarity. It can accelerate confusion, automate weak decisions, and turn an unresolved process problem into an expensive technology programme.
The right starting point is not “Which model should we use?” It is “What outcome must improve, what prevents it today, and what evidence would prove that this intervention worked?” That is the same discipline that makes cloud modernisation programmes succeed: architecture, governance, delivery ownership, and measurable business outcomes must come before technology choices.
The model is rarely the first important decision
AI initiatives often begin with a technology event: a leadership offsite, a competitor announcement, an enthusiastic internal prototype, or a vendor promising rapid efficiency gains. The organisation then asks for an AI strategy, but the practical brief is often much less defined: build a chatbot for staff, improve customer service, find value in our data, or automate manual work.
Each could be worthwhile. None is yet a workable project.
“Improve customer service” could mean faster first response, higher resolution quality, better triage, fewer handoffs, stronger compliance, or a lower cost per case. “Automate manual work” may describe repetitive copy-and-paste activity, but it may also conceal an important judgement process that needs human accountability.
Choosing a model before answering these questions commits the project to an implementation path before the problem is understood. The team starts optimising prompt quality, retrieval accuracy, latency, and token cost while the business still cannot explain which decision or workflow is changing.
That is how pilots become stranded demonstrations. They show that AI is technically possible without establishing that it is operationally valuable.
Begin with an outcome that can be measured
A useful AI project has a specific outcome, a baseline, and a decision-maker who cares about the result. It should be possible to express the project in plain language:
Reduce the time required to prepare a compliant first draft of a customer response, while preserving mandatory approval controls.
Or:
Improve the speed and accuracy of support-ticket routing, reducing unnecessary transfers without increasing escalations.
These statements are better than “deploy a customer-service copilot” because they define the work that matters, the constraint, and the trade-off. They also expose questions that technology alone cannot answer.
What counts as a compliant response? Which approvals are mandatory? Is the current delay caused by drafting, finding information, waiting for a subject-matter expert, or a poorly designed workflow? How will the team distinguish a fast but incorrect answer from a useful improvement?
Without these answers, metrics become cosmetic. A project team may report active users, prompts submitted, summaries generated, or documents processed. Those are adoption signals, not business outcomes. An assistant that produces thousands of drafts is not necessarily improving the process if employees spend as much time checking and correcting them as they would have spent writing them.
The first artefact should therefore be an outcome statement and a measurement plan, not an architecture diagram.
The process may be the real problem
Many AI opportunities are symptoms of a process that already needs attention.
Consider a sales team that spends too long producing proposals. An AI drafting tool may help, but the underlying delay may come from fragmented pricing data, unclear approval limits, repeated legal reviews, or inconsistent product information. In that situation, a model can produce polished language around unreliable inputs. It may make the problem look faster while leaving the commercial risk intact.
The same pattern appears in service operations. A support team may ask for an assistant to answer customer questions, yet the source knowledge is duplicated, out of date, and owned by no one. The assistant will retrieve conflicting material because the organisation has not decided which answer is authoritative.
AI is often most effective after a process has been simplified enough to expose the actual point of friction. This does not mean every process needs a long transformation programme before experimentation can begin. It means the team should map the current path well enough to understand where information enters, where judgement is required, which decisions are repeatable, what exceptions create disproportionate risk, and where human review is essential.
Data readiness is an operating issue
An organisation is not ready for AI merely because it has a data warehouse, a document repository, or a large volume of historical records. Quantity is not the same as usability.
For an AI system to support a real workflow, data must be relevant, accessible, current, interpretable, and governed. The business also needs a way to manage change. If a policy changes, who updates the source material? If a product specification is corrected, how quickly does that correction reach the assistant? If two systems disagree, which one wins?
These questions matter especially for retrieval-augmented generation, where a model receives documents or records as context before producing an answer. Retrieval can make a system more grounded, but it does not solve content ownership. It may faithfully retrieve material that is stale, incomplete, or contradictory.
For each proposed use case, establish an authoritative source, a named owner for correctness and updates, lawful and secure access, a traceable path from output to input, and a rule for handling conflicts. A useful cloud readiness assessment examines the operating model, data, security controls, costs, and delivery constraints, rather than simply inventorying infrastructure.
Ownership is what turns a pilot into a capability
An AI prototype can be built by a small group of motivated people. A production capability cannot.
Once a system affects customers, employees, financial decisions, regulated activity, or core operational workflows, ownership becomes central. Someone must be accountable for the business outcome, someone for the data and content, someone for technical operation, and someone for the controls that determine whether the system may act independently.
When ownership is vague, predictable problems follow. A knowledge base becomes inaccurate because no team owns upkeep. A product team launches an assistant without a support model for feedback. Security is involved late, after data has already been copied into an unsuitable environment. Operations cannot diagnose failures because monitoring was treated as a later concern.
Before build starts, name a business owner for the outcome, a process owner for exceptions and handoffs, a data owner for source quality and access, and a technical owner for architecture, reliability, security implementation, and support. One person may hold several roles in a small organisation, but responsibility must be explicit.
Build pilots with production-shaped boundaries
A pilot should reduce uncertainty, not simply impress an audience.
The strongest early projects are narrow enough to measure but meaningful enough to influence the wider programme. They use a contained workflow, a bounded data set, a defined user group, and a deliberate human fallback.
An internal assistant that helps account managers locate approved product information can be a good first step if it is restricted to a defined catalogue, returns source links, records unanswered questions, and requires users to verify high-risk content before sending it externally.
By contrast, a broadly scoped enterprise knowledge assistant attempts to solve access control, document ownership, data quality, search relevance, user experience, support, and governance in one release. It produces too many unknowns to evaluate properly.
The right first workload, like the right first cloud migration workload, creates useful learning and reusable delivery capability. Workload prioritisation should favour opportunities that are valuable enough to matter, contained enough to run safely, and representative enough to teach the team something useful.
Design governance into the workflow
Governance is often treated as a late approval gate. That creates friction because the team has already made assumptions about data access, model behaviour, human oversight, and acceptable risk.
A better approach is to design controls as part of the user journey. If an assistant drafts a response to a customer, the system should know whether the response is informational, contractual, financial, or safety-related. These categories may need different retrieval sources, output restrictions, approval paths, logging, or an outright refusal to generate an answer.
If an AI system recommends an action, the user should understand what evidence informed the recommendation and when confidence is low. If it takes an action automatically, the organisation should define the conditions under which it is allowed to do so, the controls around permissions, and how the action can be reversed.
The important questions are practical: what data may enter the system, which outputs must be reviewed, what should happen when evidence is missing, who can change instructions and permissions, and how will the organisation test for regressions after a change? A production foundation needs identity controls, auditability, environment separation, monitoring, cost management, and controlled releases. Cloud engineering connects these disciplines so new capabilities remain supportable after the prototype stage.
Model choice comes later—and becomes easier
Once the problem, process, data, controls, and operating model are defined, model selection becomes a tractable engineering decision.
The organisation can compare candidates against the requirements that actually matter: quality for the specific task and language, ability to follow constrained instructions, context and retrieval needs, latency and throughput, cost at expected usage, data-handling constraints, availability, structured outputs, integration capability, monitoring support, and portability.
There may be no single best model. A low-latency, lower-cost model may suit classification or extraction. A stronger model may be justified for complex document analysis where human review remains in place. Some tasks may not need generative AI at all; rules, search, workflow redesign, or conventional machine learning can be clearer, cheaper, and easier to govern.
That is a healthy outcome. Discovery exists to find the simplest intervention that produces the required result.
A practical starting sequence
Before funding a major build, run an evidence-led discovery phase:
- Select one process where delay, inconsistency, cost, or decision quality is visible.
- Define the measurable outcome and current baseline.
- Map the workflow, including exceptions, handoffs, and approval points.
- Identify authoritative data sources and content owners.
- Classify data and define access, retention, and audit requirements.
- Design the human oversight model and failure path.
- Build a narrow pilot with production-shaped controls.
- Evaluate task quality, workflow impact, risk, support effort, and cost.
- Decide whether to scale, redesign, pause, or solve the problem another way.
The model is part of step seven, not the beginning of the programme.
Start with the work, not the technology
AI can create meaningful value when it helps people make better decisions, complete constrained work faster, or remove avoidable operational friction. But it cannot substitute for a clear business case, reliable data, accountable ownership, and a process that can handle exceptions safely.
The organisations that get value from AI are not the ones that choose a fashionable model fastest. They are the ones that can describe the work clearly enough to know whether AI improved it.
