Почти каждый ИИ-проект в российской компании рано или поздно упирается в персональные данные. Резюме, обращения клиентов, записи разговоров, документы — всё это подпадает под 152-ФЗ, и вопрос не в том, обойти его или нет, а в том, как построить решение так, чтобы оно было и полезным, и законным. Разберём практическую сторону: что реально мешает, а что оказывается мнимым препятствием.
Сразу оговорка: это инженерный разбор, а не юридическая консультация. Конкретную конфигурацию всегда согласовывайте со своим юристом и службой безопасности — здесь мы описываем, какие технические решения обычно позволяют это согласование пройти.
Что считается персональными данными в ИИ-проекте
Шире, чем обычно думают. Помимо очевидных ФИО, паспорта и телефона, это записи голоса, изображения лица, история покупок, привязанная к клиенту, тексты обращений с упоминанием личных обстоятельств. Отдельная категория — специальные данные: здоровье, судимости, национальность. Требования к ним жёстче, и попадают они в проекты чаще, чем ожидается: например, в анкете кандидата или в обращении клиента.
Практический вывод: инвентаризацию данных надо делать до архитектуры, а не после. Обнаружить специальные категории на этапе приёмки — значит переделывать хранение и доступы.
Основание обработки — первый вопрос, а не последний
Обрабатывать персональные данные можно только на законном основании. В ИИ-проектах чаще всего работают три.
- Согласие субъекта. Универсально, но хрупко: оно должно быть конкретным, информированным и отзываемым, а при отзыве данные надо уметь удалить — включая те, что попали в обучающую выборку.
- Исполнение договора. Работает, когда обработка нужна для того, ради чего договор и заключён: доставка, обслуживание, кадровое оформление. Обучение модели на этих данных под это основание обычно не подпадает.
- Законные интересы оператора. Гибче, но требует обоснования и оценки баланса интересов. Для внутренних задач вроде антифрода применимо, для маркетинговых профилей — спорно.
Главная ошибка здесь — выбрать основание постфактум, когда решение уже построено. Основание определяет, что вообще можно делать с данными, и потому идёт первым.
Обезличивание: что это даёт и чего не даёт
Обезличивание — самый рабочий инструмент в ИИ-проектах. Если из данных убраны идентификаторы и восстановить личность по ним нельзя, режим обработки существенно мягче. Для обучения моделей этого обычно достаточно: модели нужны закономерности, а не имена.
Чего обезличивание не решает
Замены имени на идентификатор недостаточно, если по остальным полям человек всё равно определяется. Комбинация должности, подразделения и даты приёма нередко указывает на единственного сотрудника. Проверять надо не наличие ФИО, а фактическую возможность идентификации — это отдельная работа, и её стоит закладывать в проект.
Отдельная проблема: данные внутри модели
Языковая модель, дообученная на текстах с персональными данными, может воспроизвести их в ответе. Это не гипотетический риск. Поэтому мы предпочитаем подход, при котором модель не дообучается на чувствительных текстах, а обращается к ним поиском в момент запроса, — тогда права доступа работают на каждом обращении, а не «зашиты» в веса.
Локализация и трансграничная передача
Базы с персональными данными россиян должны находиться в России. Отсюда прямое следствие для ИИ: отправка таких данных в зарубежный облачный сервис — это трансграничная передача со всеми требованиями к ней, а для многих компаний просто неприемлемый вариант.
Практических выходов три: обезличивать данные до отправки, использовать российские облачные модели, размещённые внутри страны, или разворачивать открытую модель в собственном контуре. Третий вариант дороже, но снимает вопрос целиком: данные не покидают периметр физически.
Три архитектуры и их правовые последствия
Зарубежное облако
Дёшево и быстро, но для персональных данных россиян почти всегда неприменимо без обезличивания. Годится для задач, где чувствительных данных нет вовсе: работа с обезличенной статистикой, генерация маркетинговых текстов, разбор публичных документов.
Российское облако
Компромисс: локализация соблюдена, инфраструктуру не нужно закупать. Требуется договор с обработчиком и проверка его мер защиты. Для большинства задач среднего бизнеса этого достаточно.
Закрытый контур
Максимальная защищённость и максимальная стоимость: серверы с GPU, размещение, обновления, эксплуатация. Для банков, медицины и государственных учреждений это часто единственный проходимый вариант. У нас есть проект, где собственная языковая модель развёрнута в контуре заказчика именно потому, что выгрузка кода и данных была запрещена.
Что обычно требует служба безопасности
- Перечень обрабатываемых данных с указанием категорий и оснований обработки.
- Схему потоков: откуда данные приходят, где хранятся, куда уходят, кто имеет доступ.
- Подтверждение локализации: где физически лежит база.
- Механизм удаления по требованию субъекта, включая обучающие выборки и резервные копии.
- Журналирование доступа: кто и когда обращался к данным, с возможностью выгрузки.
- Оценку того, что происходит при компрометации: какой объём данных под риском и как это обнаруживается.
Этот список стоит запросить у своей службы безопасности до начала проекта, а не на приёмке. Половина требований влияет на архитектуру, и добавить их потом дороже, чем заложить сразу. В нашей практике именно поздний вход безопасности — самая частая причина срыва сроков в ИИ-проектах.
Пять типичных ошибок
- Обучать модель на «сырых» данных, потому что так проще, а обезличить обещать позже. Позже это будет означать переобучение с нуля.
- Считать замену ФИО на идентификатор достаточным обезличиванием, не проверив возможность идентификации по совокупности полей.
- Отправлять данные в зарубежный сервис на этапе прототипа «для быстроты». Прототип имеет свойство становиться основой продакшена.
- Не предусмотреть удаление данных при отзыве согласия — включая копии в обучающих выборках и бэкапах.
- Подключать службу безопасности после того, как решение готово. Это гарантированная переделка.
Записи разговоров и биометрия
Отдельная зона, где ошибаются чаще всего. Голосовые проекты почти всегда работают с записями разговоров, и здесь есть два разных вопроса, которые смешивают.
Первый: запись содержит персональные данные — то, что человек о себе сообщил. Это обычная обработка со стандартными требованиями. Второй: голос как таковой может использоваться для идентификации, и тогда речь идёт о биометрических персональных данных, требования к которым существенно строже.
Практическая граница проходит по цели. Если запись распознаётся в текст, чтобы понять запрос, и голос не используется для установления личности, это не биометрия. Если система определяет, кто говорит, по голосу — биометрия со всеми последствиями. Это стоит зафиксировать в документах проекта явно, потому что вопрос обязательно возникнет.
Практический приём для голосовых проектов: после распознавания хранить текст, а аудио удалять по короткому сроку. Текст обычно достаточен и для работы, и для дообучения, а объём чувствительных данных сокращается радикально. Исключение — задачи, где нужен именно звук, но их меньше, чем кажется на старте.
Что должно быть в согласии, чтобы оно покрывало ИИ
Типичная ситуация: согласие получено давно, сформулировано под учётные задачи и обучение моделей не покрывает. Формально обработка идёт за пределами того, на что человек соглашался.
- Цели должны быть перечислены конкретно, включая улучшение качества сервиса и обучение алгоритмов, если оно планируется. Общая формулировка «в целях деятельности организации» проверку не проходит.
- Перечень обрабатываемых данных должен соответствовать реальности, а не быть шире на всякий случай — избыточность здесь работает против оператора.
- Должны быть названы действия с данными, включая автоматизированную обработку.
- Срок действия согласия и порядок отзыва — с указанием, куда обращаться, и реальным механизмом за этим.
Отдельный вопрос — привлечение подрядчика. Если разработчик получает доступ к данным, это поручение обработки, оформляемое договором с описанием мер защиты. На практике проще и безопаснее строить работу так, чтобы подрядчик работал с обезличенными данными или внутри вашего контура.
Сроки хранения и удаление
Данные нельзя хранить бессрочно «на всякий случай»: срок определяется целью, и по её достижении данные подлежат удалению или обезличиванию. В ИИ-проектах это создаёт специфическую сложность — данные размножаются по системам.
К моменту, когда приходит требование об удалении, копии человека могут лежать в исходной системе, в промежуточном хранилище, в векторном индексе, в обучающей выборке и в резервных копиях. Механизм удаления должен покрывать все эти места, и проектировать его надо сразу — восстанавливать связи постфактум мучительно.
Практическое решение: сквозной идентификатор субъекта во всех производных хранилищах. Тогда удаление становится процедурой, а не расследованием. Стоит это дёшево на этапе проектирования и очень дорого — потом.
Порядок действий для нового проекта
- Составьте перечень данных, которые понадобятся, с указанием категорий и источников. Отдельно отметьте специальные категории.
- Определите основание обработки для каждой цели — до выбора архитектуры.
- Решите, что можно обезличить, и проверьте, что после обезличивания идентификация действительно невозможна.
- Определите, где данные будут находиться физически на каждом этапе, включая обучение и отладку.
- Согласуйте схему со службой безопасности и юристом до начала разработки, а не на приёмке.
- Заложите механизм удаления и журналирование доступа в первую версию решения.
Этот порядок выглядит бюрократичным ровно до первого проекта, где его не соблюли. Переделка архитектуры после замечаний безопасности обходится дороже, чем неделя согласований на старте, и почти всегда срывает сроки.
Обезличивание на практике: как это делается
Разберём приёмы, которые реально применяются, потому что «обезличить данные» — это не одна операция, а набор решений с разными последствиями для качества модели.
- Удаление прямых идентификаторов: ФИО, паспорт, телефон, адрес. Самое очевидное и самое недостаточное.
- Замена на устойчивый псевдоним: вместо имени — идентификатор, одинаковый для одного человека во всех записях. Позволяет сохранить связи между событиями, что часто критично для модели.
- Огрубление: вместо точной даты рождения — год, вместо точного адреса — район. Снижает риск идентификации, почти не теряя полезного сигнала.
- Обобщение редких значений: если в выборке один человек с определённой должностью, его всё равно узнают. Такие категории объединяются в более широкие.
- Маскирование в свободном тексте: имена и контакты внутри обращений и переписки надо находить и заменять автоматически — вручную это нереально на объёме.
Последний пункт заслуживает отдельного внимания, потому что о нём забывают. Персональные данные в структурированных полях обезличить легко. Но те же данные встречаются внутри текста обращения: «звонил Иван Петрович по договору такому-то». Если обезличивание работает только по колонкам, оно создаёт ложное ощущение безопасности.
Проверять результат стоит не глазами, а попыткой обратного восстановления: возьмите обезличенную выборку и посмотрите, можно ли по совокупности признаков определить конкретного человека. Если да — обезличивание не состоялось, каким бы аккуратным оно ни выглядело.
Коротко
- Основание обработки выбирается до архитектуры, а не после: оно определяет, что вообще можно делать с данными.
- Обезличивание — главный рабочий инструмент, но проверять надо фактическую невозможность идентификации, а не отсутствие ФИО.
- Дообучение на чувствительных текстах опаснее поиска по ним: из весов данные не удалить.
- Локализация закрывает путь в зарубежные облака; остаются российское облако и закрытый контур.
- Служба безопасности должна войти в проект на этапе архитектуры — поздний вход стабильно срывает сроки.