152-FZ and Foreign AI: How to Use It Legally Without Sharing Extra Data

In short: Russia’s 152-FZ does not prohibit businesses from using foreign AI services as a class. The restriction does not arise from the fact that you use ChatGPT, Claude, Gemini, or another tool, but from what data you send there, on what legal basis, to whom exactly it is transferred, where the original database is stored, whether Roskomnadzor has been notified, and whether you can prove the security of the processing. For most tasks, the most practical approach is not to send personal data to a foreign model, but to anonymize, mask, or replace it with synthetic values in advance.

AI Summary
What 152-FZ Regulates
What Counts as Personal Data
What Processing Falls Under the Law
Can You Use Foreign AI
Why Anonymization Solves Most of the Risk
How to Anonymize Data Before Sending It to AI
Free OpenAI Privacy Filter Model
Cross-Border Data Transfers and Foreign Providers
What Documents and Processes an Operator Needs
Liability and Fines
Practical AI Implementation Checklist

AI Summary

152-FZ regulates not "AI," but the processing of personal data. If a prompt, file, audio file, screenshot, or spreadsheet contains data about an identified or identifiable person, the law applies.
Foreign AI tools can be usedbut not as a gray area: you need a lawful basis for processing, compliance with data minimization principles, operator documentation, an assessment of the transfer, and control over the provider.
The best baseline approach is to anonymize before sending. Remove full names, phone numbers, email addresses, street addresses, order numbers, contract numbers, card numbers, medical data, voices, faces, and rare combinations of attributes.
Pseudonymization is not the same as anonymization. If you still have a mapping table Client_001 -> Ivan Petrovthe data usually remains personal data within your own environment.
OpenAI released Privacy Filter under Apache 2.0. It is a free, locally runnable model for detecting and masking PII in text; it can be integrated as a data redaction layer before sending information to an external AI.
Liability has increased. Under Article 13.11 of the Russian Code of Administrative Offenses, legal entities face fines for ordinary violations, localization issues, notification failures, breaches, and repeat breaches; under the new offenses, turnover-based fines of up to 500 million rubles are possible.

What 152-FZ Regulates

Key takeaways: 152-FZ protects a person's rights when their personal data is processed. For AI, that means one simple thing: what matters is not the tool, but the data you upload into it.

Federal Law No. 152-FZ of July 27, 2006, "On Personal Data," is Russia’s core personal data law. It defines what personal data is, who the operator is, which actions count as processing, and under what conditions data may be collected, stored, used, transferred, anonymized, and destroyed.

[Fact]: In the current version of 152-FZ on ConsultantPlus, the law’s key chapters are listed: general provisions, principles and conditions of processing, data subject rights, operator obligations, oversight, and liability (ConsultantPlus, 152-FZ).

For businesses, the main takeaway is this: if a company collects leads, runs a CRM, stores a customer database, processes resumes, records calls, analyzes support tickets, or uploads contracts into an AI service, it is almost always a personal data operator. An operator can be not only a large corporation, but also a sole proprietor, online store, clinic, school, agency, SaaS service, HR team, law firm, or development studio.

152-FZ does not say, "you cannot use artificial intelligence." It says something different: personal data must be processed lawfully, fairly, only for specific purposes, in the minimum necessary volume, and with protective measures. So the question "can we use ChatGPT" is legally incorrect. The right question is: "what data are we sending, why, to whom, on what legal basis, and what happens if it leaks?"

What Counts as Personal Data

Key takeaways: Personal data is not just a passport. Any information related to a directly or indirectly identified person can qualify as personal data.

Article 3 of 152-FZ defines personal data as any information relating to a directly or indirectly identified or identifiable individual. The same article defines an operator as a person or organization that determines the purposes, content, and actions involving personal data; processing is a broad set of operations, including collection, recording, storage, use, transfer, anonymization, deletion, and destruction (Art. 3 of 152-FZ).

In practice, the following are often considered personal data:

full name, date of birth, gender, citizenship;
phone number, email, delivery address, registered address;
passport, SNILS, INN, driver’s license;
order number, customer ID, contract number, if the record can be linked to a person;
IP address, cookie ID, device ID, advertising ID, login, user ID;
face photo, video, voice, biometric templates;
resume, application form, work history, salary expectations;
medical information, diagnoses, test results;
support correspondence, call recordings, chat inquiries;
geolocation, route, visit history;
a combination such as "42-year-old woman, chief accountant at LLC X, living in the small town of Y," if the person can be singled out based on the combination.

Important: the same snippet can be safe or risky depending on context. The phrase "the customer bought a printer" by itself usually does not identify a person. But if it is paired with an order number, email, city, rare product, and date, the set can already become personal data.

Higher-Risk Categories

The law separately identifies special categories and biometrics. Special categories include, for example, information about racial and ethnic origin, political opinions, religious beliefs, health status, and intimate life. Biometric personal data are details about a person’s physical and biological characteristics that can be used to identify them.

This is especially important for AI. You should not blindly upload the following into a foreign service:

medical records;
patient photos;
call recordings with the customer’s voice;
passport scans;
HR forms with sensitive fields;
litigation documents;
bank loan applications;
tables with children, students, patients, or debtors.

Such data requires a separate legal assessment and often a local or closed environment.

What Processing Falls Under the Law

Key takeaways: Sending data to AI is not "just a prompt." It can be use, transfer, provision of access, storage, organization, and sometimes cross-border transfer.

The law uses a very broad concept of processing. Article 3 explicitly lists collection, recording, systematization, accumulation, storage, clarification, retrieval, use, transfer, dissemination, provision, access, anonymization, blocking, deletion, and destruction (Art. 3 of 152-FZ).

In the context of AI, processing will include:

pasting a customer inquiry into a chatbot;
uploading an Excel file with customer data to a model for segmentation;
sending a call recording for transcription;
pass a CRM screenshot to a vision model;
ask AI to review a contract that includes a person's full name and personal details;
use an AI assistant in a help desk that can see customer history;
send data through an API to an overseas endpoint;
save the prompt and the response in application logs;
pass the prompt to an aggregator that then routes it to an upstream model.

Even if an employee "just pasted text into a web interface," for the company this may still be a violation of internal policy and legal requirements if the text contains personal data and the company has not properly documented that processing.

Can foreign AI tools be used

Key takeaways: yes, foreign AI tools can be used if the requirements of Federal Law No. 152-FZ, the service terms, sanctions restrictions, customer contracts, and information security policy are not violated. The safest approach is to send only anonymized data.

The law does not contain a general ban on foreign AI services. But when using OpenAI, Anthropic, Google, Mistral, Perplexity, DeepL, Midjourney, ElevenLabs, Notion AI, Microsoft Copilot, and other tools, a business needs to answer a few questions:

Does the request contain personal data? If not, Federal Law No. 152-FZ is usually not the main restriction. Commercial secrets, copyright, NDAs, and the provider's terms still apply.
If personal data is included, is there a legal basis for processing? Consent, contract, legal obligation, legitimate interest, or another basis.
Is the purpose of the AI processing compatible with the original purpose of collecting the data? You cannot collect a phone number for delivery and then use it to train an external system without a legal basis.
Is cross-border transfer taking place? If data is transferred to a foreign legal entity or to the territory of a foreign state, Article 12 of Federal Law No. 152-FZ applies.
Who receives the data? The provider itself, an aggregator, a contractor, subprocessors, cloud hosting.
Are prompts, files, and responses stored? If so, where, for how long, and who has access.
Is the data used to train the model? For corporate APIs, this can often be turned off or may not apply by default, but it needs to be checked in the contract and settings.
Can the data be deleted? Retention periods, logs, backups, and abuse monitoring matter.
Has Roskomnadzor been notified? Notifications may be required both for processing and separately for cross-border transfer.
Has localization of the primary database of Russian citizens been completed? When collecting data from Russian citizens over the internet, recording, systematization, accumulation, storage, updating, and retrieval must be supported using databases located in the Russian Federation.

Practical takeaway: foreign AI is best used for public, synthetic, aggregated, or anonymized data. For customer, employee, patient, student, and applicant data, a separate setup is needed.

Why anonymization solves most of the risks

Key takeaways: if after processing it is impossible to determine who the data belongs to without additional information, the risk under Federal Law No. 152-FZ drops sharply. But a mask like "Ivan -> Client_1" without deleting the mapping table is not true anonymization.

Federal Law No. 152-FZ defines anonymization as actions after which it is impossible, without using additional information, to determine the personal data's ownership to a specific subject (Article 3 of Federal Law No. 152-FZ).

For AI, this is a key tool. The model often does not need to know the real person. It needs the structure of the problem:

Task	What the model wants	What can be sent instead of personal data
Case summary	The essence of the issue and the tone	"Customer A is requesting a return because of a defect"
Ticket classification	Category, urgency, department	Text without full name, phone number, email, or order number
Contract review	Risks in the terms	A contract with names, addresses, and details replaced
Sales analysis	Segments and patterns	Aggregates by group without customer IDs
Preparing a reply to a customer	Case context	An anonymized conversation and response template
Employee training	Typical cases	Synthetic examples based on real situations

Anonymization, pseudonymization, and masking

You need to distinguish between three concepts:

Masking - hide part of the value: +7 999 *--12, ivan***@mail.ru. This reduces risk, but the person can sometimes still be identified.
Pseudonymization - replace the identifier with a code: Ivan Petrov -> Client_001. If the mapping table is retained, this is still controlled personal data inside the company.
Anonymization - make it impossible to identify the subject without additional information. This requires removing or reliably separating linking keys, and sometimes aggregating and generalizing.

For foreign AI, it is safer to build the process this way: the original personal data stays within the Russian or internal environment, and only anonymized text, aggregates, or synthetic examples go outside.

How to anonymize data before sending it to AI

Key takeaways: anonymization should be a separate technical step before the foreign API. You cannot ask a foreign model to "first anonymize this database," because the original database would already have been transferred.

The correct architecture looks like this:

Data enters your system.
The system determines whether the data contains personal data and sensitive fragments.
A local module removes or replaces personal data.
A check is performed to make sure no identifiers remain in the prompt.
Only then is the de-identified prompt sent to a foreign model.
The model’s response is returned to your system.
If needed, your system restores the real values inside the protected environment.

What needs to be removed or replaced

Minimum list for filtering:

Full names and initials;
phone numbers;
email addresses;
addresses;
passport details;
SNILS, INN, OMS;
bank cards, account numbers, BIK when linked to an individual;
contract, order, and request numbers, if they can be used to identify a person;
user ID, cookie ID, device ID, advertising ID;
IP addresses and precise geolocation;
faces in images;
voiceprints and source audio;
medical information;
information about children;
rare job titles, events, and combinations of attributes.

Example:

Before	After
"Ivan Petrov, +7 999 123-45-67, order 88421, is complaining about delivery in Kazan"	"The customer is complaining about a delayed order delivery in a major city"
"Maria Sokolova, diagnosis..., OMS policy..."	"The patient reports a medical issue. Details removed; local processing required"
"Send a reply to ivan@example.com regarding contract No. 55-IP"	"Prepare a neutral reply to the client regarding the contract. Identifiers removed"

Why you cannot rely only on a prompt instruction

The instruction "do not store this data" or "de-identify before analysis" inside a foreign AI does not solve the transfer issue. At the moment of sending, the original text has already reached the external provider. That is why anonymization must happen before the API call: using regular expressions, an NER model, a local LLM, a DLP system, a gateway, a proxy layer, or a backend module.

Free OpenAI Privacy Filter model

Key takeaways: OpenAI Privacy Filter is a free model and toolkit for local detection and masking of PII in text. It can be used as a technical data-minimization layer before sending a prompt to an external AI.

OpenAI Privacy Filter is published in the repository openai/privacy-filter on GitHub. In the README, the project is described as a bidirectional token-classification model for personally identifiable information detection and masking in text. It is designed for high-throughput data sanitization workflows where a team needs a fast, context-aware, and configurable model that can run on-premises (GitHub: openai/privacy-filter).

Key features from the repository:

Apache 2.0 license, suitable for experimentation, customization, and commercial deployment;
1.5B total parameters and 50M active parameters;
runs in a browser or on a laptop;
128,000-token context window;
ability to fine-tune on your own data;
CLI opf for one-shot redaction, file processing, pipe mode, evaluation, and training;
model weights published on Hugging Face;
support for tuning the precision/recall tradeoff through operating points.

[Fact]: Privacy Filter detects 8 private span categories: account_number, private_address, private_email, private_person, private_phone, private_url, private_date and secret; at the token level, BIOES tagging and 33 output classes are used (GitHub: openai/privacy-filter).

Important: Privacy Filter is not a "legal compliance button for 152-FZ." The README explicitly states that it is an aid for redaction and data minimization, not a guarantee of anonymization, compliance, or safety. It should be used as one layer of privacy by design: together with rules, DLP, tests on your own data, human review for sensitive processes, and an internal policy for processing personal data.

In practice, the model is useful for:

finding names, phone numbers, email addresses, physical addresses, dates, account numbers, and secrets in text;
masking personal spans before sending a prompt to an external API;
processing long documents without crude chunking;
integrating a local privacy filter into a backend, ETL, help desk, CRM, or RAG pipeline;
train the model further if the company has its own formats for IDs, contract numbers, requests, or client codes.

Practical scenario:

The local service receives a customer inquiry.
Privacy Filter identifies a PII span: name, phone number, email, date, address, or secret.
The system replaces the found spans with safe placeholders: [PERSON], [PHONE], [EMAIL], [ADDRESS].
The cleaned text is sent to an overseas API for advanced analytics or generation.
The final response is checked locally and only then sent to the operator or customer.

This gives the company the quality of overseas models where it is needed, but does not send raw personal data outside.

Cross-Border Transfers and Foreign Providers

Key takeaways: if personal data goes to a foreign individual or a foreign state, the cross-border transfer regime applies. It does not make the transfer automatically impossible, but it requires separate review and notification.

Article 3 of Federal Law No. 152-FZ defines cross-border transfer as the transfer of personal data to the territory of a foreign state to a government authority, a foreign individual, or a foreign legal entity. Article 12 requires the operator, before starting a cross-border transfer, to notify the authorized authority of its intention; the notification of cross-border transfer is submitted separately from the general processing notice (Art. 12 of Federal Law No. 152-FZ).

Article 12 also states that before filing the notice, the operator must obtain from the foreign recipient information about protective measures, conditions for stopping processing, the applicable legal framework, and the recipient itself. Roskomnadzor may request this information and has the right to prohibit or restrict the transfer in cases provided for by law (Art. 12 of Federal Law No. 152-FZ).

For foreign AI, this means:

if the prompt does not contain personal data, there is no cross-border transfer of personal data;
if the prompt contains personal data and is sent to a foreign provider, this is a potential cross-border transfer;
if a Russian aggregator is used but it routes the request to a foreign model, you need to understand who actually receives the data;
if the data is anonymized to the point where the subject cannot be identified, the risk of a cross-border transfer of personal data decreases;
if the data is pseudonymized but a person can still be re-identified from it, the personal data regime may still apply.

Database Localization

A separate risk is the localization requirement. Under Article 13.11 of the Russian Administrative Code, failure to fulfill the obligation, when collecting personal data of Russian citizens via the internet, to ensure recording, systematization, accumulation, storage, clarification, or retrieval using databases located in Russia is subject to fines for legal entities from 1 million to 6 million rubles, and for repeat violations from 6 million to 18 million rubles (Art. 13.11 of the Russian Administrative Code).

This does not mean that once data is localized, it can never be transferred abroad. But the primary database of Russian citizens must be organized in compliance with the Russian requirement, and any subsequent transfers must have a separate legal basis.

What documents and processes does the operator need?

Key takeaways: for AI, you do not need just a single "disclaimer," but a controlled process: a data inventory, purposes, legal bases, policy, notices, contracts, security, incident handling, and employee rules.

The minimum set for a company that uses AI in data processing:

Data map. Which personal data is collected, where it comes from, which systems it passes through, who has access.
Processing purposes. Why the data is collected and whether AI processing is compatible with those purposes.
Legal bases. Consent, contract, legal obligation, or another basis.
Personal data processing policy. A public document and internal procedures.
Roskomnadzor notification. A general processing notice and, if applicable, a separate notice of cross-border transfer.
Appointment of a responsible person. The organization must have someone responsible for organizing personal data processing.
Contracts with processors. If a contractor or aggregator processes personal data on assignment, this must be documented.
Assessment of the foreign recipient. Protective measures, jurisdiction, conditions for stopping processing, contacts.
Technical measures. Access control, logging, encryption, DLP, masking, secret storage, and a ban on entering personal data into public chats.
Incident response process. Who notifies and how in the event of a leak, how keys are blocked, how data is deleted.
Employee instructions. What can be sent to AI, what can only be sent after anonymization, and what must never be sent.

Article 19 of Federal Law No. 152-FZ requires the operator to take legal, organizational, and technical measures to protect personal data from unauthorized or accidental access, destruction, alteration, blocking, copying, disclosure, distribution, and other unlawful actions (Art. 19 of Federal Law No. 152-FZ).

Internal AI Use Policy

A good policy should divide data into levels:

Level	Example	Can it be used in foreign AI?
Public	Website copy, a public article, a public service description	Yes
Internal, no personal data	Draft instructions, anonymized analytics	Usually yes after review
Low-risk personal data	Customer inquiry without sensitive data	Only after anonymization or under a documented process
Sensitive personal data	health, biometrics, children, finance, HR conflicts	Do not send to a public/foreign AI without a separate legal/information security decision
Trade secret	code, contracts, strategy, customer database	Under a separate policy, often only enterprise/API or on-premises

Liability and penalties

Key takeaways: liability can be administrative, civil, disciplinary, and in certain cases criminal. The main practical risk for businesses is Article 13.11 of the Russian Code of Administrative Offenses and the consequences of data breaches.

Article 24 of Federal Law No. 152-FZ states that those found guilty of violating the law’s requirements are liable under Russian law. It also separately provides for compensation for moral harm to the personal data subject, regardless of property damage and losses (Art. 24 of Federal Law No. 152-FZ).

The main administrative article is Article 13.11 of the Russian Code of Administrative Offenses. As of 2026, it includes many offenses. The most important for AI are:

Violation	Fine for a legal entity
Processing not in accordance with the law or incompatible with the purposes of collection	RUB 150,000 - 300,000
Repeated violation of the same type	RUB 300,000 - 500,000
Processing without written consent, when it is required	RUB 300,000 - 700,000
Repeated violation related to written consent	RUB 1,000,000 - 1,500,000
No public personal data processing policy	RUB 30,000 - 60,000
Information not provided to the data subject	RUB 40,000 - 80,000
Failure to comply with a request to clarify, block, or delete data	RUB 50,000 - 90,000
Violation of database localization rules when collecting via the internet	RUB 1,000,000 - 6,000,000
Repeated localization violation	RUB 6,000,000 - 18,000,000
Failure to notify of the intent to process personal data	RUB 100,000 - 300,000
Failure to notify of an incident involving unlawful transfer/access	RUB 1,000,000 - 3,000,000
Leak of 1,000 - 10,000 data subjects or 10,000 - 100,000 identifiers	RUB 3,000,000 - 5,000,000
Leak of 10,000 - 100,000 data subjects or 100,000 - 1 million identifiers	RUB 5,000,000 - 10,000,000
Leak of more than 100,000 data subjects or more than 1 million identifiers	RUB 10,000,000 - 15,000,000
Leak of special categories of personal data	RUB 10,000,000 - 15,000,000
Leak of biometric personal data	RUB 15,000,000 - 20,000,000
Repeated large-scale leaks	1-3% of revenue, but not less than RUB 20 million and not more than RUB 500 million
Repeated leaks of special categories or biometrics	1-3% of revenue, but not less than RUB 25 million and not more than RUB 500 million

[Fact]: The current Article 13.11 of the Russian Code of Administrative Offenses provides separate offenses for unlawful processing, lack of consent, localization violations, failure to notify, leaks, special categories, and biometrics; for repeated large-scale leaks, turnover-based fines with an upper limit of RUB 500 million are specified (Art. 13.11 of the Russian Code of Administrative Offenses).

What this means for AI projects

The risk arises not only in the event of a database breach. The risk also arises when:

an employee uploads a customer database in bulk to a public AI;
a support bot sends case history to an external API without masking;
prompt logs are stored with a vendor without a deletion period;
an aggregator does not disclose where it routes the data;
the company did not notify about cross-border transfer;
the company cannot show on what basis it processed the data;
the AI integration creates copies of personal data in logs, queues, analytics, and backups;
special categories or biometrics were included in the model.

Practical checklist for AI implementation

Key takeaways: you should start not with model selection, but with data classification and the processing route.

Before launching foreign AI in a business process, go through this checklist:

Describe the use case. What the AI does: writes responses, summarizes, classifies, finds errors, analyzes documents.
Identify the data. Which fields enter the prompt, files, embeddings, logs, and responses.
Mark the personal data. Full name, contacts, ID, addresses, documents, voice, photo, IP, contracts.
Mark the sensitive data. Special categories, biometrics, children, medical, financial, HR.
Decide whether external AI is needed. If the task can be solved locally or by rules, do not send data outside.
Enable anonymization before the API. Regular expressions, NER, DLP, OpenAI Privacy Filter, or another local module.
Check the quality of the anonymization. Create a test set of 100–300 real-world examples and measure the miss rate.
Turn off unnecessary logs. Prompts and responses should not flow unchecked into analytics, error tracking, or debug logs.
Check the provider. Terms, storage, training, subprocessors, deletion, DPA, region, security.
Put the paperwork in place. Policy, consents if needed, data processing agreement, notices, information security rules.
Restrict employee access. Prohibit entering personal data into personal AI accounts; provide a corporate tool with filters.
Set up monitoring. Logs without personal data, alerts for leaks, API key control, access logs.
Prepare an incident response plan. Who is responsible, whom to notify, how to delete data, and how to disable the integration.

A practical architecture for small and midsize businesses

The optimal setup for most companies:

Layer	What it does
CRM/help desk/website	Stores source personal data in a controlled environment
Local redaction layer	Removes full names, phone numbers, email addresses, physical addresses, IDs, and sensitive fragments
Local model or rules	Check whether any personal data is still left
Foreign AI API	Receives only an anonymized prompt
Company backend	Reinserts real data back in if needed
Audit log	Stores the processing event without the source personal data

This approach lets you use powerful foreign models for quality, speed, and automation without turning every prompt into a legally risky cross-border transfer of personal data.

Bottom line

Federal Law No. 152 does not prohibit foreign AI. It requires a company to understand what personal data it processes, why, on what basis, to whom it transfers it, and how it protects it. So the safe formula looks like this: public and anonymized data can be sent to external models under an internal policy; personal data only with a documented legal and technical setup; special categories, biometrics, and highly sensitive documents are better kept in a local or corporate environment.

The main practical recommendation: anonymize before AI, not after. Use local rules, DLP, NER, or OpenAI Privacy Filter to remove identifiers before sending. Then foreign AI is no longer a forbidden zone, but a controlled tool you can build into your business without unnecessary risk for customers or the company.

Federal Law 152 and Foreign AI: Legal Use Guide