12 May 2026
Generative AI in Business: Where to Actually Start
A practical framework for starting a generative AI initiative in a business without getting trapped in noise, demos, or bloated roadmaps.
The wrong opening question
Most AI initiatives start with the same mistake: leadership asks what AI can do, the team produces a list of ideas, and everyone leaves with ten vague possibilities and no real priority. It feels strategic because it sounds exploratory. In practice, it reverses the correct order. A company does not need a pile of AI ideas. It needs to solve a specific business problem with acceptable risk and a measurable outcome.
The better first question is much more grounded: where are we currently losing time, quality, margin, or decision-making capacity? Until that question is clear, AI is just a technology-shaped excuse. It also explains why so many proofs of concept go nowhere. They demonstrate that a model can generate something impressive, but they do not prove that it improves an important operating loop.
The simple framework: data readiness, use case fit, then build vs buy
To scope the topic quickly, I use a three-layer filter. First layer: data readiness. If your information is fragmented, contradictory, badly labeled, or politically impossible to expose to a system, there is no point debating model choice. An internal assistant will never be better than the context you wrap around it. The real question is not "do we have a lot of data?" It is "do we have trustworthy enough sources to support one precise workflow?"
Second layer: use case fit. A strong use case is not merely interesting. It is a recurring task with understandable boundaries, a known input, an expected output, and a human who can evaluate the result without philosophical debate. Third layer: build vs buy. If the need is standard, a market tool solves 80 percent of the problem, and integration is clean, buying is usually the right move. If your edge depends on your context, business rules, internal data, or workflow, building becomes easier to justify.
The two signals that tell you a use case is worth pursuing
There are two simple signals that separate a real use case from an expensive curiosity. The first is a clearly defined task. If you cannot describe in one sentence what the system should do, for whom, from which inputs, and within which limits, you are not ready. "Help teams be more productive" is not a task. "Prepare a first draft support reply from the ticket, product documentation, and customer history" is a task.
The second signal is a measurable outcome. You need to know in advance what changes if the project works: shorter handling time, higher resolution rate, faster response time, steadier perceived quality, or fewer back-and-forth loops. Without a metric, the project collapses into a perception war. Some people see magic. Others see a noisy toy. An imperfect measure is better than enthusiasm with no proof behind it.
Why a two-week spike beats a six-month roadmap
When the topic is well chosen, I almost never recommend starting with a big roadmap. I recommend a tightly scoped two-week spike with a precise objective: test one workflow, connect real data, observe failures, and measure whether the signal is strong enough to continue. In two weeks, you learn whether the sources are usable, whether the use case is truly well defined, whether the user experience holds up, and whether the topic deserves broader investment. In six months of roadmap work, you mostly learn how to produce slides.
I have seen a company go from zero to a genuinely useful assistant in three weeks using exactly this approach. Not a generic company-wide AI assistant. One workflow only: helping the support team retrieve the right internal procedure for a common request type. Week one was spent cleaning the reference documents and defining twenty test cases. Week two connected a prototype to that corpus and added explicit human validation. By week three, the team was already using it on live tickets because the problem was clear, the context was narrow, and the gain was immediately visible.
Start smaller, but start seriously
If you are a CTO, Head of Product, or CEO, your job is not to launch a horizontal AI program to reassure the board. Your job is to choose a problem worth solving, enforce a narrow scope, and demand visible success criteria. Generative AI becomes useful when it stops being a narrative topic and becomes an execution topic. A clear task. Credible data. A simple metric. An owner. A short deadline to decide whether to continue or stop.
If you are not sure where to start, let's talk. The right first move is usually not a platform, a vendor, or a forty-page strategy deck. It is an honest scoping discussion anchored in your operating reality. You can email me at hi@alexandrelavallee.com or reach out on LinkedIn. If the topic is not worth building, I will tell you that too.