The gap between companies talking about AI and companies running production AI workloads is wider than the noise suggests. A small share of organisations have moved from experiments into systems that customers and operations actually depend on. Most are still circling.
For a mid-size business deciding how to make that move, the path is more practical than the conference talk track implies. Here is what the companies that succeed are actually doing in the first twelve months.
| What to know |
| • First AI initiatives that succeed almost always start with a narrow, well-defined business problem rather than a broad capability statement. |
| • Production AI work requires a different mix of engineering skills than data science alone, including MLOps, data pipelines, and software engineering discipline. |
| • Most failed first AI projects fail at the data layer, not the model layer, and the time spent fixing data infrastructure usually exceeds the time spent on model development. |
Why most first AI projects miss the runway
A pattern repeats across companies attempting their first serious AI work. The project is scoped broadly. It is positioned as a strategic transformation. A small team is assembled. Six to nine months later, the team has produced an interesting demo and a backlog of follow-up requests, but nothing that customers or operations are using day to day.
The reason is rarely the model. It is the framing. A first AI project framed as a capability rather than a problem ends up trying to be useful for too many things at once. By the time the team has prototyped one path, another stakeholder has asked for something different. The team rebuilds. The cycle continues. Nothing reaches production because nothing is bounded enough to actually finish.
Companies that get past this stage have usually narrowed the first project to something specific enough that finishing it is unambiguous. A particular workflow that needs to be faster. A particular kind of decision that needs to be more accurate. A particular customer interaction that needs to scale. The scope is small. The success criteria are measurable. The project either ships or does not.
The skill mix that actually delivers production AI
A common assumption is that AI work needs data scientists. That is partially true. Data scientists are essential, but on their own they cannot put a model into production. The full stack of skills includes data engineering for the pipelines, software engineering for the application that uses the model, MLOps for the deployment and monitoring, and domain expertise for the framing.
The companies that move fast on AI usually have a small cross-functional team rather than a single specialism. A team of one data scientist, one data engineer, one software engineer with AI experience, and one product or domain lead can deliver more than a team of three data scientists. This is also why many growing companies bring in external AI development services for the first project rather than trying to build a full internal team before the project has proven its value. The external team supplies the missing engineering disciplines while the internal team builds judgement around what works in the specific business context.
Where the time actually goes
Across the first AI projects that get to production, the time distribution is consistent. Roughly two thirds of the calendar time goes to data work. That includes pulling data from source systems, cleaning it, joining it across formats that were never designed to be joined, handling missing values, validating quality, and building the pipelines that will keep new data flowing once the model is live.
About one fifth of the time goes to model selection, training and tuning. This is the part that gets the headlines but is usually the smaller share of effort. The remaining time goes to integration, deployment, monitoring, and the work of helping users actually adopt the model output.
According to information published in the Gartner glossary on AI engineering, AI engineering is described as a discipline that creates coherent enterprise development, delivery, and operational AI-based systems, which captures the practical reality that production AI is more about engineering than research.
For companies budgeting their first AI project, the takeaway is that the data work has to be planned and resourced explicitly. Treating it as a small pre-project step that the team will figure out is the single most common reason first projects stall.
Choosing the right first application
Three categories of first project tend to succeed more often than others. The first is internal operational AI, where the model improves an internal workflow such as document classification, anomaly detection in operations, or prioritisation of a backlog. The risk is contained because the user is internal, and the success criteria are measurable.
The second is customer-facing AI in a narrow use case, such as a chatbot for a specific function, a recommendation feature for a particular catalogue, or a personalisation layer in a specific journey. The scope is bounded by the function, which keeps the project deliverable.
The third is data extraction and processing AI, where the model handles a class of documents or inputs that previously required manual handling. This is often a strong fit for companies with high volumes of unstructured data. In all three cases, the work involves real AI application development rather than experimentation alone, which is the discipline of building something that runs reliably under real conditions and is monitored and improved over time.
What the second year tends to look like
Companies that finish a successful first project rarely stop. The second year is usually about expanding the platform built for the first project to support several more. The data pipelines, the deployment infrastructure, the monitoring, and the governance framework built for project one become the foundation for projects two, three and four.
This is where the early structural choices start to pay off. A team that built the first project as a one-off has to rebuild much of the supporting infrastructure for the second project. A team that built the first project on a deliberate platform can deliver the second project in a fraction of the time. The cumulative effect over twenty four months is significant.
Companies that are eighteen months into this cycle usually do not look transformed. They look like the same business with a steadily growing portfolio of small AI capabilities that each remove a specific friction or open a specific possibility. The transformation, if it happens, is the accumulation of those small capabilities, not a single project.
What to do before you start
Three preparation steps separate the companies that move quickly from those that stall. The first is to audit data sources for the candidate first project. Where does the data live, what format is it in, who owns it, and what would it take to get a clean feed into a development environment. If the answer is unclear, that is the project plan for the first quarter, not a footnote.
The second is to set realistic success criteria with the business stakeholder before any model work starts. A model that is right 85 percent of the time may be useful or useless depending on the cost of being wrong, and that conversation has to happen up front.
The third is to plan the deployment path from the start. The team should know how the model output will reach the user, what happens when the model is unavailable, who maintains the model after launch, and how performance will be measured in production. None of these are optional, and discovering them late is one of the most common reasons first projects fail to land.
