Глава 11 — Наблюдаемость, логирование и реагирование на инциденты
Одиннадцатый пост поглавного разбора LLM Primer VII: AI Security. Глава, обращающаяся с логированием, оповещением и реагированием на инциденты как со слоем, превращающим архитектурные защиты в систему, которую операторы могут действительно эксплуатировать.
Зачем существует эта глава
Система с правильной структурой, но без видимости отказывает невидимо. Глава 11 проходит слой наблюдаемости для систем LLM — что логировать, как обнаруживать злоупотребления и аномалии, как оповещать без производства шума, как проводить playbook реагирования на инциденты, когда что-то идёт не так, и как учиться из произошедшего. Общие дисциплины переносятся из операционной инженерии в других областях с LLM-специфичными расширениями: вероятностные выводы означают, что воспроизведение инцидентов требует захвата большего состояния, чем в детерминированных системах; семантические конвенции OpenTelemetry GenAI, разрабатываемые с 2024, дают вендор-нейтральный словарь для этого состояния.
11.1 Что логировать — решение политики, а не значение по умолчанию
Логирование слишком малого оставляет команду неспособной расследовать. Логирование слишком многого создаёт проблемы комплаенса, стоимости и приватности, которые в итоге заставляют сокращение. Защитимая позиция — минимум, поддерживающий операционные варианты использования, которые команда идентифицировала, в структурной форме, поддерживающей каждый. Цели обычно включают оповещение в реальном времени о злоупотреблении или аномалии, расследование инцидентов постфактум, планирование ёмкости и анализ стоимости, комплаенс-отчётность и непрерывную оценку поведения модели. У каждой цели свои требования к схеме; лог, спроектированный под одну, неадекватен для других. Семантические конвенции OpenTelemetry GenAI определяют span'ы и атрибуты для LLM-вызова — имя модели, провайдер, параметры запроса, контент промпта, контент ответа, счётчики токенов, задержка, стоимость, — что позволяет нижестоящему инструментарию парсить одну и ту же телеметрию независимо от конкретного SDK. Langfuse, Helicone, Arize Phoenix и Datadog LLM Observability все потребляют эту форму. Продакшн-запись лога обычно включает ID запроса, аутентифицированную сущность, арендатора, версию модели и провайдера, полный собранный промпт (с извлечённым контекстом и его провенансом), tool-вызовы и их выводы, контент ответа, оценки safety-классификатора на входе и выходе, задержку и учёт токенов. Ответственное хранение этого означает явность в отношении окон удержания, обработки PII и контролей доступа на сам log-store.
11.2 Обнаружение составляет сигнатурные, статистические и поведенческие сигналы
Когда телеметрия структурирована, следующий вопрос — какие паттерны указывают на неполадку. Signature-matching — самая дешёвая первая линия: известные фразы prompt-инъекции, DAN-подобные преамбулы, base64-закодированные полезные нагрузки, role-play-заходы, которые уже наблюдались. Список строится из публичных исследований, внутренней red-team-работы и прошлых инцидентов. Сигнатуры ловят известные варианты; противники адаптируются, узнав, какие фразы флагаются. Статистическое обнаружение аномалий следит за расхождением с baseline'ом: необычные распределения токенов, атипичные отношения задержка-к-длине, внезапные пики частоты отказов или частоты конкретных tool-вызовов. Baseline'ы медленно дрейфуют в нормальных условиях и резко сдвигаются в анормальных. Обнаружение поведенческих паттернов сопоставляет профили злоупотребления, даже когда отдельные запросы не откровенно вредоносны — одна сущность, выпускающая тысячи парафразированных вариантов того же ограниченного запроса, пик запросов, сочетающих легитимный контент со специфичным суффиксом, медленный дрейф в per-user распределениях ответов. Обнаружение полезно, только если ведёт к оповещениям, на которые операторы реально реагируют. Таксономия обычно различает critical (активное злоупотребление в масштабе, пейджер on-call-инженеру), high (заметный паттерн с ограниченным вредом, уведомление в рабочие часы) и medium/low (дашборды и еженедельный обзор). Alert fatigue — режим отказа; строгая дисциплина серьёзности — то, что предотвращает его.
11.3 Реагирование на инциденты — playbook, а не импровизация
NIST SP 800-61 Revision 2 даёт фреймворк — подготовка, обнаружение и анализ, сдерживание, искоренение, восстановление, пост-инцидентная активность, — который LLM-специфичный playbook расширяет. Подготовка означает, что runbook'и, on-call-ротации и доступ к релевантному инструментарию существуют до инцидента. Обнаружение и анализ — где окупается наблюдаемость раздела 11.1. Сдерживание для LLM-инцидента может означать переключение feature-flag для отключения инструмента, деградацию к более консервативной версии модели, ужесточение лимитов скорости на конкретную сущность или арендатора или перенаправление трафика на альтернативный стек. Искоренение зависит от типа инцидента: джейлбрейку может понадобиться добавленное правило фильтра, скомпрометированному RAG-документу — удаление из индекса, утёкшему учётному данному — ротация. Восстановление — когда система возвращается к норме, со снятием сдерживания и верификацией искоренения. Пост-инцидентная активность — где концентрируется модель-специфичная работа: воспроизведение поведения по возможности, характеризация границы отказа, решение, отражает ли инцидент нечто о модели, что должно изменить её использование, и передача исхода в оценочный набор, чтобы будущие регрессии ловились до развёртывания. Воспроизведение не всегда возможно при ненулевой температуре сэмплирования, но цель — определить, когда происходит нежелательное поведение.
Что подготавливает глава 11
Глава 12 закрывает часть IV слоем идентичности и доступа — кому разрешено взаимодействовать с системой, на каких условиях и как принуждение структурировано между компонентами. Традиционные дисциплины применимы: аутентификация с API-ключами, OAuth и mTLS; авторизация с RBAC и ABAC; мультитенантная изоляция; лимиты скорости и квоты; корпоративные governance-оверлеи. LLM-специфичные расширения касаются модели как сущности — агента, действующего от имени пользователя, имеющего свою идентичность и свои разрешения, — роли capability-токенов для вызова инструментов и per-tenant-конфигурации поведения модели, которую должны поддерживать мультитенантные LLM-платформы. Глава 13 затем открывает часть V регуляторным ландшафтом, где технические контроли, разработанные этой книгой, должны быть отображены на AI Act, GDPR, законы штатов США и фреймворки, окружающие их.
Дальше — Глава 12: Контроль доступа и идентичность. Аутентификация, RBAC против ABAC, мультитенантная изоляция, лимиты скорости и корпоративный governance-оверлей, делающий LLM-системы пригодными в регулируемых средах.
