Implementing AI in your company: the three phases and what you get from each

Implementing artificial intelligence in a company takes three phases. The first decides what is worth implementing and in what order. In the second, one concrete case goes into production and the people who used to do that work by hand start using it. In the third, those people keep it running without the supplier.

Each phase ends with something that stays in your hands: nine deliverables in total, three per phase. Here they are, why each one is what it is, what it takes from your side, and when a case gets stopped.

Six in ten companies already using AI never got past the pilot

The figure comes from the Bank of Spain. In its business activity survey (EBAE) for the fourth quarter of 2024, published in the Economic Bulletin, 60 % of companies using AI report using it experimentally or as a pilot programme. 34 % report moderate use and only 6 % intensive use. The same study puts adoption at 19,9 % of Spanish companies and ranks the shortage of qualified staff as the first barrier (45,8 %).

Six in ten companies are testing, and many have been stuck at that point for years. A pilot leaves nothing behind when it is switched off: no running system, no baseline figure to compare against, no operating document, and nobody inside who can keep it going. The next project starts from scratch.

That is why this article is organised around deliverables rather than steps: the list of what stays in your hands is the only thing separating an implementation from a pilot that got switched off. The difference between a supplier who hands you that material and one who hands you a report is covered in the article on agencies and consultancies.

Phase 01. Where to start: deciding before building

The first phase builds nothing. It talks to the people who do the work every day, looks at the tasks with the screen in front of them, and ends in a session where you decide what gets implemented first.

What stays in your hands:

• The prioritised case queue. A table you maintain yourselves, with candidate tasks ordered by what they deliver and what they cost to implement. It is a table and not a presentation because it will change: when a case goes into production, the next one moves up. The criteria behind the order are set out in the article on our change of approach, and the tasks that can enter it are described one by one in the catalogue.
• The map of systems and data. A diagram of which system holds which data, what permissions reach it and how they connect to each other, plus the list of accesses the work will need. It is useful well beyond AI: it is the first thing you need the day you change one of those programs.
• The decision in writing. A one-page record: what goes first and why. It exists for whoever was not in the session and has to approve the spend, and for you six months later, when nobody remembers what was ruled out.

What it takes from your side: someone with the authority to decide what goes first, and access to see the tasks with the people who do them rather than the people who describe them. Those are two different things, and seeing the tasks with the people who do them is what decides whether the phase is worth anything.

And the decision that closes the phase: whether to continue. This phase can be contracted on its own: whatever comes out of it is yours, whether we carry on together or not.

Phase 02. Launch: into production, and into daily use

This is where the first case enters. It is built on the systems you already have, integrated where the work already happens, tested by the people who will use it, and they are trained before it is closed.

The success criterion for this phase is not that the case is deployed: it is that the case gets used every day without us. The distance between deploying and using is exactly the Bank of Spain's 60 %.

What stays in your hands:

• The case in production, inside your systems and with your accesses. Not in a separate environment or a supplier account. If the code does not live in your repository and cannot be changed without calling someone, what you have is a subscription rather than a system. The five business and operations cases and the five for technical teams cover ten cases with what each one took.
• The measurement of what changed. A short dashboard with the indicators agreed before the work started. The important word is «before»: if the baseline is taken once the case is already running, there is nothing to compare.
• The operating manual, written while the case is built and not at the end. It is written by whoever builds it, because they are the ones who remember the decisions that are not obvious, and those are the ones you need the day something breaks. Its reader is whoever maintains it afterwards, whether that is us or not.

What it takes from your side: the people who will use it, to test it before it is closed, and an environment to deploy into. When it is tested by someone who will not use it, the case comes out correct and then nobody uses it.

And the decision that closes the phase: with the case running and the measurement in front of you, you decide whether the next one starts or the work stops here.

Phase 03. Support: keeping the pace once we step back

The third phase is not maintenance: it is what turns an implementation into a capability the company owns. It means regular sessions with the teams already using the case, clearing whatever slows adoption, and folding new developments into what is already built.

What stays in your hands:

• The updated queue. The same table from the first phase, revised with what building taught you. It almost always changes order, and that is the sign that the first phase did its job with the information available at the time.
• The record of use. Who uses the system and what has stopped being done by hand. Whoever defends next year's budget needs it: it is the first thing they are asked for and the last thing that usually exists.
• People on your team who lead it. Named people, not a role on the org chart. It is the main deliverable of this phase and the one that decides whether in two years you are still moving forward or starting over.

What it takes from your side: someone inside who takes responsibility, and the freedom for us to tell you what is not working. Without that freedom, this phase turns into a meeting where everything is fine.

The three phases on one page

If you run the business, the deciding column is the second: it says what this costs on your side. If you lead IT, it is the first and the third. There is a page for each, the business view and the IT view, and the full route is on the implementation page.

When a case is stopped or postponed

A case leaves the queue for three reasons, and none of them is a failed project. Quite the opposite: a case leaving is the sign that the phase worked.

The data it needs does not exist. The data is not wrong or messy: it does not exist in any system. We say so, that case is postponed and the next one in the queue moves up. Collecting that data may well be worth doing, but it is a separate project and gets decided separately.

Nobody is going to use it every day. If the task belongs to someone leaving in three months, or is split across four departments and none of them claims it, the system has no owner the day it is handed over.

The task is only done once a quarter. The team accumulates no learning and forms no habit: every time the task comes round, they have to learn the system again. Implementing it costs more than carrying on by hand.

What should worry you is the opposite: a supplier who has never stopped a case. What we have delivered is on the projects page.

What to ask for in writing, whoever the supplier is

Four questions to copy straight into a request for proposals. They work for comparing any proposal, ours included.

1. What stays in our hands at the end of each phase, with the name and format of every deliverable.
2. Where the code lives and under what permissions, and who can change it without calling the supplier.
3. What gets measured, what the baseline is and who reads it once the project is over.
4. What happens if a case does not work: who decides, at what point, and what happens next.

If a proposal answers all four questions, you know what you are buying even if the price is high. If it answers none of them, the price is not the problem.

Where you come in

We are an AI implementation agency and we work in three lines: AI implementation, which is this route; training, when what you need is for the team to do it themselves; and custom development, when the case calls for building something that does not exist yet.

And there is a first step you can take this week without us: write the queue. Take the five tasks that repeat most in your team and note, for each one, how many times a month it happens, what data it needs and whether that data already exists. It is a small version of the first deliverable of phase 01, and it is what any supplier will ask you for in the first meeting.

If you want to go through it with us, tell us how your team works.