#AI-агенты: операционный overlay

Версия: 1.0 · Обновлено: 2026-05-28 · Теги: AI-агенты, классификация, реестр, делегированные полномочия, согласование · Tier: 1-4

TL;DR. Операционное дополнение для агентных сценариев: где граница «агент / не агент», какие классы агентов существуют, какие поля добавить в карточку реестра, как фиксировать делегированные полномочия и какие изменения считаются существенными.

#1. Граница агентного сценария

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

Фактор	Что означает	Минимальное подтверждение
Многошаговое выполнение	Модель сама выбирает следующий шаг по результатам предыдущего	Описание границы рассуждения, лимит итераций, журнал переходов
Использование инструментов	Tool-calling, function-calling, MCP, RAG-агенты	Реестр разрешённых инструментов, область действия каждого
Постоянная память	Хранение состояния между сессиями	Назначение, срок хранения, политика удаления, аудит
Действия с записью	Запись, отправка, изменение состояния внешних систем	Модель согласования, делегированные полномочия
Запуск по событию / расписанию	Cron, webhook, message-bus	Резервный сценарий, путь аварийного отключения
Передача управления	Между моделями или между моделью и человеком	Семантика handoff, границы доверия

#Дерево решений

flowchart TD
    A[AI-сценарий<br/>заявка на регистрацию] --> Q1{Есть<br/>tool-calling?}
    Q1 -- нет --> Q2{Есть постоянная<br/>память?}
    Q1 -- да --> AGENT
    Q2 -- нет --> Q3{Запуск<br/>по событию?}
    Q2 -- да --> AGENT
    Q3 -- нет --> Q4{Многошаговое<br/>выполнение?}
    Q3 -- да --> AGENT
    Q4 -- нет --> PLAIN[Обычный AI-сценарий<br/>базовый процесс]:::plain
    Q4 -- да --> AGENT[Агентный сценарий<br/>+ operating overlay<br/>+ security overlay]:::agent

    classDef plain fill:#10b981,stroke:#059669,color:#fff
    classDef agent fill:#f59e0b,stroke:#d97706,color:#1b1d22

[!warn] Если сценарий близок к границе (например, RAG с read-only), всё равно проходите через классификацию. Лучше избыточный контроль на этапе подачи, чем переоценка после инцидента.

#2. Классы агентов и матрица мер контроля

Класс	Описание	Базовые меры
A — read-only	Только утверждённые инструменты, доступ только для чтения, без изменения состояния	Реестр инструментов, владелец, журнал аудита
B — write через согласование	Запись / отправка / изменение, каждое чувствительное действие требует подтверждения человеком	+ Модель согласования, делегированные полномочия, измеримое подтверждение по каждому действию
C — автономный по расписанию	Запуск по cron / событию без немедленной проверки человеком	+ Сигналы мониторинга, резервный сценарий, путь аварийного отключения
D — привилегированный	Многоагентный, browser/computer-use, привилегированные коннекторы	+ Усиленная проверка, изоляция, ограничение времени работы, обязательный пилот

[!danger] Класс D по умолчанию запрещён без явного обоснования и утверждённого исключения. Сюда относятся multi-agent workflows и computer-use.

#3. Дополнение к карточке реестра

К существующей карточке реестра AI-системы для агентного сценария добавляются поля:

Поле	Что писать
agent_class	A / B / C / D из §2
tools	Список разрешённых инструментов с областью действия каждого
connectors	Список коннекторов с сервисной УЗ и областью доступа
memory_scope	Назначение памяти, срок хранения, политика удаления
delegated_authority	Ссылка на запись делегированных полномочий
approval_model	Запись / две подписи / без согласования (для класса A)
runtime_identity	Сервисная учётная запись среды исполнения
kill_switch_path	Путь аварийного отключения: команда, владелец, время выполнения
monitoring_signals	Какие метрики и логи отслеживаются
evidence_pack_ref	Ссылка на пакет подтверждений

#4. Модель делегированных полномочий

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

Поле записи	Назначение
agent_id	Идентификатор агента в реестре
workflow_id	Идентификатор рабочего процесса
valid_until	Срок действия
allowed_actions	Разрешённые действия
denied_actions	Явно запрещённые действия
approval_required	Действия только после согласования (с указанием схемы)
granted_by / granted_at	Кто и когда выдал
revocation_path	Как отозвать (без перезапуска)

Шаблон записи — в examples/agents/agent-delegated-authority-template.md.

[!info] Делегированные полномочия — это не RBAC. Они узкоспециализированы под конкретный рабочий процесс агента и имеют срок жизни. RBAC сервисной учётной записи определяет потолок, делегированные полномочия — фактический объём.

#5. Этапы допуска

flowchart LR
    A[Песочница<br/>изолированная среда] --> B[Пилот<br/>ограниченный круг]
    B --> C[Предпром<br/>с реальными коннекторами read-only]
    C --> D[Промышленная<br/>эксплуатация]
    D -.повторная оценка.-> B
    D -.существенное изменение.-> B

    classDef stage fill:#1f2937,stroke:#5a6474,color:#e5e7eb
    class A,B,C,D stage

Каждый этап имеет собственный пакет подтверждений: журнал событий, отчёт по защитным проверкам, реестр инцидентов, статус метрик.

#6. Существенные изменения и триггеры повторной оценки

Триггеры обязательной повторной оценки:

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

[!warn] Существенное изменение не делается через обычный pull request. Требуется новая оценка риска и согласование по базовому процессу.

#7. Краткая операционная памятка

Если сценарий	Минимальный вывод
Только read-only утверждённые инструменты	Класс A, обычный процесс подачи + журнал аудита
Запись / отправка / изменение через коннекторы	Класс B, делегированные полномочия, подтверждение по каждому действию
Запуск по cron / событию без проверки человеком	Класс C, оценка автономности, резервный сценарий, kill-switch
Постоянная память	Не по умолчанию: явное обоснование, граница, аудит, удаление
Привилегированный коннектор / browser-use / multi-agent	Класс D, усиленная проверка, обязательный пилот
Расширение области действия	Существенное изменение → повторная оценка

#8. Связь с другими документами

• Классификация → определяет, что писать в реестр.
• Класс → влияет на меры из Security Overlay.
• Класс + автономность → определяют сигналы Runtime Procedure.
• Класс D → требует расширенного пилота через Production Readiness Checklist.