Чек-лист по 152-ФЗ перед запуском агента

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

Каждый сценарий проверяется на цель и основание отдельно

По 152-ФЗ обрабатывать персональные данные можно только под конкретную цель и с одним из законных оснований — согласием субъекта, договором или прямым требованием закона. Заказчик как оператор определяет эти два параметра сам, платформа технически исполняет уже принятое решение.

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

Если сценарий собирает персональные данные, а политика обработки ещё не опубликована и согласия не собираются, это делается до первого реального диалога, а не после жалобы клиента или проверки.

Минимизация: какое поле в сценарии лишнее

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

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

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

Модель за агентом решает, где физически обрабатывается текст

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

Выбор модели под задачу и бюджет — вопрос шире одной только территории обработки, и на него отвечает статья «Какую модель выбрать для ИИ-агента». Здесь важна только одна развилка: иностранная модель плюс возможные ПДн россиян означают, что следующую настройку нужно включить.

Псевдонимизация обезличивает данные до отправки в модель

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

Внешние интеграции создают собственный поток данных

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

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

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

Что сделать до первого реального диалога

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

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

Частые вопросы