On-premise AI in regulated industries: what data residency actually requires in Uzbekistan

Somewhere in every conversation with a bank, a clinic, or a public institution, the same question arrives: where exactly does the data go. For businesses in Uzbekistan this is not only prudence; it is law. This article lays out the practical shape of the requirement and when on-premise deployment stops being paranoia and becomes the honest answer.

One disclaimer up front: this is an engineering company's field summary, not legal advice. Your compliance officer has the final word.

The legal baseline

The Law of the Republic of Uzbekistan 'On Personal Data' (ZRU-547) governs the processing of personal data, and its Article 27-1 sets the localization rule: personal data of citizens of Uzbekistan collected in defined circumstances must be recorded, stored, and processed on technical means physically located in the country, in registered databases.

For a business deploying an AI assistant, the operational question is blunt: when a customer types their name and phone number into a chat, which servers touch that message. If the answer includes an inference API in another jurisdiction, you have a data-flow conversation to have with your lawyers, your provider agreements, and possibly your regulator.

The three postures we see

Cloud with local anchoring: the website and databases live on servers in Uzbekistan, and the AI layer is designed so that what leaves for a model API is minimized and depersonalized where feasible. Workable for many commercial deployments; requires care in what the prompts contain.

Hybrid: customer data and the knowledge base stay local; only stripped, non-identifying fragments reach an external model. Better, and often the pragmatic middle for cost-sensitive businesses with moderate sensitivity.

Full on-premise: models, retrieval, logs, and integrations all run on the organization's own hardware or private cloud in-country. Nothing leaves. For banks under supervisory expectations, clinics with medical records, and public bodies, this is frequently the only posture that survives a security review without asterisks.

What on-premise actually takes

Hardware, sized honestly. A support assistant answering a few hundred dialogs a day runs comfortably on a single GPU server; you do not need a cluster to start, and anyone who insists you do is selling you the cluster.

Open models, benchmarked on your questions. For grounded tasks (answering from your documents) well-chosen open models perform close to cloud quality. The benchmark that matters is your hundred real customer questions, run before you commit, not a leaderboard.

Integration inside the perimeter: SSO, network segmentation, audit logs, role-based access wired to existing policies. And documentation good enough that your own team could run the system, because for this class of client, vendor lock-in is itself a risk finding.

The cost conversation

On-premise costs more up front and less per conversation forever after. The crossover depends on volume, but the decision rarely hinges on unit economics; it hinges on whether the alternative is deployable at all. A system that fails security review has infinite cost per conversation.

The practical path we recommend to regulated clients: benchmark open models on your real questions first, size hardware from measured load second, and let the security team read the architecture before anyone falls in love with a demo.