Чек-лист доступа и approval gates для ИИ-агента

ИИ-агенту нельзя сразу давать полный доступ к бизнес-системам. Безопасная модель начинается с read-only источников, затем добавляет scoped write для черновиков и тестового контура, а рискованные действия оставляет только после approval человека. Часть действий должна быть полностью заблокирована.

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

• база знаний и wiki;
• регламенты и инструкции;
• карточки задач или обращений;
• read-only CRM context;
• результаты проверок и статусы без права изменения;
• лог действий самого агента.

Scoped write допустим только там, где действие ограничено областью пилота и легко откатывается.

• создать черновик задачи;
• добавить внутренний комментарий с пометкой, что он подготовлен агентом;
• заполнить черновик формы;
• сохранить draft ответа без отправки;
• изменить объект только в тестовом контуре или sandbox;
• обновить временный рабочий артефакт, не влияющий на клиента.

Approval gate нужен для действий, которые меняют состояние процесса, видны клиенту или влияют на деньги, права, договоры и production.

• отправить письмо, сообщение или уведомление;
• изменить статус в CRM, helpdesk, ERP или документообороте;
• создать заказ, счёт, договорный документ или заявку на оплату;
• запустить интеграционный процесс;
• изменить данные клиента или сотрудника;
• создать pull request, merge, deploy или release в developer workflow.

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

• доступ к vault, токенам, паролям и приватным ключам;
• массовое изменение данных;
• изменение прав доступа;
• production deploy без отдельного процесса;
• финансовые операции без человека;
• удаление данных;
• использование персональных данных без утверждённой политики;
• обход approval через просьбу пользователя.

• кто запустил агента;
• какие источники были доступны;
• что агент прочитал или нашёл;
• какое действие предложил;
• кто подтвердил approval;
• что было выполнено;
• как откатить результат;
• какая ошибка или ограничение возникли.

Персональные данные подключаются только при понятном основании, минимальном наборе полей, ограниченных ролях и сроках хранения. Секреты не должны попадать в prompt, RAG-контекст, логи или память агента. Если агенту нужно выполнить действие в системе, используйте scoped service account и отдельные approval gates.

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

Перед выдачей прав проверьте карту сценариев для ИИ-агента. Если задача пока про знания и документы, используйте RAG-чек-лист. Для developer workflow применяйте отдельную рамку MCP-интеграций для coding agents. Общая рамка отличий агента от чат-бота и RAG описана в материале про ИИ-агента для бизнеса.