AI Agents and Data Law (152-FZ): When You Need a Closed Perimeter
“Where does our data go?” is the question half of all projects stop at. Three ways to answer it, and the price of each.
Almost every agent project eventually runs into one question from the security team: “Where does our data go?” The usual answers are two extremes. One is “everything is encrypted, don’t worry”. The other is “own server only, own model only”, which multiplies the budget where that was never required.
The right answer depends on what data the agent actually sees. Below are three architectures, who each one suits, and what the strictest one costs. This article is about Russian personal data law (152-FZ), but the logic carries over to GDPR and similar regimes. A caveat: this is an engineering view, not a legal opinion. Your lawyer or data protection officer should confirm the decision for your data.
What the law actually requires
152-FZ covers personal data: name, phone, address, passport, anything that identifies a person. It does not ban language models and does not name “approved” vendors. It regulates processing, and four things matter for an agent project:
- Storage in Russia. Databases with personal data of Russian citizens must sit on servers in Russia.
- Cross-border transfer. Sending personal data to a foreign service is a cross-border transfer with its own rules and notifications.
- Legal basis. Consent or another lawful basis. A website chat where a customer leaves a phone number is processing too.
- Processor agreements. If a contractor or a cloud service sees the data, that is formalised in a contract.
The practical conclusion: the question is not “Russian model or not”, but whether personal data reaches the model at all.
Option 1. A foreign model with anonymisation
Data is stored in Russia. Before text goes to the model it passes through a filter: names, phones, emails, contract and card numbers are replaced with placeholders such as [NAME_1] and [PHONE_1]. The model works with anonymised text, and the real values are put back into the answer on your side.
Who it suits. Support, sales, internal assistants: wherever the meaning of a question does not depend on who is asking. The model understands “Where is my order [NUMBER_1]” just as well as with the real number.
Weak spot. The filter is not perfect on free text: a customer can describe themselves in a way no pattern catches. So anonymisation quality is tested the same way as answer quality, on a set of real requests.
Option 2. A Russian cloud model
GigaChat or YandexGPT: data stays in the country, the contract is with a Russian legal entity, and the cross-border question goes away.
Who it suits. Companies whose policy forbids foreign services but allows cloud as such.
Weak spot. On harder tasks (long documents, multi-step actions, tool calls) quality can differ from foreign models. By how much depends on the task, so compare on your own test set, not on reviews. Sometimes there is no difference, sometimes it is decisive.
One important caveat: a Russian model does not make processing lawful by itself. Consents, a processor agreement and log retention periods are needed in every option.
Option 3. A closed perimeter
An open-weights model (Qwen, Llama, Mistral) runs on your servers or on a rented server in a Russian data centre. Nothing leaves: no requests, no documents, no logs.
Who needs it. Banking and medical secrecy, trade secrets in documents (contracts, financial statements), government clients, companies that forbid any external API.
What it costs. Noticeably more than cloud, and not only in money:
- Hardware. Models that can handle business tasks need server-grade GPUs. Renting such a server in a Russian data centre costs on the order of hundreds of thousands of roubles a month; buying one costs millions. Exact figures depend on model size and load, and come from the provider.
- People. A model server has to be updated, monitored and fixed. That is part of an engineer’s time or a support contract.
- Quality. A model that fits on one server is usually weaker than the best cloud ones. On a narrow task with a good knowledge base that is often enough, but test it before buying hardware, not after.
How to choose
- The agent only sees customer requests (orders, delivery, product questions): option 1 or 2.
- The agent works with documents where personal data is the substance (application forms, HR files, medical records): option 2 or 3.
- Data under a special regime, or a policy that forbids external services: option 3.
- Not sure: start with a question to your lawyer, not with choosing a model.
The four most common mistakes
“We use a Russian model, so we are compliant.” The law is about processing, not the model. Without consents and a processor agreement the violation remains.
Logs with personal data are kept forever. The agent’s conversations are logged for debugging and forgotten. Set a retention period and anonymise logs from the start.
Developers were given a production export. A test set with real names and phone numbers goes to the contractor as an email attachment. Anonymise it before handing it over.
No consent text in the chat. The agent asks for a phone number and there is no link to the privacy policy next to it.
How we do it
We store and process personal data on servers in Russia and anonymise it before sending it to a model. If security requirements are stricter, we deploy Russian or open-weights models inside the client’s perimeter. We help with consents and internal documents. Which of the three options you need becomes clear during the audit, which is free.