Главная
→
Блог
→
Анонимизация данных: как использовать облачный ИИ без риска утечки

Анонимизация данных: как использовать облачный ИИ без риска утечки

“

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

Проблема: данные уходят вместе с запросом

Облачная языковая модель (LLM, large language model) работает на чужих серверах. Всё, что вы в неё вставили, туда и попало, включая фамилии, телефоны и номера договоров. По российскому закону это не мелочь: закон № 152-ФЗ «О персональных данных» (далее ПДн) требует: при сборе персональных данных граждан РФ запись, систематизация, накопление и хранение в базах данных за пределами России не допускаются (ч. 5 ст. 18 152-ФЗ).

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

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

Как это работает: найти, заменить, отправить, вернуть

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

Выглядит это так. Вместо «Иванов Иван, тел. +7 000 000-00-01, оформи заявку» модель получит «{{PERSON_1}}, тел. {{PHONE_1}}, оформи заявку». Облачная модель настоящих данных не видит, а все замены детерминированные: одна и та же метка всегда соответствует одному и тому же значению.

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

Главная юридическая ловушка: обратимая и необратимая замена

Здесь многие ошибаются. Есть два принципиально разных способа спрятать данные.

Обратимая замена (псевдонимизация). «Иванов» превращается в «Клиент-17», а таблица соответствий хранится у вас. Раз восстановить данные можно, они остаются персональными данными, и закон продолжает на них действовать.

Необратимое обезличивание. Таблицы соответствий нет, восстановить «Иванова» невозможно. Тогда данные перестают быть персональными и их можно передавать третьей стороне, в том числе облачной моделью.

Но у необратимого способа есть цена: вернуть настоящие имена в ответ модели уже не получится. Поэтому на практике используют обратимую замену для внутреннего контура и необратимую для внешнего.

И важная оговорка про формулировки. Один из разработчиков таких шлюзов советует в документах и разговорах с заказчиком называть обратимую замену «технической мерой минимизации персональных данных, передаваемых внешнему обработчику», а не «обезличиванием по 152-ФЗ». Юристы добавляют: если вы называете свою защиту обезличиванием, нужны утверждённые методы обезличивания, иначе при проверке Роскомнадзором или ФСБ могут признать, что обезличивание выполнено некорректно.

Что проверить, прежде чем запускать

Три пункта, которые чаще всего упускают.

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

Нужна проверка перед отправкой. Хороший слой не просто заменяет, а останавливает отправку, если что-то осталось. Разработчик одного из таких инструментов описывает это так: если после замены остались персональные данные, система выбрасывает ошибку и текст не уходит в модель, а не молча пропускает его.

Правила нужны на уровне компании, а не только у программиста. Обычные системы защиты от утечек (DLP, data loss prevention) здесь не спасают: они ловят файлы и вложения, а не имя клиента, вставленное в текст запроса. Поэтому автоматическую замену данных советуют включать на уровне всего трафика к моделям (через прокси или API), а не полагаться на дисциплину сотрудников.

Уровень защиты стоит подбирать по риску. Для внутреннего помощника без персональных данных замена не нужна, при работе с данными клиентов и в регулируемых отраслях она обязательна.

Кейс AllSee: облако без закупки серверов

Именно с этой задачей мы в AllSee работали для медицинского центра, микрофинансовой организации и страховой компании. Мы сделали систему очистки персональных данных. Она убирает их из текста до отправки в облачную модель, поэтому облачными моделями можно пользоваться без риска утечки.

Важный побочный эффект: заказчикам не понадобилось покупать свои видеокарты. Это сэкономило до 10 млн рублей капитальных затрат, а срок окупаемости сократился с 3 лет до 8 месяцев. ROI (return on investment, возврат на вложения) вырос на 35%. Система работает на серверах заказчика и не требовательна к оборудованию, а внедрение занимает около двух недель. Подробнее о наших продуктах — на allsee.team.

Честная оговорка: какой именно способ (обратимый или необратимый) подойдёт вашему бизнесу и достаточно ли его для вашего регулятора, определяется вашими данными и отраслью. Это вопрос к юристу и специалисту по защите информации, а не к тексту статьи.

Итог

Облачный ИИ и защита персональных данных не исключают друг друга, если данные заменяются до отправки. Проверьте четыре вещи: обратима ли замена и как вы её называете в документах, утверждены ли методы, хватает ли проверки перед отправкой и защищено ли не только ПДн, но и всё остальное, что нельзя выносить. Остальное зависит от того, насколько ваш юрист согласен с таким подходом.