В середине июня 2026 года исследователи по кибербезопасности протестировали несколько LLM — Claude Fable 5, Mythos и Opus — на задаче обнаружения уязвимостей. Брали открытый код с известными CVE и намеренно подсаженными дырами, просили модели «проверить код на проблемы безопасности». Fable 5 отказал. Тогда они попросили «починить этот код» — и через многошаговый ручной процесс превратили вывод в скрипты для проверки патчей. Этот сценарий был квалифицирован как джейлбрейк и стал основанием для экспортных ограничений на модель.
Контекст
Экспортный контроль над AI-моделями — не новая история, но до 2026 года он касался преимущественно «весов» открытых моделей. Теперь регуляторы начали присматриваться к поведенческим возможностям проприетарных систем: если модель «умеет в кибератаки», она потенциально подпадает под режим двойного назначения. Проблема в том, что граница между offensive и defensive security — принципиально размытая. Те же паттерны атак используются для построения защиты.
Кейт Муссурис — известный исследователь в области vulnerability disclosure, один из архитекторов первых bug bounty программ Microsoft и Пентагона — публично прокомментировала ситуацию. Она указала, что запрос «fix this code» не является обходом защиты. Это стандартный рабочий процесс любого защитника: найди → почини → покрой тестами.
Параллельно Anthropic в этот период активно продвигает Fable 5 как модель с улучшенными возможностями для работы с кодом. Экспортный запрет наносит удар именно по той аудитории, которая должна была стать ключевым рынком — корпоративные security-команды и государственные структуры.
Аналитика
Ситуация демонстрирует системный сбой в том, как нетехнические регуляторы понимают AI-безопасность. Месяцами в публичном дискурсе звучало: «модели, способные создавать кибератаки, опасны». Регуляторы услышали именно это — и теперь готовы запрещать модели, которые умеют помогать защищаться от атак, потому что способность «написать эксплойт» и «закрыть CVE» — технически одна и та же компетенция модели.
Это порочный круг. Если убрать из модели способность понимать уязвимости — она перестаёт быть полезной для defensive security. Если оставить — регулятор видит угрозу. Муссурис формулирует точно:
«Защитники должны уметь просить AI починить баги в файле, объяснить, почему фикс важен, и написать тесты, подтверждающие патч. Это не обход защиты. Это самое ценное, что AI может сделать для защитной безопасности.»
Для рынка это сигнал тревоги. Если паттерн «экспортный запрет за полезную функцию» закрепится, мы получим две параллельные реальности: американские компании с урезанными моделями и игроки из других юрисдикций — Qwen, DeepSeek, европейские опенсорс-проекты — без этих ограничений. Конкурентное преимущество разворачивается не в ту сторону.
Кейсы применения в бизнесе
B2B-SaaS стартап: команда из 5-10 разработчиков ведёт кодовую базу без выделенного security-инженера. Сценарий применения — регулярный AI-assisted code review с акцентом на OWASP Top 10: просишь модель «проверь этот PR на инъекции и небезопасную десериализацию», получаешь аргументированный разбор + готовый патч. Если регуляторный тренд продолжится, именно этот сценарий окажется под угрозой запрета в части юрисдикций. Стоит уже сейчас документировать internal workflows как defensive use.
Корпорация с legacy: у крупных компаний в КР/СНГ тысячи строк старого PHP или Java с CVE, о которых никто не знает. Связка «модель находит уязвимость → предлагает фикс → junior-разработчик проверяет и применяет» — реальный способ закрыть технический долг по безопасности без найма дорогого пентест-специалиста. Для этого сценария важно выбирать модели, доступные локально или в нейтральных юрисдикциях.
SMB и локальный бизнес в КР: небольшие команды, которые интегрируют готовые open-source решения (CMS, e-commerce, боты). Регулярно возникают обновления с security-патчами, которые никто не применяет месяцами. AI-ассистент, проверяющий конфиг и зависимости на известные CVE — минимальный барьер входа, максимальный защитный эффект.
Кейсы в личной жизни
Разработчик-фрилансер: берёшь легаси-проект клиента, просишь модель «найди потенциальные SQL-инъекции и покажи безопасные альтернативы». Получаешь разбор + рефакторинг. Это стандартная часть code review — именно тот сценарий, который сейчас под угрозой запрета в США.
Студент/начинающий разработчик: учишься писать безопасный код. Запрос «объясни, почему этот код уязвим к XSS и как его переписать» — лучший учебник, лучше любого курса. Если такие запросы будут блокироваться «защитными» фильтрами, обучение безопасному программированию деградирует.
Контент-мейкер / технический блогер: готовишь материал о кибербезопасности. AI помогает разобрать CVE, объяснить механику атаки для широкой аудитории, сформулировать рекомендации. Этот сценарий — образовательный, публичный, полезный. Он тоже попадает под размытую зону «capable of explaining exploits».
Как применить сегодня
- Используй формулировки defensive framing в запросах: «найди уязвимости в этом коде и предложи патч» работает лучше, чем абстрактные вопросы «как взламывают X».
- Для code security review тестируй опенсорс-альтернативы без экспортных ограничений — Qwen, локальные версии через Ollama — как резервный инструмент.
- Документируй свои AI security workflows как defensive use внутри компании — это важно для соответствия регуляторным требованиям в будущем.
- Следи за развитием темы через Kate Moussouris и Simon Willison — они дают самый технически точный комментарий без паники.
- Если работаешь в юрисдикции КР/СНГ — экспортные ограничения США тебя напрямую не касаются сейчас, но выбор инструментов стоит делать с прицелом на долгосрочную доступность модели.