Your Rejected AI Project Deserves a Second Look
If an AI project was shelved last year for poor ROI, the underlying cost and performance assumptions have likely changed enough to redo the math.
The project that got shelved
A year or two ago, someone in your company ran the numbers on an AI project — automating customer replies, summarizing contracts, tagging support tickets — and the math didn't work. The API costs ate the savings, the model made too many errors to trust unsupervised, or the latency made it unusable in a live workflow. The project went into a drawer, and everyone moved on.
That drawer is worth opening again. Not because AI got "smarter" in some abstract sense, but because the unit economics of running these systems have shifted. Cost per token has dropped in some tiers, throughput has improved, and error rates on structured tasks have gone down for several providers. None of that guarantees your specific project now clears the bar — but it means the bar you measured against is outdated.
Why the math changes, not just the mood
Most failed AI business cases fail on one of three lines: cost per task, error rate, or time to integrate. Each of these is sensitive to model pricing and capability, which move independently of your business. When a vendor cuts price per million tokens, drops latency, or ships a model that's meaningfully better at instruction-following, your original cost-per-task calculation is no longer valid — it was true for the model you tested, not for the category.
The mistake most operational teams make is treating an early AI evaluation as permanent. It isn't. It's a snapshot taken under specific pricing and specific model capabilities, both of which are among the fastest-moving variables in any technology stack right now. A project rejected at $0.40 per resolved ticket might clear $0.10 with a newer model and a leaner prompt. A workflow that needed three review passes because of a 15% error rate might need one pass at 5%.
This doesn't mean re-running every dead project on a whim. It means treating cost and error-rate assumptions as things with a shelf life, the same way you'd revisit a supplier contract or a shipping rate after a year — not because you're nostalgic for the project, but because the inputs to the decision have moved.
What actually moved, and what didn't
Two things tend to change fast: price per unit of usage, and accuracy on well-defined, bounded tasks (classification, extraction, summarization, structured generation). One thing tends to change slowly: reliability on open-ended, judgment-heavy tasks where the definition of "correct" is fuzzy. If your old project failed because the model was too expensive to run at volume, or too error-prone on a task with a clear right answer, it's a strong candidate for re-evaluation. If it failed because the task itself required nuanced judgment calls that a human reviewer disagreed on half the time, better models help less — the problem was the task definition, not the tool.
This distinction matters because it tells you where to spend your re-evaluation effort. Don't blanket-retest every idea that ever got killed. Sort them first.
Before you resurrect a project, run this check
- Pull the original business case and isolate the exact number that killed it — cost per task, error rate, or turnaround time. If you don't have that number, you can't compare, so reconstruct it before doing anything else.
- Re-price the task with current API rates and a realistic token count for your actual inputs and outputs, not a generic benchmark. Volume assumptions from a year ago are usually stale too.
- Run a small live test — 100 to 300 real cases, not synthetic examples — and measure error rate against the same threshold that mattered originally, not a lower bar you're tempted to accept because the demo looked good.
- Separate model cost from integration cost. A cheaper model doesn't help if the engineering time to wire it into your systems still costs more than the savings over 12 months.
- Decide on a kill threshold in advance — the ROI figure below which you shelve it again — so the second evaluation is as disciplined as the first one should have been.
What to look at once it's live
If you relaunch a project on the strength of better model economics, don't just track whether it runs. Track cost per completed task against your revised business case for the first 60 to 90 days, and compare it to the number that justified the relaunch. Watch the error rate on a fixed, unchanged sample so you're not fooling yourself with easier inputs over time. If actual cost and accuracy hold within range of what you modeled, the project earns its place. If they drift, that's your signal to shelve it again — until the next round of pricing and capability changes makes it worth another look.
Give the numbers a fair rerun
ArkonLabs helps you rebuild the business case on current rates and real inputs, run the live test, and set the kill threshold before you commit engineering time. If you have a shelved AI project worth a second look, get in touch via www.arkon-labs.com.