Статья описывает общий подход и наш опыт и не является юридической консультацией. Требования к обработке персональных данных зависят от ваших процессов — проверяйте решения с юристом.
Коротко
- Сначала определите, какие поля модели действительно нужны: часть задач решается на обезличенных данных.
- Место обработки и возможная передача за рубеж выясняются до выбора модели, а не после запуска.
- Цели обработки, основание и роли (оператор и обработка по поручению) фиксируются заранее.
- Роли доступа, журнал и срок хранения касаются не только исходных документов, но и запросов к модели, индексов и логов.
- Статья не заменяет юридическую консультацию: решения по вашему случаю согласуйте с юристом.
Где AI сталкивается с персональными данными
Персональные данные — это любая информация, которая относится к определённому или определяемому человеку: имя, телефон, адрес, почта, должность вместе с фамилией, номер договора, по которому можно найти клиента. Для 152-ФЗ важно не только хранение: сбор, запись, использование, передача и удаление тоже считаются обработкой.
AI-решение почти всегда попадает под эти правила, если работает с живым материалом компании. Персональные данные есть в обращениях и письмах, договорах и анкетах, записях звонков, выгрузках из CRM и 1С, а также в самих запросах сотрудников. Отправка такого текста в модель, как правило, тоже считается обработкой. Поэтому вопрос не в том, касается ли это вас, а в том, как её организовать.
Какие данные передавать модели, а какие нет
Начните с вопроса: какие поля нужны модели, чтобы выполнить задачу? Для классификации обращения обычно важны текст и тема, а не фамилия и паспортные данные. Для поиска по регламентам персональные данные не нужны вовсе. Чем меньше полей уходит в модель, тем проще всё остальное: договоры, защита, состав согласий.
Обезличивание — это изменение данных так, чтобы без дополнительной информации нельзя было определить, к какому человеку они относятся. На практике имена, телефоны, адреса и номера заменяют метками, а таблицу соответствий хранят отдельно, в вашем контуре. Если по этой таблице данные легко вернуть обратно, юристы нередко считают их по-прежнему персональными. Этот момент уточните у своего юриста.
Типичные ошибки на этом шаге чаще связаны не с технологией, а с привычкой делать быстро. Ниже — те, что встречаются в проектах с живыми данными компании.
- Отправлять в модель выгрузку целиком, потому что так проще, чем выбрать нужные поля.
- Убирать только имена, оставляя телефоны, адреса и номера договоров в свободном тексте.
- Проверять модель на реальных данных в публичном сервисе, не изучив его условия.
- Забывать, что персональные данные бывают на сканах и во вложениях, а не только в таблицах.
- Хранить исходные и обезличенные данные в одном месте с одинаковым доступом.
Передача персональных данных в модель: где она обрабатывается
Когда вы отправляете текст во внешний сервис модели, данные покидают ваш контур. Нужно выяснить, где физически стоят серверы, кому они принадлежат, сохраняются ли запросы и как долго, используются ли они для дообучения. От ответов зависит оценка рисков.
Если персональные данные граждан России собираются и записываются, то, как правило, действует требование локализации: первичная запись и хранение должны быть в базах на территории страны. Если модель или журналы находятся за границей, речь идёт о трансграничной передаче, к которой предъявляются отдельные требования, в том числе к оценке того, как принимающая сторона защищает данные. Порядок для вашего случая уточните у юриста.
С технической стороны есть несколько путей: развернуть решение в собственной инфраструктуре, использовать согласованное облако (российское — если своей инфраструктуры под задачу нет) либо передавать внешней модели только обезличенный текст. Выбор зависит от того, какие данные нужны задаче, и от требований вашего юриста и службы безопасности.
152-ФЗ и AI: цели, согласие, оператор и поручение
Оператор — организация, которая определяет цели и состав обработки персональных данных. Как правило, это вы: именно вы решаете, зачем вам данные клиентов и сотрудников. Цели должны быть определены заранее и быть законными, а состав данных — соответствовать им, без избыточности.
Обработка нуждается в основании. Часто это согласие человека, в других случаях — договор или закон. Если вы собирали данные клиента, чтобы исполнить заказ, то их использование для обучения или тестирования модели — вопрос к юристу: как правило, это может быть уже другая цель.
Подрядчик, который разворачивает решение, и поставщик модели часто действуют как лица, обрабатывающие данные по поручению оператора. Поручение оформляется договором: в нём указывают перечень действий, цели и требования к защите. Ответственность перед человеком, чьи данные обрабатываются, как правило, остаётся на операторе, поэтому условия поручения стоит читать внимательно.
Журнал, доступы и срок хранения
Доступы. Решение должно показывать каждому сотруднику только то, что ему положено. Это касается и корпоративного поиска, и AI-ассистента: если модель получает контекст из базы знаний, права пользователя нужно проверять до того, как документ попадёт в ответ. Принцип простой: разграничение ролей и минимально необходимые права.
Журнал. Фиксируйте, кто, когда и с какой целью обращался к решению, какие источники использовались и какой ответ получен. Журнал помогает разбирать инциденты и отвечать на запросы. Но сам журнал может содержать персональные данные, поэтому его нужно защищать и ограничивать срок его хранения.
Срок хранения. Как правило, данные хранят не дольше, чем нужно для целей обработки. Заранее решите, сколько живут исходные документы, копии в поисковом индексе (где фрагменты документов хранятся в виде, удобном для поиска), кэш, журнал запросов и результаты работы модели. Когда данные удаляются из источника, их копии внутри решения тоже должны исчезать — это нужно предусмотреть при проектировании.
Вопросы подрядчику до начала работ
Ответы на эти вопросы стоит получить письменно, до подписания договора: так их можно приложить к договору и вернуться к ним при приёмке. Вопросы касаются данных, места обработки, ролей сторон и судьбы данных после проекта.
Если на часть вопросов подрядчик отвечает общими словами, это повод остановиться и уточнить, а не принимать ответ на веру.
- Какие поля данных нужны решению и можно ли начать на обезличенных данных?
- Где будет развёрнуто решение и где физически находятся модель, база и журналы?
- Уходят ли данные за пределы России, и если да, то кому и зачем?
- Сохраняет ли поставщик модели запросы и использует ли их для обучения?
- Кто выступает оператором, а кто обрабатывает данные по поручению, и как это оформляется?
- Как устроены роли доступа, журнал и удаление данных по окончании срока хранения?
- Что будет с данными, кодом и конфигурациями после завершения проекта?
Как мы работаем с персональными данными в проектах
Начинаем с бесплатного разбора задачи. На нём выясняем, какие поля решению вообще нужны: часть задач решается на обезличенных данных. Требования 152-ФЗ закладываем при проектировании, а не подгоняем под них готовое решение. Результат — письменный документ с границами решения, критерием приёмки и перечнем рисков.
Решение разворачиваем внутри вашей инфраструктуры или в согласованном облаке; контур выбираете вы на старте: свой или российское облако. Доступы строим на разграничении ролей и минимально необходимых правах. Для контроля работы AI предусматриваем логирование, мониторинг, участие человека и обработку ошибок.
Прототип делаем на ваших данных; если в выгрузке есть персональные данные, просим передать её в обезличенном виде. Условия передачи кода, конфигураций и прав определяются до начала проекта, а режим поддержки после запуска фиксируется договором. Юридическую оценку мы не заменяем: решения по основаниям, согласиям и передаче за рубеж согласуйте со своим юристом.
