Personal data security when integrating third-party AI in Uzbekistan
When your bot sends a customer message to an external API, you are transferring personal data to a third party outside the country. That needs designing, not discovering after the fact.
What you are actually sending
In a typical AI bot far more leaves your perimeter than people assume: the message text, the conversation history, the name from the Telegram profile, and often the phone, delivery address and order number that landed in the prompt context.
Step one is to compile an exact list of fields leaving your perimeter — from real outbound request logs, not from design documents. In projects of this type the list is almost always wider than the team assumed.
Step two is deciding which of those fields the model genuinely needs. Classifying an inquiry requires neither phone nor address. Phrasing an order status reply needs the status, not the whole customer record.
Data localization requirements
Uzbekistan requires personal data of citizens to be stored on servers located within the country, with the personal data database registered. That applies to your storage layer and the design must start from it.
The practical consequence: the primary database with names, phones and addresses lives on local hosting or in a local data centre, while only a de-identified minimum goes to the external AI service. That architecture removes most of the questions.
Regulation evolves and interpretations vary. Before launching a service that processes citizens' data at scale, get an opinion from a lawyer specializing in local legislation rather than relying on general articles.
Technical measures
Pseudonymization: send an internal identifier instead of a phone number and a role-based form of address instead of a name. Keep the mapping in your own database — the model works perfectly well with 'customer #4821'.
Masking in flight: run text through a filter that strips phone numbers, card numbers and passport data before sending. Customers routinely type such things into chat unprompted.
Provider settings: major APIs offer modes where data is not used for training, plus enterprise terms with limited retention. Enable them explicitly and fix them in the contract rather than trusting defaults.
Logs are the weakest point
Conversation logs usually contain everything you carefully avoided sending outward, sitting in plain text in a monitoring system the entire dev team can access.
The rules are simple: mask sensitive fields in logs, cap retention, restrict access by role, and keep an audit trail of log access. Backups are inside the perimeter too and need encryption as well.
Handle analytics exports separately. A table of conversations dumped into a cloud service to build a report is a classic leak channel nobody counts as an integration.
Consent and transparency
The user must understand they are talking to a bot and that processing involves automated systems. One honest line at first launch defuses more complaints than a page of legal text.
In the privacy policy list the categories of data processed, the purposes, retention periods and the fact of transfer to processors. The document must exist in Russian and Uzbek, not only English.
Offer a way to request deletion and implement it technically rather than declaratively. A delete button that removes nothing from backups and logs is worse than no button.
What to check before launch
Intercept outbound traffic on a staging environment and read with your own eyes what goes to the API. It is a five-minute check that regularly uncovers extra fields being sent.
Test prompt injection behaviour: try to make the bot reveal another user's data or the contents of the system prompt. Context isolation between conversations must be strict.
Write down the incident procedure: who disables the integration, how customers are notified, where the log lives. Working that out during an incident is too late.