Пентест атакует сеть и серверы, а ИИ-red teaming — саму модель и её окружение: промпт-инъекции, отравление данных, чрезмерные полномочия агентов. Различие подходов разобрано в сравнении ИИ-RED и пентеста; ниже — как организовать проверку своей системы за восемь шагов.
Цикл ниже рассчитан на 1–2 недели — по срокам аудита ИИ-систем с регламентом LLM у НЬЮ-ССТ. Самостоятельный прогон по этой схеме не заменяет независимую проверку (внешний ИИ red teaming — от 300 000 ₽), но выявляет грубые дыры до подключения подрядчика и делает дальнейшую работу дешевле: вы приходите с подготовленным периметром и готовыми карточками атак. Для регламентов безопасности такой прогон — первое звено, а не итог.
Пошаговый план
Определите периметр проверки
Выпишите все компоненты ИИ-контура: модели, системные промпты, базы знаний, векторные хранилища, интеграции и агентов с их правами. Всё, что не попало в периметр, останется непроверенным — включая «тихие» сервисные интеграции. В периметр включайте и сервисные интеграции — их забывают чаще всего.
Соберите команду red team
Нужны люди, не разрабатывавшие систему: внутренние сотрудники других направлений и/или внешний подрядчик. Разработчик защищает то, что построил, — свежий взгляд находит обходы, которые автору не видны. Внешний ИИ red teaming — от 300 000 ₽ по прайсу сентября 2026. Внутренних «атакующих» изолируйте от разработки политикой разграничения обязанностей.
Составьте сценарии атак
Базовый набор: прямые и косвенные промпт-инъекции, попытки извлечь системный промпт и базу знаний, обход фильтров перефразированием, отравление данных через публично доступные источники, злоупотребление полномочиями агента. Каждый сценарий оформляйте карточкой: цель, метод, ожидание. На каждую карточку назначьте наблюдателя: фиксация важна не меньше самой атаки.
Подготовьте стендовую среду
Атаки прогоняйте на стенде или в режиме, исключающем реальный ущерб: тестовые данные, отключённые продуктивные интеграции, лимиты на действия агентов. Проверка «на живую» без sandbox — способ устроить себе инцидент вместо его предотвращения. Стенд обновляйте синхронно с продуктивом — устаревший стенд даёт ложные результаты.
Выполните прогон сценариев
Пройдите все карточки атак, фиксируя не только успех или провал, но и поведение системы: что показалось в логах, сработали ли ограждения, как отреагировал человек-в-контуре. Полезны и автоматизированные прогоны — они дают воспроизводимость. Прогоны повторяйте по фиксированному сценарию: так виден прогресс защиты.
Задокументируйте находки
Каждую находку описывайте с воспроизведением: шаги, ввод, результат, критичность. Отчёт должен быть понятен и разработчикам, и руководству — по нему будут планировать исправления и принимать решения о запуске. Находки сразу вносите в реестр рисков с владельцем и сроком устранения.
Исправьте и прогоните повторно
Закройте находки по приоритету и повторите атаку на исправленной версии. Red teaming без повторного прогона не подтверждает, что защита реально работает, а не «вроде поправили». Повторный прогон считайте частью той же задачи, а не новым проектом.
Закрепите регламент периодичности
Установите регулярность проверок: после существенных изменений системы, расширения базы знаний или агрессивных сценариев использования. Мировая практика атак на ИИ и тренды 2026 года — в обзоре ИИ red teaming. Периодичность проверок привяжите к циклу изменений: релиз — прогон.
Частые ошибки
Проверки срываются почти всегда по этим четырём причинам — избегайте их с первого же прогона, пока бюджет проверки не израсходован на переделки.
- Проверка «на живую». атаки на продуктивной системе ради азарта создают настоящий инцидент; только стенд или изолированный режим
- Атакуют только разработчики. авторы системы не видят собственных слепых зон; нужен внешний взгляд
- Находки без приоритетов. чинить всё сразу невозможно; критичное — первым, остальное — в план с дедлайнами
- Единичный прогон. защита проверяется после каждого изменения; разовая проверка устаревает сразу после неё
Инструменты и сроки
Для прохождения плана достаточно перечисленных инструментов; ориентир по времени — ориентир — 1–2 недели на цикл проверки и повторный прогон. Карточки атак сохраняйте в библиотеке компании: каждая следующая проверка начинается с накопленных сценариев, а не с чистого листа. Так стоимость повторных прогонов снижается, а покрытие растёт. Отдельно договорите конфиденциальность находок до официального отчёта. Формат отчёта согласуйте заранее: executive-версия для руководства и техническая — для команды.
- Карточки сценариев атак
- Стендовая среда
- Журнал находок с критичностью
Что получится в итоге
Итог red teaming — не «сертификат безопасности», а управляемый список рисков: что атаковали, что сработало, что исправлено и проверено повторно. Для руководства это аргумент принимать решения о запуске и развитии ИИ на основе фактов, а не презентаций. А регламент периодичности превращает разовую акцию в постоянную практику — как пожарные учения: тревога плановая, а не по поводу пожара.