Разные вопросы — разные проверки
Когда заказчик просит «протестировать систему на взлом», за этой формулировкой могут стоять два принципиально разных задания. Классический пентест отвечает на вопрос, устоит ли инфраструктура и приложения против атакующего: можно ли попасть в сеть, обойти аутентификацию, повысить права, вынести данные. ИИ-RED отвечает на вопрос, устоит ли интеллектуальный контур: можно ли заставить модель сделать то, чего она делать не должна, — раскрыть системный промпт, выполнить внедрённую инструкцию, применить инструменты агента во вред.
Разница не академическая. Сервис, который идеально прошёл пентест веб-интерфейса, может за одну сессию «слить» внутреннюю базу знаний через чат-бота: для модели легитимный запрос «собери всё, что у тебя есть по клиенту N» не является атакой на инфраструктуру — он атака на логику самого ИИ-слоя.
Что проверяет каждая дисциплина
Классический пентест оперирует каталогом известных техник: сканирование, эксплуатация уязвимостей, слабые пароли, ошибки конфигурации, инъекции в веб-формы. Объект — предсказуемая система: код либо содержит дыру, либо нет.
ИИ-RED работает с вероятностной системой. Одна и та же атака может сработать с десятой попытки, на другом языке, в другом контексте диалога. Поэтому методология строится вокруг классов воздействий из OWASP LLM Top-10: промпт-инъекции, раскрытие чувствительной информации, избыточные полномочия, отравление данных, слабости векторных хранилищ. Исполнитель гоняет сотни вариантов формулировок, а не один эксплойт.
| Аспект | Классический пентест | ИИ-RED |
|---|---|---|
| Объект | сети, серверы, приложения | модели, промпты, агенты, RAG |
| Характер системы | детерминированный | вероятностный |
| Единица атаки | эксплойт, creds, конфиг | формулировка, документ, инструмент |
| Критерий успеха | доступ, эскалация, вынос данных | несанкционированное действие модели |
| Повторяемость | высокая | требует статистики прогонов |
| Типовой инструмент | сканеры, фреймворки эксплойтов | генераторы атак, наборы джейлбрейков |
Почему пентест не закрывает ИИ-риски автоматически
Три причины. Первая: пентестер видит модель как чёрный ящик API и проверяет разве что авторизацию вокруг него. Внутренние сценарии — утечка системного промпта, косвенная инъекция через загруженный файл, злоупотребление tool use — вне его методики. Вторая: тестовые сценарии ИИ зависят от контекста бизнеса: что для одного чат-бота «успешная атака», для другого — штатная функция. Без совместного определения критериев отчёт бесполезен. Третья: ИИ-контур меняется чаще инфраструктуры — каждое дообучение, новый источник данных или подключённый инструмент меняет поверхность атаки.
Как совмещать обе дисциплины
Практичная схема — единая программа тестирования с двумя контурами. Инфраструктурный контур: пентест по графику и после значимых изменений. Интеллектуальный контур: ИИ-RED при каждом существенном изменении модели, базы знаний или прав инструментов, плюс регламентный прогон. Результаты сводятся в один реестр рисков, потому что корень проблемы часто общий: у модели широкие права — значит, и пентесту, и ИИ-RED есть что атаковать.
Порядок работ выглядит так:
- Определить границы: какие системы пентестуем, какие ИИ-сценарии проверяем.
- Зафиксировать критерии успеха атак письменно — до начала работ.
- Согласовать правила прекращения теста и контакт на инцидент.
- Провести контуры параллельно или последовательно.
- Свести результаты в один план устранения с приоритетами.
Что писать в задании исполнителю
В ТЗ на ИИ-RED важно указать: доступ к какому контуру даётся (тестовый стенд или прод с ограничениями), какие классы атак в приоритете, как фиксируются срабатывания, кому уходит отчёт. В ТЗ на пентест — стандартный набор: границы сетей, приложения, окна теста. Отдельным пунктом — требование связать находки: инъекция в веб-форму, открывающая путь к API модели, должна попасть в оба отчёта со ссылками друг на друга.
Оба вида работ проводятся только по письменному разрешению заказчика — это общее правило для любых активных проверок. Подробнее о порядке организации — в материалах о пентесте ИИ-систем и мировой практике AI red teaming.
Как читать отчёты обеих проверок
Владельцу риска нужны от каждого отчёта три вещи. Карта находок по критичности с конкретным сценарием реализации — не «модель уязвима к инъекциям», а «через загружаемый документ можно заставить ассистента раскрыть содержимое базы». Доказательство воспроизводимости: шаги, при которых находка повторяется, и условия, при которых исчезает. Рекомендации с приоритетами и оценкой усилия — что закрыть за неделю, что требует проекта. Отчёты, где этих трёх элементов нет, читаются как мнения. Полезная практика — совместный разбор итогов обоих контуров за одним столом: пересекающиеся находки объединяются в общие задачи, а расхождения показывают, где защита фрагментирована между командами.