Многие предприятия воспринимают Закон ЕС об искусственном интеллекте (EU AI Act) как формальность для проверки соответствия. Поставил галочку и пошел дальше. Но статья 4 вступила в силу 2 августа 2026 года: знает ли ваша техническая команда об уязвимостях ИИ и классах атак? Способны ли они распознать эти атаки?
Закон ЕС об ИИ ставит перед вашей командой две задачи: действительно ли ваши сотрудники понимают угрозы ИИ (статья 4) и способна ли ваша система ИИ высокого риска противостоять им (статья 15)? Это вопросы квалификации, а квалификация формируется, а не декларируется. Политика задает направление. Реальная работа заключается в том, чтобы команда и система могли сделать то, что обещает эта политика.
Статья 15 вступает в силу 2 декабря 2027 года. Штрафы реальны: до 15 млн евро или 3% за несоответствие систем высокого риска требованиям статей 9–15. (Наивысший уровень — до 35 млн евро или 7% — применяется только к запрещенным практикам использования ИИ, таким как социальный скоринг, а не к обязательствам в отношении систем высокого риска, с которыми сталкивается большинство предприятий.) Но существует скрытая цена, которая гораздо выше штрафов. Если ваша команда не понимает уязвимости и атаки, которым нужно противостоять, каждая создаваемая ими система ИИ привносит этот пробел в промышленную эксплуатацию. Вот о влиянии Закона ЕС об ИИ вы узнаете из этого блога:
- Статья 4 (грамотность в сфере ИИ) имеет обязательную силу с 2 августа 2026 года. Вашей команде нужны знания об угрозах, специфичных для ИИ, а не просто общие концепции ИИ.
- Статья 15 требует, чтобы ИИ высокого риска противостоял пяти названным типам атак (отравление данных, отравление моделей, состязательные примеры, атаки на конфиденциальность, изъяны моделей) к 2 декабря 2027 года.
- Чек-листы и обучение на слайдах не развивают навыки. 25 интервью с покупателями подтверждают, что командам необходима практическая работа для распознавания угроз ИИ и реагирования на них.
- Практические лабораторные работы в песочнице формируют то, что нужно вашим техническим командам: способность выявлять уязвимости, проявлять здравый смысл, проверять результаты работы ИИ и вырабатывать привычки операционной безопасности.
- Отслеживаемые записи о прохождении практических лабораторий служат доказательством прохождения обучения по грамотности в сфере ИИ в рамках требования статьи 4 о «принятии мер».
Чего Закон на самом деле требует от вашей команды
Три статьи напрямую затрагивают технические команды.
Статья 4: Грамотность в сфере ИИ (уже действует)
- Вашей команде нужны знания об угрозах, специфичных для ИИ, а не просто общие концепции ИИ. Разработчики и специалисты по безопасности должны понимать инъекции промптов, отравление данных и избыточную автономность (excessive agency).
- Это применимо ко всем системам ИИ, а не только к системам высокого риска. Требование о грамотности распространяется даже на сценарии использования ИИ, не относящиеся к высокому риску.
- Это работает прямо сейчас. Имеет обязательную силу со 2 августа 2026 года. Это не декор в будущем.
- Это обязательство по принятию мер, а не по достижению результата. Вам не нужно доказывать определенный уровень компетентности, но вы должны показать, что предприняли реальные меры.
«Принять меры» — ключевая фраза. Презентация, которую никто не помнит, — это мера только на бумаге. Считает ли регулятор ее значимой мерой — другой вопрос.
Статья 15: Кибербезопасность (крайний срок — 2 декабря 2027 года)
- Ваш ИИ должен противостоять пяти названным типам атак: отравление данных, отравление моделей, состязательные примеры, атаки на конфиденциальность и изъяны моделей.
- Это охватывает все приложение целиком, а не только модель. API, аутентификация, средства контроля доступа и бизнес-логика — все это входит в область применения.
- Обучение является организационной мерой согласно статье 15(4). Закон прямо требует «технических и организационных мер» для обеспечения устойчивости. Обучение может быть одной из таких мер.
Но обучение, которое не формирует реальных навыков, является мерой только на словах.
Статья 14: Надзор со стороны человека (крайний срок — 2 декабря 2027 года)
- Ваши операторы должны понимать сценарии сбоев ИИ достаточно хорошо, чтобы иметь возможность вмешаться.
- Кто-то в вашей команде должен знать, как выглядит эффективный надзор за системами ИИ.
Вы не можете разработать эффективный человеческий надзор, если люди не понимают, как ИИ может дать сбой. Это близко к обучению, хотя и не является прямым требованием об обучении, но пробел в навыках здесь тот же самый.
Почему одни только чек-листы не работают
Вот что покупатели рассказали нам в ходе 25 исследовательских интервью об обучении безопасности ИИ:
- Абстрактные предупреждения не меняют поведения. Обучение приносит пользу, когда оно объясняет конкретный ущерб, который могут нанести сотрудники (например, утечка многолетних исследований), а не просто предупреждает об утечке данных.
- Знание о существовании политики не означает ее соблюдения. Сотрудники экспериментируют с запрещенными инструментами ИИ вопреки существующим правилам.
- Эту проблему нельзя решить заучиванием наизусть. Безопасность ИИ требует принятия решений в условиях неопределенности. Риски должны быть снижены, а не полностью исключены. Фиксированного чек-листа самого по себе недостаточно.
- Отсутствует базовое понимание. Одна команда начала внедрение LLM с минимальным обучением и сильно полагалась на одного знающего коллегу. Позже они задумались о том, изменило ли бы лучшее понимание их решения при внедрении.
Шаблон знаком. Команды знают, что им нужно что-то делать. Они пишут политику. В политике написано: «не делайте X». Люди все равно делают X, потому что не понимают, почему X опасен. Чек-лист рассматривает безопасность ИИ как правило, которому нужно следовать. На самом деле это навык, который нужно развивать.
Что должна уметь делать ваша команда
Судя по отзывам покупателей, техническим командам необходимы шесть навыков:
- Грамотность в области архитектуры ИИ и потоков данных. Понимание того, куда перемещается информация, как долго она хранится, используют ли ее провайдеры для обучения.
- Оценка угроз, специфичных для ИИ. Распознавание промпт-инъекций, отравления обучающих данных, галлюцинаций и дрейфа моделей. Тестирование на обход ограничений (jailbreak) и несанкционированное раскрытие информации.
- Идентичность агентов, разрешения и безопасность API. Применение принципа наименьших привилегий, различие между правами чтения и обновления/удаления, создание цепочек согласования, обнаружение повышения привилегий.
- Мониторинг и реагирование на инциденты. Захват промптов и активности инструментов, расследование инцидентов, связанных с ИИ, выявление теневого ИИ, интеграция телеметрии с существующими операциями безопасности.
- Критическая проверка результатов работы ИИ. Проверка выводов, а не слепое доверие к их надежности, отделение реальных проблем от ложных срабатываний, тщательный анализ сгенерированного кода.
- Использование ИИ в целях защиты при сохранении контроля. Практическое владение защитными агентами, проверка сводок инцидентов, тщательный анализ обнаружений, сгенерированных ИИ.
Обратите внимание на то, чего нет в этом списке: «прочитать политику». Ни один из этих навыков не приобретается с помощью презентации. Они приобретаются в процессе практики.
Почему практические занятия устраняют пробел в соблюдении Закона ЕС об ИИ
Знать об угрозах ИИ — не значит уметь реагировать на них.
Одна организация экспериментирует с локальной LLM, используя данные операционной безопасности для развития навыков промптинга, настройки и использования данных без передачи этой информации сервисам публичного облака. Они учатся посредством практических экспериментов в рамках контролируемых границ данных.
Другая организация описывает ограниченное внутреннее тестирование приложений RAG перед их публичным выпуском. Участники пытались взломать системы, и тестировщики с навыками безопасности получали несанкционированную информацию с относительно небольшими усилиями. Практическая ценность заключалась в обнаружении реальных уязвимостей в их собственных реализациях, а не просто в изучении терминологии угроз.
Общая закономерность этих интервью: команды узнают гораздо больше, пытаясь взломать систему ИИ, чем читая о том, как это можно сделать. Контролируемые эксперименты, состязательное тестирование и «песочницы» — это то, где формируются реальные возможности.
Именно здесь на помощь приходят практические лаборатории. Veracode SecLabs OWASP LLM Labs предоставляют командам «песочницу» для отработки навыков выявления и нейтрализации специфических угроз ИИ: инъекций промптов, отравления данных, чрезмерной автономности агентов, раскрытия конфиденциальной информации и других. Лабораторные работы соответствуют списку OWASP GenAI LLM Top 10 2026 и тем же классам атак, которые упоминаются в Статье 15. Команды тренируются в безопасной среде, прежде чем столкнуться с этими угрозами в промышленной эксплуатации.
Что дает практическое обучение для соблюдения EU AI Act
Покупатели отмечают явный разрыв между знанием названия угрозы и способностью что-то с ней сделать. В самом наглядном примере из нашего исследования, связанном с ИИ, команда открыла внутреннюю реализацию RAG для ограниченной группы тестировщиков и поощряла состязательное исследование. Тестировщики, осведомленные в вопросах безопасности, без особого труда обошли ограничения и извлекли избыточные данные. Это выявило наблюдаемую слабость в реализации, а не просто осознание того, что существуют джейлбрейки или утечки данных.
Это различие важно для соблюдения нормативных требований. Статья 15 не спрашивает, может ли ваша команда назвать «отравление данных». Она спрашивает, может ли ваш ИИ противостоять ему. Команда, которая только читала об отравлении данных, не сможет сказать, уязвима ли их собственная система. Команда, которая пыталась отравить модель в «песочнице», — сможет.
Четыре ценности, которые дает практическая работа
- Способность обнаружить слабость в работающей системе. Тестировщики, осведомленные в вопросах безопасности, без особого труда извлекли неавторизованную информацию из RAG-приложения, обнаружив реальные уязвимости в собственной реализации. Статья 15 требует, чтобы ваш ИИ сопротивлялся атакам. Вы не можете знать, сопротивляется ли он им, если никто в вашей команде не пытался его взломать.
- Суждение в условиях непредсказуемого поведения. Тестирование ИИ фундаментально отличается от проверки фиксированных рабочих процессов. Ответы и пути принятия решений динамичны. Одно лишь знание контрольных списков не доказывает, что человек может исследовать неожиданное поведение. Статья 14 требует эффективного человеческого надзора. Надзор означает суждение, а суждение приходит с практикой, а не с заучиванием.
- Способность проверять, а не слепо принимать результаты работы ИИ. Команды, использующие ИИ для анализа уязвимостей, все равно тратят время на проверку результатов, отделяя полезные выводы от ненадежных данных. Практические упражнения позволяют отрепетировать эту работу по валидации. Статья 4 требует ИИ-грамотности. Грамотность означает понимание того, когда ИИ ошибается, а не просто знание того, что он делает.
- Операционные привычки для безопасной разработки. Один из покупателей выявил отсутствие отработанной дисциплины между созданием прототипа на базе ИИ и его подготовкой к промышленной эксплуатации через проверку безопасности. Статья 15(4) требует «технических и организационных мер». Отработанные привычки в области безопасности — это организационная мера. Обучение, которое не формирует привычки, — это мера только на бумаге.
Почему «песочница» имеет значение
«Песочница» делает ошибки поучительными, не превращая их в инциденты в промышленной среде. Организации хотят, чтобы разработчики сохраняли свободу тестирования и развертывания, защищая при этом организацию в целом. В интервью по обучению пользователи ценили реалистичные среды для практики, потому что они могли экспериментировать, не повреждая реальные кейсы. Один из них прямо предпочел сценарии-симуляции, где ошибки не влияют на реальную работу с клиентами.
Это напрямую связано с Актом. Ваша команда должна понимать, как ИИ дает сбои, прежде чем это произойдет в промышленной среде. «Песочница» — это место, где формируется такое понимание. Это разница между командой, которая видела слайд об инъекции промптов, и командой, которая пыталась внедрить промпт, увидела, что это работает, и поняла, что именно заставляет это работать.
Аудиторский след
И еще кое-что, о чем нам постоянно говорят в компаниях: доказательства лучше абстрактных заверений. Внутреннее тестирование ИИ выявило непреднамеренное раскрытие данных. Обнаружение ранее неизвестных брешей во время оценок вызывает большой интерес к покупке. Обратная связь по обучению безопасности отдает предпочтение конкретным последствиям: объяснение того, что утечка может скомпрометировать годы исследований, находит больший отклик, чем общие предупреждения об утечке данных.
Для EU AI Act это соотносится с требованием Статьи 4 «принимать меры». Отслеживаемые записи о прохождении практических лабораторных работ показывают, какие меры вы приняли, кто их принял и что именно они отрабатывали. Это другой тип доказательств, нежели подписанное подтверждение политики. Это демонстрирует возможности, а не просто соответствие требованиям.
Заключение
EU AI Act просит технические команды сделать нечто ценное: превратить безопасность из галочки в чек-листе соответствия в ключевую часть процесса создания ИИ-систем. Статья 4 хочет, чтобы ваша команда искренне понимала угрозы ИИ. Статья 15 хочет, чтобы ваш ИИ сопротивлялся им. Статья 14 хочет, чтобы люди могли эффективно контролировать ИИ. Все три пункта указывают на одно и то же: дайте своей команде практическое понимание того, как работают уязвимости ИИ.
Команды, которые преуспеют в рамках этого Акта, — это те, чьи разработчики практиковались в выявлении инъекций промптов, пытались отравить модель в «песочнице» и перенесли это понимание в код, который они пишут. Политики задают направление. Практика создает возможности.
SecLabs OWASP LLM Top 10 предоставляет вашим командам такую практику. Практические лаборатории соответствуют классам атак, упомянутым в Статье 15 EU AI Act. Начните свою первую лабораторную работу бесплатно, заполните форму прямо сейчас!
Юридическое уведомление
Информация, представленная в этой статье, предназначена только для общих информационных и образовательных целей. Она не является юридической консультацией и не должна рассматриваться как таковая. Регуляторные требования и требования соответствия варьируются в зависимости от организации, юрисдикции и контекста. Организациям следует проконсультироваться с квалифицированными юристами и специалистами по комплаенсу, чтобы понять и выполнить свои специфические регуляторные обязательства. Veracode не делает никаких заявлений и не дает никаких гарантий относительно полноты, точности или применимости информации, содержащейся в этом посте. Регуляторные базы, обсуждаемые в этой статье, могут быть изменены; читателям следует обращаться к официальным регулирующим органам и юридическим ресурсам для получения самых актуальных требований.
