There is one question I hear often from executives who have already moved past the "should we use AI?" stage and reached the "how do we do it well?" stage. It is a more honest and more useful question, because it assumes the value can be real — which it can — but also that capturing it takes a process, not just tools.
According to Gartner, between 70% and 85% of AI initiatives fail to deliver the expected results. The most common reason is not the technology. It is the lack of organizational readiness around it.
Do you have enough data of reasonable quality? AI runs on data. If your data is fragmented across five different systems, out of date, and without quality processes, the first step is not choosing an AI tool — it is fixing the data. No model, however sophisticated, turns bad data into good decisions.
Do you have a concrete business problem to solve? Not "we want to use AI," but something specific: reducing customer service response times, improving demand forecast accuracy, automating the review of contract documents, cutting unplanned failures in production equipment. The more concrete the problem, the more manageable the project.
Do you have someone accountable for the outcome? Not for the technical project, but for the business result. AI is not the sole responsibility of IT. It needs a functional owner who has a direct stake in making it work and is willing to commit their area to the change it requires.
Assess the organization's maturity across three dimensions. On data: where is it, in which systems, what quality does it have, who governs it? On processes: which ones are repetitive, high-volume, and produce a measurable outcome? — those are the natural candidates. On capabilities: what does the organization have in-house, and what will it need to supplement?
With that diagnosis, select one or two use cases to begin with — no more. The temptation to tackle everything at once almost always produces mediocre results on every front. Criteria for choosing: clear and measurable potential impact, data available in reasonable condition, a process stable enough to model, and an internal sponsor with a genuine stake in the outcome.
Before choosing the model, define precisely what the solution is expected to do and how it will be measured. Define your success KPIs before building anything: a 30% reduction in processing time, a 15% increase in conversion, a 20% drop in incidents. Without that, there is no objective way to know whether the project worked once it is done.
Evaluate the options: buy or build? For most standard use cases, there are market solutions that can be adapted with far less effort than building from scratch. Building custom makes sense when the use case is genuinely differentiating. Also prepare the technical environment and define the governance framework: who can use the solution, what data it can process, and how results are audited.
The pilot phase is where most projects live forever. The goal is to prove that the solution works in a real environment — not a lab — and that the results align with the KPIs you defined. It is not a permanent test environment.
Set the pilot's duration and the criteria that will determine whether it moves to production from the outset. If they are met, the project advances. If not, it is adjusted or abandoned. Involve end users from the start: they hold the knowledge of the real process that no technical team has. And measure regularly throughout the pilot — not just at the end.
This transition is where many projects stumble, because they assume that what worked in the pilot will work the same at greater scale — and often there is friction that only appears in real production. Make sure the technical infrastructure can support the actual volume of operations.
Define a continuous monitoring process: AI models degrade over time if the patterns in the data shift and the model is not updated. And manage organizational change with as much care as the technology. Resistance at this stage can sabotage projects that are technically successful. Communicate the results: that builds trust and generates the momentum for the next projects.
When AI is implemented well, the data confirms it: a 40% average productivity increase among employees who use AI in a structured way, with documented gains of between 25% and 55% depending on the function (Federal Reserve Research 2025). Frequent users save more than 9 hours per week. In an organization of 500 people, that is massive operational value.
Implementing AI is not a project with an end date. It is an organizational capability that is built and improved over time. Once the first use case is in production, use that learning to tackle the next one. The data, technical capabilities, and organizational trust you have built make the next cycle easier.
Define a process for periodic review of each solution in production: Is it still generating the expected value? Is the model degrading? Are there improvements available? That systematic review is what separates an organization that operates with AI from one that simply has AI tools installed.
The timelines in this guide are references, not guarantees. What does apply universally is the order: diagnosis before design, design before build, a pilot with clear criteria before production, production with monitoring before expansion. Skipping steps speeds things up in the short term and slows them down — or cancels them — in the medium term.
Organizations that complete this process with rigor do not just get results on the specific use case. They learn to adopt technology more effectively in general, and that has a value that goes well beyond any individual project.
Sources: Gartner, McKinsey Global Institute, IDC, Deloitte State of AI in the Enterprise 2026, Microsoft LATAM, Forrester Research, Federal Reserve Research 2025.
—
Andrés Lozada
Executive Director, SUMāTO Group · Cloud · Infrastructure · Cybersecurity · Digital Transformation
linkedin.com/in/andreslozada/