Why do first AI projects fail?

Almost always for the same reason: the flashiest use case gets chosen instead of the most measurable one. A conversational assistant for customers sounds better in a presentation than “automatically classify the emails coming into support,” but the second can be measured in two weeks and the first puts the brand's face on the line.

The second reason is data quality. AI does not fix disorganized information: it amplifies it. If your documents are scattered and out of date, an assistant that consults them will give scattered, out-of-date answers — with great confidence and a good tone.

Which tasks are good candidates?

A task is a good candidate when it meets three conditions at once:

  • It is repetitive and happens on a known rhythm (daily or weekly).
  • It works on text or loosely structured data: emails, documents, forms, transcripts, tickets.
  • It has a clear standard for “done right,” so you can verify the result without arguing about it.

Concrete examples: classifying and routing incoming requests, extracting data from invoices or contracts, generating first drafts of sales replies, summarizing sales calls and pushing them into the CRM, answering internal questions about documentation.

How do I prioritize between several use cases?

Place each candidate on a matrix of impact (how much time or money it frees up per year) against effort (integrations needed, data quality, risk if it gets it wrong).

The practical rule: your first project comes from the high-impact, low-effort quadrant, even if it is the least spectacular. High-impact, high-effort cases are the ones that justify the big investment, but only after the organization already has a win it can point to.

Drop the low-impact quadrant without guilt: those are the projects done “because we can.”

How long should the first project take?

Weeks. If your first use case needs six months before showing a result, you chose badly. The point of the first project is not to transform the operation: it is for your team to learn to work with AI and for you to learn where the real bottlenecks are — which almost always turn out to be data and processes, not models.

What do I need in place before starting?

Less than people assume, but not nothing:

  • Knowing where the information the system will consult lives.
  • Someone from the business who can say whether a result is right.
  • A metric taken before you start, so you can compare afterwards.
  • Clarity on which data cannot leave the organization.

And if my team has no technical profile?

It does not need one. What it does need is someone who knows the process inside out, because the hard part of an AI project is rarely the model: it is defining precisely what should happen in the ambiguous cases. That definition comes from whoever understands the business, not from whoever writes the code.

That is exactly the work of an AI Discovery: translating the operation into prioritized use cases before investing in development.