AI is not delivering results in most companies because it was bolted onto processes designed for how work was done before: scattered information, rules that live in people's heads, messy data. Factories that put an electric motor on the old central shaft gained little for decades. The gains came once they rebuilt the floor around the task. AI follows the same rule: rewire the process first, then plug in the tool.
In September I sat down with Marius Ciurariu and Emil Muthu on the REWIRED podcast, and a good part of the conversation was about exactly this question. Below are the seven reasons I think matter most, each with its fix, followed by the podcast excerpts they rest on, each linked to its moment in the video.
What are the 7 reasons AI isn't delivering results?
In short: almost none of them is about the model. They are about the process, the data, and who decides what "correct" means.
1. AI was bolted onto the old process
The first instinct is to keep the building and change the engine. The electric-motor comparison works because both technologies produce work: a motor produces physical work, a language model produces cognitive work. What does a central shaft look like in an office? It is the point everything has to pass through: the spreadsheet only one person understands, the approval that waits in a manager's inbox, the customer email forwarded three times before anyone answers it. Put a language model next to that shaft and it will read faster than anyone in the building. It will not move the shaft.
The fix: ask a plainer question than "which tool?". If this task were designed today, around what can now be automated, what would it look like? Sometimes the answer is a smaller change than people fear. Sometimes it removes a step that only existed to feed the old one.
2. The information the system needs doesn't live in one place
Take a typical vendor data table. It has merged cells, so it reads well for the person looking at it. That is not a mistake: the document was designed for a human reader, which was the right design for the old process. The real trouble is elsewhere: part of that table gets filled in by phoning the warehouse, and, when the warehouse does not pick up, by phoning the client. No model fixes that.
The fix: a map before any code. Where each piece of information is born, who changes it and where it ends up. When that map fits on one page, automation is usually the easy part. When it does not, the map is the project.
3. The rules live in one person's head, and exceptions are handled by phone
A process that was never written down cannot be handed to a system. The person who does it knows the rules, knows the exceptions and knows whom to call. The system knows none of that.
The fix: three questions usually reveal the central shaft:
- Where does the information for this task live, and how many places is it copied to?
- Which rules are written down, and which live in one person's head?
- What happens to the exceptions, and who decides them?
4. The data is messy, and AI amplifies the mess
A model optimises towards the objective it is given, using the material it is given. It does not know that two of your rules contradict each other. It will satisfy whichever one the context makes more likely, with full confidence, a thousand times a day. A person doing the job by hand absorbs the mess without noticing. A system amplifies it.
The fix: clean the data the system will read before any model is chosen, not after. What that means for invoices, accounting exports and display spreadsheets is in what to change in your business before you use AI.
5. Nobody decided what a correct result looks like
If the company and whoever builds the system never agreed on the rules and on what counts as a good result, nobody can say whether the AI works. What remains is an impression, and impressions do not survive the budget meeting.
The fix: write down, before the pilot, what a correct result looks like for the chosen task, and check the pilot against that standard on real cases.
6. The company expects the AI to "figure it out"
That is also why I am wary of offers that promise the AI "will figure it out". It will figure out something. Whether it is the thing you meant depends on work done beforehand.
The fix: treat that work as falling on both sides of the table. The builder has to understand the process, and the company has to explain it, which is harder than it sounds when the process was never written down. Someone inside the company has to own that explanation; I wrote about who in how to structure your company for AI.
7. You started with a tool, not a process
And often you are waiting for a tool that makes the rewiring unnecessary. That tool does not exist. I think this is also where many pilots stall before production: the pilot looks good in the demo, but the process around it is unchanged and nobody measured how long the work took before.
The fix: start with one process that costs you something every week and that people already complain about. Map it, write down its rules, measure how long it takes today, and only then ask which part can be automated. I wrote the longer version as a step-by-step guide to implementing AI, and Sapio has a guide on how to run an AI pilot before you scale. If it is unclear whether your process needs an agent or plain automation, I explained the difference in what is an AI agent.
What did I say on the REWIRED podcast, and what would I correct today?
The reasons above come from the part of the conversation I keep coming back to. The excerpts come from YouTube's automatic captions, lightly edited for reading, and each one links to its moment in the video. In two places I correct what I said.
The electric motor (reason 1)
Factories before electric motors had steam engines. A steam engine isn't efficient to have many of, so they had one central shaft that would rotate through the whole factory, and every machine connected to that shaft. That one thing powered everything. Then they had the electric motor. They simply swapped the steam engine for the electric one on this central shaft [...]
On air I put a number on the lag and said nothing improved at all. Both were loose. Paul David, the economic historian who made this comparison famous in The Dynamo and the Computer (1990), describes a lag of roughly four decades, with slow gains rather than none. The shape of the story holds: electric power reached the factories long before productivity followed it.
What changed, and this is the comparison I wanted to show: they realised electric motors can be reconfigured for every task. So they rebuilt the factory. They redid the setup of the factory so that it was centred on the task. [...] What do we learn from this for businesses that want to implement AI? You cannot implement AI without rewiring your own processes.
The merged cells (reasons 2 and 3)
If they want to automate a table where all the data comes in from the vendors, and I say, okay, let me look at that table, I can bet that table has merged cells somewhere in it, so that it makes more sense visually for the person looking at it.
That is why I think the first deliverable of an AI project should not be code. It should be the map from reason 2.
Trash in, trash out (reason 4)
AI can do a ton of stuff, but you have to feed it good material. Trash in, trash out. It's a maximizer. If you're feeding in an unstructured process, conflicting rules and messy data, it will be bad.
"Maximizer" was a quick word, and I would sharpen it: a model does not maximise the mess of its own accord; it optimises towards the objective it is given, with the material it is given. The effect is the one in reason 4: the system amplifies what a person would have absorbed.
Small companies (reason 7)
What I think is that in the future we'll be looking at large companies being undercut by small companies that go 100% AI-first. You see this in tech products: startups run much faster in development than big companies, and the big dogs usually wait for the market to settle.
One of the hosts made the better half of this argument just before: a small company can change a process in a week, while a corporation needs the agreement of everyone who owns a piece of it. Small firms have fewer processes written down, but they are far cheaper to rewire.
The numbers say that advantage is mostly unused. In 2025, 19.95% of EU enterprises with ten or more employees used at least one AI technology, and Romania came last at 5.21% (Eurostat). In the episode I put the EU average lower; the 2025 figure is the one above. Inside Romania the gap sits with the smaller firms: 4.1% of companies with 10 to 49 employees used AI, against 20.8% of those with 250 or more (Eurostat, AI key results 2026).
I still think the small company has the better starting position. It just has to stop waiting for a tool that makes the rewiring unnecessary.
The full conversation, including how ai-aflat.ro started and how I would get a sceptical developer to try AI, is on YouTube.
So where do you start?
With the process that costs you most every week, not with the tool everyone is talking about this month.
The electric motor was never the hard part. It was available and it worked. The hard part was agreeing to move the machines, and I suspect that is still where most of the gains are waiting.
If you want to look at one of your own processes this way: AI consulting.