Nine AI Implementation Mistakes and How to Avoid Them

Failed AI rollouts have a family resemblance. The same nine mistakes turn up repeatedly across very different organisations, and the striking thing about the list is how little of it concerns the technology. These are decision-making, procurement and change management errors, which is good news, because those are problems businesses already know how to solve.

1. Buying before deciding

Licences purchased because a department asked, before anyone has decided what problem is being solved. The result is spend without direction, and it becomes very hard to evaluate later because there was never a stated intention to evaluate against.

The fix: name the problem in one sentence before any purchase. Not "adopt AI" but the specific task, the team, and roughly how long it takes today. If you cannot write that sentence, you are not ready to buy, and one meeting will fix it.

2. Extending the evaluation

The most expensive mistake and the one that feels most responsible. Another vendor to compare, another pilot to run, a new model release to wait for. Each individual extension is defensible, and the sequence has no natural end because the comparison never converges.

Meanwhile the cost accrues in three places: internal time in meetings, the continuing use of ungoverned consumer tools with company information, and the opportunity cost of a year of learning nobody did.

The fix: set the decision date before starting the evaluation, and evaluate against that date rather than against a standard of completeness that cannot be reached.

3. Licences without configuration

Accounts are created, everyone is emailed a link, and nothing else happens. No admin console setup, no retention decision, no sharing controls, no spending ceiling, no guidance. This is buying equipment and leaving it in its packaging in the corridor.

The fix: treat configuration as a delivery step with its own owner and its own exit criterion. A non-technical person should be able to open the console, see every user, and see a hard cap on the billing page. Until that is true, you have not deployed anything.

4. Training that names no tasks

A session about what large language models are, some impressive general demonstrations, and a reminder to be careful with confidential data. Attendance is good, feedback is positive, and behaviour does not change, because nothing in it told anyone what to do differently with the work already on their desk.

The fix: three named tasks per role, with tested prompts, the starting material identified, and a specific check before output goes anywhere. Fifteen minutes of the session must be people working on their own real material.

5. No spending ceiling

An alert is configured and treated as a control. It is not. It reports spend that has already happened, to a person who may be on leave, in an inbox competing with everything else.

The fix: a hard limit at the provider, set before anything runs, at roughly 1.5 times expected monthly spend. Layer it: organisation, project, and individual credential, so one fault cannot consume everything.

6. Everything on the flagship model

The interface defaults to the most capable model, nobody changes it, and routine reformatting runs at premium rates several thousand times a month. Separately, a developer builds something using the model they trust during development and nobody revisits that choice for production.

The fix: a written routing map by task shape. Small models for classification, extraction, reformatting and short drafts. Flagship for multi-step reasoning, long documents, nuanced judgement and code. Set defaults centrally where the console allows it.

7. Personal accounts left in place

The organisation buys a governed business tier, and the personal consumer accounts people were already using quietly continue alongside it. Company information keeps flowing into accounts nobody administers, on email addresses the company does not control, and it leaves with the employee.

The fix: an amnesty to surface what exists, a sanctioned alternative that is genuinely easier to use than the unofficial one, and only then enforcement. Closing the unofficial route before the official one is good is what pushes usage onto personal devices where you cannot see it at all.

8. Treating go-live as the finish

The launch happens, the project is marked complete, the team disbands, and usage declines steadily over the following six weeks with nobody watching. By the time anyone checks, three teams have stopped entirely and the reasons are no longer fresh enough to diagnose.

The fix: plan days 31 to 90 explicitly. Weekly active users by team at week 5, one new task card per team at week 6, a cost check at week 7, and a champions catch-up at week 8. Book the 90 day review during week 1.

9. Nobody internal owns it

The setup works, and it works only while an external party is available. Nobody inside the organisation knows where the settings are, how to add a user, or how to change the spending limit. This is not an implementation, it is a rental with the appearance of ownership.

The fix: make handover an explicit deliverable in the contract. Documentation, admin access, and at least two named internal administrators briefed on the console. Test it by having your own person make a real change while the supplier watches rather than does.

Recovering from a rollout that already went wrong

If several of these describe your situation, the recovery is usually faster than the original attempt, because the licences exist and the organisation has learned things even if it did not notice.

1. Stop adding scope. Whatever is half-built stays where it is for now.
2. Fix configuration first: admin console, retention, sharing, spending cap, deprovisioning. One afternoon.
3. Pick one team and one task. Write three task cards and test them properly before showing anyone.
4. Get the budget holder into one session with the actual users.
5. Set a decision date four weeks out, with success and failure both defined in writing.
6. Reclaim dormant seats while you are at it. It funds a surprising amount of the next phase.

Frequently asked questions