Как разделить права на чтение и изменение данных при подключении ИИ к бизнес-системе

Как разделить права на чтение и изменение данных при подключении ИИ к бизнес-системе — Изображение AI

Что произойдет, если ИИ не только найдет нужные данные, но и начнет действовать от имени сотрудника? IT-World выяснял, где в этой схеме последнее слово должно оставаться за человеком.

В бизнес-процессах всё большую роль играют ИИ-ассистенты (их обычно называют агентами). Многие ассистенты работают как автономные сотрудники-джуны: получают задания от сотрудников, выполняют задачу и возвращают результат.

Но чем больше возможностей получает ИИ, тем важнее становится вопрос: где заканчивается удобная автоматизация и начинается чрезмерно широкий доступ? Разберемся в этом вместе с Шади Эльяфи, старшим бэкенд-инженером в Fullinfo. Он разрабатывает B2B-платформы с базой более 1 млн профилей компаний, а среди его проектов — собственный MCP-сервер, который позволяет обращаться к данным платформы через Claude.

Представьте, что ваша компания подключила ИИ-ассистента к своей CRM. Сотрудник просит: «Покажи клиентов, которые не оплатили счета за последний месяц». ИИ обращается к системе, находит нужные записи и возвращает список. Но представим другой запрос: «Отправь этим клиентам напоминания и отметь счета как просроченные». На первый взгляд задача похожая. Но для корпоративной ИТ-системы разница принципиальная. В первом случае ИИ только читает данные, а во втором — уже меняет их и запускает действия от имени сотрудника.

Такие сценарии постепенно становятся частью обычного корпоративного софта. 5 августа разработчик решений для управления операционными рисками Benchmark Gensuite представил MCP-коннектор, с помощью которого AI-агенты могут взаимодействовать с внутренней системой компании. Агенту можно поручить найти информацию об инциденте или проверке, обновить запись или запустить рабочий процесс.

MCP, или Model Context Protocol, — открытый стандарт, который позволяет ИИ взаимодействовать с внешними системами и инструментами. MCP дает AI-ассистенту возможность не только разговаривать с пользователем, но и обращаться к корпоративным сервисам за данными или выполнять в них разрешенные операции.

Почему ИИ недостаточно просто «дать доступ»

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

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

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

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

Почему нельзя просто попросить ИИ ничего лишнего не менять

Самый простой вариант: просто попросить агента «не делать плохого» в инструкции. Например, позволить искать информацию о клиентах, но запретить редактировать их карточки.

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

Я в своей практике использовал такой подход при разработке MCP-сервера для Fullinfo. Сервер предоставляет AI-ассистенту девять отдельных инструментов для работы с B2B-платформой, причем операции на чтение и изменение данных разделены. Возможность выполнять мутации (то есть изменять данные) по умолчанию отключена и требует отдельного включения человеком.

По умолчанию ИИ получает только те возможности, без которых он не сможет выполнить свою задачу…

Какие действия можно доверить ИИ

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

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

ИИ не должен становиться «суперпользователем»

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

Так работает и новый коннектор Benchmark Gensuite: компания отдельно подчеркивает, что AI-агенты выполняют операции от имени авторизованных пользователей с учетом существующих разрешений и правил управления доступом.

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

Если ИИ что-то изменил, это должно остаться в истории

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

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

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

Несколько вопросов перед тем, как дать ИИ доступ к бизнес-системе

Перед подключением AI-агента полезно определить границы, внутри которых он будет работать.

Какие данные ему действительно нужны? Агенту не обязательно открывать доступ ко всей системе. Если для задачи достаточно нескольких типов данных, доступ лучше ограничить ими — и учитывать права сотрудника, от имени которого действует ИИ.

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

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

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

Можно ли быстро отозвать доступ? У компании должна оставаться возможность отключить отдельные инструменты или полностью остановить работу агента.

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