Как согласовать политику использования ИИ в компании: решения, роли и ограничения

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

1. Подготовьте список решений и границы политики

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

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

Охват документа согласуйте явно.

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

Материал адресован HR и L&D, руководителям подразделений, владельцам процессов, ИТ и информационной безопасности. Он поможет участнику, который собирает решения этих функций в один проект. Юридическую форму документа и порядок его введения организация определяет со своими специалистами.

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

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

Мнение. Если единые границы использования ИИ ещё не согласованы, начинайте с рабочих сценариев. Готовый текст политики не устранит разногласия о том, какие данные и действия допустимы.

2. Назначьте владельца политики и участников согласования

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

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

Владелец процесса описывает задачу и последствия ошибки. ИТ рассматривает доступ и интеграции, ИБ — ограничения и защитные меры, юридическая функция — применимые требования и обязательства. HR и L&D готовят ознакомление и обучение.

Участие в обсуждении ещё не означает полномочие разрешить использование.

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

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

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

3. Какие данные можно передавать ИИ?

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

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

Карточку решения по данным удобно составить из следующих полей:

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

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

Удаление имени не считайте достаточным основанием для передачи.

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

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

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

4. Согласуйте инструменты, аккаунты и интеграции

Установите порядок ведения реестра разрешённых ИИ-инструментов. Каждая запись связывает инструмент с конкретным продуктом, способом доступа, задачами и данными. В политике прямо ограничьте область разрешения: согласование корпоративной рабочей среды не охватывает личный аккаунт, API или внешнюю интеграцию без отдельного решения. Для каждого способа использования сохраните условия и основание допуска.

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

Для карточки допуска соберите:

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

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

Название сервиса само по себе не подтверждает условия.

Правила подключения расширений, ботов, коннекторов и ИИ-агентов вынесите в отдельное положение. Для каждого подключения определите, какие системы оно читает, что может менять и кто контролирует эти права. Ограничьте допуск к подготовке текста этой задачей; доступ к почте или базе клиентов рассмотрите отдельно.

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

Разделите дату проверки документов поставщика и дату внутреннего разрешения. Первая показывает, когда ответственный сверял основания. Вторая фиксирует решение компании. Изменение условий поставщика должно запускать пересмотр допуска по установленному маршруту.

5. Где заканчиваются самостоятельные действия ИИ?

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

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

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

Техническая возможность не заменяет внутреннее разрешение.

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

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

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

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

6. Закрепите ответственность за проверку результата

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

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

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

Подтверждение должно соответствовать проверке.

В одном процессе можно предусмотреть отметку в задаче, в другом — согласованную версию документа или запись в принятой системе учёта. Определите, что именно подтверждает запись: факт просмотра, завершение проверки или разрешение использовать результат. Не объединяйте эти значения без объяснения.

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

При оценке обучения учитывайте весь путь до принятого результата: подготовку, проверку и исправления. В политике достаточно закрепить этот принцип и владельца критериев. Методика оценки обучения — отдельная задача; она не должна разрастаться внутри документа о допустимом использовании ИИ.

Матрица ролей и порядок проверки в этой статье предложены редакцией. Они не приведены как требования NIST или положения закона. Документы в разделе «Источники» предназначены для отдельного изучения; конкретные требования к компании из них здесь не выводятся.

7. Опишите исключения, ошибки и остановку работы

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

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

В запрос исключения включите:

• Задачу, обоснование и причину, по которой обычный маршрут не подходит.
• Категории данных, среду и запрашиваемые действия.
• Ограничения, согласующих, срок и основания прекращения разрешения.

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

Для сообщения об ошибке предусмотрите другую короткую памятку:

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

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

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

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

Исключение должно иметь завершение.

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

8. Проверьте решения на условном рабочем примере

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

Это учебная ситуация, а не кейс AURMIND.

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

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

Факт. В условном примере разрешение охватывает публичные и подготовленные учебные материалы, а клиентскую переписку не охватывает. Основание — вводные первого абзаца этого раздела и соответствующая строка таблицы. Это условие упражнения, а не утверждение об условиях какого-либо сервиса.

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

Итоговую запись сформулируйте предметно: разрешены учебные черновики из подготовленных материалов; проверку выполняет назначенная роль; отправка клиенту не разрешена. Реальные клиентские обращения остаются на ручном маршруте до отдельного решения.

Учебный результат не расширяет допуск.

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

9. Соберите согласованную редакцию и порядок пересмотра

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

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

Маршрут подготовки можно построить так:

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

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

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

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

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

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

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

10. Доведите правила до сотрудников и проверьте понимание

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

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

Для задания используйте подготовленные учебные материалы.

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

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

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

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

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

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

11. Проверьте, что список решений готов к утверждению

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

Перед передачей проекта проверьте:

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

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

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

Готовность проекта не означает разрешение начать работу.

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

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

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

Рабочая схема

Эта схема показывает порядок действий в описанном примере. Проверки каждого этапа разобраны в статье.

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

Источники

• Artificial Intelligence Risk Management Framework (AI RMF 1.0) — NIST.
• Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — NIST.

Читайте также

Безопасность данных Как проверить ответ нейросети: проверка фактов, ссылок и чисел

Безопасность данных Конфиденциальность ChatGPT: что проверить перед загрузкой рабочих данных

Безопасность данных Как обезличить данные для нейросети и сохранить смысл задачи