AI Practice

Where to Start With AI

Most companies know they need it. Almost none know where to begin.
Christian Rose · Q-Bridges GmbH · 2026

The conversation has changed. Two years ago the question in the boardroom was whether AI mattered. Today nobody asks that. The question now is quieter and much harder to answer: where do we actually start?

I hear a version of it in almost every first conversation, and I have some sympathy for the people asking. The company has understood that AI is not optional. Someone has been handed the topic, usually on top of the job they already had. There may be a pilot running, or five. And still nothing moves, because nobody can say with any confidence which problem to point it at first.

That paralysis is rarely about ambition. It is about how the question was framed.


The wrong question produces a list

Ask "what can we do with AI" and you will get an answer. You will get a long one. Chatbots, document summarisation, forecasting, copilots, agents, predictive maintenance. Every vendor will add to it. Every workshop will extend it. The list grows, the priorities do not.

The list is the problem. It is generated by capability, not by need, and capability lists have no natural ordering. Twenty plausible ideas with no way to rank them is functionally the same as no ideas at all.

Ask instead: where does this business lose the most time, money or quality. And which of those losses is structural rather than incidental?

That question produces a sequence rather than a list. It also produces something more useful: a shortlist of places where AI is the wrong answer, which is often where the real savings are.


Start with the bottleneck, not the technology

Every organisation has a small number of constraints that govern its output. A team that spends a third of its week assembling reports nobody reads, which everyone knows and nobody has stopped. A quotation process that takes eleven days because the specification has to be read manually. An engineering group that cannot find prior work and quietly rebuilds it. A service desk that answers the same forty questions over and over.

None of those are AI problems. They are business problems that happen to sit near a tool. Some of them will yield to AI. Others will yield faster to a process change, a permission change or a decision that someone has been avoiding for two years.

The discipline is to identify the constraint first and only then ask what removes it. This ordering matters more than any technology choice, because it is the difference between a project with a business case and a project with a demo.

--> A practical test: if you cannot state what a use case is worth in hours, euros or risk avoided, you are not ready to build it. You are ready to investigate it.


What the pattern usually looks like

Across industrial, automotive and technology companies, the same categories keep surfacing as worth doing.

--> Work that is high-volume, rule-shaped and currently done by expensive people. Invoice matching, order intake, master data cleanup, specification comparison. Unglamorous, measurable, and the payback is arithmetic rather than argument.

--> Knowledge that exists but cannot be found. Most organisations do not lack expertise. They lack retrieval. When engineers rebuild what a colleague solved three years ago, the loss is real but invisible, because nobody books it anywhere.

--> Judgement work that needs preparation, not replacement. Meeting preparation, tender analysis, competitive scanning, first-draft writing. The AI does not decide. It removes the two hours of assembly before the decision.

Then there are the ones that reliably disappoint. Anything that needs accountability a model cannot carry. Anything where the underlying data is already contested internally, because AI will not settle an argument the finance and sales teams have been having for three years. And anything introduced to demonstrate innovation rather than to fix something. That last category is the most expensive of the three, and the hardest to name out loud in the room where it was proposed.


The inventory nobody wants to run

Before deciding what to build, find out what is already running.

This is usually the uncomfortable part, and it is rarely a pleasant surprise. Employees have not waited for a policy. They are pasting contracts into public models, drafting customer replies in tools nobody approved, and building small automations that now sit in the critical path of a process. None of it is malicious. All of it is unmanaged.

Two things follow from an honest inventory. First, a compliance picture. What has left the building, under which terms, and what the EU AI Act and GDPR make of it. Second, and more usefully, a demand signal. Where people improvised, there was a real need. That is free market research into your own organisation.

The same inventory should cover the official initiatives. Every running pilot deserves one of three verdicts: stop it, fix it, or scale it. Most portfolios I see contain at least one initiative that everyone privately knows is finished and nobody has been willing to close.


What a decision actually requires

A board cannot approve a direction on the strength of enthusiasm. It needs four things, and they are the same four every time.

A ranked set of use cases, ordered by value against feasibility, not by how interesting they are.

A business case per item. The hours, the licence and build cost, the expected payback, and the assumption underneath it that would have to be wrong for the case to collapse.

A named owner for each initiative, on the business side rather than in IT. Initiatives without an owner do not fail; they simply never start.

An explicit "not doing this" list, with reasons. This is the part executives value most and the part consultants most often omit, because it is the only evidence that the recommendation was not written to sell the next phase.


Fixed scope, fixed duration

An assessment that runs open-ended tells you something about the assessor. The work is bounded: interviews with the people who actually do the work, a walk through the systems, an honest look at the data, and a scoring exercise that survives contact with the leadership team.

Four weeks is enough. At the end there should be a document that goes to the board without translation, and a first project that starts the following month.

The implementation programme that follows will usually run six to twelve months. But that is the second decision. The first one is simply knowing where to point.


The uncomfortable part

Most companies do not need more AI ideas. They need someone to look at the business, say which three things are worth doing, and put a defensible number next to each one.

None of that is a technology exercise. It is the same work good consultants have always done: understand the operation, find the constraint, put a number on the fix. AI changed what is possible. It did not change how you decide, and I am not convinced it ever will.

If your organisation has been circling this question for a year, the problem is almost certainly not the technology. It is that nobody has been asked to produce the ranked list and sign their name under it.


Christian Rose (罗仕) is the Founder and Managing Director of Q-Bridges GmbH, a Berlin-based strategy, AI and technology advisory firm. He has 25 years of consulting experience and has worked as a Managing Director and Partner in both Germany and China. Q-Bridges is vendor-neutral: it sells no licences and takes no commissions.

www.q-bridges.com · LinkedIn

Related service

A four-week AI Audit produces the ranked list, the business case per item, and a board-ready decision paper. Fixed scope, fixed price, vendor-neutral.

See AI Audit