Five AI projects we tell companies not to build
A useful AI partner should help you find the right project. Sometimes that starts by being honest about the projects that are not ready.
There is a moment in some AI conversations when everyone in the room is ready to start. The idea sounds ambitious. The demo would look great. Somebody has already given the project a name.
Then we ask what should be different after it ships.
Sometimes the room gets quiet.
That does not mean the company lacks vision. It means the idea needs more work before the engineers do.
We believe saying no is part of building well. Here are five kinds of AI projects we would pause, narrow, or decline until the underlying issue is clear.
1. The project with no named outcome
"We need an AI agent" is not an outcome. Neither is "We want to use the latest model."
Those are technology preferences. They do not tell the team which work should improve, who should benefit, or how anyone will know the project worked.
A named outcome can be simple. Prepare a complete first draft of the weekly operating report. Reduce the manual steps required to open a service request. Give a reviewer the source material and the proposed answer in one place.
Each statement points to a workflow and a person. Each can be tested.
Before a project begins, finish this sentence: "This system will help this team improve this result, and we will see the change in this measure."
If the sentence cannot be completed without a list of vague benefits, the project is not ready. Keep working on the outcome, not the prompt.
2. The project built on an undocumented process
AI cannot follow a process the company cannot explain.
That does not mean every workflow needs a giant manual. It means the team needs a shared view of what starts the work, what information is required, where decisions happen, what counts as complete, and who handles exceptions.
Imagine a hypothetical operations team where three people process the same request three different ways. One trusts the customer record. One keeps a private spreadsheet. One asks a manager because the written policy is outdated.
Automating one version does not fix the disagreement. It turns an unresolved operating question into software.
Pause the build. Put those three people together. Walk through a normal case and a difficult one. Decide which differences are useful judgment and which are accidental workarounds.
The first deliverable may be a current-state map, not code. That is progress. A documented process gives the eventual system something real to support.
3. The project with unsafe write access
Reading and preparing are different from sending and changing.
A system that summarizes a record creates one kind of risk. A system that edits the record, sends the customer a message, approves a payment, or triggers an order creates another.
We would not give an early system broad authority just because the demo handled five clean examples.
Start with the smallest useful permission. Let the system draft before it sends. Let it recommend before it changes. Require human approval for high-impact actions. Log what it used, what it proposed, who approved it, and what happened next.
Also plan for recovery. If the input is wrong, can the action be stopped? If a duplicate event arrives, will the system act twice? If an integration is unavailable, does the work wait safely or disappear?
A custom AI system should have boundaries that match the consequence of being wrong. Autonomy is earned through reliable behavior, not granted on day one.
4. The integration problem wearing an AI costume
Sometimes a company asks for a new AI platform when the actual problem is that two existing systems do not share information.
A person downloads a file from one tool, cleans it, uploads it to another, then sends a message so the next person knows it is there. The pain is real. The missing piece may be an integration, not a model.
That is good news.
If a dependable rule can move the right data to the right place, use the rule. If a direct connection can remove the duplicate entry, build the connection. Add AI only where the workflow requires interpretation, judgment support, or work with unstructured information.
Our workflow automation approach starts with the handoff for this reason. The goal is not to maximize how much AI appears in the architecture. The goal is to remove the friction with the least complicated system that can do the job safely.
Do not buy a new platform to avoid understanding the stack you already have.
5. The hardest problem first
The first project is sometimes asked to solve everything at once.
It will connect every department, interpret every document, make every decision, and replace a process nobody has measured. It may also touch the highest-risk work in the company.
That is not a first project. It is a collection of projects hiding inside one sentence.
Ambition is useful. Sequence matters.
Choose one recurring workflow with a clear owner, accessible inputs, a visible result, and safe exception handling. Run it on real examples. Compare the output with the current process. Let the people doing the work show you what the design missed.
Then expand from proof.
The hardest problem may still belong on the roadmap. A smaller first build creates the operating knowledge, trust, and technical foundation needed to approach it responsibly.
A good no creates a better yes
We are not interested in talking a company out of using AI. We are interested in keeping a promising idea from becoming an expensive distraction.
No named outcome means define the result. No documented process means map the work. Unsafe access means narrow the permissions. An integration problem means solve the handoff. The hardest problem first means find the proof that earns the next step.
These are not dead ends. They are design decisions.
The right project starts when the team can name the work, the boundary, the owner, and the evidence that it helped.