Five AI projects we won't sell you
The best way to succeed with an AI project is sometimes not to start it. We are publishing our refusal grid in advance: five kinds of project we will say no to — and, for each one, what we will offer instead.
Also available in: Français
Part of our job is selling artificial intelligence projects. So here is a text our sales department would never have written: the list of projects we will say no to.
Let us be precise about what this text is not. A young company claiming to have "turned down dozens of contracts" would be storytelling — and our editorial principle is that everything we publish must be verifiable. So we do better: we publish our refusal grid in advance. It is dated, public, and you can hold us to it. If one day we sell you one of the projects described below, you can send us this page. It is the opposite of a marketing pitch: it is a commitment that will cost us contracts.
Every criterion comes from real experience — our own, on our own products and in the field. And every refusal comes with its alternative, because a no without a path helps nobody.
1. "Management wants AI" — the project without a problem
The brief starts with the solution: "we need AI", "our competitors are doing it", "the board is asking for our AI strategy". What is missing: the problem. No metric that hurts, no process whose current cost is known, no definition of what "success" would mean.
These projects do not fail loudly — it is worse: they succeed technically and change nothing. An impressive demo, a pilot that runs, and six months later nobody uses it, because it solves nothing anyone experienced as a problem.
What we offer instead: start with an inventory of your operations, not with the technology. Where do the hours go? Which tasks have volume, repetition, a rule? Which metric, if it moved by 20%, would change your quarter? If there is no answer, there is no project — and you have just saved six months.
2. Calculation disguised as conversation
"The chatbot will also be able to calculate the quote, right?" No. Not with us.
A language model is probabilistic by design: same input, possibly different outputs. That is a strength for writing; it is disqualifying for calculating a price, a total, a margin, the application of a rate card. We built an entire platform around this separation — the model interprets the request and writes the document, a deterministic, auditable engine does all the arithmetic. Same input, same result, every amount explainable line by line.
What we offer instead: the right division of roles. The model at the edges of the system — understanding a free-text request, writing, summarising. Classic software at the core — rules, calculations, data. If your need is 90% calculation, the honest answer is sometimes that you need good business software, not an AI project.
3. RAG on a documentary swamp
"Ask your documents questions" is the most-sold promise of the moment, and it works — on one condition the promise leaves out: that the documents deserve answers. Three contradictory versions of the same procedure, binders with no owner, archives nobody has sorted in ten years: an AI-augmented search system (RAG, retrieval-augmented generation) laid on top will produce fluent, sourced answers — and wrong ones one time in three, with nobody knowing which.
There is a second condition, which we detailed in our nFADP playbook: the access rights of the source system must survive in the index. An assistant that answers everyone with everyone's documents is not a product, it is an incident waiting to happen.
What we offer instead: a narrow, governed scope — a single corpus, one owner, one authoritative version, clear access rights — and a measurable pilot on it. Document governance first; it will remain an asset even if the AI project stops.
4. Nobody has hours for ground truth
This is the criterion the field taught us the hardest, and we told the story in detail: AI compresses construction, it does not compress validation. A business system has to be anchored in the company's reality — its prices, its rules, its special cases — and that truth is written down nowhere. It lives in your experts' heads.
If, at signing, the company cannot name who will validate and how many hours they will spend on it, the project will not die — it is more insidious than that: it will stay a pilot forever. Technically successful, operationally orphaned.
What we offer instead: expert hours in the contract, scheduled validation sessions, and a product designed to make validation as cheap as possible. If those hours really do not exist, the project's time has not come — and saying so before signing is a service, not a withdrawal.
5. The silent replacement
Sometimes the real specification is unwritten: automate a high-stakes decision — screening job applications, granting or refusing something to a customer, assessing employees — without human review, because human review "costs". Or replace a team without saying so, and call it "augmentation".
We turn these projects down for an ethical reason that does not need to be disguised as a technical one. But the technical reason exists too: Swiss law requires informing people about automated individual decisions and allowing a human review, and a system with no human checkpoint is fragile exactly where being wrong costs the most. Our architectural position does not change, from a single quote to an entire catalogue: AI prepares, the professional signs.
What we offer instead: openly automating what can be automated — the volume, the preparation, the draft — with human sign-off points at the decisions that commit. And if the goal is a headcount reduction, let it be decided and announced as such, by management, not delegated in silence to a model.
What this page costs us
Let us reread: we have just described five families of contracts we forbid ourselves. It is a real cost, accepted for an economic reason as much as a moral one: French-speaking Switzerland is a small market. A delivered project that serves no purpose gets talked about faster than a successful one — and it gets talked about with our name on it.
So bring us your project, including if it looks like one of the five. The diagnosis is the start of our work, and it is not complacent: if the answer is no, you will know why, and you will leave with the path to what needs to be built first. A reasoned no is worth more than a pilot that will never finish — it is, literally, our first sales page.
Frequently asked questions
- When should you not use AI?
- When the problem is not measured (no metric that hurts, no project), when the task is a calculation that demands an exact, reproducible result (that is classic software, not a probabilistic model), when the underlying documents or data are a swamp with no governance, when nobody in the company has hours to spend on validation, or when the real goal is to automate a high-stakes decision without human review. These five situations doom a project before the first line of code.
- How do I know whether my company is ready for an AI project?
- Three quick tests. One: can you name the operational metric the project must improve, and its current value? Two: do the data or documents the system needs have an owner, an up-to-date version and clear access rights? Three: can a domain expert commit to regular validation hours for the duration of the project? Three yeses, and the project has a serious chance. One no, and that is where the work has to start — it costs less than failing.
- Can an AI model replace classic software?
- For calculation, no — and it should not try. A language model is probabilistic: same input, possibly different outputs. A price, a total, a business rule demand the opposite. The systems that work use each tool for what it does well: the model interprets and writes at the edges, deterministic software calculates at the core. That is the architecture we apply in our own products.
- Why would a consultancy turn down a project?
- Out of well-understood self-interest. French-speaking Switzerland is a small market: a delivered project that serves no purpose gets talked about faster than a successful one. Turning down a doomed project costs a contract today and earns a reputation tomorrow. And a useful refusal is never barren: it comes with a diagnosis of what is missing and the path to get there.