Права доступа для ИИ-агентов: принцип минимальных полномочий

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

Почему отдельная учётная запись — обязательное условие

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

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

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

Read-only старт: сначала читать, потом действовать

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

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

Права на запись добавляют поэтапно:

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

Каждое расширение прав проходит через проверку сценариев и фиксируется в журнале работ.

Разделение доступов между отделами

Когда агентов несколько — по одному на отдел — данные должны быть изолированы. Агент отдела продаж не видит документы бухгалтерии. Агент бухгалтерии не имеет доступа к CRM отдела продаж. Это принцип наименьших привилегий, применённый к организационной структуре.

Изоляция строится на трёх уровнях:

• Память. У каждого агента свой пул памяти и своя база знаний. Общий слой компании — регламенты, структура, контакты — доступен всем, но документы отдела видны только его агенту.
• Системы. Учётная запись агента имеет доступ только к тем данным в 1С, CRM и почте, которые относятся к его отделу.
• Интерфейс. Каждый агент работает в своей Telegram-группе. В чужую группу агент не заходит и на вопросы из другого отдела сообщает, что не имеет доступа.

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

Подтверждение человека: где агент останавливается

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

Что требует подтверждения:

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

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

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

Регулярный пересмотр прав: когда и зачем

Права доступа — не настройка, которую делают один раз. Они устаревают. Отдел подключает новую систему. Меняется регламент. Появляется новый сценарий автоматизации. Всё это требует пересмотра.

Пересмотр стоит проводить:

• при каждом изменении сценариев агента;
• при подключении нового отдела;
• при смене модели или провайдера;
• не реже раза в квартал, даже если ничего не менялось.

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

Пересмотр прав входит в сопровождение и обучение: каждое изменение фиксируется в журнале работ.

Пример: агент отдела закупок с минимальными правами

Рассмотрим гипотетический сценарий. Производственная компания подключает ИИ-агента к отделу закупок. Задача: отвечать на вопросы по регламентам, готовить черновики запросов поставщикам и собирать сводки по остаткам из 1С.

Как выглядят минимальные права:

• Чтение. Доступ к документам отдела закупок и к справочнику остатков в 1С через OData. Агент видит только нужные объекты, не всю базу.
• Черновики. Агент готовит проект письма поставщику, но не отправляет. Черновик появляется в Telegram-группе отдела, сотрудник проверяет и нажимает «Отправить».
• Журнал. Каждый запрос к 1С и каждый ответ в группу записываются с идентификатором агента.
• Запрет. Агент не имеет доступа к данным бухгалтерии, к CRM продаж и к платёжным системам.

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

Этапы настройки прав доступа для ИИ-агентов

Настройка прав — часть внедрения ИИ-агента, а не отдельный проект. Она встроена в этапы работ и фиксируется в журнале.

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

Три решения принимаются с вашей ИТ-службой до того, как агент увидит первый документ:

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

Риски игнорирования принципа минимальных полномочий

Если агент получает широкие права «на вырост», последствия предсказуемы.

Непрозрачность. Без отдельной учётной записи и чёткого перечня операций невозможно понять, что именно агент сделал и почему. Журнал действий теряет смысл.

Неконтролируемый ущерб. Агент с правами на запись, который ошибочно интерпретировал документ, может изменить данные в CRM или отправить неверный ответ клиенту. Исправление занимает больше времени, чем предотвращение.

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

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

Как проверить, что права настроены правильно

После настройки стоит пройти по чек-листу:

• У каждого агента есть отдельная учётная запись с идентификатором.
• Права на запись выданы только там, где настроено подтверждение человека.
• Данные отделов изолированы: агент не видит чужие документы.
• Журнал действий записывает каждый запрос и ответ.
• Лишние права отозваны после проверки сценариев.
• Есть план регулярного пересмотра — не реже раза в квартал.

Если хотя бы один пункт не выполняется, права нуждаются в пересмотре.

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

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

Описать задачу