Делаю сервис — чат-бот для пар (психологическая помощь, разговоры об отношениях). Я самозанятый, оператор ПДн. Сервер...

Георгий, приветствую Вас.

Соглашение GigaChat (п. 8.6–8.7) прямо запрещает чужие ПДн и спецкатегории (а разговоры об отношениях — это потенциально интимная жизнь и здоровье). Сейчас собрал деперсонализацию перед API: GLiNER + pymorphy3 локально, recall ~90–95%, таблица соответствий шифрованная, наружу не уходит.

Что в вашем понимании «наружу» ?

Ваш проект так понимаю  находится в зоне  риска, так как вы работаете со специальными категориями данных (ст. 10 152-ФЗ — интимная жизнь, философские/религиозные убеждения и, возможно, состояние здоровья) и задействуете искусственный интеллект (LLM), условия использования которого (в данном случае GigaChat от Сбера) вы сейчас прямо нарушаете.

Достаточно ли псевдонимизации (приказ РКН № 996) с таким recall, чтобы передача в API стала легальной?

 На мой взгляд, категорически недостаточно.  Частичного обезличивания не существует.

Согласно п. 9 ст. 3 Закона № 152-ФЗ,

9) обезличивание персональных данных — действия, в результате которых становится невозможным без использования дополнительной информации определить принадлежность персональных данных конкретному субъекту персональных данных;

Ваши 5–10% пропусков означают, что в API Сбера уходят необезличенные персональные данные. С точки зрения КоАП РФ это квалифицируется как незаконная передача (распространение) ПДн.

Уважаемый Георгий.

Псевдонимизация с recall 90–95% сама по себе не делает передачу текста в LLM API законной. Более того, Вы ссылаетесь на уже утративший силу приказ Роскомнадзора № 996. С 1 сентября 2025 года применяются требования и методы обезличивания, утвержденные приказом Роскомнадзора от 19.06.2025 № 140; приказ № 996 этим же актом признан утратившим силу. Новый приказ требует обеспечить невозможность определить принадлежность данных конкретному субъекту без дополнительной информации. Какого-либо допустимого процента ошибок или «recall» законодательство не устанавливает. 

Поэтому при 90–95% распознавания остается 5–10% потенциально пропущенных идентификаторов. С юридической точки зрения достаточно одного сообщения, в котором субъект прямо или косвенно определяется, чтобы передаваемая информация могла сохранять характер персональных данных. Приказ № 140 допускает, в частности, замену идентифицирующих данных на условные идентификаторы с отдельным хранением ключа, но ключ не должен передаваться третьим лицам. 

При этом есть более принципиальный момент: обезличивание не создает правового основания для первоначальной обработки данных. По ст. 3 Федерального закона от 27.07.2006 № 152-ФЗ обезличивание само является операцией обработки персональных данных. Следовательно, если пользователь написал: «У моего мужа Ивана Иванова депрессия», а исходный текст сначала поступил на Ваш сервер и уже там прошел GLiNER, Вы к этому моменту уже получили и обработали персональные данные мужа. Последующая замена имени на [PERSON_1] не устраняет вопрос о законности первоначального получения этих сведений. 

Именно поэтому применительно к чужим персональным данным наиболее безопасно переносить обезличивание до момента их получения оператором: например, выполнять первичную фильтрацию непосредственно на устройстве пользователя и передавать на Ваш сервер уже очищенный текст. Это не прямо установленная законом техническая обязанность, а наиболее безопасная архитектурная модель с учетом определения обработки в ст. 3 Закона № 152-ФЗ.

Отдельно необходимо разделять обычные и специальные категории персональных данных. Сведения о состоянии здоровья и интимной жизни прямо относятся к специальным категориям по ст. 10 Закона № 152-ФЗ. Перечень таких данных закрытый. 

Для собственных специальных категорий данных зарегистрированного пользователя рабочая конструкция возможна: письменное согласие субъекта на обработку специальных категорий плюс надлежащим образом оформленное поручение обработки LLM-провайдеру. Но обычного checkbox «согласен с обработкой ПДн» здесь недостаточно. Пункт 1 ч. 2 ст. 10 требует именно письменного согласия, а ч. 4 ст. 9 устанавливает его содержание; в электронной форме оно должно быть оформлено как электронный документ, подписанный электронной подписью в установленном законом порядке. Кроме того, с 1 сентября 2025 года согласие должно оформляться отдельно от иных подтверждаемых пользователем документов и условий. 

Договор поручения по ч. 3 ст. 6 Закона № 152-ФЗ также не легализует данные, которые Вы изначально не вправе обрабатывать. Он регулирует отношения между оператором и обработчиком: в поручении должны быть определены цели, перечень данных и операций, требования конфиденциальности и безопасности и иные обязательные условия. Но основание для обработки данных субъектов должно существовать у самого оператора. 

Поэтому в отношении специальных категорий третьего лица согласие Вашего пользователя проблему не решает. Пользователь не вправе дать согласие за своего партнера, коллегу или родственника, если не является его надлежащим представителем. Для обработки сведений о здоровье или интимной жизни такого третьего лица необходимо его собственное письменное согласие либо наличие одного из специальных оснований ч. 2 ст. 10 Закона № 152-ФЗ. Для обычного B2C-чата об отношениях подходящего исключения не будет. 

С обычными персональными данными третьих лиц ситуация несколько менее категорична. Теоретически может обсуждаться п. 7 ч. 1 ст. 6 Закона № 152-ФЗ — обработка для реализации законных интересов оператора или третьих лиц при условии ненарушения прав субъекта. Однако для массового B2C-сервиса с неконтролируемым пользовательским вводом я бы не рекомендовала строить всю модель на этом основании. Более того, если идентифицируемые данные затем передаются внешнему обработчику, возникает отдельное требование ч. 3 ст. 6 о согласии субъекта на поручение обработки. 

Также необходимо учитывать ст. 18 Закона № 152-ФЗ: когда персональные данные получены не непосредственно от их субъекта, на оператора в общем случае возлагаются дополнительные обязанности по информированию субъекта, если отсутствуют предусмотренные законом исключения. Для сервиса, где ежедневно пользователи могут упоминать неопределенное число знакомых, родственников и партнеров, это еще один аргумент против модели, предполагающей фактический сбор таких данных.

Алгоритм действий:

Шаг 1. Для данных самого пользователя отдельно оформить обычное согласие и письменное согласие на специальные категории, если сервис реально предполагает обработку сведений о здоровье или интимной жизни.

Шаг 2. Если применяется внешний LLM-провайдер и ему передаются персональные данные, оформить поручение обработки строго по ч. 3 ст. 6 Закона № 152-ФЗ и отразить соответствующего обработчика в согласии в случаях, когда требуется письменная форма.

Шаг 3. Для чужих данных сделать основным принципом не получение согласий третьих лиц, что практически нереализуемо, а недопущение поступления идентифицируемых данных третьих лиц в Вашу инфраструктуру. Предпочтительно проводить первичную очистку на клиентском устройстве.

Шаг 4. Использовать не только NER по ФИО, но и удаление косвенных идентификаторов: телефонов, e-mail, аккаунтов, адресов, конкретных работодателей, должностей, уникальных дат и мест, сочетаний фактов, позволяющих идентифицировать человека. Для LLM лучше передавать «мой партнер», [PARTNER], [COLLEAGUE] и т. п.

Шаг 5. При обнаружении неочищенных чужих данных блокировать передачу сообщения в LLM и предлагать пользователю автоматически переформулированный обезличенный вариант. Одно только предупреждение в пользовательском соглашении «не вводите чужие ПДн» полезно, но само по себе проблему законности обработки не решает.

Шаг 6. Вашу текущую схему GLiNER + pymorphy3 можно оставить как важный дополнительный технический барьер, но юридически не позиционировать 90–95% recall как соответствие требованиям обезличивания приказа № 140. Необходима документированная оценка достаточности метода, правила обезличивания и подтверждаемая невозможность идентификации без дополнительной информации. Именно такой подход предусмотрен приказом № 140. 

Отдельно отмечу, что риски здесь весьма существенны: с 2025 года КоАП РФ отдельно предусматривает повышенную ответственность за неправомерную передачу информации, включающей специальные категории персональных данных. Поэтому здоровье и сведения об интимной жизни я бы технически отделяла от обычных идентификаторов и не допускала их передачи внешнему API в отношении третьих лиц вообще.

Вывод:

Псевдонимизация с recall 90–95% — недостаточное основание для вывода, что передача в LLM стала законной. Кроме того, приказ № 996 уже не действует; ориентироваться следует на приказ Роскомнадзора № 140.

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

Наиболее юридически устойчивой архитектурой B2C-чата я считаю следующую: данные самого пользователя обрабатываются на основании правильно оформленных согласий; идентифицируемые сведения о третьих лицах максимально исключаются еще до поступления оператору; наружу в LLM передается только текст после глубокой деперсонализации, а сообщения, которые безопасно очистить невозможно, в API не отправляются.

Если потребуется, можете обратиться ко мне в чат: можно отдельно разобрать Вашу архитектуру «пользователь — Ваш сервер — LLM API» и состав документов для Роскомнадзора, согласия, политики и договора поручения. Имею более 5 лет практического опыта работы в сфере персональных данных и цифрового права.

Сразу к делу: одной псевдонимизации с recall 95% недостаточно, чтобы сделать передачу в GigaChat законной. Это рискованный компромисс, а не чистое решение.

Вот почему ваш подход проблематичен, и как это исправить.

1. Почему псевдонимизация не панацея

· Соглашение GigaChat запрещает саму передачу: Пункты 8.6–8.7 прямо запрещают передавать чужие ПДн и спецкатегории. Если вы отправите хоть одно неудалённое имя, вы нарушите соглашение и подставите себя под блокировку и претензии.
· Юридическая недостаточность: Даже идеальная псевдонимизация (по Приказу РКН №996) не делает передачу легальной, если этого не позволяет договор с вендором. Вы не можете «обезличить» данные и считать, что закон не нарушен — запрет в соглашении первичен.
· Технический риск: 5% ошибок — это реальные утечки. Имена, упоминания болезней или интимной жизни с вероятностью 1 из 20 полетят в открытом виде к вендору.

2. Единственное легальное решение: Договор поручения

Самый чистый путь — заключить договор поручения обработки персональных данных (ст. 6 ч. 3 152-ФЗ) с Cloud.ru Evolution (или другим вендором, готовым на это) .

Что это даёт:

· Вендор становится вашим обработчиком, действует по вашему поручению и не имеет самостоятельных целей.
· Ответственность за его действия несёте вы, но обработка становится легальной.
· Важное исключение: По судебной практике, если передача данных необходима для исполнения договора с пользователем (ваша услуга), согласие пользователя на передачу конкретному обработчику может не требоваться. Однако для спецкатегорий (здоровье, интимная жизнь) лучше всё же получить явное согласие в оферте.

3. Что делать прямо сейчас

Если вендор не идёт на договор поручения, остаётся только локальная деперсонализация, но с двумя жёсткими условиями:

1. Обеспечьте recall 100%: Никаких имён, упоминаний диагнозов, мест работы — ничто из этого не должно уходить в API. Или технически отсекайте такие сообщения.
2. Изолируйте ключи: Таблица соответствия (ID ↔ имя) должна храниться отдельно от обезличенных данных, доступ к ней — строго ограничен .

4. Проблема «чужих» ПДн в B2C

Это системная проблема всех чат-ботов. Классическое решение:

· Сбор согласия с пользователя: В вашей оферте должно быть прямо указано, что пользователь гарантирует наличие согласия третьих лиц на упоминание их данных в чате, и принимает на себя все риски.
· Технический фильтр: Обязательный этап перед отправкой в LLM. Имена заменяются на «партнёр», «коллега», «друг» и т.д. .

Резюмирую: Сначала добейтесь юридической чистоты с вендором (договор поручения). Параллельно улучшайте recall вашего фильтра до 100%. Это единственный способ защитить себя от штрафов (до 300 000 руб. по ст. 13.11 КоАП РФ) и претензий GigaChat. Удачи в проекте

Здравствуйте, Георгий! Отвечу Вам без ИИ

Достаточно ли псевдонимизации (приказ РКН № 996)

Приказ, на который Вы ссылаетесь, утратил юридическую силу.

Псевдонимизации с recall 90–95% недостаточно, чтобы считать передачу текста в API  законной.

Приказ Роскомнадзора от 05.09.2013 № 996 утратил силу с 1 сентября 2025 года.

Сейчас  действует — Приказ Роскомнадзора от 19.06.2025 N 140

normativ.kontur.ru/document?moduleId=1&documentId=500957

Т.е., применяются требования и методы, утвержденные приказом Роскомнадзора от 19.06.2025 № 140.

Обезличивание должно приводить к невозможности определить принадлежность данных субъекту без дополнительной информации.

Вероятностная модель, пропускающая 5–10% сущностей, такой результат не гарантирует.

Более того, человека нередко идентифицируют не по имени, а по совокупности обстоятельств -  должности, места работы, города, возраста, семейной связи, диагноза или описанного события.

Поэтому замена имен токенами — спорная.

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

Для API-провайдера текст можно считать обезличенным лишь тогда, когда по содержанию и доступной ему информации субъект реально не определяется.

Определение обезличивания закреплено в пункте 9 статьи 3 Федерального закона от 27.07.2006 № 152-ФЗ «О персональных данных».

9) обезличивание персональных данных — действия, в результате которых становится невозможным без использования дополнительной информации определить принадлежность персональных данных конкретному субъекту персональных данных;

www.consultant.ru/document/cons_doc_LAW_61801/4f41fe599ce341751e4e34dc50a4b676674c1416/

Одного показателя recall для доказательства этого недостаточно.

Для сведений о здоровье и интимной жизни требуется основание по статье 10 Закона № 152-ФЗ.

В Вашей модели лучше всего  получать от зарегистрированного пользователя отдельное письменное согласие на обработку специальных категорий, прямо указывая цели, состав данных, использование LLM и привлечение обработчика.

Электронная форма должна отвечать требованиям письменного согласия по статье 9 Закона № 152-ФЗ.

www.consultant.ru/document/cons_doc_LAW_61801/6c94959bc017ac80140621762d2ac59f6006b08c/

Обычной галочки на общую политику для такого массива недостаточно.

С чужими ПД в чате задача решается не попыткой получить согласие каждого упомянутого лица, а минимизацией обработки.

В интерфейсе нужно запретить ввод ФИО, контактов, адресов, мест работы и иных идентификаторов третьих лиц, попросить использовать обозначения

партнер… коллега… родственник

локально удалять прямые и косвенные идентификаторы до отправки в LLM, блокировать сообщения с высоким риском и не использовать такие тексты для обучения.

Это соответствует принципам конкретности цели, недопустимости избыточной обработки по частям 2, 4 и 5 статьи 5 Закона № 152-ФЗ.

www.consultant.ru/document/cons_doc_LAW_61801/

Согласие пользователя не распространяется на «партнера или коллегу».

Поэтому обнаруженные сведения о третьем лице следует немедленно обезличивать либо удалять.

Предупреждение в оферте само по себе проблему не решает.

Т.е., Вам нужен российский провайдер с подходящими договорными условиями, отдельное согласие пользователя на специальные категории, отсутствие передачи идентификаторов и техническая блокировка сомнительных частей.

Псевдонимизацию стоит сохранить как защитную меру.

С уважением.

Здравствуйте.

Суть в том, что по закону (152-ФЗ) обезличивание — это когда невозможно определить принадлежность данных конкретному лицу без дополнительной информации. Если ваша система (GLiNER + pymorphy3) оставляет лазейку — например, в сочетании с другими деталями (должность, специфический контекст диалога) модель или кто-то ещё может восстановить личность, — регулятор может счесть обработку незаконной. Высокий recall — это хорошо (вы ловите много имён), но если есть ложные пропуски, риск остаётся. Поэтому я бы рекомендовал не полагаться только на технику, а документировать процесс: зафиксировать в политике, какие методы вы применяете, как проверяете качество обезличивания и какие меры принимаете, чтобы минимизировать риск реидентификации.

Вот такая ситуация. Иного не дано, согласитесь