A half-day workshop easily produces forty ideas: “we could have AI write the meeting minutes”, “an assistant that answers questions about the manuals”, “extract the data from supplier emails”. Everyone leaves the room convinced the company is about to go AI-first. Six months later, at best one project has started; at worst, none.
The weak point isn’t generating the ideas. It’s the order — and more precisely, what decides that order. The instinctive answer is return: the highest-earning cases first. It’s the answer that runs AI programs aground, because the real order is dictated by two constraints that return ignores: where the data actually is, and how the regulation classifies each case.
What follows is the method I use to turn that raw list into a sequenced plan that holds up in front of management. The thesis is simple: a defensible AI plan isn’t ordered by hoped-for return, but by real constraints — regulatory and data. It’s the point where a regulation stops being a compliance item and becomes a product decision.
The map first, then the ideas
The question “what could we automate with AI?” always arrives too early. The feasibility of every use case depends on one thing: where the data is and how you reach it. An assistant that answers questions about the manuals is trivial if the manuals are tidy PDFs, nearly impossible if they’re scattered across messy drives and inside people’s heads.
That’s why the work doesn’t start from the ideas but from an inventory: which software is in use, which exposes APIs or exports, where each piece of data physically lives, which AI licenses and tools the company has already paid for without using. It’s unglamorous, decisive work. Without it, every cost and feasibility estimate is an invented number.
From here follows the first operating principle: you start from what’s already in house. Maximizing the value of the tools and licenses already present, before proposing new purchases, avoids building the plan on foundations that don’t yet exist.
The ideas aren’t all different
Forty ideas look like forty distinct problems. They aren’t. Beneath the surface, they fall into a small number of recurring technical patterns: a copilot that drafts content over a corpus of documents, an agent that answers over a knowledge base, an automation that reacts to an event, the extraction of data from unstructured input with a human check before anything is written, read-and-write integration with the line-of-business systems.
Recognizing the pattern of each case is what changes everything. It lets you estimate cost and effort by analogy with similar cases instead of from scratch, and above all it lets you build the sequence so that each pattern is learned only once. The first project of a given type is an investment; the second of the same type costs a fraction, because the architecture and the logic have already been validated.
For the CTO this is the difference between a portfolio of disconnected projects and an infrastructure that compounds. For the CEO it’s the difference between paying forty times and paying once for each new capability.
What actually decides the order
When every idea is described at the same level of detail and assessed on the same dimensions — feasibility, cost, internal effort, risk, return — it finally becomes possible to compare them. But comparing them isn’t enough to order them, and the right criterion isn’t “highest-return ones first”. The real order is decided by constraints, not preferences: what the regulation lets you put into production now, and where the data actually exists.
There’s a constraint that beats all the others: dependencies. A use case cannot precede what it depends on — a piece of data, an integration, an API — even when its return looks better. It’s the most common mistake of plans built in a spreadsheet sorted by descending ROI: they put at the top something that rests on something that isn’t there yet.
Within these constraints, four principles govern the fine mechanics of the order: value visible in weeks and not months, because early results build the internal confidence that makes the hard phases possible; increasing technical complexity, from what you can do without custom development toward the real integrations; reuse, in each wave, of what was built in the previous one; risk last, with the cases of high legal impact or on sensitive data entering only once the team has experience and the governance measures are in place. These are the mechanics, not the engine: the engine remains the two constraints.
Regulation decides the sequence, it doesn’t just endure it
Every AI use case has a place in the EU AI Act: from the prohibited practice, which exits the plan, to high risk with its full obligations, down to the minimal risk of internal copilots. That placement isn’t a check to run at the end — it’s the first criterion by which you order. A high-risk case cannot start before the governance measures it requires are operating, however attractive the return. A minimal-risk one — an internal assistant over documents — can start immediately. It’s the risk class, not the ROI, that decides who goes first.
The same applies to personal and special-category data — health, payroll. The GDPR obligations, the legal basis, the processing agreements must be settled before launch, not chased afterward. Treating the AI Act and data protection as inputs to planning, and not as obstacles to work around, is what makes a plan defensible rather than optimistic. It’s also the precise point where a regulation becomes a product decision: not a constraint to endure downstream, but the criterion that shapes the roadmap upstream.
There’s a step between “we did the checks for this project” and “we have a stable way of doing them for every project to come”. ISO/IEC 42001 — the standard for AI management systems — covers precisely that step: it turns governance from a one-off control on a single use case into a repeatable process over the next ones. For the CTO it means not redoing the risk analysis from scratch for every new case; for the CEO it means being able to say, with evidence, that the company manages AI rather than merely using it. Having a structure harmonized with the other management systems, it plugs into what the company already has — quality, information security — without becoming a separate track.
The real cost isn’t the sum of the costs
Estimating the budget of each use case in isolation and then adding them up overstates the real cost, often grossly. A license that serves five use cases is paid once. An infrastructure — an organized repository, a database, a connector — is set up once. A project that replicates a pattern already built costs far less than the first.
Serious cost analysis reasons by phase, applying these economies of scale, and produces a license map that says not only what you need but explicitly what you don’t need to buy. The typical mistake is the premium license for everyone when a few technical profiles to build and many users to consume are enough. Telling the client what they shouldn’t buy is worth, in trust, more than any proposal.
The deliverable is a decision, not a document
In the end the method doesn’t produce a report to file away. It produces a sequence: what starts first, what it depends on, which conditions must be true for the next phase to begin. Each transition between phases is tied to a concrete check — “APIs confirmed by the vendor”, “AI Act risk class assigned”, “data agreement signed” — not to an assumption. A plan conditioned on checks holds up in front of management; a plan made of good intentions doesn’t.
Seen from a distance, this is a description of how you manage innovation: gather ideas, assess them with consistent criteria, sequence them, fund them, oversee them. It isn’t an insight of mine. ISO 56001 — published in 2024, the first certifiable standard for innovation management systems — describes exactly this cycle, and AI is the most concrete proving ground on which to apply it today. For a manufacturing company it’s the difference between treating AI as a series of isolated bets and treating it as a capability that is built and measured over time.
The distance between a list of ideas and an AI plan isn’t measured in technology. It’s measured in the discipline with which you let the order be decided by the real constraints — what the regulation allows, where the data exists — instead of by hoped-for return.