Can AI Help Your UAE Business Predict What Happens Next?

Predictive analytics for UAE SMEs used to mean hiring a data scientist. A manager can now attempt it with an LLM, if they can define the question and check the answer.

By Farshad Naderi
A manager at a desk in a Dubai office considers a glass panel showing business records feeding a model, a forecast with a widening uncertainty band, and a human review step.

Yes, for a bounded, measurable question. Predictive analytics for an SME in the UAE used to require a data scientist to build the model. Now a manager with relevant historical data can use a large language model (LLM) to prepare data, write code and test a model. The skill that matters has moved: ask the right question, understand what the LLM is doing and check its answer. Bring in an expert when the stakes are high.

This is my reasoned view, not an established finding. I found no study of small-business managers using an LLM to build a model for a live decision.

What has changed in predictive analytics for UAE SMEs

Every business makes decisions about things it cannot yet see: when an invoice will be paid, how much stock to order, which customers may leave, which leads deserve the next call. A predictive model estimates a defined outcome, amount or time from past records. Building one used to mean hiring a data scientist or a consultant, a cost that could be hard to justify for a single stock or follow-up decision.

You can now describe a task in plain language, and an LLM can clean a file, write the code, fit a model, read an error message and explain the output.

The bottleneck has moved from writing code to defining the question and checking the answer.

Three things stay with you:

  • Asking the right question: which decision, which outcome, measured when.
  • Understanding what the LLM is doing: what a baseline is, why later data matters and what it means for a model to cheat. You do not need to write the code.
  • Checking the answer, because an LLM can be wrong and sound certain.

This is not spreadsheet work, and it does not make every project feasible. The opposite mistake is just as easy: asking a chatbot what will happen and treating a confident paragraph as a forecast. A text answer is not a tested estimate based on your business history.

Five checks before you rely on a prediction

At each check, the LLM can do part of the work and you do the part it cannot.

Five connected questions guide a business prediction: define the decision, check what data is known at that time, compare with the current method, test on later data, and consider a limited pilot. An LLM assistance band lists preparing data, drafting code and supporting evaluation.

CheckWhat the LLM doesWhat you check
1. Define the decisionChallenges a vague target and suggests measurable versionsThe decision is yours. If a better estimate would not change what anyone does, stop here
2. Check the data and its timingFinds missing values, duplicates and inconsistent labels, and writes the cleaning codeWhen each field is really filled in, and how the process has changed
3. Set a simple baselineCalculates the baseline and drafts the comparisonThe baseline is what your team really does, measured against the capacity it really has
4. Test on later dataWrites the chronological split, fits the model and runs the comparisonWhen each input becomes known, and that the numbers come from code that actually ran
5. Make a proportionate decisionDrafts the pilot plan and a monitoring reportThe decision to continue, and its consequences

Two of these deserve more attention.

The target must be something you can check. “Customer quality” is too vague. “Attends at least one viewing within 30 days of initial qualification” can be checked against a record. The outcome window must begin after the moment the estimate would be made.

The model has to beat what you already do. Train with older records and evaluate on a later period that was not used to build it. Compare it with the existing queue, a basic rule or a simple forecast. Forecasting research warns that a model can look strong because it was evaluated in a way that favours it. Applying that habit to a business decision is my inference: a model must earn its place against the process already in use.

A hypothetical example: the result that looked too good

This is a teaching example, not a real company.

Imagine a real-estate business in Dubai that receives more enquiries than its team can call immediately. At the end of a standardised initial qualification, it wants to estimate whether each new lead will attend at least one viewing during the following 30 days. A booked viewing and an attended viewing are different outcomes; the target here is attendance.

The manager removes names, contact details and free-text notes from the lead records, then asks an LLM to review the columns before writing anything. The team lists only fields available at scoring: enquiry source, property needs and stated buying timeline, if reliably recorded. The LLM writes a script that trains on earlier records, evaluates on a later period and compares the model with the current queue.

A hypothetical teaching example shows information available at the end of initial qualification feeding a predictive model. At the scoring point, the model produces an illustrative ranked lead list for human review. Only after that point does the next 30-day outcome window begin, where attendance at a viewing is recorded. A booking is not attendance.

Now suppose the first run looks excellent. The manager reads the inputs and finds “number of calls made”, a field the LLM had included. Calls happen after scoring, and leads who come to viewings may receive more of them, so the model has been given a clue about the answer. The manager asks the LLM to remove the field and run the test again. The score falls, and the new result is the honest one.

The manager wrote no code, but knew what the question was and when each piece of information exists.

The LLM did the technical work; the judgement that caught the error was human.

No accuracy, conversion lift or probability can be claimed until a real dataset has been tested.

A high score does not tell you what to do

Suppose the corrected model ranks some leads above others. That ranking estimates the likelihood of the outcome under patterns in the historical data. It does not show that a higher-ranked lead will respond to an extra call, or that the call caused attendance.

Prediction and intervention are separate questions. Assess the value of the action separately, with an appropriate comparison where practical.

What the evidence supports, and what it does not

The evidence supports the direction of this argument, with one important warning. No study I found tests the exact case in this article, and none of the studies below is specific to UAE businesses.

The closest evidence is a randomised experiment published by BCG in 2024, run with Boston University scholars and OpenAI's economic research team. It assigned 480 general consultants to work with or without ChatGPT-4's data-analysis feature, using 44 BCG data scientists as a benchmark. On a coding and data-cleaning task, consultants with the tool reached 86% of the benchmark, against 29% without it, and those who had never coded reached 84%.

Predictive modelling was different. It was the task on which they were least likely to match the data scientists, and those using the tool were more likely to be led astray, although they were also 15 percentage points more likely to apply machine-learning methods appropriately. Doing the tasks with the tool did not increase their knowledge. These were consultants on 90-minute tasks with an earlier model, and the study was published by the firm that ran it.

A 2026 study gave eight LLMs detailed instructions to write code for four prediction tasks from pregnancy-research competitions. Four of the LLMs completed at least one task. The best resulting models performed about as well as the median competing team on all four tasks and beat the top team on one, while the top teams were significantly better on two others. The prompts were precise and the data were tables with no missing values, which is rarely true of business records. The authors say such models still need human oversight.

A small laboratory experiment on descriptive analysis found that experts scored only slightly higher than novices overall, although novices fell well behind on the hardest task. Its authors concluded that the tools are not yet ready to fully support non-experts, and that using them well requires domain knowledge, clear and unambiguous questions and the ability to evaluate and check the answers. It had no control group and did not test predictive modelling.

Benchmarks show why review still matters. In MLE-bench, the best setup reached at least a bronze medal in 16.9% of 75 Kaggle competitions. In ScienceAgentBench, the best agent solved 32.4% of 102 scientific tasks independently. Both tested older models, and neither is a success rate for a small-business manager.

When to stop or bring in an expert

There is no universal minimum dataset size. The number of records, the frequency of the outcome, data quality and the ability to hold out a later period all matter. Past patterns can change too, and even a later-period test cannot guarantee performance after future changes.

Improve the records or stop the test if the outcome is inconsistently logged, the process has changed, or later information cannot be separated.

Involve an appropriate specialist before using the result where privacy, discrimination or material financial consequences are involved, or where the team cannot protect the data and review the method properly. Sensitive decisions should not be automated simply because a score is available.

How to start

  1. Write one decision card. State who will use the prediction, when they decide, what action could follow and the exact outcome and time window.
  2. Map the data. List permitted fields, when each is created and where the outcome is recorded. Use only an environment approved for the data, and keep personal details and free-text customer notes out of unapproved tools.
  3. Start the LLM on a bounded task. Begin with the column list and fully synthetic rows if real data is not ready. Synthetic rows can help you draft code; they cannot validate performance.
  4. Agree the test before running it. Record the current process as the baseline, train on older data, evaluate on a later period and exclude anything recorded after the decision point. A score the LLM states without running anything is not a result.
  5. Pilot only if the comparison earns it. Keep human review and the normal process in place, name who can pause the pilot, and monitor what happens.

For the related question of where to begin with AI at all, see why the workflow comes before the tool and what becoming an AI-native company involves.

Frequently asked questions

Can I start with my existing spreadsheet or CRM?

Yes, an approved export or a well-structured spreadsheet can be enough to explore the question. Check that fields have consistent meanings, their recording times are known and the outcome is complete. A new database is not the first requirement; reliable definitions are.

Can a UAE SME use predictive analytics without a data scientist?

Yes, for a limited, low-stakes test. You need to read what the LLM did and question it, without necessarily being able to write it yourself. Get expert help when modelling choices, data quality, privacy, deployment or the consequences of error exceed what you can check.

How much data is enough?

There is no single number for every problem. It depends on how often the outcome occurs, whether the records cover varied conditions, how complete they are and whether a later period can be reserved for evaluation.

How do I know if the model is worth using?

Define the current approach as a baseline before building. Test on later data, inspect errors and use a measure that reflects the actual decision and operating capacity. One accuracy figure alone is not enough.

A practical resource

Get the article PDF

Register with your email and we will send the download link to your inbox.

Continue exploring

Related perspectives

More practical thinking for founders, investors, and operating teams.