AI implementation step-by-step plan in 7 steps

Which steps belong in an AI implementation step-by-step plan?

An AI implementation step-by-step plan has 7 steps in a fixed order: setting the goal, choosing the use case, mapping data and systems, choosing build or buy, building and testing a pilot, organising adoption, and measuring, embedding and scaling. The order matters because each step determines the next, and adoption, management and measurement are prepared as early as the first step. The plan assumes a single application; anyone with several candidates who wants to settle the order first is advised to start with an AI roadmap instead.

Does an AI implementation step-by-step plan start with choosing a tool?

No. An AI implementation step-by-step plan starts with a measurable problem, not with the technology. That goal comes with a baseline measurement and an owner in the business with budget and a mandate.

What happens if the data-and-systems step in the AI implementation step-by-step plan gets skipped?

Skipping the data-and-systems step in the AI implementation step-by-step plan means discovering at the pilot stage that the data doesn't hold up. Leaving adoption until after delivery means ending up with a working application nobody uses. The decisions are taken in a fixed order because each step determines the next.

Does the AI implementation step-by-step plan cover the EU AI Act?

Yes. Step 3 of the AI implementation step-by-step plan covers checking whether an application counts as high-risk under the EU AI Act, which applies if it's placed on the EU market or its output is used in the EU; under the Digital Omnibus package, most high-risk obligations apply from 2 December 2027.

Source: article by Dave Willemstein; Digital Omnibus timeline per the European Commission. Updated: October 2026.

Step 1: Set the goal

Start with the overview. An AI implementation step-by-step plan isn’t a project schedule with boxes to tick, but a sequence of decisions taken in a fixed order, because each step determines the next. Skip step 3, and you discover in step 5 that the data doesn’t hold up. Leave step 6 until after delivery, and you end up with a working application nobody uses.

1. 1. GoalMeasurable problem, owner, baseline measurement
2. 2. Use caseOne application, chosen on value and feasibility
3. 3. Data and systemsSources, quality, integrations, privacy
4. 4. Build or buyA reasoned choice, including the exit
5. 5. PilotIn the real work, with stop criteria
6. 6. AdoptionScenarios per role, champions
7. 7. Measure and scaleManagement, governance, next application

This plan assumes a single application. If you have several candidates and want to settle the order first, start with an AI roadmap instead. How I guide organisations through these steps is covered on the AI implementation page.

Now the first step: start with the problem, not the technology. “We want to do something with AI” or “we want a chatbot” isn’t a goal. “Quote turnaround takes too long” or “our staff spend too long searching for information in old case files” is.

Make the goal measurable and record a baseline: how long does it take now, how many errors happen now, what does it cost now? Without a baseline, you can’t later show that anything’s improved. Name an owner straight away too: someone in the business who genuinely benefits and who has budget and a mandate.

Finally, agree how much time and money you’re willing to invest before you expect a first result. That budget isn’t an estimate of the final cost, it’s a limit: this far, and then we reassess.

Pitfall: a goal that only IT or an innovation team cares about. Then there’s nobody left to realise the value once it’s delivered.

Step 2: Choose the right use case

Draw up a list of candidates and assess them against the same criteria: what does it deliver, how feasible is it, is the data ready, how much change does it demand, and is there an owner? A good first use case is well scoped, runs on a limited number of sources, and can show within a few months whether it works.

Work through the business case, including the costs that arrive after delivery: management, licences, monitoring and your own people’s time. For how to build a business case that survives scrutiny from the finance team, see the business case for AI.

Also record which candidates didn’t make the cut, and why. That shortlist of rejects stops the same ideas resurfacing every quarter, and makes visible which conditions need to be met first.

Pitfall: choosing the use case that demos best rather than the one that delivers most. Visible isn’t the same as valuable.

Step 3: Map data and systems

Work out what data the application needs, where it sits, how reliable it is, and who’s responsible for it. Also look at the systems the application needs to work with: where does the input come from, and where does the output need to go? Every integration is work, and integrations are almost always underestimated in planning. For why this foundation is so often the real bottleneck, see the data foundation under AI.

If you’re processing personal data, assess now whether there’s a high privacy risk. If so, a data protection impact assessment is required under UK GDPR, and that takes time. Also check whether the application could count as high-risk under the EU AI Act, which applies if you place it on the EU market or its output is used in the EU. Under the Digital Omnibus package, the obligations for most high-risk systems apply from 2 December 2027, according to the European Commission. More on this is covered under AI policy.

Pitfall: testing on a cleaned-up sample dataset. Real data is almost always messier, and you only find that out at scale.

Step 4: Choose build or buy

For almost every application there are three routes: build it yourself, buy an existing product, or have a partner build and manage it while you steer the outcome. The rule of thumb: build only what sets you apart, buy what’s a commodity. If you’re unsure, buying is often the cheapest way to learn what you actually need. The full decision framework is in build, buy or partner.

Choose a vendor or delivery partner, and set your evaluation criteria before the conversations start, testing on your own data rather than the vendor’s demo. For how to run that in a structured way, see AI vendor selection in eight steps. Put in the contract who owns the code, the configuration and the data, and how a handover works. You contract a partner directly; no margin is charged on parties I suggest, see the partner network.

Pitfall: looking only at first-year cost. Maintenance and exit set the real price.

Step 5: Build and test a pilot

Run the pilot in the real workflow, with real data and real users, even if that narrows the scope. A pilot in a separate environment alongside the work only proves the technology works, and these days that’s almost always true anyway.

Before you start, agree what question the pilot answers, what outcome counts as success, what outcome means you stop, and who makes that call. Build a test set of examples where you know the right answer, so you can judge quality objectively. During the pilot, carry out at least one management action, such as a model update or a configuration change, so you know what management actually costs. For why pilots so often stall, see why AI pilots stall.

Pitfall: a pilot with no stop criterion. It never ends; it just fizzles out.

Step 6: Secure adoption

A licence and a training session aren’t an adoption strategy. People start using an application when it makes their next task easier. So give them concrete scenarios for their own work rather than a blank input field, and make clear what is and isn’t allowed: what data can go in, who’s responsible for the output, and what happens if the answer’s wrong.

Find a champion per team who does the same work, and create a place where people share working examples. Talk openly, too, about what’s changing in the work and who decides on it. More on this in AI adoption starts with the work.

Pitfall: measuring adoption with a single percentage for the whole organisation. Measure per role or team, and you can see where it’s working and where it isn’t.

Step 7: Measure, embed and scale

Compare the results against the baseline from step 1. Record who manages the application, how often quality gets checked, and what happens if it drops. AI applications can quietly get worse as reality shifts, so monitoring isn’t a one-off action.

Set up light governance: a register of the AI applications in use, a check before anything goes live, a periodic review and an escalation path. For how to do that without creating bureaucracy, see AI governance without bureaucracy. Only once the first application is stable and has an owner should you start the next one. What you learn from the first about data, vendors and adoption makes the second faster.

Also schedule a fixed review point, for example after three months, where the owner decides: continue, adjust or wind down.

Pitfall: scaling up before management is in place. Then the application grows, but so does the risk.

Taking it further

Want to use this step-by-step plan in your own project, but get stuck on one of the steps, or want to know which choices you need to make upfront? See what consulting before implementation delivers. Not sure yet whether your organisation is ready? The AI Readiness Assessment gives a reasoned answer in 2-3 weeks. And if you’d just like to talk it through, book a call.