Безопасность внедрения ИИ: персональные данные и 152-ФЗ

Обработкой считается почти любое действие с персональными данными: сбор, запись, хранение, использование, передача. Специального исключения «если это делает нейросеть» в законе нет. Поэтому как только в контекст модели попадает фамилия, телефон, адрес, номер договора с привязкой к человеку или сведения о здоровье, компания действует как оператор персональных данных со всеми обязанностями.

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

Отдельная категория — специальные данные: сведения о здоровье, национальность, судимость, биометрия. Голос и изображение лица в ряде сценариев тоже требуют отдельного внимания, поэтому распознавание звонков и видеоаналитику мы всегда обсуждаем со службой безопасности до подключения источников, а не после запуска.

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

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

Практические последствия делятся на три группы. Правовые: обработка без надлежащего основания, нарушение условий согласия, вопросы при проверке. Договорные: почти в любом NDA с корпоративным заказчиком есть запрет на раскрытие сведений третьим лицам, и загрузка спецификации во внешний сервис под этот запрет подпадает. Репутационные: объяснять клиенту, как его документы оказались у стороннего провайдера, придётся вам, а не сервису.

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

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

1. Размещение внутри периметра. Модели, векторные индексы, журналы и интерфейсы на сервере заказчика либо в его выделенном контуре в российском ЦОД. Исходящий трафик закрыт на уровне сети.
2. Обезличивание на входе. Перед передачей текста в модель ФИО, телефоны, номера документов и счетов заменяются на маркеры, а в готовый ответ подставляются обратно. Для многих задач модели вообще не нужно знать, как зовут клиента.
3. Разграничение доступа с наследованием. Права берутся от системы-владельца документа. Если у сотрудника нет доступа к папке в документообороте, поиск не покажет ему фрагмент из неё даже внутри ответа модели.
4. Журналирование каждого действия. Кто спросил, что ответила система, какие документы попали в контекст, что сделал агент. Журнал пишется в хранилище, где записи нельзя изменить задним числом, и имеет собственный срок хранения.
5. Основания и согласия. Обновляется перечень целей обработки, формы согласий и условия, на которых данные попадают в систему. Это работа юриста, но состав данных и маршруты мы описываем схемой контура.
6. Минимизация и срок хранения. В контур подключаются только те источники, без которых сценарий не работает. Для каждого хранилища определён срок, после которого данные удаляются или обезличиваются.
7. Человек на необратимых действиях. Отправка письма, изменение документа, проводка в учётной системе выполняются только с подтверждением сотрудника. Это правило не отключается ради ускорения процесса.

• Новые цели обработки. Автоматическая классификация обращений, подготовка проектов документов, распознавание речи — цели формулируются конкретно, а не общей строкой про «улучшение сервиса».
• Состав данных, попадающих в систему. Перечень источников и категорий данных по каждому: CRM, документооборот, почта, телефония. Схема контура прикладывается как приложение.
• Где данные хранятся и обрабатываются. Указание, что обработка идёт на собственных серверах оператора или в его выделенном контуре, без передачи третьим лицам и без трансграничной передачи.
• Сроки хранения по каждому хранилищу. Отдельно для журналов обращений, кэша ответов, индексов базы знаний и записей разговоров. Единый срок «до достижения целей» на практике вызывает вопросы.
• Порядок доступа сотрудников. Кто имеет доступ к системе, как права наследуются от учётных систем, как доступ закрывается при увольнении.
• Роль автоматизации в решениях. Прямое указание, что юридически значимые решения принимает человек, а система готовит материалы. Особенно важно для кадровых, кредитных и клиентских сценариев.
• Порядок обращения субъекта. Как человек может узнать состав своих данных, потребовать уточнения или удаления, включая данные, попавшие в журналы и индексы.

Персональные данные и коммерческая тайна живут по разным правилам, и закрытие одного не закрывает второе. Режим коммерческой тайны требует утверждённого перечня сведений, грифа на документах, учёта лиц, получивших доступ, и обязательств в трудовых договорах. Если режим введён, ИИ-контур должен попасть в перечень систем, где такие сведения допустимо обрабатывать.

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

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

На стороне проекта мы описываем, какие источники подключены, кто имеет доступ, что пишется в журналы и как контур изолирован от внешней сети. Реестр рисков с мерами и ответственными собирается на диагностике — подробный разбор в материале про риски внедрения.

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

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

Есть вещи, которые мы не делаем и говорим об этом сразу. Формальная аттестация информационной системы, работа со сведениями, составляющими государственную тайну, и юридическое сопровождение обработки персональных данных — зона профильных подрядчиков и вашей службы ИБ. Мы передаём проектную документацию по контуру: схему размещения, маршруты данных, матрицу доступа, состав журналов.

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