Can You Send Customer Data to AI? Rules and Alternatives

Introduction – What LLMs Are and Why Data Questions Arise
What Is an LLM (Large Language Model)
2.1. Examples of International LLMs: OpenAI, Anthropic, Google Gemini, and Others
2.2. Examples of Russian LLMs: YandexGPT, Sber GigaChat, and Other Domestic Models
Types of Client Data and Their Sensitivity
3.1. Personal Data and Categories of Personal Information
3.2. Trade Secrets and Confidential Corporate Information
3.3. Sensitive Data and Customer Behavioral Profiles
Legal Restrictions on Sending Data to LLMs
4.1. Russian Law: Federal Law No. 152-FZ and Roskomnadzor Requirements
4.2. Cross-Border Data Transfer: Data Localization in Russia and Requirements for Transfers Abroad
4.3. International Standards: GDPR and Other Regulations When Working with Foreign LLMs
4.4. Regulatory Guidance: Positions of the Russian Ministry of Digital Development, Roskomnadzor, and Foreign Regulators
Risks of Sending Client Data to Cloud LLMs
5.1. Data Breaches and Unauthorized Access
5.2. No Guarantee of Deletion and Long-Term Data Retention
5.3. Sharing Data with Third Parties and Possible Uncontrolled Use
5.4. Incident Examples: Data Leaks Through ChatGPT and Company Responses
Data De-Identification (Anonymization): Concepts and Standards
6.1. De-Identification Under Russian Law (Personal Data Depersonalization)
6.2. Anonymization vs. Pseudonymization: ISO/NIST Standards and Practical Differences
6.3. De-Identification Methods: Masking, Aggregation, Encryption, Differential Privacy
6.4. De-Anonymization Risks: How Sufficient De-Identification Is and Examples of Data Recovery
What Is Allowed: Sending Data to LLMs in Law and in Practice
7.1. Can De-Identified Data Be Sent to LLMs? Legal Considerations
7.2. Restrictions on Transferring Even De-Identified Data: Formal and Practical
7.3. Is Customer Consent or Another Legal Basis Required to Use Data in LLMs?
Alternatives: How to Work with LLMs Without Violating Confidentiality
8.1. Self-Hosted LLMs (Deploying the Model on Your Own Infrastructure)
8.2. Fine-Tuning Models on De-Identified Data
8.3. Local Inference: Using Local Models Without Sending Data
8.4. Russian APIs and Solutions with Confidentiality Guarantees (Example: GigaChat, Yandex)
8.5. Intermediate Solutions: Proxy Anonymizers, Encryption, Trusted Execution Environments
8.6. Table: Overview of Alternative Solutions and Their Characteristics
Practical Recommendations for Minimizing Risks
9.1. Internal Company Policies and Procedures: What to Document and Implement
9.2. Employee Training: Digital Hygiene and Awareness of AI Risks
9.3. Technical Measures: Access Restrictions, DLP, and AI Usage Monitoring
9.4. How to Safely Experiment with LLMs in Business
Conclusion – Balancing Innovation and Security: Key Takeaways for Business Owners

1. Introduction

The rapid development of artificial intelligence technologies has raised a new question for business: can client data be sent to LLMs (Large Language Models) and how can this be done legally and safely. LLMs are large language models capable of generating coherent text and answering questions, trained on massive amounts of data. They are used in chatbots, support systems, document analysis, and many other tasks. Business owners see strong potential in LLMs for improving customer service and internal operations, but working with real customer data raises valid concerns about privacy and compliance.

In Russia, this issue is especially relevant because personal data legislation strictly regulates the handling of customer information. At the same time, the global market offers powerful LLM services, most of them foreign (OpenAI ChatGPT, Google Gemini, Anthropic Claude, and others). This creates a dilemma for companies: how to benefit from modern AI models without breaking the law or risking data leaks. In this article, we will take a detailed look at the rules that apply in Russia and worldwide, what data de-identification (anonymization) is and how to apply it, what alternatives exist to sending data directly to third-party LLMs, and what practical steps businesses can take to use these technologies safely.

We will provide real examples, from public cases such as the Samsung data leak through ChatGPT and regulators’ warnings not to share confidential information with AI, to company practices that found a balance—for example, through intermediary proxy systems for anonymizing prompts. References to regulations (Federal Law No. 152-FZ, GDPR, and others), guidance from government agencies (Roskomnadzor, the Ministry of Digital Development), and standards (ISO, NIST) will help explain the regulatory side of the issue. We will also present a comparative table of LLM implementation options (on-premises infrastructure, cloud solutions in Russia and abroad, protection methods) and their characteristics—this will help business owners choose the best approach.

The goal of the article is to provide a comprehensive guide for business owners and managers on how to integrate LLMs into work with customer data in a competent and secure way. The material is presented in a neutral business style, with an emphasis on practicality: checklists and recommendations for security policies and employee training. Let’s start with the basics: what LLMs are and what kinds of customer data exist from the standpoint of both law and business.

2. What Is an LLM (Large Language Model)

Large Language Model (LLM) is a class of artificial intelligence models trained on huge corpora of text data to understand and generate natural language. In essence, an LLM is a neural network with a very large number of parameters that can predict the next part of a text based on the preceding context. This allows LLMs to hold conversations, write coherent texts, answer questions, translate, analyze document content, and perform many other complex language tasks.

In recent years, LLMs have become the foundation of many chatbots and AI services. Foreign technology companies are investing enormous resources in developing such models, and mass-market products have emerged:

OpenAI is the developer of ChatGPT (the GPT-3.5/GPT-4 model). ChatGPT has become synonymous with advanced conversational AI, capable of everything from drafting emails to writing code. OpenAI also provides an API for developers and enterprise versions.
Anthropic is the creator of Claude, an assistant positioned as a safe and high-quality conversational partner. Claude competes with OpenAI models, and Anthropic promotes the principles of “constitutional AI” to reduce toxicity.
Google develops a family of models such as PaLM; its latest project is Gemini, presented as a new-generation multimodal AI. Google is already integrating LLMs (for example, Bard, based on LaMDA/PaLM) into its products and cloud services.
Microsoft is a strategic partner of OpenAI, having integrated GPT-4 into Bing Chat, Office Copilot, and other tools. It is also developing its own solutions and offers Azure OpenAI Service for enterprise AI use.
Amazon – in addition to its assistants (Alexa), launched services like Bedrock with access to AI21 and Anthropic models as well as its own LLMs (for example, Amazon Titan), focusing on business applications.
Others: Meta (LLaMA 2, an open model that companies can deploy locally), IBM (projects in neural NLP), and numerous startups and open-source communities (Hugging Face, BigScience BLOOM, etc.).

Russian companies are also actively working on LLMs, aiming to provide alternatives to Western solutions and account for the Russian language and local requirements:

Yandex – has been developing generative models since 2017 (YaLM). In 2023, it introduced YandexGPT, which was integrated into the voice assistant Alice and other products. YandexGPT is available to developers, trained on Russian-language data, and understands the context of Russian reality.
Sber – the Sber group launched the GigaChatmodel in spring 2023, positioning it as an answer to ChatGPT. GigaChat is built on Sber's own SBER architecture, with an emphasis on security and multimodality. Sberbank (through Sber AI) previously developed the ruGPT-3 family of models, and now offers GigaChat 2.0 and even GigaChat 3 (in preview) as a domestic AI platform.
Other players: companies like Just AI, DeepPavlov, SberDevices and others are developing conversational AI models, often highly specialized. For example, for call handling, Russian-language customer support, etc. Startups are also emerging that adapt open models (like Llama) to Russian-specific needs.

It is important to understand that an LLM is a general-purpose modeltrained on data from the internet, books, Wikipedia, code repositories, and so on. For business, the value of LLMs lies in their ability to generalize knowledge and perform intelligent operations without special programming. But that same characteristic creates risks: the model does not “know” boundaries; it memorizes fragments of training data and user conversations. For example, a major study showed that LLMs can memorize and reproduce fragments of private informationpresent in the training set. Therefore, when we give a model new input, especially input containing unique data (for example, customer information or source code), we must consider where that information will go and how the model may use it.

In summary: LLMs are a powerful tool for language processing, with examples of both global (ChatGPT, Claude, Bard) and Russian (YandexGPT, GigaChat) implementations. For entrepreneurs, they open up new opportunities for automation and analytics. However, interacting with real customer data through an LLM is an area that requires extra cautionbecause it involves privacy, data protection laws, and information security. Next, we will look at what types of data exist and how they differ in the context of risks and regulations.

3. Types of Customer Data and Their Sensitivity

Before sending any information to an LLM, it is important to classify what kind of data it is. In business, “customer data” can refer to a wide range of information—from a customer’s name to their purchase history. Different categories of data have different legal status and levels of confidentiality:

3.1. Personal Data

Personal data is any information relating to an identified or identifiable natural person (the data subject). In other words, if a specific person can be identified directly or indirectly from the information, that information is considered personal data. Personal data includes, for example:

Basic identifiers: full name, date and place of birth, gender, citizenship.
Contact information: home address, phone number, email address, social media accounts.
Document data: passport details (series, number), SNILS, INN, driver’s license, international passport, etc.—any government-issued personal identifiers.
Biometrics: facial photo, fingerprints, voice sample, iris data, etc.
Medical data: medical history, diagnoses, test results, treatment information.
Financial data: bank account and card numbers, income and expense information, credit history, purchases.
Education and career: diplomas, certificates, place of work, job title, work experience.
Movement data: geolocation, travel history, routes (for example, data from transportation apps).
Preferences and behavior: website visit history, search queries, interests, purchases, responses to promotional emails.

Some of this information is voluntarily provided by customers themselves (forms, profiles), while other data is generated during service delivery (order history, support requests). All personal data is strictly protected by law : in Russia, this is Federal Law No. 152-FZ :On Personal Data , in Europe, GDPR, and so on (more on legal aspects in the next section). Unauthorized disclosure or improper processing of personal data carries legal risks. Therefore,sending raw personal data to an LLM is extremely risky

, especially if it is an external third-party service: in effect, that would be disclosure of information to a third party. The law also identifies special categories of personal data : especially sensitive information such as race/ethnic origin, political views, religious beliefs, health, and intimate life. Processing of this data is prohibited without special grounds. There are also biometric personal data

(photo, voice), which are subject to a special regime as well. Transferring such data anywhere (especially to a foreign AI service) is practically always prohibited or requires the data subject’s explicit consent.

3.2. Trade Secrets and Confidential Corporate Information confidential informationthat does not directly concern private individuals, but is valuable to the business. This includes:

Trade secrets — information related to a business that has value precisely because access is restricted. The trade secrets law lists: information about growth strategy, marketing plans, customer and contract data, unpatented developments, know-how, supplier lists, etc. If a company has established a trade secret regime (marks documents “Trade Secret” and notifies employees), such data is legally protected from disclosure.
Financial information (confidential) — internal financial reports, forecasts, budgets, profit/loss information before public disclosure. For example, management accounting data, investment plans.
Intellectual property (in development) — technical drawings, source code, algorithms, formulas, patent applications before publication. If such information leaks, the company may lose its technological advantage.
Operational data — information about internal processes: manufacturing technologies, logistics schemes, customer databases, internal policies, data on department performance, etc. These items are not always formally classified as trade secrets, but they are usually also treated as confidential within the company.

A leak of any of these categories can cause direct harm to the business — from losing a competitive advantage to fines and lawsuits. That is why companies sign NDAs (non-disclosure agreements) with employees and partners. In the context of LLMs, this means that it is prohibited to enter information covered by an NDA or confidentiality restrictions into public AI services. For example, it would be a serious mistake to ask ChatGPT to analyze an internal report marked "trade secret" — in effect, you would be disclosing it to the model developers.

It is important to remember: sharing any information with a third party (even an AI service) is a potential breach of confidentiality obligations. Many employment contracts explicitly state that an employee has no right to disclose trade secrets or internal company information, including over the Internet. Therefore, sending such data to a chatbot without special safeguards is a violation of workplace discipline and may lead to sanctions.

Even if an employee decides to "consult" with AI about a personal matter, the information still needs to be filtered. It is absolutely unacceptable to share passwords, access credentials, PIN codes or other critical secrets with a chatbot — disclosing them causes direct harm (fraudsters could use them, and the AI may retain them). We will discuss this in more detail in the risk section.

3.3. Sensitive Data and Behavioral Profiles

In addition to standard personal data and trade secrets, there are data categories at the intersection that also require caution.

Customer behavioral profiles. Companies often collect and analyze large volumes of data about customer behavior: what they buy and when, how they respond to promotions, what pages of the website they visit, and what device they use. These profiles are valuable for marketing and personalization. Formally, if a profile is anonymized (it does not contain the customer's name, only parameters), it may not be considered personal data. But in practice, a behavioral profile can often be matched to a specific person if identifiers are available (cookie, email, etc.). GDPR, for example, treats online identifiers (IP address, cookies, advertising ID) as personal data. In Russia, too, if a subject can be identified from the profile, the profile becomes personal data. Such data is highly sensitive: a leak undermines trust, and unlawful use (for example, sharing without consent) violates the law.
Special categories of data about customers. For example, health data about a customer if you are a healthcare company; data about their children; religious beliefs (which can be inferred from content consumption). This information requires especially careful handling. You cannot just "feed" it to a model for text analysis — at a minimum, anonymization or the customer's consent is required.
Payment card and account data. In this area, in addition to personal data law, the Payment Card Industry Data Security Standard (PCI DSS) applies. Under no circumstances should you enter a full card number, CVV code, or PIN into a chatbot — neither your own nor, especially, a customer's. The Moscow Region Committee on Digital Security has explicitly recommended that citizens not share financial information with AI: PIN codes, CVV, bank account details, or savings information. For businesses, a leak of such data is not only a reputational blow, but also a possible fine from financial regulators.
Document identifiers (passport series and number, driver's license numbers, insurance policy numbers). As the Ministry of Digital Development and experts have noted, full names, passport details, SNILS, and tax ID numbers are not something to put in prompts to AI. These are also personal data, and when combined, they open the door to abuse (for example, taking out a loan in a person's name, etc.).
Customer photo and video data. Photos and videos with faces are biometric personal data. Sending them to an external AI service (for example, a facial recognition service) is allowed only if the individual has given consent to biometric processing. In Russia, the biometric data regime has been tightened since 2021 — it requires separate consent and generally must be stored in accredited information systems. Transferring biometrics to a foreign service is an almost obvious violation of Federal Law No. 152-FZ, unless the person themselves has made these photos public (though even then there may be nuances).

Section summary: customer data comes in many forms, but the golden rule is: the more personal the information or the more valuable it is to the business, the more carefully it should be used in AI. Personal data is protected by law and requires either consent or anonymization before use in LLMs. Trade secrets and confidential information generally should not leave the organization's control without a very good reason (and management approval). In the next section, we will look at legal restrictions in detail so you understand not only common sense, but also the letter of the law.

4. Legal Restrictions on Sending Data to LLMs

Using customer data in any system is regulated by data protection laws. In the context of LLMs, especially cloud-based ones, the key rules are personal data laws (in Russia, Federal Law No. 152-FZ; in the EU, GDPR), as well as laws on communications secrecy, trade secrets, and more. Let's look at the main legal requirements related to sending data to third-party AI services.

4.1. Russian Law: Federal Law No. 152-FZ and Roskomnadzor Requirements

In Russia, the core statute is Federal Law No. 152-FZ "On Personal Data". It establishes the principles for processing personal data and the duties of companies-operators (that is, those who collect and use customer personal data). Key points as they relate to LLMs:

Personal data may be processed only on lawful grounds. Article 6 of Federal Law No. 152-FZ lists the cases: the data subject's consent, contract performance, a legal obligation, vital interests, etc. There is also a separate point 9: processing for statistical or other research purposes provided that personal data is mandatory anonymized. In other words, the law explicitly says that for research purposes (which can include AI model training), personal data must be anonymized in advance. Without that, it is unlawful.
Cross-border transfer of personal data. If a company wants to transfer data from Russia abroad (and the servers of OpenAI, Google, etc. are usually abroad), it must make sure that the recipient country provides adequate personal data protection. Roskomnadzor maintains a list of countries with adequate protection. By the way, the United States is not on it. Transfer to a country without an adequate regime is allowed only with the consent of the data subject, if it is necessary for a contract with the subject (for example, buying an airline ticket and transferring the data to a foreign airline), or in several other narrow cases (Article 12 of Federal Law No. 152-FZ). Sending data to OpenAI or Anthropic without obtaining the customer's consent is a violation, because the United States does not guarantee the level of protection required by our law.
Storage of personal data of Russian citizens — Under the requirements of the “data localization law” (the amendments to Federal Law No. 152-FZ from 2015), the primary database of Russian citizens’ personal data must be stored in Russia. If we use a foreign LLM service, we are effectively uploading data to an overseas server, bypassing the Russian database, which conflicts with the localization requirement. Even if a company formally stores data in Russia, a single transfer of copies abroad may already be considered cross-border data transfer.
Liability and Oversight. Roskomnadzor (RKN) is the main supervisory authority. In 2023–2025, the requirements became much stricter: effective September 1, 2025, new anonymization rules were introduced (RKN Order No. 140), and penalties for violations were sharply increased. For example, since 2025, the fine for a personal data breach starts at RUB 1.5 million (for legal entities). Maximum fines can reach up to RUB 20 million or a percentage of annual revenue in the case of major violations—practically on par with GDPR. And there is a particular focus on cross-border data transfer: violations when sending data abroad are now extremely costly. RKN has been given authority to conduct unannounced cybersecurity inspections and demand proof of data protection. So for business, this is not an academic issue—sanctions are real.

What does all this mean for LLMs: if customer data qualifies as personal data, transferring it to an external AI service must comply with Federal Law No. 152-FZ. In practice, since neither OpenAI nor Google are located in Russia, the only somewhat lawful option is to anonymize the data before sending it. Or obtain informed consent from each client that their personal data will be sent for processing, for example, to the OpenAI API (and even then, it is questionable whether this would be fully legitimate). In the sections on anonymization we will explain the requirements in more detail, but to jump ahead: since 2025, RKN has understood anonymization to mean irreversible anonymization. Pseudonymization (when data is replaced with codes but can still be restored) does not, in essence, remove the personal data status. So simply removing a name and leaving, say, a phone number is not enough.

In addition to the personal data law, there are others as well: for example, the Commercial Secrets Law (No. 98-FZ) — if information is classified as a trade secret, disclosing it to third parties is unlawful and may lead to civil liability and, in some cases, criminal liability. The law on protection of communication secrecy (for example, correspondence and messages from telecom customers cannot be handed over to just anyone). The Banking Law (bank secrecy is established for information about customer accounts) — a bank is prohibited from disclosing information about accounts and transactions without the client’s consent. Thus, for certain industries there are special rules: for example, a bank cannot upload a customer account statement into a chatbot; that would violate bank secrecy.

It is important to note that, so far, Russian regulators have not issued a standalone law or instruction specifically for AI models. But work is underway: amendments are being discussed on experimental legal regimes for AI and on special conditions for developers (the same clause 9.1 of Article 6 of Federal Law No. 152-FZ about experiments in Moscow). Russia’s Ministry of Digital Development, together with regional authorities, is already conducting outreach to users on the safe handling of AI (an example is the recommendations from Moscow Oblast discussed below). One position is already clear: do not provide AI with any personal or confidential dataif you are not sure it is protected.

4.2. Cross-Border Data Transfer: Localization and Foreign Clouds

It is worth separately emphasizing the aspect of “where the LLM servers are located”. This is not a trivial question: if they are abroad, we have cross-border data transfer. Why this matters:

Data localization: Personal data of Russian citizens must initially be collected and stored in Russia (Article 18(5) of Federal Law No. 152-FZ). If a company uses a foreign service directly, bypassing Russian storage, it violates this requirement. In theory, a company could first store personal data in a database in Russia and then send a copy to AI—but then cross-border data transfer rules apply (see above).
Lack of jurisdiction: By sending data to a foreign model, you effectively remove it from the control of Russian law. If a breach or misuse happens tomorrow, Roskomnadzor will not be able to directly take action against OpenAI or another foreign company (except by restricting access to the service in Russia). There is no mechanism to require deletion of the data or impose a fine on the foreign provider. This is potentially dangerous for data subjects’ rights.
The Cloud Law (No. 236-FZ): In 2022, a law was adopted restricting the activities of foreign persons in the Russian segment of the internet. In particular, it requires foreign owners of information systems (which can include global AI services) to comply with Russian laws, register branches in Russia, and so on. Since OpenAI and others have not done this, their services are not officially represented in Russia. This has led to the fact that direct access to ChatGPT in Russia is currently restricted — without a VPN, many people cannot access it. On the one hand, this is a sanctions and policy issue; on the other, it is a data protection issue (RKN may be concerned about uncontrolled collection of Russian users’ data).

Thus, using foreign LLMs carries legal uncertainty: formally, the company would be violating localization requirements and, if there is no consent, cross-border transfer rules. In practice, Roskomnadzor has not yet fined companies specifically for using ChatGPT (these cases have not yet been publicly disclosed). But indirect measures are known: for example, the Main Radio Frequency Center (an RKN structure) proposed in 2023 to block data collection by the GPT bot (OpenAI’s internet crawler) on Russian websites. In other words, supervisory authorities are closely watching AI activity. It is wiser for businesses not to wait for test cases and instead take responsibility for compliance themselves.

4.3. International Rules: GDPR and Other Regulations When Working with Foreign LLMs

If a company operates not only in Russia but also in the international market (or processes data of EU, US, and other citizens), it must also take into account foreign data protection laws. Briefly, the key points are:

GDPR (EU): The General Data Protection Regulation in the European Union. In spirit, it is largely similar to Federal Law No. 152-FZ, but it sets out requirements even more strictly. Under GDPR, any processing of personal data requires a legal basis (consent, contract, legal obligation, etc.), and data subjects are given broad rights (to access and delete their data). If a Russian company working with European citizens’ data uploads it to ChatGPT, it will make a data transfer outside the EU. After the Schrems II Court of Justice of the European Union decision (2020), transfers of data to the United States became much more complicated—Standard Contractual Clauses and an additional assessment are required, since American services are subject to laws such as the Cloud Act (U.S. authorities can request data). Therefore, European regulators are cautious about such practices.
A notable case is the blocking of ChatGPT in Italy in March 2023. The Italian regulator Garante noted that ChatGPT violates the GDPR: it does not transparently say what data it collects or how it uses it, and there was a user data breach. Access to the service in Italy was suspended until OpenAI implemented the requirements (it introduced the ability for Europeans to opt out of using their data for training, etc.). OpenAI complied, and a month later ChatGPT was unblocked. This incident showed that European authorities can apply sanctions very quickly to an AI service if they see a privacy threat. For businesses operating with the EU, this is a signal: you need to be especially careful if you plan to use Europeans’ personal data in AI in any way—the consequences can be serious (GDPR fines of up to €20 million or 4% of turnover).
Laws in other countries: In the United States, there is no single federal data law, but states are passing their own laws (CCPA in California, VCDPA in Virginia, etc.). These laws are still more lenient than the GDPR, but they also require disclosure of who you share data with. If a company suddenly decides to send customers’ data (for California residents) to an external AI, it must notify them, or it risks violating the CCPA, which gives people the right to prohibit the “sale” of data to third parties. In this case, an AI service may be treated as a recipient of data for commercial purposes—a subtle point.
Privacy and AI is a new area where there are still few rules. Right now, the AI Act in the EU is being discussed; it will regulate the use of AI systems. Transparency requirements are expected: LLM developers will have to disclose what data the models were trained on and how they protect data. Voluntary AI Cards (model cards) have already appeared, where data sources and model limitations are listed, but so far this is not strict and not about user data, but about training datasets.

In short, if a business is international, it must take into account the laws of each jurisdiction. Universal advice: anonymize personal data if you plan to use it in an LLM, then formally it is no longer personal data and many restrictions are lifted. But it is important that the anonymization is truly robust (more on that below).

4.4. Regulatory guidance: positions of the Russian Ministry of Digital Development, Roskomnadzor, and foreign regulators

At the time this article was written, relevant Russian agencies had not issued a separate public guide like “How you can/can’t use neural networks with data.” However, there are indirect signals and recommendations:

The Russian Ministry of Digital Development together with the region (Moscow Region) prepared a memo for citizens on safe use of AI. It states outright: “do not provide artificial intelligence with personal data (full name, SNILS, TIN, addresses, phone numbers, passport details)”, as well as “do not disclose financial information or passwords”. In other words, at the level of public education, the state is already warning about the risks. If you extrapolate this to business: authorities clearly do not like the idea of confidential data circulating in global AI systems. Later, the same document advises treating communication with open AI as public space: “communicate with public AI (ChatGPT, DeepSeek, GigaChat, YandexGPT) as if everything you write immediately becomes part of the internet”. This is an important indication of the regulator’s philosophy: assume there is no privacy when using someone else’s AI, and therefore do not say anything you would not be comfortable seeing in public.
Roskomnadzor has so far limited itself to general reminders about protecting personal data. In 2023, it issued methodological recommendations for compliance with Federal Law No. 152-FZ, but there is no direct mention of AI there. Nevertheless, Roskomnadzor updated the de-identification requirements (Order No. 140 of 06/19/2025) — in effect, it sets anonymization standards that operators must follow if they want to use data in research or share it with others. We will look at this order later, but its essence is: de-identified data must not allow a person to be re-identified by any means. Roskomnadzor also collects breach statistics: according to its data, there were about 150 major personal data breaches in Russia in 2022 alone. This has created anxiety around any careless handling of data.
Foreign regulators are actively looking into whether LLMs violate privacy. In addition to the Italian case mentioned above, investigations against OpenAI have been launched in Spain, France, and Canada. Corporations are responding too: Samsung after the incident involving source code leakage through ChatGPT banned its employees from using public AI on work devices. In an internal memo, they noted that data uploaded to such platforms “is stored on external servers, is easy to find, but hard to delete”. Samsung employees are now prohibited from using any chatbots like ChatGPT on work computers, or even on personal devices for work tasks. Violations can result in dismissal. This example is not a law, but it reflects best corporate security practices.

To sum up this section: legal restrictions are quite strict. In Russia, you can send customer data to an external LLM only either a) after reliable anonymization, or b) by obtaining informed consent from each person for such transfer (and making sure the country to which you are transferring data protects it). In practice, option (b) is almost impossible to implement, so (a) remains — de-identification. The next section is therefore devoted specifically to de-identification: what it means in law and in technical terms, how to do it, and what pitfalls there are.

5. Risks of sending customer data to cloud LLMs

Before discussing ways to mitigate risks, it is important to clearly understand the nature of the threats that arise when data is transferred to cloud LLMs (especially foreign ones). What dangers exist if you ignore legal requirements and send real user data directly to an AI service:

5.1. Data leaks and unauthorized access to data

A data leak is every business’s nightmare. By sending data to an external service, we lose full control and are left hoping for the provider’s security measures. But even the biggest AI companies are not immune to incidents:

In March 2023, OpenAI experienced an outage: due to an error in the Redis library, ChatGPT users could see fragments of other people’s chat histories and some personal data of other users. Among other things, names, email addresses, and part of the payment data of about 1.2% of ChatGPT Plus subscribers were exposed. The Italian regulator cited this leak as one of the reasons for blocking the service.
Media reported a leak at Samsung: developers accidentally copied fragments of internal source code into ChatGPT to get help, thereby “leaking” the code to external servers. This was not a classic hacker breach, but a leak caused by users, yet the result was the same—confidential information left the company. Samsung’s response was strict (a ban on AI tools in the workplace).

Even if AI providers themselves care about security, there is always a risk that attackers will hack the service. In March 2023, hackers attempted to attack ChatGPT — some sources interpreted the outage as a “hack.” If hackers manage to penetrate an LLM cloud, they could potentially gain access to all data stored there (user query histories, uploaded files, and more). That could include personal and payment data, as well as all kinds of confidential information. In that scenario, the possible outcome is publishing the data online or selling it on the black market.

It’s also important to consider internal threats: employees of LLM developers have access to user data. OpenAI and Google privacy policies explicitly say that user chats may be reviewed by humans (for example, for moderation or to improve the services). Users are even shown a warning: “Do not enter information you would not want to show others”. This means that any information you entered into the chat could theoretically be read by an operator or moderator of the service. If that data includes customer personal information or trade secrets, you have already disclosed it to an outside party. Enterprise versions of LLMs promise stronger privacy, but you should not expect that from free/public ones.

So, the leakage risk includes: hacker attacks on the provider, system errors, and insider curiosity. The probability is not zero, and the damage can be enormous (fines, lawsuits, reputation). That’s why the first priority is to prevent sensitive data from ending up in such situations.

5.2. No deletion guarantees and long-term data retention

What happens to data after you send it to an LLM? Unfortunately, there are practically no deletion guarantees. Most services store interaction histories on their servers. For example, Google retains conversations with its Gemini chatbot for 18 months by default (users can change this to 3 or 36 months). Google keeps chats that were reviewed by moderators for at least 3 years. OpenAI and Microsoft use vague wording in their policies: data may be retained indefinitely for “trust & safety” purposes. Amazon simply says data is stored “to improve services.”

In plain English, once you send information you do not know how many years it will sit in the company’s archives. Even if you delete it from the interface (for example, clear chat history), it most likely remains on the servers. OpenAI recently introduced a setting that lets users turn off history retention for training — then chats are stored for only 30 days, but only for monitoring policy violations, after which they are supposedly deleted. However, this is based on trust — it is hard for us to verify.

The lack of deletion guarantees also means you may be unable to meet legal requirements if the data subject requests deletion of their data. In the case of LLMs, the business operator simply has no control — it cannot verify, for example, that all backups at OpenAI have been purged of previously submitted customer information. And under GDPR or Russian Federal Law No. 152-FZ, the data subject has the right to deletion (the right to be forgotten, etc.).

Long-term retention increases the risk of leakage: the longer data sits there, the greater the chance that a hack or other incident will eventually occur. In addition, long-term retention may mean the data is repeatedly used for different internal provider purposes without your knowledge.

5.3. Data sharing with third parties and possible uncontrolled use

When we send data to someone else’s LLM, we need to understand that it may be passed on or used in ways we never find out about. Several aspects:

Using data to train models. Almost all major AI companies admit that user prompts and responses may be added to training datasets to improve models. An analysis of the privacy policies of the five largest LLM providers (Amazon, Google, Anthropic, OpenAI, Microsoft) found that: all of them use user conversations for training by default of future model versions. OpenAI and Microsoft let enterprise customers opt out; Google does not provide a clear opt-out mechanism at all; Anthropic and Amazon also use the data, although Amazon does not state it explicitly in its policy, but the Nova interface warns about it. So if you have not taken special steps (for example, purchased a business plan with data collection turned off), most likely your data will become part of the corpus the model learns from.
Why is this dangerous? Because after some time the model may accidentally reveal fragments of that data to other users. This is not just theory — researchers at Google showed that LLMs can unintentionally memorize and then disclose confidential information from training. There was also an example: Meta Imagine was trained on 1.1 billion images from Facebook and Instagram users. If someone posted a cat photo back in 2017, model-generated images may end up looking very much like that cat. The same applies to text: LLMs can reproduce a piece of source text they saw during training. Demonstrations have shown that numbers of Social Security, names, and addresses could be extracted from GPT-2 when they were present in the training data. So, customer data sent today could show up tomorrow in a response to someone else. That is the risk of “ending up in the dataset.”
Data sharing with third parties via API or by law. Service policies may allow information to be shared with contractors. For example, data processing may be outsourced (voice data transcription, content moderation by outside companies). Then your data will also be seen by contractors. In addition, foreign companies may provide data to government authorities upon request — for example, in the US, the Cloud Actallows authorities to request data from providers. OpenAI’s policy states that they may disclose data if required by law or for investigations of violations (for example, if you entered something that triggers review). We won’t speculate too far, but the fact remains: data transferred to someone else’s cloud is no longer governed by our security policy; it is governed by the provider’s policy.
Lack of transparency. As users of the service, we know almost nothing about what security mechanisms are in place. Is data encrypted at rest? Who has access? Are logs deleted? — full information is usually unavailable, or it is buried deep in technical documentation. A study of the policies of AI giants showed that the public is very poorly informed about exactly what data the models were trained on and what happens to user conversations inside the system. The model cards mentioned earlier are voluntary and superficial. For example, it would be useful to know whether OpenAI deletes old data every quarter — but that is not published.

So, data can slip out of your control and “take on a life of its own”to end up in the training set, stay on the server forever, be viewed by people, shared with partners, or even come under the scrutiny of intelligence agencies. Incidentally, the former head of the NSA (the U.S. National Security Agency) recently joined OpenAI’s board of directors. That is only an indirect fact, but for many companies it signals that it would be naive to trust that a foreign AI will never share anything with government authorities. Experts note that such a move may increase the likelihood of the service cooperating with government agencies.

5.4. Incident Examples: ChatGPT Leaks and Company Responses

We have already mentioned some specific cases, so let’s summarize the most telling ones:

Samsung (March 2023) — company engineers uploaded confidential data to ChatGPT three times in three weeks: the source code for a new program, notes from internal planning meetings, and a technical task for equipment diagnostics. All of it became available to OpenAI. After learning about this, Samsung management imposed a total ban on the use of external generative AI for work purposes. They explained that the data is stored on external servers and “it is easy to find, but difficult to delete.” This case became a textbook example—discussed around the world as a warning about the risks of careless AI use.
ChatGPT User Data Leak (March 2023) — a software bug at OpenAI caused some users to see other people’s prompts and responses in their chat history. In addition, payment information for some paid subscribers was leaked. The company acknowledged the bug and fixed it within a day, but trust was damaged. It was this episode that Italy’s regulator referred to when accusing OpenAI of violating privacy rules. In the end, OpenAI had to quickly add data collection notices and a form for European users to opt out of having their chats used for training (privacy portal).
Revolut, JPMorgan, Verizon — a number of major Western companies blocked employee access to ChatGPT on corporate devices, fearing leaks. Financial companies are especially strict because of compliance: they worry workers may accidentally disclose client data or insider information to AI models. In Russia, as media reported, some government organizations also imposed bans on employees discussing work-related matters in public neural networks (especially after news about the possible use of ChatGPT in cyberattacks).
Moscow Region Recommendations (October 2025) — as noted above, the regional Ministry of Public Administration, working with the Ministry of Digital Development, issued open guidance for citizens. This is essentially an acknowledgment that the problem has matured: people are actively using AI, and digital literacy needs to be improved urgently. The guidance states directly that “AI should never, under any circumstances, be given confidential information that could be used against the user” — including passport details, tax ID numbers, driver’s licenses, card data, passwords, and contacts. It even recommends tactics such as: “When registering and interacting with neural networks, it is better to use fictitious data (for example, a made-up name and address)”. In other words, even private individuals are advised to disguise themselvesto reduce risk. That is a good principle for business too: if you really need to test a case, try it first with fictitious data, not real data.
Words from industry experts. Evgeny Osadchuk (ANO “Digital Economy”) noted in a comment that, in addition to personal and financial data, companies should not share intellectual property with AI: algorithms, unpatented inventions, growth strategies—anything that could leak and strip a company of its exclusivity. In other words, AI is like a hole through which your know-how can become public before your patent application is filed. Another specialist put it this way: when talking to ChatGPT or GigaChat, imagine that everything you write appears on your public web page. There is no privacy there, so write only what you are comfortable making public.

The takeaway from these examples and comments: the risks are real and varied. From direct leaks accessible to hackers to the gradual spread of information through models and into other people’s eyes. Companies that have already faced this have taken strict measures (ban, restriction). Regulators have increased oversight. Therefore, for an entrepreneur looking to implement LLMs, the first task is to minimize these risks. One of the main tools is data anonymization. We’ll discuss it in detail next.

6. Data Anonymization: Concepts and Standards

Anonymization (synonyms: depersonalization, anonymization) is the process of transforming personal data so that identifying a specific person from it becomes impossible without additional information. Simply put, after anonymization, the link between the data and the individual is broken. This mechanism is essential for the lawful use of customer data in research, statistics, and AI training because anonymous data is no longer considered personal data and its transfer is not restricted.

Let’s look at how anonymization is understood under Russian law and international standards, and most importantly, how to anonymize data correctly in practiceso you do not violate the law and genuinely protect customers’ privacy.

6.1. Anonymization Under Russian Law (Depersonalization of Personal Data)

Under Law 152-FZ, the term is defined in Article 3 (Section 9): anonymization is “actions that make it impossible to determine the relationship between personal data and a specific data subject without using additional information”. In other words, identifiers are removed or altered so that the remaining set does not reveal who is being described.

However, for a long time this rule was vague, and it was unclear which methods would be considered sufficient. As of September 1, 2025, amendments and subordinate regulations came into force, bringing clarity:

Order No. 140 of Roskomnadzor (06/19/2025) approved new requirements for anonymization. It states directly that anonymization must be carried out “without the ability to convert anonymized data back into its original form in a way that would allow it to be linked to a specific personal data subject”. In other words, there must be no way back — this is effectively a requirement for fully irreversible anonymization.
The earlier distinction between depersonalization/anonymization and pseudonymization has become clearer. ISO/IEC 29100 (an international privacy standard) distinguishes two approaches:
- Pseudonymization — replacing identifying attributes (name, phone number) with pseudonyms (codes). If the matching key is available, the person can be re-identified. The standard explicitly says that pseudonymized data is still considered personal data; the only difference is that the risk of leakage is lower. Example: replace customer names with numbers (ID1, ID2) and keep the correspondence table separately. If an attacker does not get the table, it will be difficult to tell who is who, but the link still exists, at least in theory.
- Anonymization — a stricter process in which the link to the individual is completely removed. According to ISO 29100, during anonymization data is changed so that the holder of the information cannot identify the subject even with all the original data. In other words, there is no matching key, so there is nothing to restore.
Russian legislation, in its updated interpretation, has effectively equated de-identification with anonymization.In other words, the requirement is to remove the ability to identify a person even for the operator itself, not to mention third parties. Now de-identified data = anonymous data. And pseudonymization is viewed more as a protection method, but not one that removes personal data status.
Government Decree of the Russian Federation No. 1154 dated 08/01/2025 clarifies that the result of de-identification must match the stated purpose and preserve data integrity. This means anonymous data must still be useful (not just erase everything), but at the same time it must under no circumstances be possible to restore it to its original state.
Bottom line: in the context of Russian law, de-identification now implies irreversibility. If your method leaves any chance of reconstruction (for example, you replace a name with a unique code that can be used to go back to the source database and find the name), the regulator will most likely not recognize it as full de-identification. From a compliance perspective, it will still be personal data.

For practical business purposes, this creates the challenge to: turn personal data into “de-identified” data so that no outside observer, and not even you yourself, can identify the person without disproportionate effort. This is the only way to use such data freely, including sending it to an external AI.

6.2. Anonymization vs. Pseudonymization: ISO/NIST Standards and Practical Differences

Let’s take a closer look at the differences, because in practice these concepts are often confused:

Pseudonymization — replacing identifiers with other values and storing the key separately. Examples: instead of a full name, assign a random UUID; instead of a phone number, use the string “TEL_12345.” The database still contains records that seemingly have no direct names, but somewhere in a safe there is a table that lets you link the UUID back to the full name. If that table is protected and does not leak, then to an outsider the data looks anonymous. However, if that table also leaks, everything is exposed. Nuance: even without the table, sometimes a person can be inferred from the combination of pseudonymized data (for example, a unique combination like “male, 42 years old, lives at 5 Lenin St.” may match only one customer). That is why pseudonymization is only partial protection. ISO 29100 classifies it as a de-identification method, but emphasizes that pseudonymization does not remove personal data status.

Anonymization — a process after which no data pointing to a specific individual remains, or it is generalized so much that identifying the person is impossible. The practical difference is that there is no secret key that can restore everything. If anything is retained for quality control, it still will not allow the original personal data to be reconstructed. International standards (ISO, as well as NIST guidance) introduce the concept of anonymity: a property of information in which identification of the subject is excluded. NIST (the U.S. National Institute of Standards and Technology) issued the special NISTIR 8053 de-identification guidance in 2015, describing methods and emphasizing the importance of re-identification risk assessment.

In simple terms:

Pseudonymization — “hide the name under the rug, but keep the rug in the same room.”
Anonymization — “take everything that points to the name out of the house and destroy it.”

For business, this means: if we want to consider data de-identified and use it freely, we need to implement anonymization. All identifiers are removed or randomly transformed without preserving mappings. Pseudonymization can be used as an intermediate step (for example, during processing), but the final dataset sent to the LLM must be anonymous.

6.3. De-identification Methods: Masking, Aggregation, Encryption, Differential Privacy

There are many de-identification/anonymization techniques. Let’s list the main ones, along with their pros and cons:

Data Masking — replacing real data with fictitious or truncated values. It can be:
- Static Masking: a copy of the database is created where real values are replaced with fake (but plausible) ones. For example, all last names are replaced with “Ivanov,” phone numbers with “+7 (000) 000-00-00” or random numbers from the same range. Static masking is irreversible because the real values are not present in the copy. It is used to prepare de-identified data suitable for testing and analysis. This is a good way to give a dataset to developers or an external analyst without risking disclosure of identities.
- Dynamic Masking: data is de-identified on the fly at the time of a request, while the original in the database remains unchanged. For example, a support agent sees not the customer’s full passport number in the CRM, but ****1234 (asterisks hide part of it) — that is, the system masks the field in the interface depending on access rights. This also applies to LLMs: you can configure a proxy that will mask sensitive details when calling the API (as we will see below).
Aggregation and Generalization : instead of specific values, we keep generalized ones. For example, instead of the exact age “34,” you can specify the range “30–35”; instead of the exact address “10 Lenina St., Kazan,” you can specify only “Kazan.” And instead of a unique customer ID, you can omit the ID altogether and keep only summary metrics for the group. Generalization reduces precision, but often sharply lowers the likelihood of identification. The k-anonymity method groups data so that each record is among at least K records with the same set of quasi-identifiers. For example, if K=5, you can make sure there is no unique combination of “gender + age + city” in the dataset — each combination appears for at least 5 people. Then it is difficult for an outside observer to isolate a specific person.
Deletion/Concealment — the simplest method: just remove personal fields. For example, delete full name, phone number, and email. But it is important not to forget indirect identifiers: a unique order No. 12345 may also be linked to only one customer, and geolocation accurate to a specific building also effectively identifies a person (if that person is the only resident of that building). Companies often delete only direct identifiers and consider the data de-identified — that is a mistake, because context can reveal the identity (see Section 6.4).
Encryption — a cryptographic method in which data is transformed according to an algorithm using a key. If stored in encrypted form, without the key it looks like a random string of characters. It can be used for de-identification, but there is a nuance: encryption is reversible (it can be decrypted if the key is available), so by itself it is more of a protection method than anonymization. However, if a company encrypted the identifiers and destroyed the key — then in effect it achieved irreversible anonymization (but key destruction is essentially the same approach as deleting the data). Sometimes it is done more cleverly: the key is stored with a trusted third party so that the operator itself also cannot easily match the identity — but that is already a more complex scheme.
Hashing — a one-way cryptographic transformation (for example, SHA-256). You cannot directly recover the original value from a hash (if the algorithm is strong), which is why passwords are typically stored as hashes. In the context of personal data, hashing can be applied to string identifiers: for example, instead of the email ivanov@mail.com store hash_XYZ. However, hashes are vulnerable to brute-force and dictionary attacks. If a field has a limited set of values (for example, a SNILS number — 11 digits, only 10^11 possible combinations), an attacker can recalculate the hashes for all possible values and match them. That is why hashing should be used with a salt (add a random secret before calculating the hash). But then, when anonymizing, we must forget the salt; otherwise, it becomes reversible for the operator.
Differential Privacy — a modern statistical method that is being actively developed in large tech companies. The idea: random noise is added to the data so that it is impossible to reconstruct an individual record with high precision, but aggregated statistics remain accurate within certain limits. For example, if you have a customer table with incomes, you can add or subtract a few random thousand rubles to each income value. The overall analysis will still show the averages correctly, but you won’t be able to determine Ivanov’s income exactly. Differential privacy provides a mathematically measurable protection guarantee (the parameter ε, “epsilon,” controls the privacy level — the smaller it is, the stronger the protection, but the lower the data accuracy). Apple and Google have used this approach for telemetry collection, and the U.S. census has also applied it. It is also possible for LLMs — for example, by adding noise to prompts to make them less specific. But in business practice, differential privacy is still rare and requires expertise.
Synthetic Data Generation — creating an artificial dataset that is statistically similar to the real one, but does not contain records about real people. For example, you can take a customer dataset and generate “similar,” but fictional, profiles based on it (using machine learning methods). Synthetic data does not refer to any specific person, so it is not personal data. However, it is difficult to verify whether any real fragments have leaked into it. And synthetic data does not always preserve all of the value of the original data for analysis. Still, the field is developing — for example, in marketing, synthetic customer profiles are created to train recommendation algorithms without using real personal data.

In practice, a combination of methodsis often used: first remove direct identifiers, then mask some fields, generalize the values of others, and encode the remaining ones. The 2025 Roskomnadzor order includes lists of methods recognized as acceptable. It mentions encryption, depersonalization through generalization, and attribute substitution. The key point is that the result must satisfy the requirement of irreversibility.

6.4. Re-identification Risks: Is Anonymization Sufficient, and Examples of Data Recovery

Simply applying a method is not enough — you need to make sure that anonymization is reliably strong. Otherwise, the data may be formally “anonymized,” but who are we kidding? A skilled analyst or algorithm can match facts and identify the person. What can go wrong:

Preservation of unique combinations of attributes. Example: you removed names, but kept the address and date of birth. It may turn out that, based on the combination of “born on May 5, 1990, lives on Zelenaya St., Building 7,” there is only one person in your city who fits. In that case, the data has no name, but it still effectively identifies that same customer. A real-world case: Netflix once published anonymized data about which ratings users gave movies (no names, only IDs). Researchers at the University of Texas were able to match this data with IMDb profiles and reconstruct who rated which movies. Lesson: external open sources (OSINT) make it possible to recombine information and “unmask” identities from seemingly anonymous datasets. That is why, when anonymizing, you need to remove or heavily blur rare or highly specific combinations.
Incomplete masking. Sometimes part of a field is left unmasked “for convenience.” For example, showing the first letters of a last name: Ivanov -> “Iv****.” That already gives a clue. Or a phone number: “+7 912 *** ** 34” — we learned the carrier code and the last digits, which narrowed the search. If the goal is to provide data to AI, such partial masks do more harm than good — it is better to replace the field entirely.
Background knowledge. The person analyzing the data (for example, AI) may have additional information. For example, you anonymized a chat with a customer by removing the name, but in the dialogue the customer mentioned “my BMW X5.” If the analyst knows that only one of your customers had a BMW X5, they will figure it out. This is a problem of implicit identifiers: preferences, speech style, mentions of individual facts (for example: “I live near the train station in the green house” — it seems non-identifying, but in your city there may be only one green house near the station, and an external data search can easily find the residents). For anonymization to be complete, you need to review the content of texts and documents — to check whether there are any personal details there. Sometimes you have to either edit them or avoid using overly detailed texts altogether.
Re-identification attacks are becoming more effective. With the rise of AI, it has become easier to match large volumes of data. Cross-correlation methods and clustering make it possible to extract likely individuals from “anonymized” big data. That is why simply meeting formal requirements is not enough — you need to think about how an attacker would approach the task. For example, if you have a purchase dataset: date, amount, product — with no names. If you know from another source that customer N bought an expensive TV on January 5, you can find a transaction in the anonymized data on January 5 for about 100k rubles — most likely, that is them. Then, using that transaction ID, you can trace the history and learn more about them.

Because of this, a paradox of anonymityarises: to completely eliminate identifiability, you need to hide as many details as possible (to the point of “anonymizing to zero”), but then the usefulness of the data declines. And if you leave even a little bit of information, the risk of de-anonymization increases. For example, in a customer conversation: if you delete every word that could tie it to a person (name, address, mentions), the text may become of little value. But if you keep the meaning and context, it may be possible to tell who it is from the details — especially if the conversation is unique.

The operator’s job is to find a reasonable balance. The new Roskomnadzor order hints at using “cryptographic methods for computing on data” as a future solution to this dilemma. The idea is that data can be analyzed in encrypted form (for example, Secure Multi-party Computation technologies or homomorphic encryption) without revealing it to anyone. This is promising, but for now it is complex and rarely available in practice.

Conclusion: anonymization is a powerful tool, but it must be applied correctly. Insufficient anonymization creates a false sense of security and can lead to violations. That is why, before using anonymized data, it is worth conducting a re-identification risk assessment: try to restore identities yourself or consult specialists. Ideally, meet the formal criteria (k-anonymity, differential privacy with ε), then you can be confident.

We focused in detail on anonymization because it is the key to the legal use of data in LLMs. Next, in the following section, we will discuss in practical terms: Can data be sent to an LLM after anonymization, or do restrictions still remain? And what should you do if even anonymization is undesirable?

7. What Is Allowed: Sending Data to an LLM Under the Law and in Practice

Now that we have built an understanding of the law and anonymization methods, let’s answer the main question: can client data still be sent to an LLM—and in what form, so that it is lawful? Here we’ll look at what the law formally permits, as well as how companies interpret it in practice.

7.1. Can anonymized data be sent to an LLM? (Legal aspects)

From a legal standpoint, if data are reliably anonymized (de-identified) —they stop being personal data. Accordingly, Federal Law 152-FZ no longer applies to them (the law regulates personal data only). That means:

There are no restrictions on storing/transferring such data, including abroad, because formally it is no longer personal data.
You do not need to obtain data subjects’ consent to process anonymous data, since there is no identifiable subject.
You can use this data to train AI models, for statistics, and so on—the law explicitly encourages this (Section 9, Part 1, Article 6 allows personal data to be processed for research purposes, provided it is anonymized).
You can share it with third parties (for example, upload it to a cloud API) without notifying the regulator about cross-border transfer (since officially you are not “transferring personal data” anymore—it is simply a set of anonymized information).

So, anonymized data can be sent to an LLM —on paper. That is exactly what many companies do: before sending a prompt to an external service, they strip out all personal information. In Section 8.5, we’ll look specifically at the architecture companies use to implement real-time anonymization.

However, there is one important condition: anonymization must be complete and meet the required standards. If the regulator decides the data were improperly anonymized (i.e., re-identification is still possible), it may classify that as unauthorized processing or transfer of personal data. Since 2025, as we noted, Roskomnadzor has had clear criteria (Order No. 140, Decree No. 1154). For example, if a company claims, “We transferred only anonymized data,” but an audit shows that specific individuals can easily be identified from it, the company will be held liable.

That is why, in practice, companies often do this: they anonymize data as strongly as needed to remove identifiers, but the data remain partially unique. For example, names are replaced with pseudonyms, but the content of the inquiries is kept. Formally, that is not 100% anonymization (because pseudonyms can be reversed if needed—meaning pseudonymization). However, a company may see this as an acceptable compromise if the third party (for example, OpenAI) still does not know who “Client123” and “Client124” are.

The law, however, requires that the company itself also have no way to map them back. In other words, if you keep the key “Client123 -> Ivanov I.I.” and at the same time send “Client123” to the LLM, for the regulator that is not anonymization, but the transfer of personal data under a pseudonym. That is allowed only if the conditions for cross-border transfer, etc., are met.

Still, one point: Federal Law 152-FZ, Article 6, Section 9 —speaks about mandatory anonymization in research processing. Strictly speaking, training someone else’s model is precisely a research purpose. That means it must be anonymized. GDPR says something similar: anonymous data are not personal data. But pseudonymized data remain personal data under GDPR, although they are subject to somewhat lighter processing. That is why European companies using AI also try to scrub the data or sign strict agreements with providers.

Legal conclusion: after proper anonymization—yes, you can. There are no rules prohibiting the exchange of anonymous information with AI. On the contrary, the government is interested in developing technologies based on de-identified data. An example is the “Digital Profile” project and the experiments in Moscow: businesses were required to provide anonymized datasets to the government for AI-related needs. They see this as beneficial for the data economy. The only thing that is getting tighter is oversight of anonymization.

7.2. Restrictions on transferring even anonymized data: formal and practical

Although the law does not oppose the exchange of anonymous information, practical limitations remain:

Contractual and ethical obligations. Even if personal data are removed, information may still remain confidential or commercially valuable. For example, you may have a customer transaction database (anonymized—with names removed). That is not personal data, but it is commercially sensitive information: it reflects customer behavior and sales patterns. By passing it to someone else’s AI, you are effectively revealing some of your business secrets, even without customer names. For example, the AI may “see” that sales of product X spiked sharply in a given month—that may be something only your company knew, and now the AI provider has that data too. Most AI service policies say that the rights to user content remain with the user (that is how OpenAI phrases it), but the company receives a license to use it. In other words, you give OpenAI the right to use (including, as we know, to train the model on) your content. And even if there is no personal data in that content, there may still be confidential business information. Your NDA with partners may prohibit disclosure of certain information, even if it is anonymized. For example, project documentation that contains no names but does contain know-how. So anonymization does not remove all restrictions —only those related to personal data.
Risk of context leakage. Imagine you anonymized medical records of patients (removed names, contacts). In theory, you could give them to an AI for analysis. But the records contain rare diagnoses and case descriptions. If the AI then generates a similar description when speaking with another person, that person may be able to identify someone’s medical case. Yes, there is no name, but a person may recognize themselves or someone they know (especially if the case is unique). This is a fine line: there is no personal data, but privacy violation may still occur (a privacy breach if someone learns about another person’s illness). GDPR, for example, treats such situations as sensitive. In practice, there was a case where Netflix’s algorithm recommended a documentary about cancer to a woman who had a rare form of cancer—she realized that information about her illness had leaked somewhere. Even though no one used her name, the situation itself revealed the fact of the illness.
Regulatory skepticism. Until practice settles, companies may worry that Roskomnadzor or a court will not believe the data were fully anonymized. If inspected, they will have to prove it. The new order requires a methodology and proof of compliance. In the future, anonymization certification may be needed—i.e., an expert opinion confirming that anonymization was carried out according to the standard. If you simply say, “We anonymized it,” and the regulator finds otherwise, fines are guaranteed. That is why, for example, the banking sector (which is very cautious) may even ban data transfer to AI altogether, regardless of anonymizationjust to avoid risk.
Accidental inclusion of identifiers. Even during process debugging, mistakes can happen. For example, you forgot to remove a last name from one field, or the AI inferred a name from indirect clues. In any case, the human factor can lead to extra information being disclosed.

In practice, some companies take the position: “Even anonymized customer data, we do not want to share anywhere except when required by law”. That is a conservative but safe position. Others, on the contrary, say: “We can share aggregated insights and trends — that does not violate anyone’s rights”. For example, an e-commerce company can give an AI analyzer summarized sales statistics by product category (with no data about specific buyers) — that is truly safe and lawful.

Conclusion: from a legal standpoint, anonymized personal data is allowed, but from the standpoint of internal company policy, reputation, and overall risk, you still need to weigh whether it is necessary. Sometimes it is better to play it safe and not send even anonymous information if it is extremely sensitive or unique.

7.3. Do you need customer consent or another legal basis to use data in an LLM

If you still want to use non-anonymized personal data in an LLM (which is highly undesirable), the only legal path is having the appropriate customer consent or another legal basis. Let’s look at it:

Consent of the personal data subject. In theory, you can include a clause in the user agreement: “the customer authorizes the company to transfer their personal data for processing to automated systems of partners, including artificial intelligence services, for such-and-such purpose (for example, to provide responses to customer inquiries).” If the customer has clearly and knowingly consented, then under Federal Law No. 152, processing is allowed. But! Consent must be specific and informed. What exactly will you write? “...to third-party services like ChatGPT (OpenAI, USA)” — the customer may get scared and refuse consent. In addition, consent does not relieve you of the obligation to ensure security. If the data leaks, the customer may withdraw consent and file a claim that you did not ensure its protection. Consent is not immunity from a data breach. Therefore, relying on consent as protection is a weak position.
Contractual basis. Some types of processing can be justified by the need to perform a contract with the data subject. For example, a customer asks a question — the company uses AI to answer it, supposedly as part of providing consulting services. But that is a stretch. More accurately: if the customer themselves interacts with the AI (for example, a chatbot on a website that states it runs on an external AI), then sending their data is part of the service, and this can be spelled out in the terms of the offer. However, again, the risks must be disclosed. Plus, a foreign service means cross-border data transfer, and a contract will not help you bypass the requirement for adequate protection abroad.
Anonymization as a condition. As noted, the law expressly requires anonymization for research. In other words, without anonymization, it is not allowed, even with consent, if it is just “for a better answer.” The exception is if a person truly needs an answer only by personalizing it, in which case it is better not to call an external AI and instead do it manually or locally.
Exceptions. If you happen to have a case that falls under the exceptions in Article 6 (for example, the data is publicly available, or life protection is needed — unlikely to apply to LLMs), then it may be allowed. But such exotic grounds are unlikely to fit business use cases.

There are no precedent examples: so far, no company has openly announced “we collect consents and send customer personal data to ChatGPT.” Most likely, lawyers at all major companies advise against doing that. Even if the customer gives consent today, tomorrow they may change their mind — then you would need to delete everything from OpenAI, which is impossible.

Recommendation: avoid using non-anonymized data in LLMs altogether. The exception is when the data is not personal in the first place, or you are working strictly within Russia with a provider that you have a contract with and everything complies with Federal Law No. 152 (for example, a Russian cloud provider certified to store personal data). Then at least there is no cross-border transfer, and protection can be addressed in the contract. But even in that case, it is better to inform customers in your policy that you use AI services (without details, but so it is not a surprise).

Let’s sum up this section: customer data should be sent only in anonymous form, or not sent at all — everything else is too legally risky. Now, based on that, let’s look at the available alternatives: how else you can use LLMs and AI technologies without violating privacy. This will be useful for anyone who does not want to give up the benefits of AI entirely, but is also not ready to sacrifice data.

8. Alternatives: how to work with LLMs without violating confidentiality

There are several strategies that allow businesses to use LLM capabilities with minimal data risk. Below, we will cover these approaches, from full control (self-deployment) to compromise solutions (anonymization, trusted services). We will also include a comparison table to clearly show the pros and cons.

8.1. Self-hosted LLM (deploying the model on your own infrastructure)

Self-hosted LLM means the company deploys the model on its own servers (on-premises or in a private cloud), and all data is processed internally without leaving the organization. This is the best option from a confidentiality standpoint: the data remains under the company’s full control.

What is needed for this: either use available open-source models or purchase a commercial version of the model for on-premises installation. Fortunately, after Meta released LLaMA (2023), many high-quality open models have appeared (Llama-2, Falcon, GPT-J, RuGPT3, Sber models, etc.). They can be run on your own servers or powerful workstations. For example, Llama-2 13B can handle many tasks, and it can be deployed in SberCloud or Yandex Cloud in an isolated environment.

Pros of self-hosting:

Data does not leave anywhere, and there is no cross-border transfer.
You do not need to worry about someone else’s service policies — you are in control.
You can fine-tune the model for your needs without worrying about leaks.
Compliance with Federal Law No. 152 is easier to ensure: the data stays in your personal data information system, and you can certify the system to meet personal data security requirements.

Cons:

It requires powerful hardware (GPU) and specialists who can deploy and maintain the model. LLMs are large — for example, a 13-billion-parameter model requires tens of gigabytes of GPU memory. There are still no open-source equivalents with GPT-4-level quality, so you have to accept lower capability.
Updates and maintenance are on you. External services keep improving all the time, while locally you will be stuck on the current version unless you invest in upgrades.
Some tasks (for example, complex code generation) may be beyond the capabilities of smaller models. That means quality may drop.

Still, many large companies are taking this route. For example, Sber is developing GigaChat and internal models for its own use — clearly, neither Sberbank nor other banks send customer data to ChatGPT; they use their own AI systems (even if they are less powerful for now). Just AI notes: customer requests for a model that must run locally (on-premises) come up very often. This reflects a broader trend: businesses prefer private AIeven if it is more expensive and more complex, in exchange for security guarantees.

8.2. Fine-tuning models on anonymized data

A close variant of self-hosted is fine-tuning. This is when you take a pretrained model (for example, Llama-2 or YandexGPT) and further train it on your own data so it handles specific tasks better. Fine-tuning can be done either on your own infrastructure or with a trusted provider, but the important thing is that training should use anonymized or synthetic data.

For example, you want to train a model to answer your customers’ questions. You can take past support ticket conversations and fine-tune the model. But those conversations contain names, contact details, and order information — before training, the dataset needs to be cleaned: replace names with neutral placeholders ("Ivanov" -> "<NAME>"), remove addresses or replace them with a template ("<CITY>"), and so on. As a result, the model will learn the right answers, but it won’t memorize personal information, since it won’t be in the dataset.

Benefits of a fine-tuned model:

It is trained specifically on your domain and responds with your product’s specifics in mind. That is better than relying on an external general-purpose AI that may get things wrong in your environment.
After training, the model can work offline, again without sending data outside.
Anonymizing the source data before training protects against the model leaking secrets. And in an offline model, no one from outside will be able to dig into it.

Drawbacks:

Training is an expensive process (you need powerful GPUs and a lot of time), especially if the model is large.
Not every open model can be fine-tuned well without degradation — you need an ML specialist to choose hyperparameters and prepare the dataset.
Every time the data changes significantly, you will have to retrain or fine-tune again.
And the model base is still open-source (it may itself have contained some unnecessary internet data). But here we are still partly trusting the developer to have cleaned the training data.

Fine-tuning is a popular approach, and cloud providers offer it too (for example, Amazon Bedrock or SberCloud ML Space). But from a privacy standpoint, it is better to do it either on-prem or in a certified cloud in Russia.

8.3. Local inference: using local models without sending data

If you do not want to take on heavy infrastructure, there is also an intermediate option: local inference using optimized CPU-based models. There are slimmed-down versions of LLMs (quantized) that can run on standard PCs or server CPUs without GPUs, albeit more slowly. For example, Llama-2 in 4-bit quantization can run on computers with 16 GB of RAM. There are projects like GPT4All that let you download an assistant and run it locally on a laptop.

For business, this is an option to embed a local LLM in an applicationso it processes data without calling an API. For example, a document management system can include an AI module that summarizes a document. If it uses a local model, the document never leaves the system.

Pros:

Full autonomy. Works even offline.
No external API costs (which can be significant with OpenAI).
Control over what the model does — you can integrate logic, restrict outputs, and so on.

Cons:

Speed and power are limited. On CPU, the model generates more slowly than in the cloud on GPU.
Quality may be lower, especially if the model is heavily compressed.
Limited context: smaller models cannot keep large documents in memory, unlike GPT-4 with a 32k-token context.

Still, for many tasks (short answers, classification, information extraction), local models are a good fit. At the very least, when you start implementing AI, it is worth trying an open-source model on test datato see whether it handles the job. Often it turns out that it covers 80% of tasks, and the remaining 20% require something more advanced.

8.4. Russian APIs and solutions with privacy guarantees (example: GigaChat, Yandex)

If you still need a powerful AI comparable to foreign alternatives, but cannot send data abroad, it makes sense to consider domestic services. In Russia and friendly jurisdictions, LLM APIs have appeared that are positioned as compliant with local legal requirements:

Sber GigaChat API — Sberbank has promised to open access to the GigaChat API. For now (late 2025), it is still in test mode. Sber says it pays special attention to security in its LLM. Using GigaChat through SberCloud will likely comply with Federal Law 152: Sber’s data centers in Russia are certified, and there is a cloud environment for personal data (PDN) at security level UZ-1. You can sign a personal data processing agreement with Sberbank-Service (as with any IT outsourcing provider). In that case, transferring data to Sber is not cross-border transfer and not disclosure to a third party, but processing assignment (Article 6, Part 3 of Federal Law 152) — the law allows personal data to be transferred to a processor under a contract. Of course, the processor is required to maintain confidentiality and security measures. Sber is a trusted organization (a major player that understands its responsibility). So the option is to use a Russian cloud LLM service and document everything properly (contract, guarantee that the data will not leak).
Yandex GPT — Yandex recently opened access to YandexGPT 5.1 Pro. You can try it via API or through Yandex Cloud. The situation is similar: Yandex is a Russian legal entity and complies with personal data law (it stores everything on Russian servers). With a contract in place, you can legally process personal data through Yandex’s service. How powerful the model itself is remains to be seen, but for Russian-language tasks it may understand local context better (as claimed, Russian LLMs have fewer hallucinations on Russian legal nuances).
Sputnik, Silero, etc. — There are other solutions too: for example, Sputnik from Rostelecom (originally a search-related project, possibly now with AI), and models from AI institutes. If they are available, their advantage is that they are guaranteed to comply with our laws or can be deployed inside the country.

Benefits of Russian services:

Compliance with Federal Law 152 (data stays in Russia, and oversight is possible).
Language and cultural localization — sometimes ChatGPT makes mistakes in Russian realities, while a domestic model may be better trained on Russian data (laws, naming conventions).
You support the local AI business, which is also an argument in today’s geopolitical climate.

Drawbacks:

For now, quality may lag behind global leaders. Independent tests show that GigaChat 2.0 and YandexGPT are improving, but they still "trail top Western or Chinese LLMs." However, they are enough for many routine tasks.
Access restrictions — you need a contract, a cloud account, and often a closed preview.
Scale and extra features: foreign models have richer ecosystems (plugins, integrations). Ours still offer only a minimal API.

Still, for many companies, Russian LLMs are the best choice: with minimal legal risk. For example, government organizations are obviously prohibited from uploading citizens’ data to foreign services — they prefer domestic solutions or open-source on-prem deployments.

8.5. Intermediate options: proxy anonymizers, encryption, and trusted execution environments

There are hybrid approaches that let you use the power of external models without exposing real data. One of these is the implementation of a special proxy server for dynamic anonymization.

Here’s how it works: a proxy sits between your application and the external LLM API, intercepts employee requests, and strips out all sensitive data on the fly. We’ve already touched on the steps in part:

Intercepting the request: the user types something like, “Generate an email to client Ivanov Ivan regarding contract No. 123 about an extension.” The proxy catches this text before it is sent.
PII detection: using rules and NER models, the proxy identifies personal data and confidential fragments—“Ivanov Ivan,” “contract No. 123.”
Transformation: all identified fragments are replaced with placeholder labels, and the mappings are stored in an internal lookup table. For example, “Ivanov Ivan” -> <NAME1>, contract No. 123 -> <DOC1>.
Secure sending: the cleaned-up request (“Generate an email to client <NAME1> regarding <DOC1> about an extension”) is sent to the external LLM. The external model never sees the real names—it only sees abstractions.
De-anonymizing the response: the response from the LLM comes back with the same labels. The proxy takes the original values from the table and puts them back in place of the labels. The user receives a meaningful answer with the real names already restored, without even realizing that the AI actually processed a sanitized request.

This approach is described, for example, in the Jay Guard solution from Just AI. They built a proxy “guard” that works with popular models (ChatGPT, GPT-4, Claude, Google Gemini) and also supports Russian models (YandexGPT, Sber GigaChat). In other words, a universal filter.

The advantage of a proxy anonymizer is obvious: real data never leaves the company. Even if the external service stores requests, it only stores labels. Of course, in theory, a determined attacker could infer context from the text, but there will be no explicit personal data. And the entire mapping table is stored inside the organization and never leaves it.

An example architecture with an anonymizing proxy gateway (an intermediary server) that protects data when connecting to an external AI service:

Fig. 1: Dynamic data anonymization flow for a request to an external LLM. The proxy filters sensitive data, replaces it with labels, and then restores the original values after the response is received.

Another approach is encrypting data before sending it. Option: fields that are not critical for processing but do contain personal information can be encrypted. For example, if you are sending the model email correspondence for training, you can symmetrically encrypt all email addresses. The model will see unreadable strings and won’t be able to use them meaningfully. But they wouldn’t help anyway. The catch is that if the model’s response later needs to be decrypted, you have to keep the key. Usually, it is simpler to replace data with labels than to encrypt it (encryption makes sense if you need to preserve a strict format or avoid exposing even the string length).

Ideas are also emerging around confidential computing: running an LLM in a Trusted Execution Environment (TEE)—that is, even if the model is in the cloud, it operates in encrypted memory and the data is visible only inside the encrypted container. The client uploads encrypted data, the AI processes it somehow there (possibly with homomorphic encryption), and returns the result without ever “seeing” the data itself. These technologies are still highly experimental (for example, MTS’s “Cooper” project for secure computing). They are not widely deployed yet, but they may be in a few years.

Bottom line: proxy anonymization is already a real, working compromise tool. It allows companies to use top-tier AI models (available only via API) without exposing confidential information. Of course, dictionaries and templates need to be configured properly (figuring out how to detect all phone numbers and all full names in text is a nontrivial task). But Just AI and others have already developed solutions. The important thing is that such a proxy is not a silver bullet: it reduces the risk of personal data leaks, but it does not eliminate the risk of leaking de-identified information. Plus, you can’t rule out the possibility that some unrecognized entity slips through (for example, a rare name that NER failed to detect). That’s why the proxy is part of a comprehensive security system, as the Jay Guard authors note.

Below, we offer a table summarizing the alternatives discussed:

8.6. Table: Overview of alternative solutions and their characteristics

SolutionWhere data is processedControl and securityExamples/toolsFeatures
Self-hosted LLM (On-Premises)	On the company’s own servers (in Russia)	Full control; data never leaves the organization’s environment. Requires powerful hardware and expertise	Llama-2, GPT-J, RuGPT3 on your own servers; enterprise versions of GPT for on-prem	+ Confidentiality, compliance	+ No dependence on external services	- High deployment and maintenance costs	- Quality depends on the chosen model (it may be behind SOTA)
Fine-tuning a local model	Training on your own data (de-identified), then running on-prem	Training data can be anonymized; the resulting model is kept by the company.	Training Llama-2 on customer requests; AutoML for text (example: Sber AI Cloud fine-tuning)	+ The model is adapted to the company’s tasks	+ We do not share data with anyone	- ML specialists and computing resources are required	- Risk of overfitting or pattern leakage if the data is poorly anonymized
Local inference (desktop/edge AI)	On devices or local servers (possibly CPU)	Data is not sent over the network; processing is local.	GPT4All, Local LLM (for example, RWKV, Mistral 7B) on workstations	+ Maximum autonomy	+ Low compliance requirements (no data sharing)	- Limited performance and context	- Suitable for simple tasks or small data volumes
Russian cloud LLM services	In Russian data centers (provider cloud)	Data stays in Russia; you can sign a Controller-Processor agreement with the provider.	Sber GigaChat API, Yandex GPT, Huawei (Astra), etc.	+ Compliance with Federal Law 152 and data localization	+ Lower risk of foreign government interference	- Model quality may be lower than the market leaders	- Requires trust in the provider (even if legally backed)
Proxy anonymizer + external LLM	Processing in an external LLM (abroad), but only after anonymization through a local proxy	Real personal data never leaves the company; the external service receives only aggregated or masked data.	Just AI JayGuard (anonymization before GPT-4, Claude, etc.); custom proxies with NER (SpaCy) + RegEx	+ Using the most powerful AI models with minimal risk of personal data leakage	+ Does not require your own GPU — we use a cloud GPU	- Complex to set up (you have to continuously maintain dictionaries and masking algorithms)	- The external service still sees de-identified but confidential data (for example, support request texts without names)
Encryption/TEE when using an external LLM	External LLM (foreign) — data is sent encrypted or processed in a protected environment	Experimental methods: the provider does not see the raw data and operates blind or in a secure container.	Confidential computing mechanisms (homomorphic encryption, Secure Enclave); there are still few projects in production.	+ Theoretically the highest privacy level (even the provider will not know the data)	- Still at the research stage / limited pilots	- Significantly slower and more complex than standard processing

(Note: in any case, it is recommended to execute the necessary NDAs, process only the minimum data necessary, and comply with internal information security policies.)

The table shows that an alternative to using ChatGPT directly with raw data exists — from the simple “do everything yourself” approach to the more sophisticated “let ChatGPT work, but don’t tell it anything personal.” The choice depends on the company’s capabilities: whether it has resources for its own infrastructure, how critical answer accuracy is, and of course how much risk is acceptable.

For a small business, it may be optimal to stick to Russian or open-source solutions. For a large company, it may make sense to invest in its own AI platform or buy an enterprise version of Western models, but in an isolated mode. By the way, Microsoft offers a product Azure OpenAI — GPT-4 in Azure’s private cloud, where they guarantee that customer data does not go into the general model. But it is still a foreign cloud, although under a contract with Microsoft (which, unfortunately, is not operating in Russia right now).

To conclude the technology review, let us note: security is a process. Any solution requires ongoing support: updating models (so there are no vulnerabilities), monitoring what data goes into them, and controlling employee access. More on that in the next section, which is dedicated to practical recommendations.

9. Practical recommendations for minimizing risk

Regardless of the chosen approach, business owners need to develop organizational and technical measuresto secure work with LLMs. Below is a kind of checklist of what to pay attention to when implementing AI in business processes involving customer data.

9.1. Internal company policies and procedures: what to spell out and implement

The first thing to start with is creating internal policies for AI usage. Just as information security policies were introduced before, now it is necessary to add a section on AI (or create a separate document).

What should be included in such a policy:

Prohibition or restrictions on entering confidential information into unauthorized AI services. Spell it out clearly: “It is prohibited to use public neural networks (ChatGPT, Bing AI, etc.) to process the following information: customer personal data, trade secrets, company financial and legal documents, project source code...”. For especially sensitive departments, a complete ban on using external AI at work may be appropriate. Such a policy can be strict, but necessary — as noted at Kaspersky Lab, for highly regulated industries or departments with special data, this is the only option.
Approved tools. If the company has deployed its own secure tool (for example, a corporate chatbot based on a local model), the policy should state: “For tasks X, only the approved solution Y must be used. The use of any third-party AI tools for these tasks is prohibited.”. Some organizations create a whitelist of approved AI services.
Data classification and usage modes. A good practice is to define data categories and the corresponding AI usage mode. For example: public data — can be used in any AI (for example, press release texts); internal non-confidential data — can be used in approved AI services; confidential data — only in internal models; secret data — no AI. This matrix should be formalized. Kaspersky recommends creating a policy that “provides for different modes of AI use for different types of data” — the most universal approach.
Procedure for approving exceptions. A situation may arise in which an employee really needs to run something through ChatGPT (for example, code for debugging), and formally that is prohibited, but there is no other option right now. You need to provide a process: perhaps through a request to the information security team or the department head with justification. That way, it becomes a controlled exception. The policy should describe how such requests are reviewed.
Obligation to anonymize before sending. If the use of external AI for certain data is still allowed, specify the requirement: “Before sending any information containing customer or company details, the employee must remove or alter those details (anonymize them)”. In other words, train people to manually redact names and contact details. You can even give an example: before — “Write a letter to Ivanov offering a 10% discount on product Z”; send — “Write a letter to <customer> offering a discount...”. Yes, a person is not an algorithm and can make a mistake, but at least the procedure forces them to stop and think.
Tracking AI usage. It is useful to introduce a rule requiring employees to report which AI tools they use at work, at least for risk assessment. You may also create a register of such cases.
Penalties for violations. To keep the policy from becoming just paperwork, responsibility must be defined. For example, a violation of the ban (for example, uploading a customer database into a chatbot) = disciplinary action, up to termination for a serious violation (as Samsung announced). Of course, apply this case by case, but if people are warned, they are, in theory, more likely to think twice.

Overall, the policy should “cover different departments and types of information”and be detailed, and reviewed regularly, because technology changes. By the way, it can be included in the overall Personal Data Processing Policy by adding a section on AI use — then it will also be transparent to customers in the public policy that you take the issue seriously. As specialists advise, right now “this is the minimum set of requirements for any company working with personal data… ignoring it can lead to fines…”.

9.2. Employee training: digital hygiene and awareness of AI risks

Even the best policy will not work if employees do not know about it or do not understand its importance. That is why training and communication are key elements.

What needs to be done:

Hold a training session or seminar for staff on the risks associated with using AI. Explain in plain language what can happen if confidential data is entered into a public service: leaks, fines, dismissals. Give examples (Samsung, data leaks, etc.—there are plenty of materials available). Kaspersky notes that “First and foremost, this is about training employees on what risks AI brings: from data leaks to hallucinations and prompt injection.”, and everyone has to complete it.
Send out quick-reference guides/reminders. For example, a poster or PDF: “Never enter into ChatGPT anything you wouldn’t be ready to make public!” — this should become a habit, front and center. Moscow Region put it this way for citizens: “Talk to AI as if everyone else will see it”. For employees, you can add: “Keep in mind: everything you send to an external AI permanently leaves our protected perimeter”.
Specialized training for managers and IT. Department managers should be able to evaluate employee requests: whether a given AI use case should be allowed. And IT/security specialists need to understand the technical measures we discussed (anonymization, proxies, etc.). It may make sense to appoint an AI compliance owner who can advise colleagues.
Ongoing training and regular updates. In cybersecurity, people have long understood that a one-time lecture isn’t enough; you need regular refreshers. The same goes for AI—include data privacy topics in annual security training and add new case studies. Kaspersky recommends “regular adjustment of measures and policy as AI use scenarios change”. It would also be good for employees to speak up themselves: “We found a new AI service, can we use it?”—so that a culture of thoughtful use develops, rather than shadow use (Shadow AI).
Involve employees. If you simply ban everything, they may start hiding usage (like people installing torrents despite bans). It’s better to explain where AI can genuinely help them work safely—for example, by providing an internal tool. And emphasize ethics: not just penalties, but responsibility to customers. In other words, “our customers trust us with their data, and we have no right to carelessly leak it.”

It’s important to make it clear that the risks are not abstract. As one CEO said: “A data leak is not just a problem for big companies; it is a direct threat to every entrepreneur.”. The same is true for every employee: the threat of losing a job or harming the company. Training should move this from theory into practice—for example, by simulating a scenario: “You entered a query with these data, and a month later those data surfaced in someone else’s response—the client learned we disclosed them... Imagine the reaction.” Exercises like that can really reinforce caution.

9.3. Technical measures: access restrictions, DLP, and AI usage monitoring

Policies and training alone won’t solve the problem— technological barriersare also needed to minimize human error:

Restrict access to external AI services on corporate networks/devices. At the firewall level, you can block requests to known APIs (api.openai.com, etc.), or conversely allow only certain proxies. Samsung, as we saw, blocked all such services on work devices. That is an extreme step, but for organizations with higher requirements (banks, government agencies) it is justified. Another option is to prohibit software installation such as desktop AI apps (via group policy).
Device policy (MDM): if the company issues laptops/smartphones, configure MDM so arbitrary AI apps can’t be installed on them and web access to those services is restricted. Also prohibit use of personal devices for work tasks so employees can’t bypass controls.
Data Loss Prevention (DLP) systems**. Modern DLP tools can detect confidential information being sent to the internet—usually this is about email/messengers, but they can also be trained to inspect web requests. If DLP sees text containing, for example, 16 digits like a card number being sent to chat.openai.com, it can block the action and alert security. Of course, DLP needs to be tuned to patterns for personal data and trade secrets. It is a complex and not cheap tool, but it is useful for large companies to have. At the very least, if someone violates policy, DLP will record the incident (evidence for an investigation).
Logging and log analysis. If you use a corporate proxy or your own AI solution, log the requests. You can do this anonymously—not to spy, but to identify potentially risky behavior, for example, an employee tried to enter passport data. Then you can have an individual conversation with that person.
Role-based access control. Kaspersky’s policy suggests considering “a role model for applying the appropriate security policy”. That means some people may have exceptions, while others may be barred altogether due to their role. For example, IT developers may be allowed to use Codex (GitHub Copilot) for non-sensitive code, while finance staff may be prohibited from using ChatGPT to prepare reports containing employees’ personal data. This can be implemented through access separation: for example, developers have internet access to domains X,Y, while finance staff do not.
A safe environment for experimentation. If the company still wants to experiment with external AI for research, it can create an isolated environment (a sandbox): a separate computer/VM with no access to real data, where employees can “play around” with ChatGPT only using fictional or public data. That way they won’t do it on the main system.
Database and channel encryption. This is a general requirement under Federal Law 152-FZ—if any data are transmitted at all (for example, between your service and a proxy anonymizer), use channel encryption (TLS) and store keys securely. Then even if the channel is compromised, the attacker won’t get the data in plaintext. Infrastructure security is fundamental and must not be overlooked.

Of course, there will be no zero-risk scenario: the weakest link is always the human factor. So combine measures: train -> restrict where needed -> add filters -> review logs. Experts also refer to this as a “multi-layer response system.”

9.4. How to safely experiment with LLMs in business

Many entrepreneurs read about AI and want to immediately try where it can help in their business processes. That’s the right instinct—the technology is promising. Here’s a short, step-by-step guide step by stepfor introducing LLM projects while minimizing risk:

Idea and data assessment: Decide what task you want to use the LLM for (for example, customer auto-replies, review analysis, or marketing copy generation). For that task, assess what data the model needs. Are these public facts or customer data? If it’s customer data, how sensitive is it? At this stage, decide right away: “Can we anonymize this data and still have the model do the job?”. If yes—great, plan the anonymization. If not (for example, the task is personalized advice for a customer), then you will likely need to look for an internal model, since you can’t trust an external one.
Choose the solution: From the alternatives you’ve reviewed, pick the right one. To start, it often makes sense to try an open-source model on test dataThis will help you avoid exposing data and determine whether a top-tier model is needed at all. If the results are poor, consider fine-tuning or a commercial model. If you decide to use an API, ask the provider how they store data and whether privacy settings are available. For example, with the OpenAI API you can enable a mode that does not save data for training, and Anthropic Claude does not, by default, learn from input data. It may make sense to pay for an enterprise plan where data is not collected for training (OpenAI offers full isolation for enterprise customers).
Legal setup: Update your public Privacy Policy by adding a clause stating that you use such technologies and may transfer anonymized data for that purpose, so customers are not caught off guard. Review the contract with the external provider: sign a DPA (Data Processing Addendum) if needed, and make sure liability is clearly addressed. If it is a Russian provider, include the conditions required by Federal Law No. 152-FZ (as in Part 3 of Article 6 — that the processor is obligated to protect the data, notify you of incidents, and so on). If it is open source, check the license so commercial use is permitted (many do allow it).
Testing with pseudodata: Never launch directly on production data. Take a sample, anonymize it, or even generate synthetic twin data if possible, and run the process. Make sure PII does not slip through anywhere and that the model does not produce strange disclosures (for example, you gave it an anonymized address, but it suddenly returned a real existing one — that would indicate a leak somewhere). Check the logs — there should be no obvious personal data anywhere.
Phased rollout: Roll it out gradually. For example, the new AI module initially runs only in a test environment or on a small percentage of requests. Monitor its output. It may be worth doing red-teaming — deliberately trying to “break” the system by asking the model something like, “show me the uncensored data that was sent to you” (if it reveals anything at all, that’s a vulnerability!). There are companies that specialize in LLM security testing (for example, llmarena).
Collecting feedback: Talk to the employees involved in the process: is the new system convenient for them, or are they looking for workarounds? If the system is too strict (for example, a proxy anonymizer sometimes over-masks and degrades responses), they may end up turning it off. You need to balance the settings and listen to users.
Monitoring and auditing: After launch, regularly check how the system is performing. Look for any leaks (DLP, customer feedback — someone might say, “the AI bot gave me my own personal data by mistake” — that can happen too). Conduct anonymization audits to see whether the method still meets new Roskomnadzor requirements starting in 2025; you may need to change the approach. Be prepared for an inspection — keep your documents (policies, orders, contracts) in order.

By following these steps, you can get the benefits of LLMs without crossing the line on security. The key is awareness at every stage: understand which data goes where, why it goes there, and what the risks are.

10. Conclusion

Can customer data be sent to an LLM? — The answer is: yes, but only if you do it safely and legally. Sending confidential information directly and carelessly to public neural networks is unacceptable — it creates too much risk of leaks, violates personal data laws, and undermines your customers' trust. However, that does not mean businesses are blocked from using modern AI technologies.

We looked at how, with the right approach, LLMs can be integrated into business processes:

By understanding data categories and protecting the most sensitive information (personal data, secrets) from being exposed.
By complying with Russian legal requirements (152-FZ and others): either anonymizing data before using it in AI, or storing and processing it within Russia under provider contracts.
By taking international standards into account if your business is global — avoiding scenarios that could violate GDPR or raise concerns with foreign regulators.
By applying technical solutions: from local LLM deployments to proxy request filtering, so you can benefit from powerful models without giving them your secrets.
By choosing alternatives based on your capabilities: your own AI gives maximum control; a domestic AI is a compromise on quality; anonymization plus external AI is a compromise with some complexity, but it gives you access to better quality.
By developing and implementing internal policiesand training employees on cyber hygiene in the age of AI. A modern employee should understand that cloud AI is not a magical black box, but a potential “leak waiting to happen.”
By documenting and contractually formalizing all the key points so that customers, partners, and regulators can see that you handle data responsibly, even when using cutting-edge technologies.

In the end, it all comes down to balancing innovation and security. LLMs can deliver enormous value to business: saving time (drafting documents, answering questions), generating insights (data analysis), and improving customer service (smart chatbots). Refusing to use them means ceding ground to competitors. But rushing into AI blindly and risking your reputation and finances is not an option either. The optimal solution is to “turn on AI wisely”: think it through, secure it, and then use it.

For entrepreneurs in Russia today, awarenessmatters. Those who understand the rules of the game (152-FZ, GDPR), ensure data anonymization, and set up the right processes can safely use AI and sleep without worrying about inspections or leaks. Those who ignore this risk becoming the subject of negative headlines.

We hope this article helped shed light on the more complex aspects of the topic. As practice shows, following the principle of “Do no harm (to data)”allows business to stay on good terms with both customers and neural networks. Be innovative, but responsible — and modern LLMs will become a reliable assistant rather than a source of problems.