Ask around the UAE market and almost every company of any size will tell you it has tried something with AI. A chatbot. A summarisation tool somebody in marketing pays for monthly. A proof of concept a vendor built, demoed once, and never mentioned again.
Ask what is running in production, who owns it, and what changed as a result — and the room goes quiet.
This is not a UAE problem specifically, but it is worse here than in smaller markets, because there is enough budget to keep starting things. The failures are remarkably consistent. In my experience they cluster in four places, and the model is not one of them. Getting past them is most of what my AI consulting work actually consists of.
1. The process was chosen because it was interesting
Almost every stalled pilot I have looked at automated something visible rather than something expensive. A customer-facing chatbot is exciting and demos well to a board. It is also the hardest thing to get right, has the highest cost of being wrong, and usually is not where the money is leaking.
The processes worth automating first are dull: quote preparation, document intake, reconciliation, first-line internal support, tender paperwork. They have volume, they have rules, someone can tell you what an error costs, and there is a named person who wants it fixed.
If nobody in the business can tell you what the current process costs per month, you are not ready to automate it. You are ready to measure it.
2. It was proved on the vendor’s data, not yours
A model that scores well on a clean sample will meet your abbreviations, your scanned PDFs, your supplier names in three spellings, your bilingual documents, and the exception that accounts for nine per cent of volume and was never written down.
Test on your own material before you sign anything. Not a curated set — a random slice of last month, including the ugly ones. If the vendor resists this, that is the answer.
Arabic deserves its own test. Most tooling is built and benchmarked in English, and performance on Arabic — especially with dialect, transliterated names or mixed-script documents — is often materially worse. A system that will meet Arabic in production has to be tested in Arabic before it goes live, not translated afterwards. The same principle applies to websites, and Arabic-second always shows.
3. It was shipped somewhere nobody goes
This is the quietest killer. The pilot works, the numbers are good, and it lives in a separate portal that the team has to remember to open. Adoption dies within a fortnight.
Whatever you build has to appear inside the tools the work already happens in: the CRM, the inbox, the WhatsApp thread, the ERP. If your team has to change where they work in order to use it, they will not use it.
4. Nobody was given ownership
Ask who can change a prompt, read the logs, and switch the thing off. If the answer is the vendor, you have rented a capability rather than acquired one. When the contract lapses or the consultant moves on, the system quietly rots — and because it never visibly breaks, nobody notices for months.
Before any of that, settle what happens to the data — what the UAE PDPL asks of you before you connect a model is the checklist I use. Handover is not documentation. It is somebody on your side who has made a change, watched what happened, and knows how to undo it.
What a project that reaches production looks like
Boringly, it looks like this: one process, chosen because it costs money; tested on real data including the exceptions; shipped into a tool people already open; owned by a named person who can turn it off. Six weeks, not six months. Then the second one.
The companies here that are getting real value from AI are not the ones with the most ambitious roadmap. They are the ones that finished something small, and then did it again. Often the first thing worth finishing is not AI at all but the data underneath it, which is why e-invoicing is quietly an AI-readiness project.
What the four have in common
Read them together and the pattern is not technical. Every one of the four is a decision about the business that was quietly delegated to whoever was closest to the technology.
Which process to automate is a question about where the money and the friction actually are. Whose data to prove it on is a question about whether your reality resembles the demo. Where to put it is a question about how your people already work. Who owns it is a question about accountability. None of these is a modelling problem, and none of them is answered by a better model.
That is why the pilots keep failing in the same places while the technology keeps improving. The part that fails did not get better, because nobody was working on it.
What to do with a pilot that has already stalled
Most companies reading this are not deciding whether to start. They have three or four pilots in various states of abandonment and a growing suspicion that AI is oversold.
The useful exercise takes an afternoon. List every pilot. For each one write down, in a sentence, what process it touched, whose data it was proved on, where it runs, and who owns it. Anything you cannot answer is the reason it stalled, and it will be one of the four.
Then be willing to kill most of them. A pilot that touched an interesting process nobody is paid to improve is not salvageable by adding effort; it was aimed at the wrong thing. The one worth restarting is usually the least exciting on the list — the one attached to a process someone complains about every week.
The failure that is genuinely worth fixing rather than abandoning is the third one. Something that works but sits in a tool nobody opens is a distribution problem, not a capability problem, and distribution problems are cheap to solve compared with everything else on this page.
The order that actually works
Pick the process by cost and frequency, not by interest. Prove it against a month of your own real data, including the messy records you would not put in a demo. Ship it where the work already happens rather than behind a new login. Name an owner before it launches, not after. Then measure the thing you claimed would improve, and be willing to publish the number internally whether or not it flatters the project.
None of that is novel and none of it is difficult. It is simply the part that gets skipped when the interesting question is which model to use.
Getting a pilot to production is a different discipline from starting one, and it is what my company is built to do: AI agents and automation at Tothiq.
Frequently asked questions
How long should an AI pilot take before we know whether it works?
Weeks, not quarters, for a single well-defined process. If it is taking longer, the delay is almost never the build. It is waiting for access to a system, or discovering that nobody agrees on how the process actually runs today. Both are worth knowing early, and both are cheaper to surface in week one than in month six.
Do we need to replace our existing systems first?
Very rarely. Most of the value comes from connecting what you already have. Replacing a core system in order to enable an automation is the priorities inverted, and I will argue against it unless that system has reached end of life for reasons of its own.
Our vendor demo was impressive. Why would it not survive contact with our data?
Because a demo dataset is chosen to be clean and representative, and yours is neither. Real records carry inconsistent naming, half-filled fields, exceptions somebody made three years ago, and Arabic and English mixed in the same field. None of that is a criticism of your data; it is what operating data looks like everywhere. The point of proving it on your own records is to find out which of those actually matters before you have paid for the rollout.
Does this mean cutting headcount?
That is your decision rather than a technical one, and it deserves to be clear internally from the start. In most projects I see the effect lands on capacity rather than headcount: the same team absorbs more volume without quality falling over. Teams told the truth early cooperate. Teams that suspect a hidden intention comply on paper and guarantee the failure quietly.
Who should own an AI project inside the company?
Whoever owns the process it touches, not whoever owns the technology. If the automation handles supplier invoices, it belongs to finance with technical support, not to IT with finance consulted. Ownership by the technology function is the most common version of the fourth failure, because the technology function cannot decide what the output is supposed to be worth.
A question worth asking in your next vendor meeting
“Which of your UAE clients has this in production today, and can I speak to the person who owns it?” It is a simple question and it ends a surprising number of conversations.