We get asked to build AI features every week. A meaningful share of the time, our honest answer is that the client shouldn't.
That's an odd thing for a company that builds AI systems to say, so let me be precise about why. AI projects rarely fail because the model didn't work. They fail because nobody asked whether the problem was worth solving this way — whether the thing being automated was actually expensive, whether being wrong occasionally was survivable, and whether a far simpler fix would have delivered most of the value for a tenth of the cost.
Those questions are answerable in an afternoon. Here they are.
Filter 1 — Is it repetitive, at real volume?
AI earns its cost by doing something many times. The economics are close to fixed-cost: substantial effort to build and evaluate, then cheap per use.
So the arithmetic is simply:
(time per task × tasks per month × cost of that time) vs (build cost + running cost + oversight)
Run it honestly. Two numbers get distorted:
Volume gets rounded up. "We process hundreds of invoices" often means 140 a month. At three minutes each, that's seven hours of work monthly. Seven hours is not a budget for a machine learning project — it's a part-time person, and probably a better spreadsheet.
Time per task gets rounded up too. People quote the worst case. Measure the median.
The threshold is fuzzy, but the pattern is consistent: below a few hundred instances a month of a task taking a few minutes, automation of any kind rarely justifies itself, and AI specifically almost never does. Above a few thousand, it usually does.
If volume is low, stop here. Not "start smaller" — stop. The right answer is a better process, a template, or a person.
Filter 2 — Can it tolerate being wrong?
This is the filter that eliminates the most ideas, and the one people find hardest to accept.
AI systems are probabilistic. They will be wrong. Not rarely-and-then-fixed wrong — routinely wrong at some rate, forever. A very good system might be wrong 3% of the time. A great one on a narrow task, 1%.
So the question is: what happens on the wrong ones?
Good candidates — being wrong is cheap and recoverable:
- Drafting a reply a human will edit before sending
- Suggesting a category a user can change
- Prioritising a queue someone works through anyway
- Extracting data that gets reviewed before it's committed
- Summarising, where the source is one click away
Bad candidates — being wrong is expensive, invisible, or both:
- Anything that moves money without review
- Medical, legal, or safety decisions
- Irreversible actions with no confirmation step
- Anything where a plausible-looking wrong answer won't be noticed
That last one deserves emphasis. The dangerous failure mode isn't obviously-wrong output — someone catches that. It's confidently wrong output that looks right. A summary that quietly omits the one clause that mattered. An extracted total that's off by a decimal. If your process has no natural point where a human would notice, you're building a system that generates errors nobody catches.
The reframe that saves projects: stop asking "can AI do this task?" and ask "can AI do the first 80% and hand a human the rest?" The second question has far more good answers, and the resulting systems actually survive contact with production. That's the subject of human-in-the-loop AI, which is where most successful deployments end up.
Filter 3 — Does the data exist?
Not "could we get data." Does it exist, now, in a usable form?
Be concrete:
- Where is it? In a database, or in email attachments, WhatsApp threads and someone's Downloads folder?
- How much? Custom models need meaningful volume. Modern general-purpose models need far less, which has genuinely changed this filter — but you still need enough examples to evaluate whether the thing works.
- Is it labelled? For anything requiring examples of correct answers, do you have them? Creating them is real work that lands on your busiest domain experts.
- Is it representative? Data from your three biggest clients won't generalise to the long tail.
- Are you allowed to use it? Customer data carries consent, contractual and DPDP obligations. Check before building, not after.
A specific trap: your best people's judgement is usually undocumented. The senior underwriter who "just knows" which applications smell wrong has decades of pattern recognition that exists nowhere in your systems. You can't train on it, because the reasoning was never written down. This is the most common reason a promising project stalls.
Filter 4 — Does it beat the boring alternative?
Before any AI project, force this question: what's the simplest thing that could work?
Astonishingly often, the answer isn't AI:
- A better form. Half of "extract data from documents" problems exist because someone sends a PDF instead of filling a form. Fixing the input beats parsing the output.
- Rules. If the logic is "flag anything over ₹50,000 from a new vendor," write the rule. It's deterministic, explainable, debuggable, and free.
- Search. "AI that answers questions about our documents" is sometimes just search that works.
- A template. Many "generate this text" problems are a template with three variables.
- A process change. If the bottleneck is that approvals sit in someone's inbox for four days, no model fixes that.
We've had clients arrive wanting a document-processing model and leave with a restructured intake form that eliminated the problem. Less revenue for us, better outcome for them, and a client who trusts what we say next time.
The test: if a rules-based version gets you 70% of the value at 10% of the cost, build that first. You'll learn what the real edge cases are, and you'll have a baseline. If it turns out to be enough, you've saved a great deal. If not, you now know exactly what AI needs to add — and you have a working system to compare against, which is worth more than it sounds.
The costs nobody budgets for
The build is often the smaller half.
Evaluation. You need a way to know whether it's working. That means a labelled test set, defined metrics, and a repeatable process. Without it you're guessing, and you'll ship regressions you can't detect. Teams consistently underestimate this and it's frequently the largest single cost.
Ongoing quality monitoring. Accuracy in testing tells you little about accuracy in six months. Inputs drift, customers change behaviour, vendors change document formats. You need production monitoring and a plan for when quality slips.
Human review capacity. If your design routes low-confidence cases to a person, that person's time is a permanent operating cost. Budget it explicitly.
Model and API costs at real volume. Cheap in testing, meaningful in production. Model your actual monthly volume, and check what happens if usage triples.
Prompt and model maintenance. Providers deprecate models and update behaviour. Something that worked perfectly can shift. This is a maintenance commitment, not a one-time build.
A useful planning heuristic: whatever you estimate for building it, budget the same again for evaluating, monitoring and maintaining it in year one.
What good candidates look like
Across the projects that worked, the pattern repeats:
- High volume, thousands of instances monthly
- Genuinely repetitive, the same shape of task each time
- Currently done by people who find it tedious rather than interesting
- Tolerant of error, with a natural review point
- Data already exists as a by-product of doing the work
- The boring alternative was tried and hit a real ceiling
Concretely: document data extraction at volume with review before commit. Support ticket triage and routing. First-draft generation a human finishes. Search and retrieval over a large internal corpus. Anomaly flagging for human investigation.
Notice what these share — AI does the tedious first pass, and a person keeps authority over the outcome. That's not a compromise. It's the shape that works.
What to measure in a pilot
If you clear all four filters, pilot properly. Most pilots fail to prove anything because success was never defined.
Before starting, write down:
The baseline. How long does this take today, how often is it wrong today? Without this you cannot demonstrate improvement, and human error rates are almost always higher than people assume — which usually helps your case.
The success threshold. A specific number, agreed in advance. "90% extraction accuracy with under 10% routed to review." Not "see if it's useful."
The failure threshold. What result means you stop? Agreeing this beforehand is the difference between a disciplined experiment and a project that limps on because nobody wants to call it.
A time limit. Six to eight weeks. Pilots without end dates become permanent, unmeasured, and unowned.
The honest summary
Most businesses asking about AI in 2026 have one or two genuinely good candidates and a long list of things that would be better served by a better form, a clear rule, or a fixed process.
Finding the good ones is the valuable work. Run the four filters. If an idea survives all four, it's probably worth building and will probably pay. If it fails filter two or four — which most do — you've saved a quarter and a budget.
And if someone tells you every process in your business is an AI opportunity, they're selling, not advising.
Want an honest assessment?
We build AI systems for Indian businesses, and we'll tell you when you don't need one. Two weeks, fixed scope: we look at your actual processes and volumes, run these filters, and give you a written recommendation — including which problems to solve without AI.
Bengaluru-based, working with clients across India and globally.
Get in touch · See our AI work · WhatsApp: +91 9677749648