By KYN AI Advisory Team — AI implementation specialists, Singapore
Most SME AI pilots do not fail on the technology. They stall because nobody owns the result, nobody measured the starting point, the data was worse than assumed, the approvals clog, or no one is left to change the system once the pilot team moves on. All five are operating problems with operating fixes. This article names each, says how to spot it by week six, and gives the countermeasure.
Fact: we have no study to cite, and we do not state a failure rate. This is our judgement from building and running systems, and from the patterns we see when clients describe earlier attempts. Treat it as a diagnostic list, not as research.
Why do pilots stall at about 90 days?
A pilot has a built-in clock. The first 30 days are novelty: a demo works and people are interested. Days 30 to 60 are integration: the system meets real data and real exceptions. By day 90 the question changes from "does it work?" to "does anyone depend on it?". If no one does, there is no pull, and the pilot fades.
That is the pattern: the system is not rejected; it goes unused. The causes below explain why.
Cause 1: Nobody owns the outcome
A pilot started by "the team" belongs to nobody. A named person owns a workflow, the system's result in it, and the decision to keep or kill it.
- Sign: questions about the system wait days for an answer.
- Fix: name one owner per workflow before the build. Give them time: a few hours a week for review in the first quarter.
An owner who is also the busiest person in the company is a poor choice. Pick someone for whom this workflow is their job.
Cause 2: There was no baseline
If you do not know the starting hours, errors or delay, you cannot show an improvement. At day 90 someone asks "is it worth it?" and the answer is a feeling.
- Sign: the success measure is "it seems faster".
- Fix: before the build, record two or three numbers from the old process over four weeks. Hours per week on the task. Errors found per month. Days from request to response. Re-measure at day 60 and day 90.
A simple log beats a good guess. The baseline is also what you take to a grant application or a board.
Cause 3: The data was worse than assumed
Pilots use sample data. Production data has duplicates, missing fields, odd spellings and files in three formats. The first weeks of real use expose it.
- Sign: many items are routed to "needs a person" for data reasons, not judgement reasons.
- Fix: test 50 real records before building, and treat cleaning as part of the project with its own time. See the AI readiness checklist.
One hard rule: do not let the AI hide bad data. A system that fills a gap with a confident guess produces output that looks fine and is wrong. Better to flag the gap.
Cause 4: The approvals clog
A system that drafts needs a person to approve. If the queue grows faster than the reviewer clears it, output piles up, and the benefit disappears.
- Sign: drafts older than a day, and a reviewer who approves in bulk without reading.
- Fix: review the gate design. Keep approvals for outbound messages, money, filings and deletions. Remove them from low-consequence steps. Put the evidence beside the draft. Name a backup. See where to place approvals.
The opposite error is also common: skipping approvals to look fast. That works until the first wrong message reaches a customer, and then the pilot is stopped by management.
Cause 5: No one can change it
Business rules move. A supplier changes its invoice layout. A new product line needs a new category. A form gains a field. A system with nobody assigned to change it becomes wrong slowly, and people stop trusting it.
- Sign: a list of small requests that nobody works on.
- Fix: budget for change from the start. For a build, that is the monthly retainer: changes, monitoring and fixes. For an in-house team, it is a named maintainer with hours set aside.
Treat a pilot as the first release, not as a finished product.
What else goes wrong?
Two further causes appear less often but are worth listing.
Scope too wide. A pilot that tries to cover sales, finance and operations at once ends with none of them working. One workflow, end to end, teaches more than ten half-built ones.
Wrong first workflow. A workflow where the cost is not visible gives no pull. Choose one where someone already feels the pain: late replies, overdue invoices, month-end reconciliation, a report that eats Monday morning.
What does a pilot that survives day 90 look like?
It has these features by week six:
- an owner who uses it weekly;
- a baseline and a second measurement;
- a short list of change requests being worked;
- a log that shows what the system did and who approved;
- a reviewer who clears the queue in minutes;
- a decision date, already in the diary, to keep, change or stop.
None is difficult. They are a matter of discipline early.
Should you run a pilot at all?
Often a pilot is the wrong shape. A pilot is a throwaway test; a first release is the start of the system. If you already know the workflow and the tools, build the first release properly: in your own cloud account, with named access and logging, so the work is kept. A throwaway pilot on a vendor's platform has to be rebuilt later.
Use a short pilot when you genuinely do not know whether the idea works, for example whether a model can classify your customers' emails correctly. Answer that with a one-week test on 100 real records, and then decide.
Where KYN fits
KYN builds the first release as a real system, not a demo. The first 14 days are a review of your stack and interviews with your team, which sets the owner, the baseline and the scope. A full build ships in under 90 days. After that, a monthly retainer of at least twelve months covers changes, monitoring and fixes, which answers cause five directly.
Everything runs in a cloud account in your name. Rights in the custom code and configuration pass to you on full payment, and you can revoke KYN's role while everything keeps running. Every action is logged with the actor, and outbound messages, money, filings and deletions wait for a named person. See operations and pricing.
Frequently asked questions
How long should an AI pilot run?
Long enough to see real data and real exceptions, which is usually several weeks, and short enough that a decision date is not forgotten. Set the date at the start, with the measures you will read.
Who should own an AI project in a small company?
The person who runs the workflow it changes, not the IT contact and not the founder by default. They need authority to change the process and time to review output.
Is a stalled pilot a sign that AI does not suit my business?
Not by itself. Check the five causes first. Most stalled pilots show at least one, and each can be fixed without changing the technology.
Checked 30 October 2026.
Curious whether Marketing agents fits your business? Talk to KYN on WhatsApp — no forms, just a conversation.
