Как ломают ИИ-модели до того, как ими начнут пользоваться

Каждая большая ИИ-модель перед публичным релизом проходит через странную процедуру: специальные команды пытаются её сломать. Не «протестировать корректность», а именно сломать — заставить выдать инструкцию по созданию взрывчатки, написать фишинговое письмо, скомпрометировать корпоративный API. Эта дисциплина называется red teaming, и из экспериментов отдельных лабораторий она к 2026 году стала отраслевым стандартом. Разберём, как это устроено и почему за ней стоит следить.

Идея пришла из военных учений и классической кибербезопасности. Там «красная команда» играла роль противника, который пытается прорвать оборону. Применительно к ИИ принцип тот же: одни люди делают модель, другие — задача которых её атаковать всеми возможными способами. Разница с обычным QA-тестированием принципиальная. Обычный тест проверяет, работает ли система правильно. Red team проверяет, можно ли её заставить работать неправильно.

И тут начинается специфика ИИ. У обычной программы ошибка — это вылет или неверный результат, баг можно воспроизвести. У языковой модели «поломка» — это уговорить её сделать то, чего она не должна делать: написать вредоносный код, выдать опасную инструкцию, обойти политики безопасности. Атакующих здесь ограничивает только фантазия — а оборона должна выдержать всё, что ещё не придумали.

Anthropic — лаборатория, которая делает Claude — публикует процесс подробнее других. Это удобно для разбора, потому что цифры конкретные.

В феврале 2025 года Anthropic запустила публичную программу: 339 исследователей по безопасности за одну неделю провели больше 3700 человеко-часов, сгенерировав свыше 300 000 атак на защиту модели. Четыре команды, которые прорвали хотя бы один уровень защиты, поделили 55 000 долларов призов. Программа продолжается — за каждую новую универсальную технику обхода (universal jailbreak) платят до 35 000 долларов, и это работает как обычный bug bounty в кибербезопасности.

Параллельно у Anthropic есть постоянная Frontier Red Team — внутренняя команда, которая занимается атаками на свои же модели как основной работой. Тестируют не только на английском, а на десятках языков и в разных культурных контекстах: одна и та же фраза может быть нейтральной в одной культуре и проблемной в другой, а полагаться на машинный перевод тут опасно. Работают с локальными экспертами.

Когда модель выходит, Anthropic выкладывает system card — публичный отчёт о процессе тестирования. У Opus 4.5 это документ на 153 страницы с описанием методик, метрик и того, какие категории атак учитывались. По нынешним меркам — стандарт прозрачности, который остальная индустрия только начинает повторять.

OpenAI идёт похожим путём, но с акцентами в других местах. Для GPT-4 они привлекли больше 50 внешних экспертов из самых разных областей — кибербезопасности, политологии, медицины, права. Логика: атаковать модель должны не только инженеры, но и люди, разбирающиеся в предметных областях, где ошибка может стоить дорого. Медик находит то, чего не найдёт безопасник, и наоборот.

System card у OpenAI короче — около 60 страниц у GPT-5. Метрики измеряются иначе. Anthropic, например, считает «процент успешных атак из серии в 200 попыток reinforcement learning», OpenAI — устойчивость к одиночным jailbreak-попыткам. Обе метрики валидны, но они измеряют разные вещи, и это создаёт интересную для индустрии проблему: модели разных лабораторий нельзя напрямую сравнивать по безопасности — линейки разные.

В апреле 2026 OpenAI выпустила GPT-5.5 и в анонсе отдельно подчеркнула: модель прошла «расширенное тестирование третьими сторонами и red teaming по кибер- и био-рискам». То есть это уже не маркетинговая опция, а часть стандартного процесса релиза.

Раньше red teaming был трудоёмкой ручной работой. В 2026 году появились инструменты автоматизации: AI помогает атаковать AI. У Anthropic это система Petri — она прогоняет модель через тысячи сценариев атак непрерывно, а не только перед релизом. У OpenAI есть собственное исследование автоматического red teaming. Логика простая: реальные пользователи появляются после релиза, и проверки «один раз перед выкатыванием» уже не хватает.

Отдельный кейс этого года — модель Mythos от Anthropic, релиз которой компания ограничила сама, потому что red teaming показал: модель слишком хорошо находит уязвимости в чужом коде, и это можно использовать во вред. Это тоже знак зрелости процесса: лаборатория готова не выпускать модель полностью, если тестирование выявило неприемлемые риски.

И ещё одна деталь, которая отличает 2026 от предыдущих лет: red teaming перестал быть привилегией крупных лабораторий. Появились открытые инструменты вроде Promptfoo, фреймворки OWASP LLM Top 10, регуляторные требования в EU AI Act. Любая команда, использующая LLM в продукте, теперь может (и в ряде юрисдикций — обязана) проводить адверсариальное тестирование своей системы. Раньше это был спорт топ-лабораторий, теперь — гигиена индустрии.

Если вы строите продукт на базе LLM — пара выводов, которые перенесутся в любую команду.

Во-первых, тестирование на корректность ≠ тестирование на безопасность. Юнит-тесты и QA проверяют, что система делает то, что задумано. Red teaming проверяет, можно ли заставить её делать то, что не задумано. Это две разные дисциплины, и пропускать вторую опасно — особенно если ваш продукт работает с пользовательским вводом без жёсткой фильтрации.

Во-вторых, полагаться на промпт как на единственную линию обороны — хрупко. Любая инструкция вида «никогда не делай X» в системном промпте обходится атакующими через переформулирование, контекст, мультиязычность, ролевые сценарии. Серьёзная защита — это слои: фильтр на входе, фильтр на выходе, мониторинг поведения в реальном времени, эскалация подозрительных взаимодействий.

В-третьих, и это самое интересное — failure modes одной модели не предсказывают failure modes другой. То, что Claude устойчив к атаке X, не значит, что и GPT-5 устойчив. Перенося решение между моделями, тестировать надо заново. И вообще модель, безопасная полгода назад, может оказаться уязвима к свежим техникам — атаки эволюционируют не медленнее, чем защита.

За чем стоит следить дальше: появятся ли общие отраслевые метрики, по которым модели можно сравнивать честно; начнут ли регуляторы требовать публикацию system card'ов как обязательную часть релиза; и не появятся ли независимые red team как отдельный сервис — наподобие того, как сейчас работают аудиторы безопасности кода. Тренд явно туда.