Мониторинг и реагирование на инциденты
Наблюдаемость ИИ-системы состоит из трех слоев: облачные события управления и отдельных операций, эксплуатационные метрики среды исполнения и прикладная трассировка модельного или агентного запроса. Их связь и сигналы для расследования проверяются по AI-MON-ANOMALY2 и AI-MON-TRACE1.
Сигналы и оповещения
Нетипичное использование API и ресурсов обнаруживается
Идентификатор требования: AI-MON-ANOMALY2
Требование
Организация должна определить наблюдаемые признаки злоупотребления для своего сценария: всплеск вызовов модели или инструментов, необычный расход, повторяющиеся отказы политик, изменение объема исходящего трафика, исчерпание ресурсов, нетипичную активность GPU или резкое изменение ошибок и задержки. Для каждого сигнала задаются источник, окно наблюдения, ответственный канал и ожидаемое действие.
Для агентного слоя дополнительно наблюдаются решения по извлечению данных и инструментам, сессии MCP и длительность работы инструментов.
Для каждого правила фиксируются точная метрика или событие, метки ресурса, запрос и порог, назначение и владелец.
Реализация
Yandex Monitoring позволяет строить запросы и алерты по доступным метрикам; алерт оценивает условие и отправляет уведомление, но сам по себе не останавливает нагрузку. Бюджеты Yandex Cloud Billing могут дополнять контроль расходов, но не показывают число и характер модельных вызовов.
Yandex Cloud Detection and Response находится на стадии Preview; доступ к разделу в Security Deck предоставляется после одобрения запроса. Сервис может использоваться как дополнительный источник, если доступ получен, для облака развернут отдельный коллектор и нужный сигнал действительно поступает по документированному TLS-пути. Условия и архитектура описаны в документации YCDR.
Семейство сервисных ролей ycdr.admin — единственное документированное для YCDR; оно не назначается шире необходимого.
Проверка
Для каждого правила сформируйте безопасный тестовый сигнал и подтвердите срабатывание алерта, доставку в нужный канал и регистрацию действия ответственного. Значения порогов и периодичность утверждает организация; стандарт не задает универсальных чисел. Оповещение должно прийти владельцу с идентификаторами ресурса и корреляции. Отдельная отрицательная проверка подтверждает, что отсутствующий или отключенный маршрут оповещения обнаруживается.
Артефакт
- Конфигурация алерта.
- Тест доставки.
- Регистрация действия ответственного.
- Идентификаторы дашборда и оповещения.
- Временная шкала события.
- Тикет реагирования.
Сквозная прикладная трассировка
Модельный и агентный запрос прослеживается без избыточного содержимого
Идентификатор требования: AI-MON-TRACE1
Требование
Приложение должно присваивать запросу идентификатор корреляции (correlation ID). Общая запись содержит время, проверенную идентичность или обезличенный идентификатор субъекта, рабочую идентичность вызывающего компонента, целевой ресурс или эндпоинт, версию модели и конфигурации, идентификаторы RAG-источников, результат входной и выходной политики, технический исход, код ошибки и длительность.
Для агента дополнительно записываются шаг, выбранный инструмент, проверка полномочий, запрос подтверждения человека и результат бэкенда.
Идентификаторы платформенных запросов сопоставляются с прикладным идентификатором в карточке корреляции и не считаются тождественными ему.
Полные промпты, ответы, диалоги и скрытые рассуждения модели не являются обязательным минимумом и не должны собираться только ради соответствия. Если облачный сервис не публикует нужное событие уровня данных, приложение обязано сформировать запись само. Cloud Functions и Serverless Containers передают журналы запросов и stdout/stderr в Cloud Logging в пределах документированной модели: логи Cloud Functions, логи Serverless Containers.
Проверка
Выполните запрос, включающий RAG и вызов тестового инструмента, и восстановите путь от входа до результата. В трассировке должны быть видны решения политики и технические исходы, но отсутствовать секреты и неутвержденные данные. Отдельный отрицательный тест: пропавший или неверно сопоставленный идентификатор делает проверку покрытия невыполненной.
Артефакт
- Сквозная трассировка от входа до результата.
- Отсутствие секретов.
- Сопоставление идентификаторов платформы и приложения.
Каждая итерация агентного цикла связана с задачей и действием
Идентификатор требования: AI-MON-TRACE2
Применимость
Требование применяется, если система выполняет многошаговый агентный цикл.
Требование
Для каждой итерации сохраняются идентификаторы задачи и сессии, номер шага, выбранный инструмент, параметры, переданные после редактирования, проверка полномочий, результат или код ошибки и решение продолжить, остановить либо запросить подтверждение. Если оркестратор сам создает план или подцель, записываются их идентификатор и версия; стандарт не требует сохранять скрытые рассуждения модели.
При использовании MCP элементы Responses mcp_call, mcp_approval_request и mcp_approval_response связываются с событиями Audit Trails mcp_hub.StartMcpSession, mcp_hub.ListMcpTools и mcp_hub.InvokeMcpTool и с отдельным событием целевой системы; ни одна из этих записей сама по себе не доказывает побочный эффект в целевой системе, а отдельное событие подтверждения в справочнике Audit Trails не опубликовано.
При наличии доступных метрик можно дополнительно записывать время и расход ресурсов шага. Запись должна быть связана с AI-MON-TRACE1, но не содержать секреты, полные регулируемые данные или неутвержденное содержимое.
Проверка
- Выполните сценарий из нескольких шагов с одним успешным и одним отклоненным вызовом инструмента.
- Восстановите порядок действий, активную версию плана при ее наличии, решение авторизации, ошибку и условие остановки по единому идентификатору задачи.
Отсутствие итерации или подтверждения эффекта в целевой системе означает невыполнение.
Артефакт
- Трассировка многошагового сценария с успешным и отклоненным вызовом.
- Версия конечного автомата задачи.
- Запись подтверждения.
- Событие целевой системы.
Сохранность материалов расследования
Архив содержимого диалога имеет утвержденный объем и контролируемый доступ
Идентификатор требования: AI-FORENSIC2
Применимость
Требование применяется, если полное или частичное содержимое диалога сохраняется для расследования, качества, поддержки или иной утвержденной цели. Если сохраняются только минимальные криминалистические события без содержимого, для ветви необработанного содержимого результат N/A допустим со ссылкой на решение.
Требование
Решение о хранении должно определить состав сообщений и изменений контекста, цель, правовое основание, срок, место хранения, владельца и круг читателей. Архив отделяется от обычных прикладных журналов, шифруется средствами выбранного хранилища и не используется как обязательный источник там, где достаточно метаданных из AI-MON-TRACE1.
Чтение и экспорт архива должны фиксироваться сервисом или приложением в пределах доступной телеметрии.
По умолчанию архив содержит идентификаторы, версии и решения, а не содержимое; глобальный сбор диалогов на случай возможного будущего инцидента не включается. Архив изолируется по делу, а читатели продуктивных журналов и расследователи разделяются.
Проверка
- Сопоставьте одну сохраненную сессию с утвержденным составом и сроком.
- Выполните разрешенное и запрещенное чтение, проверьте событие чтения или прикладную запись и удаление тестовой сессии по окончании срока.
Если платформа не публикует событие чтения, эта слепая зона и компенсирующая запись должны быть указаны явно. Расследователь другого дела не должен получить доступ к объекту проверяемого дела.
Артефакт
- Сохраненная сессия.
- Тест разрешенного и запрещенного чтения.
- Область дела.
- Результат удаления или запрета на удаление.
Материалы расследования защищены от незаметного изменения
Идентификатор требования: AI-FORENSIC3
Требование
Журналы и выгрузки, используемые для расследования, должны храниться отдельно от рабочих администраторов исследуемой системы. Права записи, чтения и удаления разделяются; время, источник и целостность записи должны проверяться. Срок хранения устанавливается утвержденной политикой и правовыми требованиями.
Реализация
Для защищенного назначения Audit Trails можно использовать рекомендации по журналам аудита.
В Object Storage версионирование и Object Lock могут поддерживать неизменяемость при корректной настройке, но бессрочное удержание и срок хранения требуют отдельного управления.
Идентичности записи и чтения разделяются; манифест хешей и выгрузка ссылаются на точную версию объекта. Object Lock включается только после согласования хранения: защищенные им данные могут стать неудаляемыми.
Проверка
Выберите сохраненный инцидент, проверьте цепочку от исходной записи до архива, эффективные права и возможность обнаружить изменение. Рабочий администратор приложения не должен единолично изменять или удалять единственную копию. Разрешенная попытка изменить или удалить защищенный синтетический объект должна вести себя согласно режиму блокировки; восстановленная версия сверяется по хешу.
Артефакт
- Права на журналы.
- Тест изменения единственной копии.
- Конфигурация бакета, политик, ACL, версионирования, блокировки и шифрования.
- Версия и хеш объекта.
Порядок реагирования
Для выполнения AI-MON-ANOMALY2 и AI-FORENSIC3 используется следующий порядок:
- Установить затронутые модели, данные, идентичности, инструменты и получателей.
- Ограничить последствия — остановить опасный маршрут или инструмент, отозвать ключ, сузить привязку либо перевести конечную точку в безопасный режим.
- Сохранить минимально необходимые материалы расследования.
- Устранить причину в данных, политике, конфигурации, коде или доступах.
- Повторить исходную и связанную негативную проверку.
- Вернуть сервис только после документированного решения.
Действия должны учитывать риск потери данных и возможность отката. Изоляция инцидента не должна без проверки уничтожать единственные материалы расследования.