If you run a business in Uzbekistan, or serve Uzbek customers from Dubai, London or anywhere else, and want an AI agent to answer Telegram enquiries, update your CRM or sort application forms, someone will eventually ask: "Is it legal to send this data to a model hosted abroad?" Until 2026 the honest answer was uncomfortable, because Uzbek law required personal data of citizens to be stored on servers inside the country. That rule has now been narrowed. This article explains what changed, where personal data actually flows in a typical AI setup, and which technical measures to put in place before launch. It is not legal advice: we cover how systems are configured, and your own lawyer should assess your specific case.
What changed in Uzbekistan's data law in 2026
The core act is the Law "On Personal Data" No. ZRU-547 of 2 July 2019. The provision that worried foreign and local businesses most was Article 27¹. In its earlier wording it required personal data of Uzbek citizens processed with information technology to be stored on servers located in Uzbekistan. For any cloud AI service, that was a serious obstacle.
Law No. ZRU-1125 of 26 March 2026 rewrote Article 27¹. Mandatory storage inside Uzbekistan now applies to three categories:
- biometric data of individuals;
- genetic data;
- data of users of telecom operators working in Uzbekistan.
Other personal data may be stored and processed abroad if one of these conditions is met: the destination country is recognised as providing adequate protection; standard contractual clauses or binding corporate rules approved by the authorised body are used; or international standards from the authorised body's list are followed.
The list of adequate countries was approved by Cabinet of Ministers Resolution No. 415 of 29 July 2026. It names 49 states and took effect on 3 August 2026. The authorised body is the State Personalisation Centre under the Cabinet of Ministers. The current text of the law is on lex.uz; the Uzbek version is the official one, and other language versions are translations.
If you are used to GDPR or UK GDPR, the structure will feel familiar: adequacy decisions, contractual safeguards, purpose limitation. But do not assume the details match. The Uzbek country list, consent rules and registration procedure are their own, and a GDPR-compliant setup is a good starting point, not proof of compliance here.
Mapping where personal data flows
Most problems do not come from deliberate violations. They come from nobody drawing where the data goes. Take a common setup: a customer writes to a Telegram bot, an AI agent replies, creates a lead in the CRM and hands the deal to a sales manager.
| Stage | Data involved | Physical location | What to check |
|---|---|---|---|
| Messenger | Name, username, phone, chat text | Messenger's servers | Consent and a policy link are shown before you ask for a phone number |
| Language model API | Everything in the prompt, sometimes the whole conversation history | Model provider's data centres | Is the country on the list; does the provider retain prompts and for how long; does the model need the full data at all |
| Logs and debugging | Full prompts and responses | Your server or cloud | Log retention period and who has access |
| CRM | Customer record and history | CRM cloud or your own server | Database registration, staff access rights |
| Voice notes and files | Voice, photos of documents, passports | File storage, speech recognition service | Whether you are handling biometric or special-category data |
Build this table for your own system before development starts. It takes about an hour and shows where the real risk sits. Quite often the most sensitive place is not the model but the logs, which pile up for years with no deletion date.
Three areas that need extra care
Biometrics and voice
Biometric data must still stay in Uzbekistan. If your system recognises people by face or voice, that is biometrics, full stop. Plain transcription of voice messages is less clear-cut, since a voice recording itself can be interpreted in different ways. If voice notes are your customers' main channel (and in Uzbekistan they often are), raise this with a lawyer early and consider a design where the audio is transcribed and deleted, and only the text is kept.
Identity documents and special categories
Passport scans, medical details, health questions in forms. For special-category data the law requires written consent, which can include an electronic document, so a single button tap in a bot may not be enough. A practical rule: if the agent needs two fields from a document rather than the document itself, extract the fields and do not store the scan.
Telecom
If you are a telecom operator or work with subscriber data, full localisation still applies to you. An ordinary business that simply takes orders by phone usually falls outside this category, but confirm the wording with a lawyer.
Six technical measures for your AI agent
- Minimise. Send the model only what it needs to answer. To classify an enquiry, it does not need the customer's phone number.
- Mask. Before calling the model, replace phone, card and passport numbers with placeholders such as [PHONE_1], then restore them on your side after the response. This is ordinary code, no AI required.
- Choose provider and region deliberately. Check which country processes the requests against the list, and read the provider's terms: whether data is used for training and how long prompts are kept. Major API providers state this in their documentation and contracts.
- Set retention periods. The law ties retention to the purpose of processing: once the purpose is met or consent is withdrawn, the data goes. Define periods for logs, chats and files and make deletion automatic.
- Restrict access. A sales manager sees their own clients, an accountant sees invoices, not the whole database. In our own ERP this separation is enforced at the database level rather than by agreement.
- Keep a human on sensitive actions. Sharing data with third parties, bulk messages and exports happen only after a person confirms. We cover these limits for a CRM agent in our article on an AI agent in amoCRM.
Collecting consent inside a bot
The law allows consent in any form that lets you prove it was obtained. For a bot, that means recording the fact, the time and the version of the text. Here is a sample opening step:
Bot: Hello! I can help you pick a tour and pass your request to a manager. To book, we will need your name and phone number. We use them only to contact you about this request and keep them for no longer than 12 months. Details are in our data processing policy (link).
[I agree] [I have a question first]Customer: Question first. Do you have tours to Turkey in November?
Bot: Yes, I can answer without your contact details. When you are ready to book, I will ask for consent again.
Note that the customer gets an answer without consent, because no phone number is needed yet. The retention period in the text is illustrative; set your own and agree it with your lawyer. The button press, timestamp and text version are written to the database, and that record is your proof. If customers write in Uzbek or Russian, the consent text should be in their language too. We looked at how well models handle Uzbek in our article on AI in the Uzbek language.
Pre-launch checklist
- A data map exists: which fields, where they go, where they are stored and for how long.
- You have confirmed there is no biometric, genetic or telecom subscriber data in the flow.
- The country where the model processes requests has been checked against Resolution No. 415, or another lawful route under Article 27¹ is in place.
- Consent text and a processing policy exist in your customers' languages, and each consent is recorded.
- Phone and document numbers are masked before reaching the model.
- Retention periods are set for logs, chats and files, with automatic deletion.
- You have decided with a lawyer whether the database needs registering in the State Register of Personal Data Databases (the procedure is notification-based).
- A named person handles "delete my data" requests and knows where the data lives.
- There is a breach procedure: who finds out, who reports, and by when. Check notification deadlines against the authorised body's current documents.
For more on working with AI in the local context, see the Uzbekistan section of our blog.
FAQ
Can we now use foreign AI models for customer conversations?
For most ordinary data, such as name, phone and enquiry text, the 2026 amendments allow it if one of the Article 27¹ conditions is met, for example the processing country is on the list. Biometric, genetic and telecom subscriber data must still be stored in Uzbekistan.
If we mask the data, does the law stop applying to us?
No. Masking reduces what leaves your systems, but your messenger, CRM and logs still hold personal data. It is a good safeguard, not a way out of the law.
Our company is registered in the UAE or UK. Does Uzbek law still apply?
If you collect and process personal data of people in Uzbekistan, you should assume it is relevant to you, alongside your home jurisdiction's rules. Exactly how it applies to a foreign entity is a question for a lawyer familiar with both systems.
Who is responsible if the agent makes a mistake, us or the contractor?
Towards customers and the state, the company that collects and processes the data, which is you. The split of responsibility with a contractor is set out in the contract: what they configure, what they can access and how they delete data when the work ends.
Where do we start if automation is already running?
With the data map above. Go through each stage and mark where retention periods and consent are missing. Close the gaps in order of risk: documents and voice first, then logs, then everything else. If you need help with the technical side, get in touch; in the first conversation we will walk through your setup, and the legal side is best agreed with your own lawyer.