LLM, персональные данные и 152-ФЗ

от автора

Мы занимаемся внедрением LLM и агентов в бизнесы, и одна из самых частых проблем — как обрабатывать данные клиентов и при этом соблюдать закон 152-ФЗ о персональных данных.

Давайте разберёмся!

Сразу две оговорки:

  • Это разбор для инженеров и продактов, а не юридическая консультация. Перед применением обратитесь к врачу профильному юристу

  • Тема двигается быстро, и два изменения произошли этим летом. Обратите внимание, сколько времени прошло с даты выхода этой статьи

Что вообще такое персональные данные

Персональные данные — любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу (субъекту персональных данных) (п. 1 ст. 3 152-ФЗ)

По сути это любая информация о человеке, которого можно определить: и телефон, и должность, и город. Критерий один — определяемость субъекта.

Конечно, формулировка максимально резиновая, и практика до конца ещё не сформировалась.

Даже государственные ведомства иногда спорят по поводу того, что является ПД, а что нет. Например, по ИНН:

Минкомсвязь считает, что ИНН «позволяет без дополнительной информации идентифицировать субъекта персональных данных», а Минфин против: «ИНН не является информацией, входящей в перечень персональных данных» 

У судов тоже очень разные трактовки того, что является ПД, а что нет.

В общем, разных примеров полно, но мы решили для себя, что максимально безопасный подход — это считать ПД максимально всё: имена, идентификаторы, электронные почты и т. д. Это снижает риск, связанный с широтой трактовки и возможным непостоянством судов.

Как правильно обрабатывать персональные данные

Если вы собираете персональные данные, то вы — оператор персональных данных.

Для того чтобы начать эти данные собирать и обрабатывать, нужно, во-первых, уведомить РКН, во-вторых, вам нужно основание для обработки этих данных (например, согласие, исполнение договора и т. д.), а в-третьих, ПД должны быть локализованы на территории России. Тут останавливаться не будем, статья не об этом.

Допустим, вы всё это выполнили и теперь хотите использовать LLM для обработки данных клиентов.

В законе это называется обработка ПД по поручению оператора. Для этого нужно оформить поручение либо отдельным договором, либо частью обычного договора или оферты.

Во многих российских сервисах, куда обычно отправляются ПД пользователей, это поручение есть. Например, у Битрикса.

Если серверы LLM находятся за границей, всё значительно усложняется.

В законе это называется трансграничная передача персональных данных. Для того чтобы такую передачу осуществить, нужно отдельно уведомить РКН. При этом РКН делит страны на адекватные и нет. По адекватным странам достаточно уведомить и можно сразу передавать. По «неадекватным» — только по прошествии 10 дней, и то если РКН не запретит.

Как в итоге законно использовать LLM?

Тут есть несколько вариантов.

Зарубеж в лоб: Claude, OpenAI, DeepSeek.

Тут мы не видим законного способа обрабатывать персональные данные пользователей. Даже если вам повезло и LLM крутится в адекватной стране, вы не можете нормально оформить поручение обработки. Это главный стоп, помимо остальных «неудобств».

Российские модели.

Всё зависит от политики компании, и на это нужно внимательно смотреть. Например, Яндекс позволяет обрабатывать персональные данные, а вот Сбер ГигаЧат — нет: «сервис не предназначен для направления запроса, содержащего персональные данные как третьих лиц, так и самого пользователя» [https://developers.sber.ru/docs/ru/policies/gigachat/agreement].

Open-source модели в российском облаке.

Тоже надо смотреть на политику сервиса. У того же Яндекса по API доступен DeepSeek (правда, в несколько раз дороже, чем оригинальный), в котором можно обрабатывать ПД.

Open-source модели на своём или арендованном железе (в РФ).

Всё ок.

Важная оговорка. В законе о ПД также предусмотрена необходимость удаления этих персональных данных в некоторых случаях. Поэтому всегда при использовании публичной LLM нужно отключать логирование и запрещать сервису обучаться на ваших данных.

Обезличивание

Это главный приём, который мы используем, и я советую его использовать всегда, кроме случаев крайней необходимости, даже если вы работаете с РФ-моделями.

Идея простая: сделать так, чтобы в модель уходили не персональные данные.

Покажу на двух примерах.

Первый пример: вам нужно откорректировать какой-то договор, в котором содержатся персональные данные клиента. Для этого все его данные типа ФИО, ИНН, номера паспорта вы заменяете на плейсхолдеры типа NAME, INN и отдаёте в LLM. Когда получаете ответ, заменяете обратно.

Второй пример. Есть таблица:

user_id, name, email, phone, feedback

И вы хотите написать пользователям, которые оставили вам плохую обратную связь.

Перед тем как отправить эту таблицу в LLM, нужно удалить колонки, содержащие ПД. А потом восстановить их по user_id.

Тут, конечно, есть проблема: система не может работать на 100% точно. То есть таким образом вы снижаете вероятность и количество передаваемых ПД, но не до нуля.

Как обезличивать?

Вариант первый — у себя.

Можно написать решение, максимально подходящее для ваших данных, с нуля, можно использовать какой-нибудь опенсорс типа Presidio.

Вариант второй — посредники.

Есть сервисы, которые проксируют ваши запросы в LLM, сами находятся на территории России, с ними оформлено поручение на обработку, и они при проксировании запросов сами удаляют персональные данные. Примеры: KodikRouterJaycopilot и другие.

Важно смотреть, чтобы сервис не просто проксировал ваши данные в иностранную LLM, а сам удовлетворял 152-ФЗ и у него была функция обезличивания.

Итого

  • Персональных данных нет вовсе — можно куда угодно, включая любые зарубежные модели

  • Данные обезличены — риск существенно ниже, но есть

  • Есть необезличенные ПД — только российский контур: российское облако с оформленным поручением или своё железо


Если хотите разбираться глубже в том, как использовать LLM и AI-агентов в продуктивности, работе, бизнесе и повседневной жизни — подписывайтесь на наш Telegram-канал “Вкалывают роботы”.

ссылка на оригинал статьи https://habr.com/ru/articles/1078722/