Using Foreign AI APIs Under Uzbekistan Data Localization Rules
Practice4 minInnovialabs editorial team
In short
Keep the master copy of personal data on servers in Uzbekistan and send foreign AI APIs only de-identified text; when that is not possible, run a self-hosted model locally.
The short answer
Uzbekistan's Law on Personal Data, with the 2021 amendments, requires companies that process personal data of Uzbek citizens with information technology to collect, organize and store that data on servers physically located in Uzbekistan, in databases registered with the state. Calling OpenAI, Anthropic or Google means the text leaves the country and is processed abroad. That is a cross-border transfer, which the law allows only under specific conditions.
The practical rule: personal data lives at home, and only what cannot identify a person goes abroad. If the task needs the raw personal data, process it with a model running inside the country. This is not legal advice: confirm your specific case with a lawyer who knows the current regulations.
What counts as personal data in an AI request
Teams often forget that a prompt is data too. A request to a foreign API can contain personal data even if your database never leaves the country:
- names, phone numbers, passport and PINFL numbers, addresses;
- chat messages and call transcripts where clients mention themselves;
- scanned documents sent to OCR or vision models;
- voice recordings sent for speech recognition;
- combinations that identify a person indirectly: date of birth plus district plus workplace.
Logs matter as well. If your application logs full prompts to a foreign monitoring service, that is another transfer.
Four architecture options
| Option | What goes abroad | Quality | Effort |
|---|---|---|---|
| Local storage + de-identified requests | Masked text without identifiers | Top foreign models | Medium |
| Self-hosted open model in Uzbekistan | Nothing | Depends on the model and hardware | High |
| Hybrid routing by sensitivity | Only non-personal requests | Mixed | Medium to high |
| Transfer on a legal basis (consent, contracts) | Personal data | Top foreign models | Legal work, ongoing risk |
1. Local storage plus de-identified requests
The main database stays on servers in Uzbekistan. Before calling the API, a de-identification layer replaces personal data with placeholders:
Original: Aziz Karimov, +998 90 123 45 67, asks to move his delivery.
Sent: [PERSON_1], [PHONE_1], asks to move his delivery.
The mapping table between placeholders and real values never leaves your server. When the answer comes back, you substitute the real values locally. This works well for classification, summarization, drafting replies and extracting intent.
Key details:
- detect identifiers with rules (regex for phones, passports, cards) plus a named-entity model for names and addresses;
- treat de-identification as best effort: test it on real samples and measure what slips through;
- check the provider's data retention and training policy and use enterprise or zero-retention terms where available.
2. Self-hosted model inside the country
Open-weight models can run on your own GPU servers or in a data center located in Uzbekistan. Nothing leaves the country, so tasks involving raw documents, voice and full client histories become possible.
Trade-offs to plan for: GPU cost, model updates, monitoring, and usually lower quality than the strongest commercial models, especially in Uzbek. Test the model on your own data before committing.
3. Hybrid routing
A gateway decides per request: if the text contains personal data or a document scan, it goes to the local model; generic questions, marketing copy and code go to a foreign API. This gives you strong quality where privacy is not at stake.
4. Transfer on a legal basis
In some cases transfer abroad is allowed, for example with the subject's consent or to countries with adequate protection. This route requires careful legal work, clear consent texts and a data processing agreement with the provider, and the local storage requirement still applies to your primary database.
Common mistakes
- Treating the API as "just a tool". Every prompt with personal data is a transfer.
- Masking names but not context. A unique combination of facts can identify a person.
- Sending full logs abroad to analytics or error-tracking services.
- Using RAG with a foreign embedding API over client documents: the documents are transferred during indexing.
- No register entry. Local storage is only part of the requirement; databases also need to be registered.
How to choose
- List every AI task and mark which ones truly need identifiable data.
- For tasks that do not, use de-identification and a foreign API.
- For tasks that do, use a self-hosted model or obtain a clear legal basis.
- Document the data flows: what is sent, where, and who keeps it.