AI-агенты внутри компании: где нужны доступы, ограничения и человек на проверке

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

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

Мы разрабатываем AI-чатботов, RAG-системы и LLM-интеграции. В этой статье разберу практическую схему: какие данные ему открывать, когда разрешать запись и где действие должно ждать проверки сотрудника.

До первого действия агенту уже нужен пропуск

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

Каждому агенту нужна отдельная идентичность с понятным владельцем. В журналах должно быть видно, какой агент вызвал инструмент, с каким набором прав, к какому объекту обратился и от чьего имени действовал. Общая учётка «ai-service» для всех сценариев упрощает запуск и усложняет любое расследование.

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

Пароль от всего иногда экономит час настройки. Потом этот час вспоминают на длинном созвоне.

Читать можно раньше, чем нажимать

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

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

2. Чтение разрешённых данных. Система ищет регламент, проверяет статус заказа или собирает карточку клиента. Запись, отправка и изменение недоступны.

3. Черновик действия. Агент готовит письмо, ответ, заявку или изменение записи. Человек видит результат и запускает следующий шаг.

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

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

OpenAI советует оценивать инструменты по типу доступа, обратимости, правам учётной записи и финансовым последствиям. У нас эта оценка превращается в техническое правило: низкий риск проходит автоматически, средний запускает дополнительную проверку, высокий передаёт управление человеку.

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

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

Промпт объясняет, как поступать. Система доступа определяет, что возможно

Широкий доступ не увеличивает число ошибок агента — он увеличивает цену одной. OWASP относит избыточные инструменты, широкие разрешения и лишнюю автономность к риску Excessive Agency. Рекомендация практичная: агент получает только необходимые функции. Для чтения писем ему не требуется отправка и удаление. Для подбора товаров достаточно доступа к каталогу без права менять цены и остатки.

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

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

В Qtim закладываем рамки доступа до подключения агента к корпоративным данным.

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

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

Человек подключается до необратимого шага

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

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

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

Экран согласования должен показывать действие без загадок: какой объект изменится, какие данные использованы, что получится после подтверждения и как выполнить откат. Кнопка «Продолжить?» без контекста добавляет ритуал. Контроля не добавляет.

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

Скучная кнопка подтверждения редко попадает в презентацию. Финансовый директор обычно переживает это спокойно.

У бухгалтера и рекрутера разные пропуска, хотя мессенджер один

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

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

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

За одинаковым интерфейсом чата должны стоять три разных набора прав.

Чем сложнее откат, тем ближе проверка

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

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

Тот самый агент из начала статьи по-прежнему разбирает почту. Разница в том, что теперь видно, что именно он может сделать с ответом.

Если вы готовите внутреннего агента, RAG-систему или LLM-интеграцию, можно обсудить AI-проект с командой Qtim. Разложим сценарий на данные, инструменты, уровни прав и точки передачи человеку до выхода в продакшен.