What Is an AI Roadmap, and What Should Be in One?

What is an AI roadmap?

An AI roadmap is a short document that decides three things: where AI is worth using in your business, in what order those things get built, and who owns each result.

The word roadmap gets used for two different objects. The first is a technology plan: which models, which platform, which vendor, which integrations. The second is an operating plan: which processes in this company are expensive, which of them AI can carry, and what has to be true before any of it runs unattended. Only the second one is useful to an owner, because the technology questions have converging answers and the process questions do not.

A useful roadmap is specific enough to argue with. Not "use AI in customer service" but "the after-hours calls that currently go to voicemail get answered and booked, the answers come out of the scheduling system, and the front desk keeps anything involving a complaint". Somebody reading that can tell you it is wrong, which is the whole point of writing it down.

Length is not the measure. A roadmap for a forty-person company can be four pages and still be the most valuable document it owns that year, because the expensive decision is what not to build. Most businesses have between three and ten processes worth automating and can only absorb one change at a time, so the sequence carries more value than the list.

At BLACKSIG the roadmap is the paid engagement and the build follows it. Our strategy work produces the decisions, our engineering team builds what the plan calls for, and we run the result on our infrastructure from there.

What should an AI roadmap actually contain?

An AI roadmap should contain six things, and a document missing any of them is a summary of a conversation rather than a plan.

What it contains	What it answers	What makes it useless
The process inventory	What work happens here, who does it, how long it takes	A list of departments instead of a list of processes
The cost of each one today	What those hours cost in wages, errors and lost work	Percentages with no basis, or a saving with no arithmetic behind it
What AI can carry, and how far	Which parts run unattended, which get drafted for approval, which stay human	Claiming a capability is proven when it is early
The sequence	What is first, what follows, what waits for the first one to prove out	Everything at once, or a phase one with nine items in it
The systems each one touches	Which software gets written to, and who can authorise that access	"Integrates with your existing tools"
Who owns the running system	Who watches it, who fixes it, who is called when it is wrong	Silence, which means it lands on whoever notices

The row that gets skipped most often is the third one, and it is the one that decides whether the plan survives contact with reality. Capability maturity is uneven: reading documents and drafting replies is settled work, and a good deal of what gets demonstrated on stage is not. We publish that split by industry on the industry boards, marked proven, working or early, because a roadmap built on a demo is a roadmap with a hole in it.

The row that costs the most when skipped is the last one. A system with no named owner degrades quietly, because the failures are small and boring: a form gains a field, a vendor changes an API, a supplier switches invoice layouts. Systems we build run on our infrastructure and we operate them from there, which is the answer to that row rather than a hope about it.

How far ahead should an AI roadmap plan?

An AI roadmap should plan the first build in detail, the next two in outline, and nothing beyond that in any detail at all.

The reason is not modesty about the future. It is that the second decision is better after the first system runs. You learn what your records are actually like, which exceptions the people handling the work never mentioned, and how much oversight your team wants before it trusts an output. All three change what the second build should be, and none of them are knowable from a workshop.

Long plans fail in a specific way. A twelve-month program with four workstreams commits to a shape of company that will not exist in twelve months, and by month five the plan is being defended rather than used. Shorter cycles avoid that: decide, build one thing, run it, decide again with better information. Our own lifecycle is four stages, discover, plan, build and improve, and the fourth one is where most of the value shows up in year two.

Enterprises are the exception worth naming. A company with a data team, a governance function and a platform selection under way genuinely needs a longer plan, because the foundations take that long and the sequencing problem is real. McKinsey's State of AI survey, published on 5 November 2025 from 1,993 respondents across 105 countries, found 88% of organisations reporting regular AI use in at least one business function while only 7% report having scaled it fully, which is the gap those programs exist to close.

For an owner-led business the honest planning horizon is one build and a queue. Anything further out is a list of intentions, and calling it a roadmap does not make it one.

Why do most AI plans never turn into working systems?

Most AI plans die between the document and the build, and the research on this is consistent enough to plan around.

Gartner's July 2024 press release predicted at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, naming poor data quality, inadequate risk controls, escalating costs and unclear business value. Gartner's later analysis, published on 30 April 2026 as Why Half of GenAI Projects Fail, says at least 50% were abandoned after proof of concept, and puts underestimated running cost at the top of the reasons.

MIT's Project NANDA report, The GenAI Divide: State of AI in Business 2025, reviewed more than 300 publicly disclosed AI initiatives alongside 52 structured interviews and 153 leader surveys, and found about 95% of enterprise generative AI pilots produced no measurable profit impact, as reported by Fortune in August 2025. The authors attribute it to workflow fit rather than model quality: brittle processes, systems that learn nothing from context, and poor match with how the work actually runs.

Underneath those numbers are four failure modes a roadmap can prevent. Building the demo instead of the process, where the impressive part is automated and the tedious part that consumed the hours is not. Skipping the records question, where the plan assumes data that is clean and finds data that is three spellings of the same customer. Committing to everything, where phase one has nine items and none of them ship. And nobody owning the result, where the system runs for four months and then quietly stops being right.

The full failure analysis, including what it looks like from inside a stalled project, is in why AI automation projects fail.

Who should build the AI roadmap, and should they also build the systems?

The firm that builds your AI roadmap should be able to build what it recommends, and should be willing to tell you when the answer is to buy something instead.

Separating the two sounds prudent and usually is not. A strategy firm with no delivery arm writes recommendations it never has to live with, and the gap between a plan and a buildable plan is where most of the wasted year goes. Integration constraints, vendor access limits and the condition of your records all change what is worth recommending, and a firm that has never wired into your kind of systems cannot see them from a workshop.

The real risk in one firm doing both is the obvious one: a builder recommends building. The protection is not separation, it is a firm that says no to things and can point at where it has. Our industry boards publish what we think is early and not worth buying yet, which is the same judgement applied in public.

What to avoid is a roadmap priced as a product with no relationship to what follows. If the document is the deliverable and nobody is accountable for whether anything works afterwards, you have bought a research report. The phrase worth listening for is who owns the outcome, and the answer should not be you.

At BLACKSIG the roadmap decides where AI belongs, our engineering team builds what it calls for, and we run the result from there. That is the transformation work rather than a handover, and it is the reason the plan stays honest: we have to live in it.

How do you tell a good AI roadmap from an expensive document?

A good AI roadmap can be checked by somebody who was not in the room, and five tests do it in about ten minutes.

Does it name processes rather than technologies? A plan whose first page lists models, platforms and vendors was written about the industry. A plan whose first page lists quoting, intake, invoice coding and after-hours calls was written about you.

Does every recommendation carry a number from your business? Not an industry average. The hours that process takes here, the people who take them, what that costs. A plan without your own arithmetic in it cannot be argued with, and anything that cannot be argued with cannot be tested.

Is the first item small enough to finish? One process, named systems, a described output. If the first item is a program, the plan has no first item.

Does it say what stays human? A roadmap with no boundary is a roadmap that has not thought about being wrong. Where the output touches money, health or a legal filing, the plan should say who signs and when. The design side of that question is in what happens when AI gets something wrong.

Does it name who operates each system after launch? Ownership is the row that decides year two, and the answer should be a person or a firm rather than a role that does not exist yet.

A document that passes all five is worth paying for. A document that fails three is a reading list with a cover page on it. If you want the shorter version of this exercise, the AI audit page covers what the mapping engagement itself involves.

Frequently asked questions

How much does an AI roadmap cost?

Cost tracks how much of your business is in scope and how deep the process work goes, so a roadmap for one department and a roadmap for a company with four sites are different pieces of work. What you should establish before paying for either is what the processes in question cost you per year in hours, because that number decides whether the exercise is worth running. BLACKSIG scopes strategy work on a call rather than from a rate card, since the number depends on what we find. The market context for the build that follows is in how much AI automation costs.

How is an AI roadmap different from an AI audit?

An audit is the mapping exercise: where the time and money go, which processes are expensive, what each one costs today. A roadmap is the decision that comes out of it: what gets built, in what order, and who owns it. The audit is evidence, the roadmap is the plan, and buying the first without the second leaves you with a document that describes your problems accurately and changes nothing.

Can a small business have an AI roadmap, or is that an enterprise thing?

A small business can have one and needs it more, because it can absorb fewer failed attempts. The enterprise version is long because the foundations are long: platform selection, governance, a data warehouse, agreement between departments. A twenty-person company skips nearly all of that and gets a roadmap that fits on a few pages, names three processes and orders them. Smaller scope makes the document sharper, not thinner.

Do we need a roadmap, or can we just automate the obvious thing first?

If the obvious thing is genuinely obvious, automate it and write the roadmap afterwards with better information. The case for planning first is that the obvious thing is often the visible thing rather than the expensive one. The process that annoys everybody is rarely the one eating the most hours, and a week of mapping usually reorders the list. Where it does not, you have lost a week and gained a sequence for what comes next.

Who should be in the room when the roadmap is written?

The people who do the work belong in the room alongside the people who manage them. Undocumented rules live in the judgement of whoever has been doing the task for nine years, and those rules are what the system has to reproduce. An owner can describe what should happen. The person doing it can tell you what actually happens when the input is wrong, which is where the exceptions are.

What Is an AI Roadmap, and What Should Be in One?

The short version