AI Strategy & Readiness Assessment Find the AI use cases worth building, and what they need

We score each candidate against criteria you agree before scoring starts: business value, feasibility, data readiness, risk and regulatory constraints. You set the weights, so the ranking reflects your priorities. A use case with high value but unusable data, or with data that may not go where the model would run, moves down the list or gets a precondition, such as cleaning a data source first. Use cases that tend to rank well have a named owner, a task that recurs, data you are allowed to use for that purpose, and errors a person can catch before they have an effect.

A senior sponsor, time from process owners, representative data samples, access to system owners and architecture documents, and your known constraints. The sponsor settles priorities when departments disagree, and process owners join the workshops and answer follow-up questions. Samples, or supervised access to them, let us judge data quality on real records. The constraints we need to know include data classification, procurement rules and the budget cycle. Where samples contain personal or classified data, we agree before we receive them where they are reviewed, who sees them and when they are deleted.

This assessment produces decisions and plans, not working software. It tells you which use cases to pursue, what each one needs and how to test it. A proof of concept then tests one use case on your data against acceptance criteria agreed in advance; a production build delivers it on the chosen deployment option, with security testing before go-live; and managed operation runs it afterwards, with scope and support hours set in the contract. Any step can be the last. The build and run steps are covered by services such as Private & Sovereign AI Platforms, Enterprise Knowledge AI & Document Intelligence and Managed AI Platforms & LLMOps.

It depends mainly on the number of business units and use cases in scope, and on how quickly people and data become available. Other factors are the number of data sources to sample, whether Arabic and English content must both be assessed, the depth of the architecture work, whether you want proof-of-concept charters, and how many stakeholder groups review the results. We set scope and duration in a proposal after a first meeting, and do not publish generic figures.

For the assessment, success is a decision your leadership can take and defend: a short list of use cases, the reasoning behind it, and the measures each use case will be tested on. Those measures are defined before anything is built, such as answer accuracy on a test set drawn from your own material, the time a task takes before and after, the errors a reviewer finds, use by the intended staff, and running cost per use. Each measure gets a baseline and an owner, and a proof-of-concept charter sets the threshold it must reach. We do not promise business outcomes; the assumptions behind any expected value are written down so you can test them.

No, not to start and not for the assessment. Whether a use case needs dedicated graphics processing units (GPUs) depends on the data it handles and the deployment option it requires. Where your data classification and the PDPL rules on transfers outside the Kingdom allow it, a proof of concept can use a commercial model through its enterprise application programming interface (API), with no new hardware. Data that must stay in a sovereign or air-gapped environment needs models that run inside it, usually open-weight models you run locally on hardware you own or host with a provider you choose. The architecture options state the compute each use case needs, so any purchase follows a tested need rather than preceding it.

On your own tasks, not on public rankings. For each use case you plan to test in a proof of concept, we prepare a small evaluation set from your material, such as real questions, documents and expected answers in Arabic, English and the mix your staff actually write, and agree with your reviewers how answers are scored. This tests what matters to you: your terminology, colloquial phrasing in user questions, scanned documents and text that mixes right-to-left and left-to-right writing. The assessment also records where language capability decides the architecture; the candidate approaches are compared on the evaluation set in the proof of concept itself.

The contract sets this: your data stays yours, and the deliverables are handed over to you as it specifies, including the readiness report, use-case register, architecture options, roadmap and any proof-of-concept charters. They are written so that your own teams, or any provider you choose for the next step, can use them, and the register includes the scoring model and its weights so you can score new proposals the same way.