How to implement AI in a company: a step-by-step guide

Implementing artificial intelligence in a company is not a technology project: it is a process project with a technology component. That distinction sounds like rhetoric until you look at the real funnel of enterprise projects, and then it becomes the explanation for almost everything that goes wrong.

The first three numbers come from the same study and describe a single funnel. They deserve careful handling: the MIT Media Lab Project NANDA report that publishes them is a preliminary, not peer-reviewed document with a limited sample ¹. But its shape matches what firms measuring in other ways report, and that convergence is what makes it useful.

Gartner forecast in 2024 that at least 30% of generative AI projects would be abandoned after proof of concept before the end of 2025; in January 2026 it revised that figure upward ³. For agentic projects, its forecast is that more than 40% will be canceled by the end of 2027, because of rising costs, unclear business value or inadequate risk controls ². These are forecasts from an analyst firm, not field measurements, and they should be read as such; even so, the three causes they list are exactly the ones that show up in the half-dead projects we inherit.

There is a second pattern, more economic than technical. In the same study, when executives were asked to split a hypothetical hundred dollars across functions, sales and marketing took around half the budget ¹, and that tends to be the area where AI is most visible, not where it pays off most. Returns tend to show up in the boring functions: back office, documents, reconciliations, support.

The first mistake is starting with *which model should we use?*. The right question is *which process costs us the most and repeats the most?*. A good candidate has four traits: it happens many times a month, it follows rules someone can explain out loud, it produces or consumes text or documents, and today it is done by a person who would rather be doing something else.

McKinsey describes the shortcut trap well: roughly eight in ten companies have deployed generative AI in some form, but approximately the same proportion reports no material impact on earnings. Its explanation is an imbalance between horizontal use cases (general-purpose copilots and chatbots, which scale fast and deliver little) and vertical cases, specific to one function, which deliver more but get stuck in pilot ⁸. Starting with a general copilot is the fastest way to get high adoption and zero measurable impact.

The practical recommendation: pick one vertical case with a clear owner, and leave the general copilot for later, once you have a win that justifies the budget.

This is the step that kills the most projects and the one that gets skipped the most. Gartner predicts that through 2026 organizations will abandon 60% of AI projects that are not supported by AI-ready data, and in its survey of 1,203 data management leaders, 63% of organizations do not have the right practices in place, or do not know whether they have them ⁴. That *or do not know* is the revealing part.

The audit does not have to be a six-month project. In a week you can answer the essentials: where does the data live, who can export it, is it complete, does it have enough history, and are there permissions to use it? If the answer to any of those is *I would have to ask*, that is the project's first deliverable, not an assumption.

• The data exists outside one person's head and outside a scanned PDF with no text layer.
• Someone has technical and legal permission to export it to wherever the system will run.
• There is enough history to know what a normal case looks like and what a rare one looks like.
• The fields that matter are populated in most records, not in 30% of them.
• You know which information is sensitive and what cannot leave your infrastructure.

A prototype is not a demo. A demo is built with data chosen so that it works; a prototype is built with your real data, the ugly records included, and with a pilot user working in it every day. Three weeks is a realistic window for a narrow case, and it is short by design: the goal is to find out fast if the idea does not hold up.

1. 1

   Week 1: Connection and baseline

   Ingest the real data, sort out permissions and, most critical of all, measure how the work is done today. How long it takes, what it costs, how many errors it carries. Without that prior measurement you will not be able to demonstrate improvement later, and that is the moment when projects lose their budget.

2. 2

   Week 2: First end-to-end version

   The complete flow working, even if every piece is imperfect. A mediocre full run beats a single excellent stage: integration problems show up at the seams, not in the middle.

3. 3

   Week 3: Real use and a decision

   A pilot user runs it in their daily work and writes down where it breaks. At the end of the week an explicit decision gets made: continue, adjust the scope, or stop. Stopping here is cheap, and it is a legitimate outcome.

This is where 20% becomes 5% ¹. Production means concrete, unglamorous things: observability for latency, cost and quality; retries when the provider fails; spend control with alerts; prompt versioning so you can roll back; and an escalation path to a human when the system is not confident. A system with no human fallback is not more autonomous: it is more fragile.

It also means integrating into the tools your team already opens every morning. If the system lives in a separate tab that someone has to remember to visit, adoption falls off on its own within weeks, no matter how good the model behind it is.

Governance usually arrives late and all at once. Gartner predicts that by 2027, 40% of enterprises will downgrade or retire autonomous agents because of governance gaps detected only after incidents in production, and it names the underlying cause: treating governance as binary (either everything is blocked, or the agent is fully trusted) instead of grading it by the risk of each action ⁵.

You do not need to invent the framework. Three references cover most cases: the NIST AI Risk Management Framework, voluntary, which organizes the work into four functions (govern, map, measure and manage) ¹⁰; the ISO/IEC 42001:2023 standard, the first international standard for AI management systems, certifiable by independent bodies ¹¹; and, if you touch the European market, the European Union AI Act, in force since August 2024 and applicable from 2 August 2026, with staggered obligations that started in February 2025 ¹².

For a mid-sized Mexican company with no European exposure, the reasonable minimum is this: a log of every action the system executes, control over who can ask it for what, a written policy on what data goes into the model, and one accountable person by name. That alone puts you ahead of most.

The last step is the one that separates the projects that show up in the income statement from the ones that do not. BCG found in 2024 that only 26% of companies had developed the capabilities needed to go beyond proofs of concept and generate tangible value, and that just 4% had advanced capabilities ⁶. Its recommended split of effort is a prescriptive rule, not a measurement, but it sums up the lesson well: 10% on algorithms, 20% on technology and data, 70% on people and processes ⁷.

Scaling well means changing how the work happens around the system: who reviews what, which steps disappear, how the team's targets change. Copying the same agent into five departments without touching their processes produces five pilots, not a transformation.

And it is worth keeping the ambition calibrated. In McKinsey's 2025 global survey, 88% of respondents say their organization uses AI regularly in at least one function, but only 39% attribute any EBIT impact at the enterprise level, and most of them put it below 5% ¹³. Reaching that 39% with a measurable, defensible impact is already a good result.