- 1Правила начинают с фактических задач сотрудников. Перечень сервисов без описания данных и допустимых действий оставляет главные вопросы открытыми.
- 2Для каждого сценария определяют разрешённый инструмент, состав сведений, ограничения и проверку результата. Исключения проходят понятное согласование.
- 3Документ должен совпадать с доступами и настройками. Его работоспособность проверяют на обычных действиях сотрудника, а не только на формальном ознакомлении.
Правовые выводы проверены и актуализированы 3 октября 2026 года. Примеры условные; рекомендации по организации работы отделены от обязательных требований.
Сначала выясните, как сотрудники уже используют ИИ
Начните с коротких разговоров с подразделениями. Какие задачи ускоряют нейросети? Кто оплачивает аккаунт? Загружают ли документы, используют ли историю переписки, подключают ли расширения? Спросите о рабочем процессе, чтобы получить факты, а не только ответ о знании запрета.
Разделяйте личный чат, корпоративный сервис и встроенную функцию другой программы. Сотрудник может не замечать, что помощник в редакторе отправляет текст внешнему поставщику. Правила должны охватывать такой маршрут, даже если человек не открывал отдельный сайт нейросети.
Для начала достаточно описать наиболее распространённые задачи и несколько чувствительных ситуаций. Не требуйте от работников точного названия модели, если они его не знают. Техническую схему уточнит ответственная команда; отсутствие названия не делает использование безопасным.
Разрешайте сценарий, а не только название сервиса
Запись «сервис разрешён» легко трактуется как разрешение отправлять в него любые сведения. Лучше определить, для чего инструмент допущен: подготовка шаблонного письма, проверка общедоступного текста или работа с определённой категорией внутренних документов. Затем связать допуск с конкретной учётной записью и настройками.
Условный пример: сотруднику разрешили составлять черновики коммерческих предложений на вымышленных данных. Это ещё не означает разрешения загружать клиентскую базу для персонализации. В правилах нужно показать границу на таком примере и указать, как согласовать расширение сценария.
Список инструментов должен иметь владельца и дату проверки. После изменения тарифа, условий или функций сервиса прежнее разрешение может потребовать пересмотра. Если решение хранится только в переписке одного сотрудника, подразделения быстро начнут пользоваться разными версиями правил.
Объясните, какие сведения можно передавать
Перечислите категории, которые компания допускает в конкретном сценарии, и те, для которых нужна отдельная проверка. Среди чувствительных материалов могут быть клиентские документы, данные работников, договоры с ограничениями и сведения о доступе к системам. Состав зависит от деятельности компании.
Для персональных данных статья 5 Закона № 152-ФЗ требует учитывать цель и объём обработки, а статья 6 — её основание. Внутренняя политика не создаёт отсутствующее законное основание. Допуск такого сценария должен опираться на отдельную проверку данных и поставщика.
Дайте сотруднику способ уменьшить состав входных сведений: взять условный пример, оставить только необходимый фрагмент, убрать лишние вложения. При этом замена имени сама по себе не доказывает обезличивание всего документа. Человек может определяться по должности, событию и другим обстоятельствам.
Если подготовить допустимый материал невозможно, предусмотрите альтернативу: проверенный внутренний инструмент или выполнение задачи без внешней LLM. Иначе правило сведётся к требованию результата, который сотрудники смогут получить только нарушив ограничения.
Опишите ответственность за использование ответа
Сотрудник должен понимать, что именно он проверяет перед использованием результата: факты, ссылки, расчёты и существенные условия. Генерация черновика и отправка готового документа клиенту — разные действия. Для важных решений определите, кто вправе согласовать итог.
Не заменяйте инструкцию фразой «проверяйте всё». Покажите несколько характерных ошибок: выдуманная норма, пропущенное исключение, неверная сумма или обещание клиенту, которого компания не давала. Затем объясните, где взять источник для проверки и что сделать при сомнении.
При работе с чужими текстами и изображениями отдельно оценивают права на использование. Статья 1270 ГК РФ регулирует способы использования произведения. Доступность файла для просмотра не является универсальным разрешением применять его в любом рабочем процессе.
Сделайте согласование исключений удобным
Для запроса нового сценария достаточно понятной карточки: задача, сервис, данные, пользователи и предполагаемое действие с результатом. Назначьте того, кто собирает решение юриста, информационной безопасности и IT. Работник не должен самостоятельно выяснять внутренние границы полномочий этих подразделений.
Ответ на запрос должен содержать конкретные условия либо объяснение, что требуется уточнить. Если разрешение выдано для пилота, определите его границы и момент повторной проверки. Ограниченный тест не должен незаметно превращаться в постоянную обработку всей клиентской информации.
Подготовьте действия при неправильной передаче
В правилах нужен доступный контакт для сообщения об ошибке. Опишите, какие факты сообщить: инструмент, время, категория сведений и выполненные действия. Просите сохранить необходимые подтверждения безопасным способом, а не повторно пересылать чувствительный файл всем участникам обсуждения.
Ответственная команда выясняет, что произошло, можно ли ограничить дальнейшую обработку и какие действия требуются. Обязанности по уведомлению и сроки оценивают по фактам и применимым нормам. Универсальный приказ «удалить чат и забыть» может помешать разобраться в последствиях.
Проверьте правила на действиях обычного сотрудника
Попросите работника найти разрешённый сервис, подготовить допустимый запрос и согласовать исключение. Затем проверьте, совпадают ли правила с интерфейсом, доступами и настройками. Если путь непонятен человеку без юридической подготовки, документ стоит доработать.
Начните с короткой инструкции и нескольких примеров для каждого подразделения. Подробные требования можно вынести в связанные документы. После внедрения отслеживайте вопросы и повторяющиеся нарушения: они часто показывают, где правило расходится с реальной задачей.
Рабочая политика даёт сотрудникам способ выполнять задачи в согласованных границах, а компании — возможность видеть и менять эти границы. Она требует поддержки владельца процесса и технической команды, а не только подписи на последней странице.