Допустим, в политике или регламенте использования ИИ записано, какие сервисы разрешены и какие данные нельзя вносить. Сотрудник приходит с вопросом поуже: «Можно мне готовить черновики коммерческих предложений через ИИ?» Общие правила могут не дать на него прямого ответа. Ниже карточка, по которой руководитель согласует или отклоняет один такой сценарий: заполненный пример, два примера изменений с решениями и пустой шаблон.
Согласуйте отдельно каждый рабочий сценарий: одну задачу, которую делает определённая группа сотрудников. В карточке запишите задачу, разрешённые входы, сервис с учётной записью и подключениями, человека, который сверяет результат, и того, кто отправляет результат дальше. Эти решения принимают разные люди: владелец процесса утверждает рамку, администратор настраивает права, проверяющий сверяет факты с источником, руководитель закрепляет право отправки. Добавьте дату пересмотра и сигналы, которые возвращают карточку на согласование. В предложенном здесь методе новая версия того же согласованного публичного источника и правки запроса или формата остаются в рамках карточки, пока не меняются тип данных, права, отправка и проверка. Новый тип данных, другой аккаунт или автоматическая отправка требуют нового согласования.
Четыре решения внутри одного «да»
Общий документ задаёт рамку для всей компании, а конкретный вопрос в нём может остаться открытым. Допустим, в политике написано «пользуйтесь только разрешёнными сервисами и не вносите конфиденциальные данные», а менеджер так и не знает, можно ли загрузить файл каталога и отправить клиенту то, что получилось. Если данные размечены по цветам, разметка подсказывает, куда смотреть, но не решает, годится ли этот файл для этой задачи.
Когда руководитель говорит сотруднику «да», он на деле принимает четыре решения. Их стоит развести по людям.
- Рамка сценария. Владелец процесса вместе с владельцем данных решает, какую задачу и на каких материалах можно делать с ИИ.
- Технические права. Администратор настраивает учётную запись и подключения так, чтобы сервис видел только согласованное. Инструкция сотруднику доступ не перекрывает: если к учётной записи подключена почта, запрет в тексте политики её не отключит.
- Проверка результата. Человек сам сверяет факты с источником, а не спрашивает модель, всё ли верно. Чем дороже ошибка, тем больше смысла назначить проверяющим не того, кто готовил черновик.
- Право отправки. Отдельно записывают, кто передаёт результат клиенту или в рабочую систему. Разрешение готовить черновик не даёт права его отправлять.
Пока хотя бы одно из четырёх решений никто не принял, сценарий не согласован. Проверку агента, который сам меняет данные в системах, я разбирал в статье о тестировании ИИ-агентов. Здесь вопрос возникает раньше: можно ли вообще давать сотруднику эту задачу и в каких границах.
Пример: карточка для черновика коммерческого предложения
Пример условный и показывает только порядок заполнения. Менеджер отдела продаж регулярно сравнивает несколько позиций каталога и пишет описание к коммерческому предложению. Каталог опубликован на сайте компании. Цены, скидки и переписка с клиентом в сценарий не входят.
| Поле | Запись в карточке | Кто подтверждает |
|---|---|---|
| Задача | Черновик сравнения двух–четырёх позиций каталога по характеристикам и нейтральное описание к коммерческому предложению | Руководитель отдела продаж |
| Исполнители | Менеджеры отдела продаж | Руководитель отдела продаж |
| Разрешённые входы | Файл текущей версии публичного каталога; список позиций и параметров для сравнения, который менеджер пишет сам | Владелец каталога в маркетинге |
| Не вносить | Письма и сообщения клиентов, выгрузки из CRM, прайс со скидками, условия сделки, любые сведения о клиенте | Владелец каталога, руководитель отдела продаж |
| Сервис и доступы | ИИ-сервис, который компания утвердила для рабочих задач, только под рабочей учётной записью. Подключений к CRM, почте и мессенджерам нет | Администратор, проверил настройку учётных записей |
| Проверка результата | Менеджер сверяет каждую характеристику с каталогом. Первые черновики дополнительно смотрит руководитель отдела | Руководитель отдела продаж |
| Отправка | Цены и условия менеджер добавляет сам. Письмо уходит клиенту только из рабочей почты менеджера после сверки. ИИ ничего не отправляет и не пишет в CRM | Руководитель отдела продаж |
| Решение | Согласовано. Дата решения, пересмотр через три месяца | Руководитель отдела продаж |
| Сигналы пересмотра | Новый тип входных данных, другой сервис или учётная запись, новый канал отправки, ошибка в факте, которая дошла до клиента | Все, кто подписал |
Строка «Отправка» стоит отдельно, потому что за черновик и за письмо клиенту отвечают по-разному. Предложение подключить почту, чтобы ИИ «сразу отправлял», будет уже другим сценарием с другими подписями.
Работа людей после подписи никуда не девается. Менеджер сверяет каждый черновик, владелец каталога следит за актуальной версией, администратор не даёт правам разрастаться. Карточка эту работу не снимает, зато у каждой её части появляется конкретный человек.
Сценарий изменился: когда согласовывать заново
Карточка нужна прежде всего тогда, когда сценарий меняется. Два условных изменения в том же отделе.
Менеджер хочет вставлять письмо клиента
Через месяц менеджер предлагает вставлять запрос клиента целиком, чтобы ИИ сразу писал персональное предложение. Выглядит как мелкое удобство, но меняется строка «Разрешённые входы». В письме есть имя, должность и контакты, нередко объёмы закупки и условия конкурентов. Удалить имя недостаточно: клиента узнают по названию компании, деталям сделки и подписи.
Решение: новая карточка. В текущих границах письмо в сервис не попадает, персональную часть менеджер дописывает сам. Если персонализация через ИИ действительно нужна, сценарий согласуют заново. Владелец клиентских данных и руководитель отдела решают про входы, администратор проверяет, подходят ли для таких данных сервис и учётная запись, юристы компании смотрят вопросы персональных данных и коммерческой тайны. До нового решения работа идёт по старой карточке.
Каталог обновили, запрос переписали
Маркетинг выпустил новую версию каталога с новой линейкой. Заодно менеджер переписал запрос: сравнение теперь выходит таблицей, описание стало короче. Источник того же типа и от того же владельца. Сервис, учётная запись, проверяющий и право отправки прежние.
Решение: в рамках карточки, пока тип данных, права, отправка и проверка прежние. Менеджер заменяет файл, в карточке отмечают версию каталога, новых подписей не нужно. Проверка остаётся: новые позиции сверяют так же построчно. Если пересогласовывать карточку из-за каждой правки формулировки, заполнять её скоро перестанут.
| Изменение | Решение | Почему |
|---|---|---|
| Новая версия того же каталога | В рамках карточки | Источник и владелец прежние, меняется только версия |
| Правка запроса, формата, тона | В рамках карточки | Входы, права, отправка и проверка не изменились |
| Письмо клиента, выгрузка из CRM, прайс со скидками | Новая карточка | Появились данные с другим владельцем |
| Другой ИИ-сервис или личный аккаунт | Новое решение до первого использования | Меняется техническая граница, её проверяет администратор |
| ИИ сам отправляет письмо или пишет в CRM | Новое решение | Меняется право отправки, нужны отдельные технические права |
Пустая карточка для своего сценария
Скопируйте поля в документ или таблицу и заполните на одну задачу. Одна карточка описывает один сценарий. Если в строке «Разрешённые входы» получается «всё, что нужно для работы», сценарий слишком широкий и его стоит разделить.
| Поле | Вопрос для заполнения | Кто обычно подтверждает |
|---|---|---|
| Задача | Какой результат нужен и на каком шаге процесса? | Владелец процесса |
| Исполнители | Кто запускает сценарий? | Владелец процесса |
| Разрешённые входы | Какие материалы и какой версии можно вносить? | Владелец данных |
| Не вносить | Что исключено, даже если очень нужно? | Владелец данных |
| Сервис и доступы | Какой сервис, какая учётная запись, какие подключения? Кто проверил настройку? | Администратор |
| Проверка результата | Кто сверяет результат и с каким источником? | Владелец результата |
| Отправка | Кто передаёт результат дальше и через какой канал? | Руководитель направления |
| Решение | Согласовано, отказ или на доработку; дата; срок пересмотра | Владелец процесса |
| Сигналы пересмотра | Какие изменения возвращают карточку на согласование? | Все, кто подписал |
Отказ тоже нормальный итог. Сценарий отклоняют или возвращают на доработку, если входы не отделяются от клиентских и кадровых сведений, если результат некому сверить с источником или если нужный сервис компания не утверждала. Причину отказа записывают в ту же карточку, чтобы при следующем запросе было видно, что изменилось.
На что опирается метод и чего он не даёт
Карточку, её поля и правила пересмотра я предлагаю как практический метод. Это не результат замеров и не описание внедрения в конкретной компании.
Похожие мысли есть в добровольной рамке управления рисками ИИ NIST AI RMF 1.0 2023 года. В её разделе об управлении говорится, что роли и ответственность людей должны быть определены и понятны, правила и меры контроля прозрачны, а мониторинг и периодический пересмотр запланированы. Её действия не задуманы как чек-лист с обязательным порядком. В ответах NIST о сопровождающем рамку Playbook сказано, что его материалы можно брать выборочно и перерабатывать во внутренние документы. Поля и пример карточки NIST не предписывает. Следование рамке само по себе не означает выполнения российских требований.
Карточка не заменяет политику компании, договоры, приказы и работу юристов. Соответствие закону она не подтверждает, а доступы технически не перекрывает: это делает настройка учётных записей. Сверку результата человеком она тоже не заменяет, а только называет, кто её делает. Она отвечает на более узкий вопрос: кто разрешил этот сценарий, на каких данных, кто проверил результат и кто его отправил.
Если сценариев пока нет, их удобно собирать на обучении, куда каждый сотрудник приходит со своей повторяющейся задачей. Как выбрать такую программу и что принять на финале, я разбирал в материале о корпоративном обучении ИИ.
Источники и методика
- NIST — AI RMF Core, ядро AI Risk Management Framework 1.0 (2023). Добровольная рамка управления рисками, не сертификация и не требование российского права.
- NIST — NIST AI RMF Playbook FAQs. Как устроен и как применяется Playbook.
- Карточка согласования, правила пересмотра и критерии отказа — метод автора, а не результат замеров. Пример с коммерческим предложением условный и в компании не проверялся.