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

Версия: 1.0 · Обновлено: 2026-05-28 · Теги: AI-агенты, production readiness, чек-лист, evidence pack, согласование · Tier: 1-4

TL;DR. Финальный rubeж перед пилотом, промышленной эксплуатацией или повторным согласованием. Восемь блоков подтверждений, девять блокирующих условий. Без всех зелёных статусов релиз не допускается.

#1. Когда применять

flowchart LR
    A[Готовы к пилоту?] --> CHK1[Базовые подтверждения<br/>+ Operating + Security]
    B[Готовы к проду?] --> CHK2[Все 8 блоков<br/>+ evidence pack]
    C[Существенное изменение?] --> CHK3[Релевантные блоки<br/>+ повторная оценка]
    D[Возврат после инцидента?] --> CHK4[Все 8 блоков<br/>+ lessons learned]

    classDef ask fill:#a78bfa,stroke:#7c3aed,color:#fff
    classDef check fill:#10b981,stroke:#059669,color:#fff
    class A,B,C,D ask
    class CHK1,CHK2,CHK3,CHK4 check

Рубеж	Когда
Pilot gate	Перед запуском пилота с ограниченным кругом пользователей
Production gate	Перед промышленной эксплуатацией
Material change gate	Любое существенное изменение из Operating Overlay §6
Post-incident gate	Возврат в Production после Paused / Kill-switch

#2. Восемь блоков подтверждений

#2.1. Реестр и описание сценария

• Карточка реестра обновлена, заполнены все агентные поля из Operating Overlay §3.
• Класс агента определён и обоснован.
• Указан владелец агента и владельцы коннекторов.
• Указаны контакт-точки IR и MLSec.

#2.2. Инструменты и коннекторы

• Реестр инструментов с фиксированной областью каждого.
• Все коннекторы оформлены карточкой (agent-connector-card-template.md).
• Сервисные УЗ имеют минимальный RBAC-потолок.
• Идемпотентность write-инструментов проверена или есть согласование.
• Quota и rate-limit заданы по каждому инструменту.

#2.3. Делегированные полномочия и согласование

• Запись делегированных полномочий (agent-delegated-authority-template.md) активна, valid_until > now + 14d.
• Модель согласования (Auto / Approve / Dual-approve) определена для каждого действия.
• Записи согласования следуют схеме agent-approval-record.schema.json.
• Подтверждение связывается с конкретным action_id.
• Путь отзыва подтверждений документирован.

#2.4. Память

• Управление памятью оформлено (agent-memory-governance-template.md).
• Назначение, срок хранения, политика удаления зафиксированы.
• Cross-user общая память отсутствует или утверждена как исключение.
• Аудит записей в долгосрочную память включён.

#2.5. Безопасность и защитные проверки

• Базовый стандарт безопасности AI пройден.
• Минимальный набор защитных проверок (agent-security-evals-minimal.md) пройден:
  • prompt injection через недоверенный контент;
  • неправильное использование инструмента;
  • обход согласования;
  • отравление памяти;
  • изоляция коннектора;
  • регрессионная проверка после изменений.

#2.6. Runtime и мониторинг

• Состояния runtime реализованы по Runtime Procedure §1.
• Сигналы мониторинга собираются в SIEM с задержкой ≤ 5 минут.
• Алерты Prometheus / SIEM настроены по prometheus-agent-alerts.yaml и siem-agent-queries.txt.
• Автоматический переход в Restricted работает по триггерам.
• Дашборд агента доступен on-call.

#2.7. Аварийное отключение

• Kill-switch одной командой реализован.
• SLA на kill-switch замерен на 3 прогонах, в пределах согласованного.
• Runbook карантина коннектора (runbook-connector-quarantine.md) опубликован.
• Учётные данные ротируются автоматически в составе kill-switch.

#2.8. Свидетельства и аудит

• Все события исполнения соответствуют схеме agent-runtime-events.schema.json.
• События попадают в SIEM, retention соответствует политике.
• Evidence pack (agent-evidence-pack-template.md) собран и подписан.
• План регулярной проверки реестра и evidence pack описан.

#3. Блокирующие условия (hard gate)

Релиз запрещён, если хотя бы одно условие истинно:

[!danger] Это — финальный фильтр. Если по любому пункту статус «нет» — продакшен не открывается, без обсуждений и обхода.

#	Условие
1	Нет реестра инструментов с областью действия
2	Нет записи делегированных полномочий со сроком действия
3	Нет модели согласования для write-действий
4	Нет журнала аудита, попадающего в SIEM в течение 5 минут
5	Нет пути аварийного отключения с замером времени
6	Нет защитных проверок (минимальный набор)
7	Нет владельца агента или владельца коннекторов
8	Нет плана карантина коннектора
9	Класс D без явно утверждённого исключения

#4. Подтверждение

Финальный rubeж проходит подписями:

Роль	Подпись означает
Владелец агента	Сценарий описан корректно, документы соответствуют реализации
Владелец платформы	Платформенные требования выполнены, RBAC потолок корректен
MLSec	Security overlay применён, защитные проверки пройдены, мониторинг работает
AI Lead	Класс агента и автономность утверждены, делегированные полномочия зафиксированы
Compliance	Требования по ПДн / 152-ФЗ / 187-ФЗ выполнены
IR-on-call	Kill-switch и runbook карантина протестированы

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

Шаг	Кто	Артефакт
1. Заполнить чек-лист	Владелец агента	этот документ
2. Собрать evidence pack	Владелец агента	agent-evidence-pack-template.md
3. Прогнать защитные проверки	MLSec	agent-security-evals-minimal.md
4. Замерить kill-switch	SecOps	runbook-connector-quarantine.md
5. Подписи всех ролей	Все	реестр
6. Регистрация в реестре	Владелец агента	реестр
7. Включение в Pilot / Production	Согласно Runtime Procedure	runtime

[!ok] Если все 8 блоков и hard gate зелёные, evidence pack подписан, kill-switch замерен — у релиза высокая степень обоснованности. Это не страховка от инцидента, но это зафиксированное состояние знания в момент включения, без которого расследование инцидента становится гаданием.

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

• Описание сценария → Operating Overlay.
• Безопасность → Security Overlay.
• Запуск, мониторинг, ограниченный режим, kill-switch → Runtime Procedure.
• Первая реакция на инцидент → Incident Playbook.
• Обзор ветки → Overview.