---
title: "AI roadmap: foundation first, then the first use case | Carl-Uwe Würfel"
description: "An AI roadmap for business starts with a shared foundation, then use cases. Three questions set the order, five fields per project, one date to end it."
url: https://carl-wuerfel.de/en/ai-roadmap
author: Carl-Uwe Würfel
---

1. [Home](https://carl-wuerfel.de/en)
  2. [Knowledge](https://carl-wuerfel.de/en/knowledge)
  3. AI roadmap

# AI roadmap: a list of use cases is not a plan.

An AI roadmap puts the shared foundation first and the individual use cases after it.

The usual roadmap is a list of use cases on a timeline, each one its own pilot with its own tool. That builds islands with separate contracts, permissions and costs, and in the end nobody can tell which pilot pays for itself. At SUMAX we started with sign-in, permissions and our own layer in front of the AI models, which now handles a five-figure number of calls a month, each booked with its cost.

[Carl-Uwe Würfel](https://carl-wuerfel.de/en/about)Updated November 7, 2026[Deutsche Fassung](https://carl-wuerfel.de/ki-roadmap)

## On this page

  1. Skip the starting point and you prioritize on gut feeling.
  2. The foundation comes first, even though it doesn't demo well.
  3. If nobody on the team can check it, it doesn't go first.
  4. Every project gets a date on which it may end.
  5. If nobody looks after it, it doesn't go live.
  6. Five fields per project, or it stays off the roadmap.
  7. Frequently asked questions

> To me, priority and support are one decision. If nobody has time to run a project once it's live, it doesn't go on the roadmap, however good the idea.

## Skip the starting point and you prioritize on gut feeling.

**Takeaway** Write down the workflow, handoffs, data and known errors before any project goes on the roadmap.

Start with the workflow as it runs today: who is involved, where the handoffs are, which data gets used, which errors are known. At SUMAX our time tracking was the basis, because it shows where the work lands day to day. Before that, process knowledge sat in spreadsheets and people's heads. As long as it's scattered like that, you can't judge any project honestly. To set the order, I ask three questions about every important workflow. Does it depend on a single person? Has nobody questioned it in years? Does it cost the most money? Where more than one answer is yes, that's where the first project goes.

## The foundation comes first, even though it doesn't demo well.

**Takeaway** Put users, permissions, access and cost tracking ahead of the first tool.

Before tools for single tasks, you need a base that everyone uses: users, permissions and access. Who may work with which data is then settled once, not again in every tool. Security goes in from day one, because it's hard to bolt on later. A layer of our own sits between our applications and the AI models. It lets us switch models without touching a tool, and it books every call with its cost. A foundation is hard to show off, so it tends to slide down the roadmap. Then every new tool brings its own contracts, permissions and data flows, and the [AI transformation](https://carl-wuerfel.de/en/glossary/ki-transformation) turns into a collection of islands.

## If nobody on the team can check it, it doesn't go first.

**Takeaway** Define what a good result looks like before the pilot starts.

Value, data, checkability and the effort to run it go into the same assessment, and checkability weighs the most, because a result may only move on once it has been checked. If nobody on the team can judge the result reliably, the reviewer turns into a rubber stamp. Good first [use cases](https://carl-wuerfel.de/en/glossary/use-case) are repetitive routine tasks with the data already in place. AI takes away grunt work, not people, and if you calculate [AI ROI](https://carl-wuerfel.de/en/glossary/roi-ki) as headcount saved, you'll pick the wrong cases. Before the start, decide which results are acceptable and which cases go back to a person.

## Every project gets a date on which it may end.

**Takeaway** Put a date on every project for the call to expand, rework or end it.

The pilot runs on real tasks with the people who will use the tool later. Feedback from the business team goes straight into the next version. That's how our own AI tools at SUMAX get built, and most of our people use them every month. A pilot without a decision date keeps running because nobody ends it, and the [pilot graveyard](https://carl-wuerfel.de/en/glossary/pilot-graveyard) grows. So every project has a fixed date on which it is expanded, reworked or ended. Only as many projects run at once as the team can carry, even when the tech could handle more.

Every project gets a date on which it may end.

_Figure: How an AI roadmap runs: record the starting point (workflow, handoffs, data, known errors), build a foundation for everyone (users, permissions, access, cost tracking), pick the first case by value, data, checkability and the effort to run it, then test it in daily work. On the fixed date the project is expanded into operations once support, maintenance, cost tracking and error handling are settled, or reworked and tested again, or ended with its reasons recorded._

## If nobody looks after it, it doesn't go live.

**Takeaway** Only put an application into operation once it's clear who looks after it and what it may cost.

Whatever gets expanded needs support, maintenance, cost tracking and error handling settled before launch. Without support an application goes stale with the next model change, and the team drifts back to the old way of working. You can only weigh cost against value if every call is booked. That's why our layer books each call with its cost to the application that made it. When a new model version comes out, the business review runs again. A project that gets ended is recorded with its reasons, so the next assessment can build on it.

## Five fields per project, or it stays off the roadmap.

**Takeaway** Fill in the five fields first for the workflow that gets the most yeses on the three questions.

Every project on the roadmap needs five entries.

  1. The workflow: what work, who does it today, which of the three questions applies.
  2. What it needs from the foundation, meaning permissions, data and access.
  3. What a good result looks like and which cases go back to a person.
  4. Who looks after the application once it's live and what it may cost per month.
  5. The date of the call to expand, rework or end it.

If a field stays empty, the project waits. Whatever waits stays on the roadmap with its reason, so it isn't forgotten and doesn't quietly start anyway.

## From practice.

  * [Read the note**Shutting down an AI system: keeping it is a decision too** The criteria we use to expand, rework or end an application, and who makes that call.](https://carl-wuerfel.de/en/notes/when-we-switch-off-an-ai-system)
  * [Read the case**The transformation at SUMAX** How the company has been moving leadership, roles, workflows and rules onto AI since 2023.](https://carl-wuerfel.de/en/transformation)

## Frequently asked questions

What should an AI roadmap include?

The shared foundation comes first: users, permissions, access and cost tracking per call. Then the projects, each with five entries: the workflow, what it needs from the foundation, criteria for a good result, support with a cost limit, and a decision date. At SUMAX this also meant rewriting role descriptions and training people on real tasks from their own work.

How is an AI strategy different from an AI roadmap?

The AI strategy says where the company wants to go and which guardrails apply. The AI roadmap decides what comes first, who looks after it and when the next step gets decided. The strategy rarely changes, the roadmap changes at every decision date.

How long does an AI roadmap take?

A first version is ready once the starting point of the key workflows is written down. It's never finished, because it gets updated at every decision date. Blanket deadlines say little. What tells you more is whether every project has a date on which you find out if it holds up.

How do you prioritize AI projects?

Ask three questions about every important workflow: does it depend on one person, has nobody questioned it in years, does it cost the most money? Where more than one is a yes, you have a candidate. Checkability decides after that. A case with clear value whose result nobody on the team can judge reliably moves down the list.

Who owns an AI roadmap?

Leadership sets the order, because it ties up budget, time and support. Each project also needs one person who makes the call on the decision date and looks after the application once it runs.

When does a project not belong on the AI roadmap?

When one of the five fields stays empty, for example because nobody has time to support it, the data is missing or nobody can judge the result. Those projects go on the waiting list with a reason. They move up once the gap is closed.

## Read on

  * [**Leading AI transformation in the middle market**](https://carl-wuerfel.de/en/ai-mid-market)
  * [**Measuring AI ROI: time saved isn 't money saved**](https://carl-wuerfel.de/en/notes/ai-roi-in-an-agency)
  * [**OKRs in practice: goals that steer the workday**](https://carl-wuerfel.de/en/notes/okrs-in-practice)
  * [**Owning automation**](https://carl-wuerfel.de/en/ai-automation)
  * [**The transformation at SUMAX**](https://carl-wuerfel.de/en/transformation)