Именно здесь начинается настоящий разговор — не о том, «опасен ли ИИ вообще», а о том, что именно нужно проверить, прежде чем организация начнёт ему доверять в реальной работе.
Разрыв между демо и реальностью
Демонстрация — это управляемая среда. Тестовый стенд, подобранные данные, отсутствие противника, который адаптируется в реальном времени. Когда модель решает задачу на красивом примере, это говорит только о том, что она решает эту конкретную задачу в этих конкретных условиях.
Авторы оценки Claude Mythos, проводившейся совместно с UK AI Security Institute на высокоточном полигоне промышленных систем управления («Cooling Tower range»), пришли к показательному выводу: фронтирные модели демонстрируют заметные ограничения именно там, где требуются контекстное понимание, операционная осведомлённость и многошаговое рассуждение. Иными словами — там, где реальный инцидент отличается от учебного примера.
Это не повод отказываться от ИИ. Это повод не принимать его возможности на веру.
Похожая картина складывается из масштабного академического анализа: исследователи, изучившие более 500 работ о влиянии фронтирных моделей на кибербезопасность, зафиксировали, что возможности ИИ в атаках опережают возможности в защите. Экспертный опрос подтвердил: большинство специалистов в области ИИ и безопасности считают, что ближайшие годы по-прежнему будут выгоднее для атакующих, хотя разрыв ожидается постепенно сокращающимся.
Асимметрия, которую нельзя игнорировать
Кибербезопасность устроена принципиально несправедливо. Атакующему достаточно найти один работающий путь. Защитнику нужно держать закрытой всю систему — постоянно, на всех уровнях, учитывая все зависимости. ИИ не отменяет эту асимметрию, но способен её усилить.
Когда Anthropic сообщила, что Mythos выявил тысячи уязвимостей высокой степени серьёзности в крупных операционных системах и браузерах — включая 27-летнюю уязвимость в OpenBSD, которую не находили ни люди, ни автоматизированные системы, — это прозвучало как впечатляющий результат. Но одновременно это описание новой проблемы: ИИ способен генерировать находки быстрее, чем организации успевают их исправлять.
В рамках партнёрства с Mozilla Anthropic сообщила о 22 уязвимостях в Firefox, обнаруженных за две недели, 14 из которых Mozilla классифицировала как высокосерьёзные. Проверка, приоритизация, разработка патча, тестирование, распространение обновлений — всё это требует времени и человеческих ресурсов. Скорость обнаружения и скорость устранения движутся в разные стороны, и этот разрыв выгоден атакующему.
Где ИИ сильнее помогает атакующим, а где защитникам
| Направление | Преимущество ИИ для атакующего | Преимущество ИИ для защитника | Оговорка |
|---|---|---|---|
| Разведка (reconnaissance) | Автоматизация сбора информации, сканирования | Мониторинг аномалий, обнаружение угроз | Атаки уже применяются реально; защита — преимущественно исследовательский уровень |
| Поиск уязвимостей | Быстрый анализ кода, zero-day и N-day discovery | Fuzzing, статический анализ | Обнаружение опережает возможности патчинга |
| Разработка эксплойтов | Автоматическая генерация PoC, обход защит | Тестирование патчей | Эксплойт-разработка — преимущественно исследования, но граница смещается |
| Триаж и форензика | — | Анализ инцидентов, сортировка алертов | Агенты плохо справляются со сложными многошаговыми workflow |
| Патчинг и remediation | — | Автоматизация исправлений | Сильные агенты достигают >90% на упрощённых бенчмарках, <30% на реальных |
Важно: эта таблица отражает текущее состояние согласно доступным исследованиям, а не постоянный закон природы. Баланс будет меняться по мере развития инструментов.
Что нужно проверить, прежде чем доверять
Разрыв между впечатляющим демо и обоснованным операционным доверием можно описать через уровни проверки. Каждый следующий уровень даёт больше оснований для уверенности — но требует больше усилий.
| Уровень проверки | Что проверяется | Чего не хватает | Пригодность для продакшена |
|---|---|---|---|
| Демонстрация | Базовая функциональность в контролируемой среде | Нет противника, нет неопределённости | Нет |
| Публичный бенчмарк | Сравнение с другими моделями по стандартным задачам | Не отражает реальный контекст, легко переобучить | Недостаточно |
| Стресс-тест | Поведение под нагрузкой, при неполных данных | Не учитывает adversarial-манипуляции | Частично |
| Adversarial-тест | Реакция на целенаправленные атаки на модель | Требует экспертизы, дорог, не стандартизирован | Необходимо, но не достаточно |
| Контролируемый пилот | Работа в реальной среде с ограниченным охватом | Может не воспроизводить все edge cases | Ближе к реальности |
| Продакшен с human on the loop | Реальная эксплуатация с человеческим контролем | Требует зрелых процессов надзора | Целевое состояние |
Ключевой вывод здесь не в том, что нужно пройти все шесть ступеней перед любым использованием ИИ. А в том, что организации часто останавливаются на первых двух, называя это «валидацией».
Диаграмма: как ИИ проходит путь от помощника до автопилота
flowchart LR
A[Подсказки и<br/>рекомендации] --> B[Триаж алертов]
B --> C[Приоритизация<br/>уязвимостей]
C --> D{Точка риска:<br/>нужен human<br/>on the loop}
D --> E[Автоматическое<br/>исправление]
E --> F[Автономные<br/>решения<br/>в IR]
Каждый шаг вправо увеличивает операционную ценность — и одновременно цену ошибки. На уровне подсказок ошибка модели — это неудобство. На уровне автономных решений в реагировании на инциденты — это потенциально катастрофа. Граница, где требуется человеческий контроль, не фиксирована: она зависит от контекста, зрелости процессов и того, насколько хорошо поведение модели изучено именно в этом сценарии.
От публичных лидербордов к приватному red teaming
Публичные бенчмарки сыграли важную роль в развитии области, но у них есть структурный изъян: они известны заранее. Модели обучаются на данных, близких к тестовым наборам, а разработчики оптимизируют под известные метрики. В результате высокий балл на лидерборде говорит скорее о том, что модель хорошо решает задачи этого конкретного набора, а не о том, что она будет надёжна в вашей корпоративной среде.
flowchart LR A[Внешние<br/>red team эксперты] --> B[Приватный<br/>adversarial набор] B --> C[Многошаговые<br/>и tool-calling<br/>сценарии] C --> D[Итерация<br/>и обновление<br/>тестов] D --> E[Контекстная<br/>оценка под<br/>реальный use case]
Зрелый red teaming в 2026 году — это не публичное соревнование, а закрытое экспертное испытание. Оно включает многошаговые атаки, тестирование в мультиязычных средах, проверку tool-calling сценариев (когда модель не просто отвечает, а вызывает внешние инструменты) и непрерывное обновление тестовых наборов по мере появления новых угроз. Именно такой подход применялся при оценке Claude Mythos на промышленном полигоне.
Важно понимать: даже хорошо проведённый red teaming не превращает модель в «безопасную» — он даёт понять, где именно и при каких условиях модель ведёт себя предсказуемо, а где нет.
Human on the loop — не костыль, а архитектурное решение
Есть распространённое недоразумение: если ИИ требует человеческого надзора, значит, он недостаточно хорош. Логика обратная. Чем выше ставки решения, тем важнее, чтобы человек оставался в процессе — не потому что модель слаба, а потому что решения в кибербезопасности редко бывают чисто техническими.
Решение о том, какую уязвимость патчить первой, зависит от бизнес-контекста, операционных зависимостей, допустимого уровня риска и того, как изменение повлияет на работу компании. Технически корректная рекомендация ИИ может создать операционный риск, если реализована без человеческого суждения. Это не гипотетический сценарий — это описание реальных управленческих решений, которые SOC принимает каждый день.
Human on the loop означает не то, что человек проверяет каждый алерт вручную. Это означает, что в критических точках процесса — там, где цена ошибки высока — есть квалифицированный специалист, который может усомниться в выводе модели, запросить дополнительный контекст и при необходимости отменить решение. Это архитектурный принцип, а не временная мера до появления «более умного» ИИ.
Что это значит для CISO
Вопрос не в том, хорош ли ИИ для безопасности или плох. Фронтирные модели действительно способны ускорить поиск уязвимостей, улучшить скорость анализа и помочь обрабатывать растущий объём угроз. Одновременно они снижают барьер для атакующих и создают новые риски, если внедряются без должной проверки.
Правильный вопрос звучит иначе: готова ли ваша организация к ограничениям этой модели в реальной эксплуатации? Есть ли процессы непрерывного бенчмаркинга? Проводился ли adversarial-тест в условиях, приближённых к вашей среде? Есть ли у команды компетенция замечать, когда ИИ-вывод неточен, манипулятивен или операционно небезопасен?
Ограниченный релиз — как в случае с Glasswing — может давать временное преимущество хорошо оснащённым организациям. Но он не решает проблему диффузии: сопоставимые возможности появятся у других разработчиков, доступ расширится, а горизонт патчинга останется тем же. Это означает, что устойчивость не строится на закрытости модели — она строится на зрелости процессов вокруг неё.
Организации, которые выиграют от фронтирного ИИ, — это не те, кто первыми его внедрит, а те, кто выстроит систему непрерывной валидации, реалистичного тестирования и человеческого надзора над критическими решениями. В кибербезопасности доверие не декларируется — оно зарабатывается под давлением.
