It is hard to run a business right now without feeling that you are being left behind. A new model lands every few weeks, every vendor has added the word AI to their product page, and someone at every meeting has read that a competitor is already doing something dramatic. Some of it is real and some of it is noise, and from the outside the two look almost identical. This guide gives you a filter you can apply in an afternoon, so your first AI project is chosen on its merits rather than on the mood of the news cycle.
Short answer: Ignore how loud the market is and look at the task. If it is repeated, has a measurable cost today, runs on data you already own, produces output a person can check, and has one named owner, it is worth a pilot. If it fails two or more of those, it is probably hype.
1. Two Things Are True at the Same Time
The debate is usually framed as boom versus bubble, as if one side has to be wrong. In practice both are happening. Investment and expectations are running ahead of what most companies have actually shipped, and some of the products being sold today will not survive. Meanwhile the capability underneath is genuinely useful: systems can now read and search large piles of documents, draft and classify text, extract structured data from messy inputs, and act on simple instructions across your tools.
For a business owner this means you do not have to pick a side. Market sentiment is a poor guide to whether a specific project will pay back. A well-chosen use case delivers value whether the wider market goes up or down, and a badly chosen one fails in either case.
2. The Five-Question Filter
Before you spend anything, put the idea through these five questions. They are deliberately plain, because the most common failure is a project that sounded impressive and never had a real user.
| Question | Real value looks like | Hype looks like |
|---|---|---|
| What is the task? | A specific, repeated job someone does weekly | “Use AI across the company” |
| What does it cost today? | Hours, errors or delays you can count | No baseline to compare against |
| What data does it need? | Documents or records you already hold | Data you hope to collect later |
| How is output checked? | A person reviews, or a test set scores it | “It seems to work” |
| Who owns it? | One named person who wants the result | A committee, or nobody |
Notice that none of these questions mention which model you would use. That is intentional. Model choice is the easiest part of the project to change later, and the least likely to decide whether it works.
3. Warning Signs That You Are Buying Hype
- The pitch starts with the technology. A good proposal opens with your process and your numbers. A weak one opens with the model name.
- There is no test on your own data. Demos on tidy sample files prove very little. Ask to see it run on a small, real sample of yours.
- Success is undefined. If nobody can say what number should move, nobody will be able to say afterwards whether it worked.
- Everything is described as autonomous. Most useful systems keep a person in the loop for anything consequential. Full autonomy on day one is a red flag, not a feature.
- The vendor cannot say what it will cost to run. Build cost is only half of the bill. Ongoing model, hosting and maintenance costs should be estimated up front.
4. What Tends to Work First
The projects that reliably reach production are unglamorous. They take work that people already do, and remove the slow or repetitive part of it.
- Searching your own knowledge. Staff or customers ask questions and get answers with citations to your documents, instead of hunting through folders.
- Triage and routing. Incoming emails, tickets or forms are read, classified and sent to the right place.
- Data extraction. Invoices, contracts and forms are turned into structured records a person only has to confirm.
- Drafting for review. Replies, summaries and reports are drafted, and a person edits and approves them.
What these have in common is that a mistake is cheap to catch, because a human sees the output before it matters. That is a much better place to start than anything that acts on its own with real money or real customers on the line.
5. Why Pilots Stall, and How to Avoid It
Most stalled AI projects were not killed by the technology. They were built to impress a room, never connected to the tools people actually use, and left without an owner. Three habits fix most of it:
- Define the number before you start. Pick one metric, such as minutes per ticket or documents processed per day, and record where it stands today.
- Put it where people already work. A tool that lives in a separate tab gets forgotten. Connect it to the inbox, the CRM or the chat tool that is already open.
- Keep the first version small. A few weeks, one workflow, real users. You want evidence quickly, and you want to be able to walk away cheaply if the evidence is weak.
6. Should You Wait for the Technology to Settle?
It is tempting to hold off until the market calms down. The trouble is that the slow parts of an AI project are not the models. Getting your documents into shape, agreeing who owns the process and getting real feedback from real users all take months, and they are identical whichever model you eventually use. Teams that start a small pilot now are building that groundwork while others wait.
The sensible middle path is to start narrow and stay flexible. Build so that the model behind the system can be replaced without redoing the rest, because prices, capabilities and the best option for your task will keep changing.
A simple rule: spend enough to learn something real, and no more. A short pilot on your own data answers the question that actually matters, which is whether this works for you, and it costs a small fraction of a full build.
Frequently Asked Questions
Is the AI boom a bubble?
Both things can be true at once. Valuations, funding rounds and product announcements move faster than revenue, and some of that will correct. But the underlying capability is real and already useful for specific, well-defined work such as document search, support triage, data extraction and code assistance. For a business the practical question is not whether the market is overheated, it is whether a particular use case pays back on its own numbers. If it does, market sentiment barely matters.
How do I tell a genuine AI use case from hype?
A genuine use case has four things: a repeated task with a measurable cost today, data you already own that the system can use, a way to check the output, and an owner in the business who wants it. If you cannot name the task, the current cost and the person who will use the result, you are buying a technology rather than solving a problem.
Should we wait for the technology to mature before investing?
Waiting on the models is rarely the right call, because the parts that take longest are not the models. Cleaning up your data, deciding who owns the process and getting a small pilot in front of real users all take months, and they are the same whichever model you end up using. Start with a narrow, low-risk pilot now, and design it so the model can be swapped later.
Why do so many AI pilots never reach production?
Usually for organisational reasons, not technical ones. The pilot was built to impress rather than to be used, it was never connected to the systems people actually work in, nobody owned the outcome, or nobody defined what success looked like before it started. A pilot that fits into an existing workflow, with one named owner and one number to move, is far more likely to survive.
Do we need the newest, biggest model for our use case?
Almost never. Most business tasks are narrow, and a smaller or cheaper model, sometimes a self-hosted one, does them well at a fraction of the running cost. Choose the smallest model that clears your accuracy bar on your own test set, and keep the architecture flexible so you can move up or down as prices and capabilities change.
How much should a company spend on its first AI project?
Enough to learn something real, and no more. A scoped pilot that runs for a few weeks against real data is a small fraction of a full build and answers the question that matters: does this work on our data, for our users. Commit to the larger build only after the pilot has shown a number you can defend.