AI is only worth it where it replaces real work
Most AI projects that fail did not fail technically. They failed because nobody could say which task was being replaced, or how the gain would be measured. "We want AI in our product" is not a use case; "our support team spends two hours a day sorting incoming email" is.
So the first conversation is not about models. It is about which task is repetitive enough, high-volume enough and stable enough in its rules to be worth automating, and what would count as success once it is.
The use cases that hold up in production
Four families cover the large majority of what I deliver, and they share a property: the rules are stable and the output is checkable.
- Document processing: extracting structured data from invoices, contracts, forms or CVs, in a format your systems can consume directly.
- Internal documentation search, a RAG assistant that answers from your own procedures and product sheets, citing its sources, instead of from general knowledge.
- First-line customer support, an agent that genuinely resolves part of the requests and escalates explicitly as soon as it leaves its scope.
- Automation workflows, connecting the tools you already use so information stops being copied by hand between them.
Measure before generalising
A generative AI feature is not deterministic: the same input can produce ten different outputs. Conventional tests don't catch that, which is why the first thing built alongside any AI feature is a set of evaluations: a body of real cases with quality criteria, replayed whenever the model or the prompt changes.
Without that, quality drift is invisible until a customer sends you a screenshot of your assistant inventing a policy that doesn't exist. With it, you know before they do, and you can change model without crossing your fingers.
Your data, and where it goes
Every AI project raises the same question, and it deserves a direct answer rather than reassurance: what leaves your infrastructure, to which provider, under what retention terms. These are settled at scoping, in writing, before any development.
Self-hosting an open-weights model is a legitimate option, but it trades a usage bill for GPU infrastructure to run, secure and keep updated. For the vast majority of products the cloud API wins on cost and quality. Where a genuine constraint blocks it, the self-hosted route is the right call, and I'll say which case you're in.
When another solution will fit better
- AI projects without an identified use case. If we can't name the task being replaced, there is nothing to build.
- Automating processes that aren't stable. Automating a process nobody agrees on hard-codes the disagreement.
- Training models from scratch. I adapt and integrate existing models; I don't train foundation models.
- Guaranteeing a percentage gain before measurement. Anyone promising a figure before seeing your data is selling, not estimating.
