Стандарт ETSI EN 304 223 задаёт базовые требования к безопасности ИИ, которые компании обязаны встроить в свои системы управления.
Сейчас организации всё глубже интегрируют машинное обучение в повседневные процессы, и этот европейский стандарт предлагает конкретные меры для защиты моделей и систем ИИ. Он стал первым в мире европейским документом по кибербезопасности ИИ с глобальным применением — национальные стандартизирующие органы дали ему официальное одобрение, что повышает его вес на международной арене.
Документ работает в паре с Законом ЕС об ИИ и учитывает особые уязвимости ИИ-систем, вроде отравления данных, запутывания модели или косвенной инъекции промптов, — риски, которые стандартные подходы к защите ПО не всегда покрывают. Стандарт распространяется на глубокие нейросети и генеративный ИИ вплоть до простых систем прогнозирования, но не касается случаев, когда ИИ используют исключительно для научных исследований в вузах.
Стандарт ETSI определяет ответственность за безопасность ИИ
Одна из главных сложностей при внедрении ИИ в компаниях — понять, кто именно отвечает за риски. ETSI решает эту задачу, выделяя три ключевые технические роли: разработчики, операторы систем и хранители данных.
В реальности эти роли часто пересекаются. Например, компания из финансового сектора, которая дообучает открытую модель для обнаружения мошенничества, выступает сразу разработчиком и оператором системы. Из-за этого на неё ложатся жёсткие обязательства: защитить инфраструктуру развёртывания, задокументировать источники обучающих данных и провести аудит конструкции модели.
Отдельная роль хранителей данных напрямую затрагивает главных офицеров по данным и аналитике. Они управляют доступом к данным и их целостностью, и теперь эта функция включает чёткие меры безопасности. Хранители должны проверять, чтобы назначение системы соответствовало уровню чувствительности данных, — по сути, они ставят барьер безопасности прямо в процессах работы с данными.
Стандарт ETSI подчёркивает: безопасность ИИ нельзя добавлять на финальном этапе. Уже на стадии проектирования компании проводят моделирование угроз, ориентированное на специфические атаки вроде вывода членства или запутывания модели.
Разработчики обязаны сужать возможности системы, чтобы минимизировать уязвимые места. Если модель многомодальная, но нужна только обработка текста, то модули для изображений или аудио становятся лишним риском — их нужно нейтрализовать. Это побуждает технических руководителей отказаться от привычки запускать огромные универсальные базовые модели там, где хватит компактной специализированной.
Документ требует строгого учёта активов. Разработчики и операторы систем ведут полный реестр компонентов с учётом их связей и подключений. Такой подход помогает выявлять теневой ИИ — модели, о которых ИТ-отделы даже не подозревают. Кроме того, стандарт предписывает разрабатывать планы восстановления после специфических атак на ИИ, чтобы при компрометации модели можно было вернуться к проверенному состоянию.
Безопасность цепочки поставок сразу создаёт напряжение для компаний, зависящих от внешних поставщиков или открытых репозиториев. Если оператор системы берёт модель или компонент без полной документации, ему приходится обосновывать выбор и фиксировать связанные риски.
На практике отделы закупок больше не могут брать "чёрные ящики". Разработчики предоставляют криптографические хэши для проверки подлинности компонентов моделей. Когда данные для обучения берут из открытых источников — обычная практика для больших языковых моделей, — разработчики указывают URL источника и время загрузки. Эта цепочка фиксации нужна для расследований после инцидентов, особенно чтобы отследить возможное отравление данных на этапе обучения.
Если компания предоставляет API внешним клиентам, она вводит меры против атак на ИИ: например, ограничение скорости запросов, чтобы затруднить обратный инжиниринг модели или перегрузку защит для внедрения отравленных данных.
Подход стандарта охватывает весь жизненный цикл. Крупные обновления, вроде переобучения на свежих данных, приравниваются к новому развёртыванию — с обязательным повторным тестированием безопасности.
Непрерывный мониторинг тоже формализован. Операторы систем разбирают логи не только на предмет работоспособности, но и на признаки дрейфа данных или постепенных сдвигов в поведении, которые могут сигнализировать о взломе. Так мониторинг ИИ превращается из метрики производительности в инструмент безопасности.
Стандарт касается и завершающей стадии. При выводе модели из эксплуатации или передаче третьим сторонам подключают хранителей данных для безопасного уничтожения информации и конфигураций. Это предотвращает утечки конфиденциальной интеллектуальной собственности или обучающих данных через забытые облачные инстансы или отбракованное оборудование.
Контроль со стороны руководства и управление
Чтобы соответствовать ETSI EN 304 223, компаниям придётся пересмотреть программы обучения по кибербезопасности. Обучение адаптируют под роли: разработчики изучают безопасный кодинг для ИИ, а обычные сотрудники узнают об угрозах вроде социальной инженерии через выводы ИИ.
"ETSI EN 304 223 — важный шаг к созданию единой надёжной основы для защиты систем ИИ", — отметил Скотт Кадзоу, председатель Технического комитета ETSI по защите искусственного интеллекта.
"В эпоху, когда ИИ всё шире входит в критическую инфраструктуру и услуги, чёткие практические рекомендации, учитывающие сложность технологий и реалии внедрения, бесценны. Эта рамка — плод масштабного сотрудничества, она даёт организациям уверенность в ИИ-системах, которые устойчивы, надёжны и безопасны с самого начала".
Внедрение базовых мер из стандарта ETSI помогает безопаснее развивать ИИ. Благодаря фиксации аудита, ясным ролям и прозрачности поставок компании снижают риски от ИИ, а заодно готовят крепкую позицию для будущих проверок регуляторов.
Вскоре выйдет технический отчёт ETSI TR 104 159, который применит эти принципы к генеративному ИИ, сосредоточившись на deepfakes и дезинформации.