Your first AI use case: how to choose where to start
The first AI use case is the project with which a company gets serious about AI, and its choice matters disproportionately: a visibly successful first project creates trust, budget, and appetite for the next ones; a failed first project blocks the subject for years. The right choice is made on four criteria: impact, feasibility, risk, and readiness, not on which demo looks better.
"Where do we start with AI?" is probably the question we hear most often from executives. The bad answer is a list of 30 brainstorming ideas. The good answer is a single project chosen with discipline, with a measurable result in 90 days.
Why the first use case matters disproportionately
The first AI project does not deliver only its own result; it delivers the internal story about AI. If it succeeds visibly, the next projects get budget, people, and goodwill. If it fails or lingers in the gray zone of demos, every future proposal starts with a handicap: "we tried that and nothing came of it".
That is exactly why the first use case is chosen with different weights than the fifth: feasibility and speed matter more than ambition. You are looking for the demonstrable win, not the total transformation.
The four criteria
- Impact: the result shows up in money, time, or quality, on an indicator someone already tracks. A project whose impact nobody measures does not exist politically.
- Feasibility: today's technology solves the problem with reasonable effort, and the required data exists and is accessible. This is where most beautiful ideas fall.
- Risk: what happens when the system is wrong? For the first project, choose workflows where errors are cheap and recoverable, with a human in the loop.
- Readiness: the team that owns the process wants the change and has time for it. The most feasible project dies in a team that does not want it.
Score every candidate on the four criteria and take seriously only the ones that are good at all of them. A high impact score does not compensate for nonexistent data.
Where the good use cases hide
- Repetitive, high-volume tasks: replies to similar requests, document or ticket classification, data extraction from forms. Volume makes the gain measurable.
- Knowledge locked in documents: procedures, contracts, technical documentation, support history. A system that answers with sources from them shortens daily searching; it is the natural territory for RAG integration.
- Drafts that consume hours: offers, reports, long replies. The AI writes the first draft, the human decides; low risk, visible gain.
- Decisions waiting on synthesis: someone reads for hours to prepare a five-minute decision. Assisted synthesis shortens the road.
The anti-criteria: what you do NOT choose first
- Critical processes without a safety net: invoicing, medical decisions, any place where an error costs dearly and immediately.
- High-risk domains on the first try: recruitment, employee evaluation, credit scoring fall into the serious-obligations category under the EU AI Act; they are not for the first attempt.
- Projects that require data you do not have: if the project starts with "first we collect a year of data", it is not the first project.
- The complete transformation of a department: ambition is built on foundations, not the other way around.
- The use case that came from a vendor's demo: it may be good, but the right order is your problem first, the demo after.
Validate cheaply before you invest
Before any purchase or development, one week of manual validation cuts months of wrong road: take 30-50 real cases from the targeted workflow and try them with a generic, available tool. If the results on real cases are promising, you have a cheap signal that a serious pilot is worth it. If not, you just saved a quarter.
Validation ends with the same short document that starts any disciplined pilot: target result, quality threshold, stop conditions, owner, and the decision date.
Checklist for choosing the first use case
- The candidate list comes from real processes, not just brainstorming.
- Every candidate is scored on impact, feasibility, risk, readiness.
- The result indicator exists and someone already tracks it.
- The required data exists and access to it is confirmed, not assumed.
- The system's errors are cheap and there is a human in the loop.
- The team that owns the process wants the project and has time for it.
- Manual validation on real cases happened before the investment.
- The result is demonstrable in 90 days, with written criteria.
FAQ
How many use cases should we run in parallel at the start?
One, taken all the way to a measurable result. Parallelism splits attention, ownership, and the organization's trust budget. The second project starts from the lessons of the first, not next to it.
Should the first use case be internal or customer-facing?
Usually internal: errors are cheaper, the data is under control, and you learn operations without public exposure. You go customer-facing after proving the discipline on an internal workflow, with the same criteria and thresholds.
What budget is reasonable for the first project?
Enough for validation and a disciplined pilot, not for a platform. The practical rule: the first project buys measurable learning, so you size it by the cost of validation plus a 4-8 week pilot, with the scaling decision made on numbers, afterwards.
What if the board asks for a complete AI strategy, not a single project?
The two do not exclude each other: a good strategy starts from evidence, and the first use case is the evidence generator. You present the 12-month direction and, inside it, the project you start with and the criteria it will prove. The board gets both vision and discipline.
What do we do with the good ideas that did not pass the filter?
Keep them in a short backlog, with the reason for rejection: missing data, too much risk for a start, an unprepared team. Many become viable after the first success, when the data, the trust, and the budget look different.