Процесс согласования ИИ-инструментов: приложения, подключения и действия агентов
Выстройте процесс согласования ИИ-инструментов: быстрый для инструментов с низким риском и тщательный в отношении корпоративных систем, к которым может обращаться агент, и действий, которые он может выполнять.
Коротко о решении
Процесс согласования ИИ-инструментов определяет, какими ИИ-инструментами могут пользоваться сотрудники, с какими данными и на каких условиях. Для инструментов, которые подключаются к корпоративным системам, он также определяет, к каким системам они могут обращаться и какие действия требуют проверки человеком. Сделайте подачу запросов простой, соразмеряйте проверку с риском, одобряйте конкретные рамки использования с владельцем и датой пересмотра, закрепляйте решение в конфигурации, а не в таблице, и проводите повторную проверку, когда инструмент меняется.
Что определяет процесс согласования ИИ-инструментов
Процесс согласования ИИ-инструментов — это то, как организация решает, какими ИИ-инструментами сотрудники могут пользоваться в работе, с какими данными и на каких условиях. Большинство процессов начинается с самого приложения: чат-ассистента, сервиса для заметок на встречах или ассистента для программирования.
Агенты добавляют еще два решения. Многие ИИ-инструменты теперь подключаются к корпоративным системам через встроенные коннекторы или протокол MCP (Model Context Protocol), а некоторые могут действовать в этих системах: отправить сообщение, обновить запись или выполнить слияние изменений. Одобрение приложения не решает, к каким системам оно может обращаться и какие действия требуют проверки человеком.
Поэтому полезный процесс согласует три вещи, каждую — с нужной степенью детализации.
| Решение | Вопрос | Кто обычно проверяет |
|---|---|---|
| Инструмент | Можно ли использовать этот продукт с данными компании? | ИТ-отдел, служба безопасности, специалисты по конфиденциальности и отдел закупок |
| Его подключения | К каким корпоративным системам и данным он может обращаться и с чьими учетными данными? | Владельцы систем и служба безопасности |
| Его действия | Какие изменения он может вносить и какие из них сначала требуют проверки человеком? | Бизнес-владелец и служба безопасности |
Упростите подачу запросов
Люди пользуются теми инструментами, которые легко получить. Если официальный путь медленный или непонятный, они находят собственные — так и появляется теневой ИИ. Короткая форма запроса, опубликованный список одобренных инструментов и понятный ожидаемый срок рассмотрения дают больше, чем строгая политика, которую никто не читает.
Сразу запрашивайте сведения, которые нужны проверяющим, чтобы запросы не ходили туда и обратно:
- Бизнес-цель и команда, которая будет пользоваться инструментом.
- Задействованные данные — по вашим существующим уровням классификации.
- Корпоративные системы, к которым он должен подключаться, и нужно ли ему что-либо в них менять.
- Кто будет владельцем инструмента после одобрения.
- Поставщик, тариф и ссылки на его условия безопасности и использования данных.
Соразмерьте проверку с риском
Не каждому запросу нужна одинаковая проверка. Уровни позволяют быстро пропускать инструменты с низким риском и оставлять более глубокую проверку для инструментов, которые работают с конфиденциальными данными или выполняют действия.
Определяйте уровень для сценария использования, а не для продукта. Один и тот же ассистент несет низкий риск как помощник в написании текстов и высокий — как только может отправлять письма от чьего-то имени. Приведенные ниже уровни — условный пример; адаптируйте их к своей классификации данных и своим обязательствам.
| Уровень | Пример | Рассмотреть |
|---|---|---|
| Низкий | Помощь с черновиками для неконфиденциального содержимого, без подключений | ИТ-отдел проверяет условия поставщика и способ входа, затем одобряет по стандартному списку |
| Средний | Читает внутренние документы или заявки через коннектор | Служба безопасности и владелец данных проверяют доступ, области действия (scopes) и обработку данных |
| Высокий | Читает данные клиентов или финансовые данные либо может изменять записи и связываться с людьми | Полная проверка безопасности и конфиденциальности, назначенный владелец, ограничения на действия и пилотный запуск |
Проверяйте то, что важно для ИИ-инструментов
Стандартная проверка поставщика по-прежнему нужна: практики безопасности, вход через вашего поставщика удостоверений, журналы аудита и условия договора. ИИ-инструменты добавляют вопросы о данных. Проверьте, использует ли поставщик ваши данные для обучения моделей, как долго хранятся промпты и ответы и различаются ли эти условия в бесплатных и бизнес-тарифах.
Для инструментов, которые подключаются к корпоративным системам, рассматривайте каждое подключение как отдельное решение: какая система, чьи учетные данные, какие области действия и какие данные. Подключение, авторизованное с широкой областью действия, может обращаться ко всему, что эта область разрешает, независимо от того, для чего был одобрен инструмент.
Для инструментов, которые выполняют действия, решите, какие действия они могут выполнять самостоятельно. OWASP называет наделение ИИ-системы большим количеством функций, разрешений или автономности, чем ей нужно, избыточной автономностью (Excessive Agency) и среди мер защиты указывает обязательное одобрение человеком действий с серьезными последствиями.
Если для этой работы нужна более широкая структура, концепция управления рисками ИИ от NIST (AI Risk Management Framework), которая сейчас пересматривается, выстраивает ее вокруг организации управления (govern), картирования (map), измерения (measure) и обработки (manage) рисков.
Одобряйте конкретные рамки использования с датой окончания
Одобрение наиболее полезно, когда в нем точно сказано, что именно одобрено: этот инструмент, для этой команды и этого сценария использования, с этим классом данных, с подключением к этим системам и с разрешением этих действий. Все, что выходит за эти рамки, — новый запрос.
Добавляйте условия там, где они снижают риск: например, только бизнес-тарифы, обязательный единый вход (SSO), без данных клиентов или проверка определенных действий во время пилота. Назначайте каждому одобрению владельца и дату пересмотра, чтобы инструменты, которые больше не нужны или изменились, снова выносились на решение.
Закрепите решение в конфигурации
Решение, которое существует только в таблице, никого не остановит. Применяйте его технически там, где это возможно: включите инструмент через единый вход для одобренной группы, настройте только одобренные подключения и области действия и опубликуйте список одобренных инструментов там, где его будут искать.
Для агентов, которые подключаются к корпоративным системам по MCP, шлюз может превратить решение в правила, применяемые к каждому запросу: кто может использовать подключение, какие инструменты и данные доступны и какие изменения требуют проверки. Запросам в обход шлюза по-прежнему нужны другие средства контроля, например управление конечными устройствами и аккуратное обращение с учетными данными.
Разберитесь с инструментами, которые уже используются
Процесс часто начинается, когда инструменты уже используются. Период амнистии, в течение которого сотрудники могут зарегистрировать инструменты без последствий для себя, дает достоверный перечень. Помогает и обнаружение: журналы входа, отчеты о расходах, перечни расширений браузера, а для агентов — конфигурации MCP на управляемых устройствах.
Затем разберите найденное: одобрите с условиями, предложите одобренную альтернативу или попросите сотрудников прекратить использование. Если объяснять, почему инструмент отклонен и чем его заменить, процесс сохраняет доверие.
Одобрить инструмент — не значит одобрить каждое его действие
Одобрение инструмента для использования и проверка того, что он делает, — это разные средства контроля. Первое происходит один раз, до внедрения. Второе — когда агент предлагает конкретное действие, например оформить возврат средств или отправить список клиентов по электронной почте.
Спецификация MCP рекомендует, чтобы человек всегда мог отклонить вызов инструмента, а клиенты запрашивали подтверждение перед выполнением операций. Для значимых действий можно пойти дальше и поручить второму человеку проверить точный запрос до его выполнения. Выбирайте действия, которым нужна такая проверка, исходя из того, какой вред может причинить ошибка.
Пересматривайте одобрения со временем
ИИ-инструменты быстро меняются. Поставщики добавляют функции, меняют условия обработки данных и выпускают новые коннекторы, поэтому одобрение, выданное шесть месяцев назад, может описывать уже другой продукт. Пересматривайте одобрения по графику и при существенных изменениях: новом использовании данных, новых подключениях, новых действиях или смене тарифа.
Сохраняйте записи: кто запросил инструмент, кто его одобрил, на каких условиях и когда его последний раз пересматривали. Они упрощают аудит и показывают, какие решения пересмотреть в первую очередь.
Где подходит Durin
Durin берет на себя решения о подключениях и действиях для агентов, использующих MCP. Участники запрашивают подключение в разделе «Подключения», выбирая провайдера из каталога или предлагая собственный сервер с указанием его назначения, а администратор одобряет или отклоняет запрос в разделе «Согласования». Само по себе одобрение ничего не активирует: после него все равно следуют настройка провайдера, проверка инструментов и тест в режиме только для чтения.
Когда подключение активно, Durin проверяет каждый запрос на соответствие текущим правам доступа и правилам команды. По умолчанию проверенные запросы могут выполняться после этих проверок. Администраторы могут требовать, чтобы предлагаемые изменения проверял другой администратор; затем инициатор запроса отправляет тот же запрос повторно до истечения срока действия разрешения. Функция обнаружения теневых MCP (Shadow MCP) сообщает о серверах MCP, настроенных на зарегистрированных устройствах, и помогает найти инструменты, которые обошли процесс.
Durin не оценивает поставщиков ИИ, приложения и их условия обработки данных и управляет только запросами, которые проходят через его шлюз. Эти решения по-прежнему остаются за вашим общим процессом согласования.