Why AI Adoption Fails in Saudi Companies (Research)

AI adoption can disappoint for different reasons: the capability may not meet the task, people may be unable to use it in the intended work, or the resulting improvement may not justify its full cost. Explaining a particular outcome requires evidence about that initiative. A striking failure percentage from another population cannot supply the explanation.

For a Saudi executive, the useful research question is therefore precise: which outcome was observed, among which initiatives, over what period, and what supports the proposed cause? Answering it separates an avoidable delivery problem from an appropriate decision to stop, and an immature pilot from a completed investment that missed its objective.

This guide, within the Saudi AI authority collection, examines published evidence and develops an original research-reading method. It does not report an Open for AI survey or estimate a national company failure rate. The worked portfolio below is entirely fictional and is used to make denominator and timing errors visible.

Define failure before explaining it

Write the promised outcome in observable terms. A document assistant might need to preserve specified information, support regular use in an approved workflow, and improve a business measure after review costs. These are separate claims. A convincing demonstration establishes none of the later outcomes automatically, while a weak financial result does not by itself identify a model defect.

Specify the decision rule before inspecting the outcome. If success originally meant an accepted operational service, changing it afterwards to a completed workshop hides a change in objective. A revised objective can be reasonable, but retain both definitions and explain the decision. Otherwise the apparent evidence describes the reporting process more than the initiative.

Distinguish an experiment from a rollout commitment. An experiment can complete its learning objective by showing that a proposed task is not feasible within the allowed conditions. Record that result alongside its cost and quality of learning. Calling every rejected idea a failed deployment makes a disciplined selection process appear worse than one that launches unsuitable work.

The guide to barriers before AI adoption addresses whether an organisation can begin. Here the concern is the meaning of evidence after a claim is made: readiness, participation, operational acceptance and sustained benefit each require a different observation.

Read Saudi usage statistics at the right level

In its July 2026 release about Saudi Internet 2025, the Communications, Space and Technology Commission reports AI-tool adoption of 45.2% among internet users in Saudi Arabia. The unit is an internet user. It is not a count of company initiatives that reached operational acceptance or achieved an investment return.

A person may use a tool privately, study with it, or use it for part of a work task. A company may operate several initiatives, employ users of consumer tools, and still have an unaccepted internal project. None of these conditions creates a one-to-one relationship between people using tools and business projects delivering their intended outcomes.

Preserve the source's population, question and period when discussing its findings. Replacing “internet users” with “Saudi companies” changes the claim. Subtracting a usage percentage from 100 does not produce a project failure rate. That calculation would describe a different population and an outcome the measure never observed.

Useful national context can still inform a discussion about familiarity or potential exposure. It should sit alongside project evidence, with its own label. This allows the board to acknowledge the wider environment without confusing widespread availability or use with the performance of a particular investment.

Read an interview study by its method

RAND's 2024 study of AI project failure interviewed 65 experienced practitioners. Its method examined failures as perceived by organisations, including technical and business failures. The stated scope excluded projects that simply used pretrained large language models.

The study's interviews provide accounts of mechanisms and experiences. They do not establish a Saudi company failure percentage. Its background also cites an external failure estimate; that estimate should not be presented as a rate measured by the interviews. Distinguish a report's original research from the material it cites for context.

For any interview-based account, ask who can observe the event being discussed. A technical specialist may know the model's behaviour closely but have incomplete visibility of customer value or budget decisions. A sponsor may know the investment case but miss the workarounds used by staff. Combine perspectives around the same episode rather than treating one role as an exhaustive witness.

Qualitative evidence is useful when it identifies a process that can be investigated locally. It becomes weaker when a reader converts a recurring interview theme into a population ranking without the sampling and outcome data needed for that calculation. The appropriate output may be a well-formed question, not a national league table of causes.

A 40-initiative example: one portfolio, several measures

Imagine a fictional Saudi business group reviewing 40 initiative records on one observation date. Eight were declined before a trial began. Twelve remain in active pilots. Ten have been accepted into live operation. Ten are paused after their trials started. Each record appears in exactly one current state; these are invented teaching numbers, not market findings.

Illustrative portfolio states at the observation date

Current state	Records	What the state establishes
Declined before trial	8	The idea did not enter a trial
Active pilot	12	A trial is still being evaluated
Accepted live	10	The defined operational acceptance occurred
Paused after trial started	10	Work is currently paused; its final outcome is unresolved
Total	40	All records in this fictional review population

The accepted-live share of all recorded ideas is 10 divided by 40, or 25%. The share not yet accepted live is 30 divided by 40, or 75%. The second statement is arithmetically correct, but calling it a 75% failure rate adds a conclusion the state information does not support.

There are 32 initiatives whose trials started: the 12 pilots, 10 live initiatives and 10 pauses. The accepted-live share of that group is 10 divided by 32, or 31.25%. This answers a different question from the 25% figure. Neither figure establishes sustained benefit, and neither tells us the final outcomes of the active or paused work.

Choose the denominator that answers the question

Begin with the population relevant to the decision. For idea selection, all logged proposals may matter. For a trial conversion question, use clearly defined trial starters. For operational performance, use accepted services observed over a suitable period. Write the numerator and denominator in words before calculating a percentage.

Keep the counting unit stable. A parent initiative can contain multiple pilots, while one shared service can support several departments. Counting departmental users as separate projects in one period and the shared service as one project in another creates a change that may have no operational meaning.

Assign persistent identifiers and record splits, mergers and closures. A renamed project should not disappear from its original cohort. A useful research table includes both the current state and the history needed to understand how it arrived there. This makes the analysis reproducible when a second reviewer asks to reconstruct the headline.

Give each cohort time to reach its outcome

A snapshot mixes initiatives of different ages. An accepted service may have been trialled months earlier, while an active pilot may have started shortly before the review. Treating both as if they had the same opportunity to finish rewards age and can misrepresent current delivery quality.

Record the relevant starting event and the elapsed observation time. The starting event might be an authorised trial, first operational use or formal acceptance, depending on the question. A funding announcement is not interchangeable with a trial start. Choose one event consistently for the comparison and retain exceptions visibly.

In the fictional portfolio, the paused records need reasons and follow-up before their eventual outcomes can be classified. A pause may become a restart, a closure or a redesigned initiative. Record what is known now and the next observation date. Do not fill an unfinished history with an assumed future failure or success.

This is also why a statement about short-term acceptance should not be presented as long-term return. The AI total-cost guide examines the wider operating period. Evidence about that period requires actual observations or clearly labelled assumptions, rather than an inference from the first successful demonstration.

Trace a cause through competing explanations

Suppose a paused initiative has low staff usage. “Employees resisted AI” is an interpretation, not the observation itself. Access might have been unavailable, the relevant task might occur infrequently, or previous outputs might have required excessive correction. These explanations imply different evidence and should not be collapsed into a claim about employee attitudes.

Build a dated account of one episode: when the capability became available, what work could use it, what users encountered, and when the pause was decided. A proposed cause should precede the effect it is meant to explain. If a team received training only after the project paused, the timing cannot support a claim that the training caused the earlier pause.

Ask what else changed. A more experienced team may have received both better training and easier tasks. Its stronger result cannot automatically be attributed to training alone. A comparison needs relevant similarities, known differences and a credible account of how the alternative condition would have affected the outcome.

Counterevidence is valuable: an initiative with the same suspected weakness that nevertheless met its objective, or one without the weakness that still disappointed. Such cases may reveal an interacting condition or show that the explanation is incomplete. They should improve the hypothesis rather than be removed to protect a convenient story.

Test whether findings transfer to a Saudi company

Describe the local task before borrowing a conclusion. Compare the studied technology, workflow, language, sector, organisation size and outcome with the intended use. A study of training predictive models may raise useful questions for a bilingual writing assistant, but it does not directly measure that assistant's quality or adoption prospects.

Language is an observable design condition. If a workflow crosses Arabic and English records, identify where meaning can change and how users assess the output. The Arabic AI quality guide helps specify that evidence. Treat a local language requirement as a testable characteristic, rather than assuming that country alone explains performance.

Similarly, distinguish an actual applicable requirement from a participant's understanding of it. A reported approval delay may reflect incomplete information, an internal choice or a real obligation. The research record should state which is established. A general reference to regulation cannot identify the causal step that affected the initiative.

The AI literacy guide for leaders supports the vocabulary needed for these comparisons. A useful local conclusion states which mechanism appears relevant, why the cases are comparable, and which uncertainty remains before committing resources.

Include missing cases and quiet outcomes

A supplier's published successes show selected examples, while a troubled-project workshop may attract people with unusually difficult experiences. Both can teach something. Neither should silently stand for all initiatives. Record how cases entered the evidence set and which groups were unable or unwilling to contribute.

Missing outcomes need their own status. If a project owner left and records are incomplete, classify the outcome as unknown until evidence is recovered. Removing unknown cases from the denominator may make the remaining result look cleaner while changing the question. Report their count and explain the consequence for interpretation.

Look for quiet outcomes as well: useful services that attract little publicity, experiments closed appropriately, and projects that remain nominally active without current evidence. A complete record of these states supports a more informative discussion than a collection selected only for dramatic success or failure.

Keep technical, adoption and economic results separate

A model test asks whether outputs meet defined criteria on relevant examples. An adoption assessment asks whether people can and do use the capability in the intended process. An economic assessment asks whether the changed process creates sufficient value after its costs. Keep a result for each layer and describe the link between them.

Usage alone may reflect an instruction to try the tool. Time saved in drafting may be absorbed by review or by another bottleneck. Conversely, modest usage may be appropriate for a rare but important task. Select a measure that follows the promised outcome instead of assuming that more activity always means more value.

The Saudi AI transformation guide considers programme design around business outcomes. Research about an existing initiative should preserve the original outcome and the evidence that connects a technical change to it. That connection may remain uncertain even when the tool is functioning and users report satisfaction.

Create an evidence card for every important claim

Use a short record that another analyst can audit. Include the exact claim, original source, collection period, population, counting unit, outcome definition, method, observation length and missing cases. Add the proposed mechanism, plausible alternatives and the narrow decision the claim is being used to support.

Fields for assessing an adoption-research claim

Evidence-card field	Question it must answer
Observation	What was actually measured or reported?
Population and time	Whose outcomes were visible, and for how long?
Interpretation	Which conclusion is a measurement and which is an inference?
Alternatives	What other explanation fits the observations?
Local relevance	Which conditions match the Saudi initiative?
Decision	What action would change if the claim were false?

The final field prevents decorative research. If a percentage would not alter the decision, it may not deserve emphasis. If it would justify substantial spending or closure, require evidence proportionate to that consequence. A precise statement of uncertainty is more useful than a confident number attached to the wrong denominator.

Use research to choose the next enquiry

End with a bounded conclusion: an observed outcome, a plausible explanation, supporting evidence, alternatives and the next fact needed. This permits action without pretending every causal question is settled. It also allows a later reviewer to see what would change the conclusion.

For an AI adoption evidence review, bring the claim being relied on, its original source and a redacted initiative register with definitions and observation dates. That creates a concrete discussion about what the evidence can support and which local question deserves investigation next.