GDPR for Uzbek Startups: When European Rules Apply to You

If a startup in Uzbekistan deliberately targets people located in the EU, GDPR may apply to its processing of their personal data even if the company has no European office. The same can be true in certain cases involving the monitoring of users' behaviour in the EU. For founders, the key issue is therefore not the company's place of incorporation, but the actual product architecture, target audience and data flows.

Key takeaways:

• The fact that a user is an EU citizen does not, by itself, make GDPR applicable: the circumstances matter, including where the person is located when the relevant activity takes place.
• Targeting the European market—for example, selling SaaS to users in the EU—is one of the main triggers to assess.
• For an AI product, you should separately map what data is collected, why it is needed, who can access it and where it is transferred.
• GDPR compliance is best designed into the product from the start rather than added as a legal patch after launch.

When GDPR applies to a startup from Uzbekistan

GDPR is not limited to companies incorporated in the EU. In particular, the rules may apply to an organisation outside the EU where processing is connected with offering goods or services to people located in the EU or monitoring their behaviour within the EU.

There is an important product-level distinction here. The EDPB makes clear that simply processing the data of a person who happens to be in the EU does not, by itself, mean GDPR applies. For a non-EU company, the relevant factor is whether it is deliberately targeting people in the EU or monitoring their behaviour there. For example, if an Uzbek service operates exclusively in Uzbekistan and one of its users travels to Paris on holiday and continues using the service, that does not automatically make the company subject to GDPR.

In practice, I would look at the product the way an engineer looks at a system: which users fall within scope, which events trigger processing, which services receive the data, and where the infrastructure and contractors are physically located.

What counts as a “European user”

I would not build your compliance analysis around a simple `country = EU` field. The legal analysis is more nuanced.

Consider three scenarios:

So don't look only at IP addresses. I would check the language and content of the website, currencies, marketing campaigns, delivery terms, onboarding, advertising geography, product settings and which users are actually being targeted. The mere presence of European users in your database does not, by itself, answer whether GDPR applies.

Where GDPR most often breaks down in IT and AI products

The first mistake is treating the privacy policy as a lawyer's document rather than part of the product. GDPR requires transparent information about who processes the data, for what purposes, on what legal basis, which categories of data are used, how long they are retained and with whom they are shared.

The second mistake is collecting data “for later”. GDPR is built around principles including purpose limitation and data minimisation: collect only what is necessary for a specific purpose and do not retain personal data longer than necessary.

The third is forgetting about vendors. Your CRM, cloud provider, analytics platform, support system, email service and AI API may all be involved in processing personal data. You need to understand who is the controller, who is the processor, what contractual terms apply and what data is transferred to each provider.

For AI products, I recommend adding another layer: document separately whether user data is used for training, evaluation, personalisation or model improvement. That use should align with the stated purpose of processing rather than appearing silently after launch.

Transferring data from the EU to Uzbekistan

If data relating to users in the EU is transferred outside the EEA, you need to assess the applicable mechanism for international data transfers. GDPR provides several mechanisms, including adequacy decisions, standard contractual clauses and other recognised transfer regimes.

This means that saying “the data is on our server” is not enough. You need a real data-flow map: user → application → database → cloud → analytics → CRM → AI provider → support.

Check separately where the data is actually transferred and on what legal basis. For example, EU standard contractual clauses are one tool for certain cross-border transfers, but applying them requires an analysis of the specific parties, contractual structure and transfer involved.

What to do this week

I would not start by buying another privacy policy template. Start with an inventory.

Checklist:

• List all personal data collected by the product.
• Identify which users are located in the EU and whether the product actually targets them.
• Map all data transfers and connected SaaS/API providers.
• For each processing activity, identify its purpose and legal basis.
• Review the privacy notice, consent flows and process for handling user requests.
• Check retention periods and whether the data can be deleted.
• For AI, document separately whether user data is used for training or other secondary purposes.
• Assess whether additional GDPR roles and documentation are required, taking into account the nature and risk of the processing.

This kind of audit quickly shows where legal risk is being created by the product architecture itself rather than by the wording of a contract.

FAQ

If a startup has no office in Europe, does GDPR not apply?

Not necessarily. Having no European office does not, by itself, exclude GDPR. The rules may apply to a company outside the EU in certain circumstances involving the offering of goods or services to people in the EU or monitoring their behaviour there.

Is it enough that the user is an EU citizen?

No. For territorial scope, the actual circumstances matter, including where the person is located when the relevant activity takes place. Citizenship alone is not the deciding factor.

Do we need consent for all data?

No. GDPR provides several legal bases for processing; consent is only one of them. The appropriate basis depends on the specific purpose and circumstances of the processing.

Does GDPR only concern large companies?

No. The GDPR's approach takes the risk of processing into account, while its core data-protection principles apply regardless of company size. At the same time, specific additional obligations may depend on the nature, scale and risk of the processing.

Should GDPR be considered at the MVP stage?

If you plan to target the European market from the outset, yes. Privacy by design means building appropriate safeguards into the processing architecture at the design stage.

Conclusion

For an Uzbek startup, GDPR is primarily a question of product scope and data architecture. If European users are part of your target audience, don't wait for your first enterprise customer or investment due diligence. Map your data, processing purposes, vendors, international transfers and user rights in advance.

At Pactum, this is exactly how we approach legal work: as part of the product. We look at the business model and data flows, then translate the legal requirements into concrete documents and processes. If you want to check whether your product falls within GDPR scope and what needs to be fixed before entering the European market, book a consultation.

*This is general information, not individual legal advice.*