Why most AI pilots in Indian companies stall after the demo

The demo went well, and then nothing happened

Most AI pilots follow the same arc. Someone senior sees a demo. A vendor, or an enthusiastic person in the IT team, shows a model reading a scanned invoice, drafting a reply to a customer or summarising a forty page agreement. It is impressive, and a pilot is approved. Six weeks later there is a slide deck, a shared folder of test outputs and a meeting where everyone agrees it was "promising". Then the pilot quietly stops.

Nobody cancels it. It simply loses its place in the queue behind GST filing, the quarterly audit and the new branch opening. Three months later, someone asks what happened to the AI project, and the answer is that it never became anyone's job.

This is common in Indian companies of every size, from a family run distributor to a listed NBFC. The reasons are rarely about the model. They are about data, ownership, process and money, and almost all of them are visible before the pilot starts if you know where to look.

What a demo actually proves

A demo proves that a model can do a task once, on inputs someone chose, with a person watching. That is worth knowing. It does not tell you:

• whether it can do the task on the inputs your business really produces, including the blurred photo of a delivery challan sent on WhatsApp at 11 at night
• who checks the output, how long that takes, and whether checking is faster than doing the work by hand
• what happens when the model is wrong, and who notices
• where the result goes next: into Tally, into the loan management system, into a ticket, or into someone's inbox where it waits
• what it costs per transaction once usage is real and not a few hundred test runs

A pilot exists to answer those questions. Most pilots are set up to answer the demo's question again, at slightly larger scale.

Five reasons pilots stall

1. The pilot has no owner inside the business

The most reliable predictor of a stalled pilot is that the person who wanted it is not the person whose work it changes. A CFO asks for invoice matching. The accounts team, who will live with it, were not in the room. When the pilot needs their time to label examples, review outputs and explain exceptions, that time is not available, because month end is coming and month end always wins.

A pilot needs a named owner in the team whose work it touches, with a few hours each week set aside for it. Not a sponsor. An owner. Someone who can say "this output is wrong, and here is why" and who will be measured on whether the thing works.

2. The data is messier than anyone admitted

Demos use clean examples. Real data in Indian businesses is shaped by years of practical workarounds. Supplier names are spelt three ways in Tally. Purchase orders are raised after the goods arrive. Half the vendor invoices come as PDFs, a quarter as photos and the rest as Excel files with merged cells. In a hospital, discharge summaries follow one template in the cardiology department and a different one in orthopaedics, and some are still typed by a resident who prefers capital letters.

The response is to look at a few hundred real records before the pilot is scoped, and to budget time for cleaning and mapping. If the data is not ready, the useful thing to say early is "the data is not ready, and here is what fixing it involves". Saying it in week five is how pilots die.

3. Nobody designed the review step

Every useful AI system in a business has a person somewhere in the loop. The question is where, and how much of their day it takes. Pilots often skip this design work. The model produces outputs, someone looks at them in a spreadsheet, and the team concludes it is "about 80 percent right" without knowing what that means for the work.

Eighty percent right can be excellent or useless. If the 20 percent that is wrong is flagged clearly, and a person can fix each case in thirty seconds, you have saved most of the effort. If the wrong cases look exactly like the right ones, so every output must be checked from scratch, you have saved nothing and added a step.

Good pilots design the review screen early. What does the reviewer see? What does the agent say about its own confidence? Which cases go straight through, which need a glance and which need a decision? This is ordinary process design, and it matters more than which model you use.

4. It never connected to the system of record

A pilot that ends in a spreadsheet is a research exercise. Real work happens in systems: Tally or SAP for accounts, a loan management system for an NBFC's collections team, a hospital information system, a CRM, a ticketing tool, the WhatsApp Business account. If the AI output has to be copied by hand into one of those, people will try it for a week and then go back to the old way, because the old way has fewer steps.

Integration is usually where the real cost sits, and it is often left out of the pilot to keep it cheap. That makes the pilot easier to approve and almost impossible to turn into production. It is better to integrate with one system properly, even in a narrow way, than to demo against five systems with no connection to any of them.

5. Nobody worked out the cost per transaction

Model usage is cheap at pilot scale and becomes a line item at production scale. A support agent answering a D2C brand's WhatsApp queries might handle a few thousand conversations a day during a sale. Each conversation might involve several model calls, a lookup in the order system and a knowledge search. Multiply that out and compare it with the cost of the current process, including the people who check the agent's work.

Sometimes the numbers are clearly good. Sometimes they only work with a smaller model for routine cases and a larger one for hard ones. Sometimes they do not work at all, and it is much better to find that out in week two than after a launch.

What a pilot that survives looks like

The pilots that make it to production tend to share a few features.

It starts with one named process

"Try generative AI in finance" is an ambition. "Match supplier invoices to purchase orders and goods receipt notes for our top 40 suppliers, and send mismatches to Priya for review" is a pilot. A distributor in Rajkot with a few thousand invoices a month can describe exactly what the team does today, how long it takes and where it goes wrong. That description is the specification.

It has a measurable before

Before the pilot, write down how the work is done now. How many invoices, tickets or summaries per week. How long each takes. How many come back with errors. You do not need precise figures, just honest ones. Without a before, the after is a matter of opinion, and opinions are easy to ignore when budgets are set.

It defines what the agent must never do

Write the limits down first. The agent may draft a reply but never send a refund. It may suggest a ledger entry but never post it. It may summarise a discharge note but never change a dosage. It may remind a borrower of a due date but never threaten or misstate the amount. These limits shape the design, make the review step obvious and give the compliance team something concrete to approve.

It runs on real volume for long enough

Two weeks of real work tells you more than two months of test cases. Run the pilot on live inputs, with outputs reviewed before they take effect, through at least one busy period. For a finance team that means a month end. For a school group's admissions office it means the weeks when enquiries peak. For an NBFC's collections team it means the first ten days of the month.

It ends with a decision

Agree at the start what the pilot must show to go ahead, what would mean adjusting the scope and what would mean stopping. Then hold the meeting and make the decision. Stopping a pilot that did not work is a good outcome. It is far better than an indefinite pilot that consumes attention and teaches the organisation that AI projects never finish.

The trade offs

Narrow pilots succeed more often but impress less. A tightly scoped invoice matching agent that handles one supplier group well will not excite a board the way a general "finance copilot" demo does. It is, however, the thing that gets used.

Integration makes a pilot slower and more expensive to start. Skipping it makes the pilot faster and much less likely to matter.

Keeping a person in the loop reduces the efficiency gain. Removing them increases the risk. For most Indian businesses in 2026, the right answer is to keep a person approving anything that moves money, changes a record of a customer or patient, or goes out under the company's name, and to let the agent handle the preparation work around those decisions.

Building on a platform is faster than building from scratch, and less flexible at the edges. For most first pilots the speed matters more. For some integrations you will still need engineers, and it is worth knowing which those are before you start.

A simple checklist before you approve the next pilot

• Is there a named owner in the team whose work changes, with time set aside each week?
• Has someone looked at a few hundred real records, not a curated sample?
• Is the review step designed: what the reviewer sees, and what goes straight through?
• Does the output land in a real system, even in a limited way?
• Is there a rough cost per transaction at production volume?
• Are the agent's limits written down and agreed with whoever owns risk?
• Is there a date for a go, adjust or stop decision?

If most of these answers are yes, the pilot has a good chance. If most are no, the demo was the easy part, and the hard part has not started yet.

If you have a process in mind and want to test it against this list with someone who has built these systems, talk to us.