Как разработать правила использования ИИ в компании: пошаговый план

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

Зачем компании правила использования ИИ

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

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

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

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

Что меняется в компании после появления правил

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

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

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

Когда регламент критичен, а когда достаточно памятки

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

1. Компания обрабатывает персональные данные клиентов или сотрудников в объёме, выходящем за кадровый учёт
2. В работе есть информация, составляющая коммерческую тайну, включая финансовые модели, условия сделок, незапатентованные разработки
3. Организация работает в регулируемой отрасли, где есть требования надзорных органов к обработке информации
4. Нейросети применяются в разработке продукта, то есть генерируемый код попадает в промышленную эксплуатацию
5. Численность превышает сотню человек и прямой контроль за практиками невозможен
6. Есть подрядчики и распределённые команды с доступом к внутренним системам

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

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

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

Категории информации с полным запретом

В этот список попадает то, передача чего создаёт либо прямое нарушение закона, либо неустранимый ущерб.

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

Запрет имеет смысл дополнять объяснением альтернативы. Если сотруднику нужно проанализировать клиентскую базу, правило должно подсказывать путь обезличивания, а не оставлять человека без решения. Иначе запрет будет нарушен тихо и без обсуждения.

Серая зона и как с ней работать

Большая часть реальных вопросов приходится не на явные запреты, а на промежуточные случаи. Коммерческое предложение без названия клиента. Договор с заменёнными реквизитами. Фрагмент кода без бизнес-логики. Техническое задание, которое само по себе не секретно, но раскрывает направление развития продукта.

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

Обезличивание считается выполненным, когда по оставшемуся тексту невозможно определить, о каком клиенте, сделке или сотруднике идёт речь, даже имея общее представление о бизнесе компании.

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

Как узнать, что данные уже уходят

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

1. Логи сетевого оборудования и прокси за последние два-три месяца показывают обращения к известным сервисам генеративных моделей и их объём
2. Анонимный опрос сотрудников даёт понимание задач, для которых нейросети применяются, и причин выбора конкретных сервисов
3. Выгрузка корпоративных расходов и личных компенсаций обнаруживает оплаченные подписки, о которых не знает ни один отдел

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

Что включить в регламент использования ИИ

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

Общие положения и область действия

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

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

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

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

Классификация данных по уровням доступа

Это ядро документа и единственный раздел, который действительно меняет поведение. Запрет без классификации заставляет сотрудника угадывать. Классификация превращает решение в проверку по таблице.

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

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

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

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

Реестр разрешённых ИИ-инструментов

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

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

Вот как это может выглядеть в минимальной форме.

Инструмент	Назначение	Максимальный уровень данных	Ограничения
ChatGPT Plus	Написание текстов, переводы, анализ информации	Публичная и внутренняя информация	Без загрузки документов с реквизитами клиентов
GitHub Copilot	Помощь в написании кода	Внутренняя информация	Не использовать на закрытых компонентах
Claude	Анализ больших текстов, разработка документов	Внутренняя информация	Без загрузки исходного кода критичных систем

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

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

Порядок согласования новых сервисов

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

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

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

Отрицательный ответ должен содержать причину, а не просто закрывать вопрос. Типичные причины отказа.

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

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

Роли и ответственность сотрудников

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

В малых компаниях часто одно лицо собирает все роли. В больших они распределяются. Полный набор выглядит примерно так.

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

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

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

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

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

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

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

Правила применения ИИ в разработке

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

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

• Код, сгенерированный нейросетью, обязательно проходит код-ревью перед коммитом, независимо от статуса автора в команде
• Разработчик несёт полную ответственность за корректность, безопасность и производительность сгенерированного кода
• Генеративные модели не должны использоваться при разработке безопасностью-критичных компонентов без дополнительного тестирования на уязвимости
• Нейросеть нельзя использовать для написания кода обработки криптографии, валидации входных данных и мер защиты от атак, пока этот код не проверен специалистом безопасности
• Все зависимости и библиотеки, предложенные нейросетью, должны быть выверены на предмет наличия известных уязвимостей и лицензионной совместимости
• При использовании нейросетей для документирования кода ответственность за актуальность документации остаётся на разработчике

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

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

Порядок действий при инцидентах

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

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

Типичные инциденты, которые стоит предусмотреть.

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

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

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

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

Памятка для сотрудника

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

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

Рабочая версия памятки обычно выглядит так.

• Используйте только инструменты из корпоративного списка и только через рабочую учётную запись
• Перед отправкой запроса проверьте текст на наличие фамилий, телефонов, адресов, номеров договоров, сумм сделок и реквизитов
• Заменяйте названия клиентов и контрагентов условными обозначениями вида Заказчик А
• Любой факт, цифру, ссылку на закон или цитату из ответа модели проверяйте по первоисточнику перед использованием в документе
• Не выдавайте текст, сгенерированный моделью, за результат собственного анализа там, где от вас ждут экспертного заключения
• Если нужного инструмента нет в списке, отправьте запрос на согласование вместо самостоятельного решения
• Если данные ушли туда, куда не должны были, сообщите в первый же час и не пытайтесь исправить ситуацию самостоятельно

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

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

Как разработать регламент: этапы

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

Аудит текущего использования ИИ

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

Порядок работы примерно такой.

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

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

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

Согласование с ИБ, юристами и руководителями

На этом этапе документ впервые встречается с реальностью. Служба безопасности предсказуемо будет сужать разрешённое, подразделения будут расширять, юристы будут требовать формулировок, которые устоят в споре. Задача не в том, чтобы найти компромисс между всеми, а в том, чтобы каждая сторона отвечала за свою часть решения.

Распределение зон ответственности при согласовании.

• Служба информационной безопасности определяет технические ограничения, допустимые категории данных для каждого инструмента и механизмы контроля
• Юридический отдел проверяет соответствие 152-ФЗ, режиму коммерческой тайны, требованиям отраслевых регуляторов и формулирует раздел об ответственности
• Руководители подразделений подтверждают, что описанные процессы выполнимы и не ломают их рабочие задачи
• Кадровая служба отвечает за порядок ознакомления, хранение подписей и связь регламента с трудовыми отношениями
• Закупки и финансы берут на себя вопросы оплаты корпоративных подписок и договоров с поставщиками

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

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

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

Как внедрить правила и добиться соблюдения

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

Разумный график внедрения растягивается на четыре-шесть недель.

1. Первая неделя уходит на объявление от руководства с объяснением причин и публикацию документа в доступном месте
2. Вторая и третья недели занимает обучение по подразделениям с разбором их собственных задач
3. Четвёртая неделя отводится на подключение корпоративных инструментов и выдачу доступов
4. Пятая и шестая недели работают как переходный период, когда нарушения разбираются как ошибки обучения, а не как дисциплинарные случаи
5. После этого включается технический контроль в полном объёме и начинает действовать раздел об ответственности

Обучение сотрудников

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

Структура занятия на сорок минут.

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

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

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

Технические настройки и контроль

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

Базовый набор технических мер.

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

Контроль соблюдения не сводится к наблюдению за трафиком. Полезнее комбинация из нескольких источников.

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

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

Типичные ошибки при разработке правил

Большинство неработающих регламентов повторяют один из нескольких сценариев. Знание этих сценариев заранее экономит время на переделку.

• Полный запрет без альтернативы. Сотрудники продолжают использовать нейросети через личные устройства и учётные записи, но теперь скрытно, и компания теряет даже тот контроль, который был
• Отсутствие классификации данных. Запрет на конфиденциальную информацию без перечня примеров заставляет сотрудника угадывать, и угадывает он в свою пользу
• Копирование шаблона без адаптации. Документ описывает процессы, которых в компании нет, и не упоминает те, которые есть, после чего теряет доверие при первом же применении
• Юридический язык вместо рабочего. Регламент, который нужно перечитывать дважды, чтобы понять одно требование, не используется в момент принятия решения
• Отсутствие владельца документа. Через полгода регламент описывает устаревший набор инструментов, и его перестают воспринимать серьёзно
• Игнорирование подрядчиков и распределённых команд. Правила распространяются на штат, а данные обрабатываются внешними исполнителями по их собственным привычкам
• Расчёт только на документ без технических мер. Намерение зафиксировано, настройки инструментов его не поддерживают
• Наказание за добровольное сообщение об инциденте. После первого показательного разбора компания узнаёт о проблемах только тогда, когда их уже нельзя исправить
• Избыточная детализация. Документ на сорок страниц с матрицами и схемами не читает никто, включая его авторов

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

Чего регламент не решает

Документ задаёт рамку и распределяет ответственность. За его пределами остаётся несколько вещей, которые придётся решать отдельно.

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

Регламент не повышает качество результата сам по себе. Правило о проверке фактов работает, только если у сотрудника есть время на проверку и понимание, как её делать. Без обучения работе с запросами и без реалистичных сроков правило превращается в формальность.

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

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

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

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

Нужны ли правила компании из пяти человек

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

Можно ли просто запретить нейросети

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

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

Чем регламент ИИ отличается от политики обработки персональных данных

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

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

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

Как часто обновлять документ

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

Помимо плановых сроков есть события, которые требуют внеочередной правки.

• Появление в компании нового класса инструментов, например перехода от текстовых помощников к автономным агентам с доступом к внутренним системам
• Изменение условий обслуживания у используемого поставщика в части обработки данных
• Выход нормативного акта или разъяснения регулятора, затрагивающего обработку данных в автоматизированных системах
• Инцидент, причиной которого оказалась неоднозначная формулировка в документе
• Накопление трёх-четырёх однотипных запросов на согласование, что говорит о пробеле в реестре
• Существенное изменение структуры компании, появление новых подразделений или передача процессов подрядчикам

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

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

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