AI, honestly
When AI is a bad idea (a field guide from people who build it)
We build AI systems for a living, which is exactly why we'll talk you out of half of them. The failure patterns are predictable: here they are.
Alphacroft · 1 Jun 2026 · 8 min read
About half the AI feasibility probes we run end with a recommendation not to build. That ratio surprises people, coming from a company that sells AI systems. It shouldn't: the cheapest possible AI project is the one you correctly never start, and being the firm that tells you so is worth more to us than one bad engagement.
The failures are not random. After enough of them (ours, the industry's) the patterns are clear enough to write down.
Pattern one: the task needs to be right every time
Current models are extraordinary at tasks where 95% correct is transformative and a human catches the rest: triaging tickets, extracting invoice fields, drafting responses. They are the wrong tool when a single silent error is catastrophic and unreviewable: calculating payroll, applying regulatory rules, anything where 'mostly right' equals 'wrong'.
The test we use: what happens to the 1-in-20 failure? If the answer is 'a human review queue catches it', AI is a candidate. If the answer is 'nobody notices until the fine arrives', it isn't.
Pattern two: there's no data, only enthusiasm
An AI system is a mirror held up to your data. Companies that can't produce a few hundred representative examples of the task (real tickets, real documents, real decisions) aren't ready to build; they're ready to start collecting. That costs almost nothing and makes the eventual project dramatically better.
Related: if your process is currently inconsistent (three staff members would give three different answers), the model will faithfully learn the inconsistency. Fix the process definition first; it's cheaper than fine-tuning around chaos.
Pattern three: a checklist would have done it
A real conversation from a strategy engagement: a company wanted an AI system to route incoming emails to departments. We asked how a human decides. 'Well, if it mentions an invoice number it's finance, if it names a product it's support…' That's not an AI project, that's twelve if-statements: deployable in a day, explainable to an auditor, free to run.
The rule of thumb: if an expert can write down the decision procedure, write it down and execute it as code. Reach for models when the procedure resists being written down: judgment, language, perception.
When it is a good idea
High-volume, language-heavy, judgment-shaped work with a tolerable error mode and a human escape hatch: support triage, document extraction, knowledge retrieval, first-draft generation. These projects pay for themselves in months and their returns are boringly measurable, which is the point.
The discipline isn't pessimism about AI. It's respect for it: reserving it for the problems where it's genuinely the best tool, and having the evaluation harness to prove it's working once it ships.