11 сентября 2026 года в Евросоюзе начинают действовать первые обязательства по Cyber Resilience Act, а 11 декабря 2027-го регламент заработает в полном объеме. Для компаний, которые продают софт или устройства с цифровой начинкой на рынке ЕС, это плохая новость для любителей отговорки «код сгенерировал ИИ»: отвечать все равно придется людям и бизнесу.
Об этом пишет The New Stack в материале о том, как новый европейский режим меняет правила игры для разработки. Главная мысль предельно земная: регулятору неинтересно, кто именно написал уязвимый фрагмент, штатный разработчик или помощник на базе LLM. Если продукт попал на рынок с известной эксплуатируемой дырой, если инцидент не был вовремя раскрыт, если у компании нет доказуемого процесса secure by design, крайним будет производитель и его управленческая цепочка.
Самое неприятное для рынка в том, что Cyber Resilience Act задуман как горизонтальный регламент. Это не узкая история для критической инфраструктуры, оборонки или пары «особо опасных» отраслей. Речь идет почти о любых продуктах с цифровыми элементами, включая программное обеспечение и подключенные устройства, которые выводятся на рынок ЕС. И вот здесь AI-ассистенты попадают под прожектор не потому, что Брюссель отдельно ополчился на генеративный код, а потому что закон не делает скидку на происхождение кода. Написано человеком, подсказано Copilot-подобным инструментом, собрано полуавтоматически из промптов, регулятору все равно: безопасность, сопровождение и доказательная база должны быть у поставщика.
До формального дедлайна еще есть время, но оно уже не выглядит комфортным. С 11 сентября 2026 года производители должны сообщать об активно эксплуатируемых уязвимостях и тяжелых инцидентах безопасности. По правилам ЕС раннее уведомление подается в течение 24 часов после того, как компания узнала о проблеме, полное уведомление, в течение 72 часов. Для команд, где релизы идут непрерывно, а куски AI-сгенерированного кода разлетаются по репозиториям быстрее, чем их успевают осмысленно ревьюить, это означает не просто «добавить еще один чекбокс». Это означает построить трассируемость: от коммита и зависимости до инцидента, отчета, исправления и подтверждения, что проблему реально закрыли.
В статье The New Stack отдельно подчеркивается организационный сдвиг: кибербезопасность перестает быть заботой одной security-команды. У разработчиков и инженерного руководства появляется обязанность не только быстро поставлять фичи, но и показывать, что продукт создается с контролируемыми практиками безопасности. У product security, своя зона боли: обработка уязвимостей, disclosure-процессы, точность SBOM и соблюдение жестких сроков уведомления. У legal и compliance, собственная бюрократия, только уже в плохом смысле слова: сертификация, общение с регуляторами, формальные процедуры. А у топ-менеджмента, ответственность за бюджет, контроль и наличие аудиторского следа, который доказывает, что компания не играла в старый добрый «разберемся после релиза».
Именно поэтому тезис «ИИ ускоряет разработку» в европейской регуляторной реальности звучит уже не как безусловный плюс, а как источник нового долга. Чем больше кода команда производит с помощью моделей, тем выше риск, что внутрь продукта просочатся плохо понятые зависимости, шаблонные ошибки или просто фрагменты, которые никто по-настоящему не верифицировал. The New Stack формулирует это довольно жестко: организации все сильнее полагаются на автономные инструменты, которые умеют генерировать код быстрее, чем люди успевают его проверить и понять. Для CTO и VP Engineering это означает неприятный, но полезный возврат к дисциплине. Нельзя считать контролем безопасности сам факт, что код вообще компилируется и проходит happy-path тесты.
На практике регламент подталкивает компании к вещам, которые отрасль и так давно обещала себе «сделать со следующего квартала»: проверяемый secure-by-design процесс, регулярную верификацию кода, нормальный учет компонентов, понятную политику обработки уязвимостей и доказательства того, что все это не нарисовано в презентации для совета директоров. Для русскоязычной аудитории тут есть отдельный деловой смысл. Даже если команда сидит не в ЕС, регуляция касается не географии офиса, а доступа к европейскому рынку. SaaS, коробочный софт, IoT-устройства, встроенные компоненты, white-label-продукты, все это может внезапно оказаться в зоне действия CRA, если продается или поставляется в Европу.
Есть и более широкий эффект. Требования, которые сегодня выглядят как европейская специфика, завтра легко превращаются в стандарт закупки для крупных клиентов. Сначала compliance спрашивает, есть ли у вас процесс, SBOM и порядок раскрытия инцидентов. Потом это уже оказывается в тендере. Потом вендор без таких артефактов начинает выглядеть не «гибким», а просто рискованным. И вот тут появляется главный практический вывод из истории с AI-кодом: генеративные инструменты можно использовать сколько угодно активно, но только если компания заранее встроила в конвейер проверки, ревью, тестирование, управление зависимостями и аудит действий. Иначе выгода от ускорения быстро превращается в юридический и коммерческий риск.
Европейский регулятор, похоже, первым внятно оформил то, что рынок давно чувствовал на уровне интуиции: эпоха, когда AI можно было продавать как волшебного стажера без последствий для процесса, заканчивается. Вопрос теперь не в том, будет ли бизнес писать код с помощью моделей, а в том, кто сумеет доказать безопасность и управляемость этого процесса раньше, чем в дверь постучат с проверкой.