Сайт и нейросети по 152-ФЗ: что проверить до запуска

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

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

Сначала нарисуйте путь данных

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

Виджет может передавать не только текст вопроса. В запрос могут попадать идентификаторы сессии, адрес страницы, контактные данные из формы, история чата или сведения из внутренней CRM. Проверьте реальные запросы браузера и серверные логи. Название поля «вопрос» не гарантирует, что в нём нет имени, телефона или других персональных сведений.

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

Определите цель и минимальный состав данных

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

Задайте вопросы команде: какие данные действительно необходимы для ответа? Может ли интерфейс попросить не вводить чувствительные сведения? Нужно ли вообще сохранять переписку? Какой срок хранения обоснован задачей? Кто имеет доступ к логам? Как посетитель узнаёт, что взаимодействует с автоматизированной системой и куда его сообщение может передаваться?

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

Проверьте поставщика и маршрут обработки

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

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

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

Согласия, уведомления и тексты интерфейса

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

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

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

Ограничьте ответы и доступ

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

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

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

Проведите проверку до открытия посетителям

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

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

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

Короткий чек-лист перед запуском

1. Нарисован полный маршрут пользовательского ввода и ответа.
2. Для каждого поля обоснована цель, а лишние данные не собираются.
3. Проверены поставщик, договор, настройки хранения и логи.
4. Юрист проверил применимые основания и документы для конкретного сценария.
5. Права доступа, отказ, передача человеку и выключение системы проверены.
6. Назначен владелец качества и обновления информации.

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

Не забывайте о работе после запуска

Даже аккуратный запуск не делает сценарий неизменным. Компания может добавить новую форму, сменить API или включить запись истории диалога. Назначьте владельца, который проверяет изменения и понимает, когда снова нужно согласовать обработку. В журнале изменений полезно фиксировать, какие поля появились, зачем они нужны и кто одобрил обновление.

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

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

Бесплатная диагностика за день

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

Оригинал опубликован на verstalabs.ru.