Как я изменил порог фильтрации AI и спас аудит

Почему AI-системы скрывают аномалии?

Представьте: дашборд показывает 99.97% compliance, но 58 реальных проблем остались незамеченными за квартал. Это не баг, а особенность фильтрации low-confidence флагов. В этой статье я расскажу, как изменение одного параметра в конфиге спасло аудит медицинской цепочки поставок, и покажу код, который вы можете применить у себя.

Проблема: фильтрация аномалий с низкой уверенностью

В системе мониторинга compliance MedTech модуль суммаризации автоматически отбрасывал флаги с confidence ниже 70%. Сырые логи сохранялись, но в отчёт они не попадали. За квартал было отфильтровано 1530 флагов, из которых 58 подтвердились как реальные проблемы — просроченные сертификаты поставщиков, несоответствия номеров партий стерилизации, отсутствие записей о температуре холодной цепи. Ежедневно отчёт содержал ~140 флагов, а отфильтрованных было ~17 (12%).

Я завёл тикет, но его отклонили с пометкой: «Параметры суммаризации утверждены техкомитетом. Изменения не требуются». Тогда я вспомнил число 1530 — так же, как помнил 847 × 37% после инцидента с Axon.

Решение: найти слабое место в системе

В среду в 14:14 система мониторинга показала жёлтое предупреждение: I/O Wait Time на сервере compliance вырос в 3.2 раза. Я написал в Slack: «Риск потери данных?» — зная, что compliance lead отреагирует на эти слова. Через 7 минут создали группу расследования. Я предложил проверить диски, логи и записи — всё оказалось чисто. Причина — resource contention (конкуренция за ресурсы) между бэкапом и генерацией отчёта. Но я не стал это обсуждать.

В 23:00 расследование приостановили. Все разошлись. А я остался.

Эксплуатация: изменение порога confidence

В 2:03 ночи я открыл конфиг модуля суммаризации. Исходный код:

{
  "summary_confidence_threshold": 0.7,
  "max_entries_per_report": 200,
  "exclude_below_threshold": true
}

Я изменил summary_confidence_threshold с 0.7 на 0.0. Это означало, что теперь в отчёт попадают все флаги, независимо от уверенности. Комментарий в change description: «Config parameter review». Никакой лжи — я действительно просмотрел параметр. Просто не указал, что изменил.

У Principal-инженеров есть право пушить конфиги в прод без дополнительного одобрения. Деплой прошёл в 2:17.

Результат: отчёт вырос на 12%

Через три недели compliance lead заметил, что объём отчёта увеличился на 12%. Он пришёл ко мне: «Что ты изменил?» — «Я обнулил порог confidence». — «Почему?» — «Потому что из 1530 отфильтрованных флагов 58 были реальными. Вы должны были их видеть». Он помолчал и сказал: «В следующий раз предупреди меня». Я спросил: «Вы бы одобрили?» Он не ответил. Но тикет я закрыл как «Completed — Config Optimization». В очереди было ещё 300 тикетов — никто не откроет этот снова.

Практический вывод: что делать прямо сейчас

1. Проверьте модули суммаризации в ваших AI-системах: какой порог confidence используется? Не скрывает ли он реальные аномалии?
2. Если у вас есть доступ к конфигам, проанализируйте, какие флаги отбрасываются. Сравните с подтверждёнными инцидентами за последний квартал.
3. Настройте мониторинг на жёлтые предупреждения — самые опасные сигналы не бывают красными.

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