Three places a model can run

A public API is the fastest way to start and gives access to the largest models, but the data leaves your environment. An in-Kingdom cloud region keeps data inside Saudi Arabia while still giving you managed services and scale. An on-premise deployment puts the model inside your own data center, with full control and full responsibility.

Start with the data, not the model

Before comparing models, classify the data the use case touches. Public content, internal documents and restricted records each allow different options. Many entities discover that only part of their use case involves sensitive data, which opens the door to a hybrid design.

Test Arabic on your own cases

Benchmarks tell you little about how a model handles your regulations, your terminology and formal Arabic correspondence. I take fifty to a hundred real cases from the client, run two or three candidate models on them, and let the business users score the answers. The winner is often not the biggest model.

Count the full cost

A local model has no per-request fee, but it needs GPUs, people to operate it and a plan for upgrades. A cloud model is cheaper to start and can become expensive at volume. I size both for the expected usage in year one and year three before recommending either.

Work with the vendors early

Local cloud and AI providers know what is available in their Saudi regions today, which is not always what the global website says. Bringing them in early, with a clear use case and realistic volumes, gets you accurate sizing and better pricing.

My default answer

Use the smallest model that passes your quality bar, hosted in the least restrictive place your data classification allows, and design the solution so the model can be swapped later. Models will keep changing. Your data rules will not.

Originally published on my website. I'm Osama Elmelegy, an Enterprise AI Solutions Consultant in Riyadh. More at melegy990.github.io.

Ask a team how a complaint or a request moves through their organization and you'll get a clean flowchart. Pull the event logs from their systems and you'll see something very different: loops, rework, cases waiting days for one approval, steps nobody mentioned.

That gap between the process on paper and the process in reality is why I like to start with process mining before talking about AI.

What process mining gives you

Using the timestamps systems already record, process mining rebuilds the actual journey of every case. You can see where time is lost, which paths are most common, and where cases bounce back. It turns opinions about bottlenecks into evidence.

Why it matters for AI

Once you see the real flow, the right AI use cases often become obvious. A step where cases wait for someone to read and classify a document is a candidate for automatic classification. A step where information is missing and has to be requested is a candidate for an agent that detects gaps early. You're no longer guessing where AI helps; the data points to it.

A practical sequence

Map the most important customer journeys first, five to seven is usually enough. Find the two or three biggest bottlenecks. Design AI use cases aimed at exactly those steps, with the mined baseline as your measure of success. After go-live, mine the process again and compare.

The takeaway

AI applied to a broken process gives you a faster broken process. Process mining helps you fix the flow and point AI at the steps where it really pays off.

Originally published on my website. I'm Osama Elmelegy, an Enterprise AI Solutions Consultant in Riyadh. More at melegy990.github.io.

When a client brings me a list of AI ideas, the list is usually long and the budget is not. Before anything goes into a proof of concept, I run each idea through five questions. Most ideas don't survive all five, and that's the point.

1. What does this cost today?

In hours, money, delays or errors. If nobody can put a rough number on the current pain, the use case is not ready. "It would be nice" is not a cost.

2. Who changes their work if it succeeds?

Every useful AI solution changes how someone works. If we can't name that person or team, and they're not in the room, adoption will stall no matter how good the model is.

3. Is the data there, and can we use it?

Availability, quality and permission. In government projects the permission part, data classification and residency rules, often decides between a cloud service and an on-premise model before we discuss anything else.

4. How will we know it works?

I ask for a baseline and a target: current handling time, current accuracy, current backlog. The proof of concept is then measured against that, not against expectations.

5. What happens after the proof of concept?

Who funds the next step, which platform it runs on, which systems it needs to connect to. If the answer is "we'll see", the proof of concept is likely to become another pilot that never ships.

Putting it together

Scoring each idea on these five questions, even roughly, gives a shortlist the whole room can agree on. It also changes the conversation with leadership: instead of asking for a budget for "AI", you are asking for a budget to solve three named problems with clear targets.

Originally published on my website. I'm Osama Elmelegy, an Enterprise AI Solutions Consultant in Riyadh. More at melegy990.github.io.

Over the last two years I've sat in a lot of rooms where an organization proudly shows its AI pilot. A chatbot, a document classifier, a dashboard with a forecast line. Six months later, most of them are still pilots.

When I look back at why, the reasons are almost never technical. The model worked well enough. What didn't work was everything around it.

1. The use case was picked because it was easy to demo

A chatbot over a policy document is quick to build and looks impressive in a meeting. But if the people answering those questions today spend two hours a week on it, the business case is tiny. Pilots should start where the pain is measurable: hours spent, cases backlogged, errors that cost money.

2. Nobody owned the outcome

IT owned the pilot and the business "supported" it. When it was time to change a real process, nobody on the business side had the mandate to do it. Every use case I take forward now has a named business owner before we write a line of code.

3. Success was never defined

"Let's see what AI can do" is not a success criterion. Before a proof of concept starts, I agree on two or three numbers with the client: time per case, accuracy against a human reviewer, share of requests handled without escalation. If we hit them, we scale. If not, we stop without arguing.

4. The data question came too late

Many pilots run on a clean sample that someone prepared by hand. Production runs on the messy reality. I now ask in the first workshop where the data lives, who owns it, and whether it can legally be used for this purpose. In government work, that last question often decides everything.

5. There was no path to production

A pilot built in a notebook on someone's laptop has nowhere to go. The architecture, hosting and integration choices need to be made with production in mind from day one, even if the first version is small.

What I do differently now

I treat the use case selection as the most important deliverable. A ranked shortlist, each item with an owner, a measurable goal, a data check and a rough cost, is worth more than any demo. The proof of concept then becomes a test of a clear hypothesis, not a showcase.

AI adoption in the Kingdom is moving fast, and the organizations that win won't be the ones with the most pilots. They'll be the ones that picked three good ones and took them all the way.

Originally published on my website. I'm Osama Elmelegy, an Enterprise AI Solutions Consultant in Riyadh. More at melegy990.github.io.