AI and personal data: what to consider under 152-FZ

This article describes a general approach and our experience. It is not legal advice. Personal data requirements depend on your processes, so check your decisions with a lawyer.

Where AI meets personal data

Personal data is any information that relates to an identified or identifiable person: a name, phone number, address, email, a job title together with a surname, or a contract number that lets you find a customer. Under Federal Law No. 152-FZ (the Russian personal data law), storage is not the only thing that matters. Collection, recording, use, transfer and deletion also count as processing.

An AI solution almost always falls under these rules if it works with a company's live material. Personal data appears in requests and emails, contracts and forms, call recordings, exports from your CRM and 1C (a Russian ERP platform), and in employees' own queries. Sending such text to a model is, as a rule, also processing. So the question is not whether this applies to you, but how to organize it.

Which data to send the model and which not to

Start with a question: which fields does the model need to do the task? To classify a request, the text and subject usually matter, not the surname and passport details. For search across internal regulations, personal data is not needed at all. The fewer fields go to the model, the simpler everything else is: contracts, protection, the set of consents.

Depersonalization means changing data so that, without additional information, it cannot be tied to a specific person. In practice, names, phone numbers, addresses and numbers are replaced with labels, and the mapping table is stored separately, within your own environment. If the data can easily be restored using that table, lawyers often still treat it as personal. Confirm this point with your lawyer.

Typical mistakes at this step are more often about the habit of moving fast than about technology. Below are the ones we see in projects that use a company's live data.

• Sending the whole export to the model because it is easier than picking the fields you need.
• Removing only names and leaving phone numbers, addresses and contract numbers in free text.
• Testing a model on real data in a public service without reading its terms.
• Forgetting that personal data also appears in scans and attachments, not only in tables.
• Keeping original and depersonalized data in the same place with the same access.

Sending personal data to a model: where it is processed

When you send text to an external model service, the data leaves your environment. You need to find out where the servers physically are, who owns them, whether requests are stored and for how long, and whether they are used for further training. Your risk assessment depends on these answers.

When the personal data of Russian citizens is collected and recorded, a localization requirement usually applies: the initial recording and storage must be in databases located in Russia. If the model or the logs are abroad, this is a cross-border transfer. It has separate requirements, including an assessment of how the receiving party protects the data. Confirm the procedure for your case with a lawyer.

Technically, there are several options: deploy the solution in your own infrastructure, use an agreed cloud (a Russian one if you have no infrastructure of your own for the task), or send an external model only depersonalized text. The choice depends on what data the task needs and on the requirements of your lawyer and security team.

152-FZ and AI: purposes, consent, operator and processing on its behalf

The operator is the organization that determines the purposes and the scope of personal data processing. As a rule, that is you: you decide why you need the data of customers and employees. Purposes must be defined in advance and be lawful, and the data collected must match them, without excess.

Processing needs a legal basis. Often it is the person's consent. In other cases it is a contract or the law. If you collected a customer's data to fulfill an order, using it to train or test a model is a question for a lawyer: as a rule, that may be a different purpose.

The contractor who deploys the solution and the model provider often act as parties processing data on behalf of the operator. This is set out in a contract that lists the actions, the purposes and the protection requirements. As a rule, responsibility to the person whose data is processed stays with the operator, so read the terms of that arrangement carefully.

Logs, access and retention periods

Access. The solution should show each employee only what they are entitled to see. This applies to enterprise search and to an AI assistant alike. If the model gets context from a knowledge base, check the user's permissions before a document reaches the answer. The principle is simple: separate roles and grant only the minimum rights needed.

Logs. Record who used the solution, when and for what purpose, which sources were used and what answer was returned. Logs help you investigate incidents and respond to requests. But a log can itself contain personal data, so protect it and limit how long you keep it.

Retention period. As a rule, data is kept no longer than the purposes of processing require. Decide in advance how long to keep the original documents, copies in the search index (where document fragments are stored in a form suited to search), the cache, the request log and the model's outputs. When data is deleted from the source, its copies inside the solution must disappear too. Plan for this at the design stage.

Questions for your contractor before work starts

Get answers to these questions in writing, before you sign the contract. That way you can attach them to the contract and return to them at acceptance. The questions cover the data, where it is processed, the roles of the parties and what happens to the data after the project.

If the contractor answers some of the questions in general terms, that is a reason to stop and ask for details, not to take the answer on trust.

• Which data fields does the solution need, and can you start with depersonalized data?
• Where will the solution be deployed, and where are the model, database and logs physically located?
• Does data leave Russia? If so, who receives it and why?
• Does the model provider store requests and use them for training?
• Who is the operator, and who processes data on the operator's behalf? How is this documented?
• How are access roles, the log and data deletion at the end of the retention period handled?
• What happens to the data, code and configurations after the project ends?

How we handle personal data in projects

We start with a free discovery. In it, we find out which fields the solution actually needs, because some tasks can be solved with anonymized data. We build the requirements of Federal Law No. 152-FZ (the Russian personal data law) into the design instead of fitting a finished solution to them. The result is a written document that sets out the solution's boundaries, the acceptance criteria and a list of risks.

We deploy the solution inside your infrastructure or in an agreed cloud. You choose the environment at the start: your own or a Russian cloud. We build access on separated roles and the minimum necessary permissions. To keep AI under control, we provide logging, monitoring, human involvement and error handling.

We build the prototype on your data. If the export contains personal data, we ask you to send it in anonymized form. The terms for handing over code, configurations and rights are set before the project starts, and the support arrangement after launch is fixed in the contract. We do not replace legal review: agree decisions on legal bases, consents and transfers abroad with your own lawyer.