Locally hosted computer use in Saudi Arabia: the agent that clicks should run on your own servers

A computer use agent does something no other kind of AI does: it looks at your screen. Not a document you chose to upload, not a question you chose to type. The screen, as it is, several times a minute, including whatever happened to be open behind the window you meant it to work in.

That is the whole mechanism, and it is worth being blunt about what it implies. If the model doing the looking runs somewhere else, then a picture of your screen goes somewhere else, every few seconds, for as long as the agent is working. For a Saudi bank, hospital or ministry, that is not a technical detail buried in an architecture diagram. It is the first question a compliance officer will ask, and most teams evaluating these tools have not asked it yet.

What computer use actually is

Computer use is the capability that lets a model operate software the way a person does: it receives a screenshot, decides where to click or what to type, and issues that action back to the machine. Repeat. It is how an AI agent uses an application that has no API — a legacy ERP screen, a government portal, a desktop client from 2011 that the vendor stopped supporting and nobody dares replace.

That is genuinely valuable in this market, and more valuable here than in most. A large share of the systems that matter in Saudi organisations are exactly the kind that cannot be integrated: an in-house application maintained by two people, a supplier portal with no partner API, an internal tool whose source code left with a contractor. Automating those has historically meant RPA — brittle scripts pinned to pixel coordinates that break the moment somebody moves a button. A model that can read the screen does not break when the button moves.

So the capability is right. The question is where it runs.

The screenshot is the payload

Here is the part that gets skipped. In a cloud computer use setup, the machine being controlled is often yours — you run the container, the browser, the virtual desktop. That sounds reassuring, and it is why the architecture diagrams look local. But the model is not yours. The model is an API endpoint in another country, and the screenshots are what you send it.

So "the agent runs on our infrastructure" can be entirely true while every frame of the screen still leaves the Kingdom. Those frames are not sanitised. Whatever is on screen is in the image: the customer record open in the next tab, the national ID in the header, the salary column, the patient name, the case notes, the internal pricing. You cannot redact a screenshot you did not know was taken.

Compare that with the AI systems your organisation has already been through procurement on. A chat assistant sends the text somebody typed. A document reader sends the document somebody selected. A computer use agent sends the screen, and nobody selected anything.

"The session is ephemeral" is a retention policy, not a residency guarantee

The usual reassurance is that these sessions are temporary: the container is destroyed, the context is gone, nothing persists. That is often true, and it is not the answer to the question that was asked.

Ephemerality tells you what happens to the data after processing. It tells you nothing about where the processing happened, whose jurisdiction it happened in, or what could be compelled from it while it was there. Under a data residency requirement, the transfer is the event. A regulator asking whether personal data left the Kingdom is not satisfied by an assurance that it was deleted shortly after it arrived.

And ephemerality cuts the other way too, which is the part vendors do not volunteer. If the session is gone, so is your evidence. Six months later, when somebody asks why the agent approved that transaction or amended that record, you have your own logs of the actions and nothing at all about the reasoning that produced them. For a regulated process that is a bad position to be in, and it is a strange thing to have accepted in exchange for convenience.

The audit question nobody asks in the demo

Any agent operating a real system inside a regulated organisation has to be able to answer three questions after the fact: what did it see, what did it do, and on what basis. Cloud computer use can usually answer the second. It answers the first only if you captured the screenshots yourself, and the third almost never, because the model's reasoning lived in a session that no longer exists.

This is solvable, but only by a system that keeps the whole loop — screenshots, decisions, actions — in a place you control and can subpoena yourself. That is an argument for local hosting on its own, before residency enters the picture at all.

What locally hosted computer use means, precisely

The phrase gets used loosely, so it is worth defining tightly. Three things have to be in the same place, and vendors routinely deliver one or two and describe it as all three:

• The controlled machine — the browser, desktop or virtual session the agent is operating. Easy. Almost everyone offers this.
• The model — the thing that receives the screenshot and decides what to do. This is the one that usually is not local, and it is the one that determines whether your screen leaves the building.
• The record — screenshots, decisions, actions and outcomes, retained on your terms rather than discarded on somebody else's schedule.

Locally hosted computer use means all three sit inside your perimeter. In practice that is one of two deployments: on your own servers, in your own building, on your own network; or in a Saudi region, on infrastructure inside the Kingdom, where the data never crosses a border to be processed.

The two are not equivalent and the choice is not about technology. A bank under a strict interpretation of its own controls will want the first. An organisation that wants the operational benefits without running GPUs itself will take the second. What matters is that both keep the screenshot in-country, and the vendor should be able to explain exactly which one they are offering rather than blurring the two.

Why this lands harder in Saudi Arabia than elsewhere

Three things stack here that do not stack in most markets.

First, the Personal Data Protection Law places real conditions on moving personal data outside the Kingdom. A system that transmits screens containing customer records to an endpoint abroad is a transfer, whatever the retention policy says, and it has to be justified as one.

Second, organisations in scope of the National Cybersecurity Authority's controls carry obligations about where systems run and how they are monitored that were not written with a remote model receiving continuous screen captures in mind. "It is a SaaS feature" is not a category that survives contact with those controls.

Third — and this is the practical one — the buyers who most want computer use are precisely the ones who cannot use the cloud version. The organisations with unautomatable legacy systems are banks, hospitals, ministries and utilities. They are the same organisations with the tightest residency constraints. The capability and the constraint land on the same desk, which is why so many of these projects stall between an enthusiastic pilot and a security review.

What to ask a vendor before you buy

These are the questions that separate a genuine local deployment from a local-looking one. Ask them in this order and the answers get short quickly.

• Where does the model that interprets the screenshot run? Name the country and the facility, not the product.
• Does any screenshot, at any point, reach infrastructure outside the Kingdom — including for safety filtering, telemetry, evaluation or abuse monitoring?
• If the answer is no, can you run it with the network egress blocked and show me it still works?
• Who retains the screenshots and the agent's decisions, for how long, and can I hold them instead?
• Six months from now, can I reconstruct what the agent saw and why it acted, without your help?
• What happens when your service is unreachable — does my automation stop, or does it keep running locally?
• Is the deployment auditable by my own security team, or only certifiable by yours?

The third one is the test that matters. A system that genuinely runs locally survives having its internet connection cut. A system that merely has a local component does not, and that is a five-minute experiment rather than a procurement cycle.

Where Voho fits

Voho builds AI that runs on your own servers, in your own building, or in a Saudi region — that is the constant across everything we make, from the voice agents answering phone lines in Najdi to document reading over Arabic contracts. Computer use is the same architecture pointed at a screen instead of a call.

What that means concretely: the model interpreting the screenshot runs on hardware you control or inside the Kingdom, the screenshots and the agent's decisions are retained where you decide, and the deployment keeps working with egress blocked. Your legacy ERP screen gets automated without a picture of it being sent anywhere you would have to explain to a regulator.

We would rather be measured on the fourth question in that list than on a feature comparison. Bring the system you were told could not be automated, and block the outbound traffic while we demonstrate it.

The short version

Computer use is the most useful agent capability for Saudi organisations, because so much of what needs automating here has no API to automate against. It is also the one that transmits the most sensitive thing an AI system can transmit, which is an unedited picture of whatever an employee had on screen.

Those two facts do not cancel out. They mean the deployment model is not an implementation detail to settle after the pilot — it is the decision. Get it right and you automate the systems nobody else could touch. Get it wrong and you find out during the security review, after the business has already been promised the outcome.