Атаки на системы ИИ: разбираем обновлённый отчёт NIST
Друзья, возвращаюсь к вам после победы над ветрянкой😐 . Если кто-то не болел в детстве, мой совет вам — сделайте прививку. Взрослые болеют тяжко, поверьте на слово.
В последнее время в работе и на лекциях я часто сталкиваюсь с вопросами об атаках на модели ИИ. В связи с этим разберём небезызвестный документ NIST 100-2e2025 Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, который как раз недавно обновили.
Все системы ИИ в документе подразделяются на две группы: предиктивные и генеративные. Применительно к каждой из этих групп определяются свои векторы атак. Впрочем, есть масса схожестей, поэтому мы сразу остановимся на генеративных.
В зависимости от целей злоумышленника атаки подразделяются на несколько групп:
Атаки для нарушения доступности: злоумышленник пытается вмешаться в работу системы ИИ, чтобы помешать другим пользователям или процессам получать своевременный и постоянный доступ к её выходным результатам и другим функциональным возможностям.
Атаки для нарушения целостности: злоумышленник пытается вмешаться в работу системы ИИ, чтобы заставить её работать не по назначению и выдавать результаты, соответствующие его целям.
Атаки для нарушения приватности: злоумышленник стремится получить несанкционированный доступ к персональным данным или иной чувствительной информации — как через обучающие данные, веса, архитектуру модели, так и через иные базы знаний, например, если используется RAG.
Злоупотребления при работе с системой ИИ: злоумышленник старается обойти ограничения работы системы ИИ (например, системный промт, RLHF-подсказки).
Также атаки характерны для разных стадий жизненного цикла систем ИИ: разработки (причём могут различаться как для пре-, так и посттрейнинга) и эксплуатации.
В документе выделяются и основные векторы атак:
Отравление данных и моделей: злоумышленник может испортить данные или внедрить в них бэкдор (это может произойти на любом этапе жизненного цикла). Также в интернете могут распространяться заранее инфицированные модели ИИ (например, под видом известных брендов).
Прямые атаки через промт: злоумышленник напрямую взаимодействует с системой ИИ через запросы. Результатом этого может стать как обход ограничений модели, так и “вылавливание” фрагментов обучающих данных или получение информации об инфраструктуре системы.
Непрямые атаки через промт: в том случае, если система ИИ взаимодействует с интернетом или используется RAG, то злоумышленник может воздействовать на информацию, которая в дальнейшем поступает модели на вход.
Атаки внутри цепочки поставки: для систем ИИ характерны дополнительные риски относительно традиционного ПО. Например, для создания наборов данных используется массовый сбор информации из интернета, которая может быть заражена (причём может попадать и в сторонние наборы данных). Также дополнительные риски создаются на этапе посттрейнинга (помимо обучающих наборов данных могут быть инфицированы инструкции и наборы данных для дообучения).
Друзья, возвращаюсь к вам после победы над ветрянкой
В последнее время в работе и на лекциях я часто сталкиваюсь с вопросами об атаках на модели ИИ. В связи с этим разберём небезызвестный документ NIST 100-2e2025 Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, который как раз недавно обновили.
Все системы ИИ в документе подразделяются на две группы: предиктивные и генеративные. Применительно к каждой из этих групп определяются свои векторы атак. Впрочем, есть масса схожестей, поэтому мы сразу остановимся на генеративных.
В зависимости от целей злоумышленника атаки подразделяются на несколько групп:
Атаки для нарушения доступности: злоумышленник пытается вмешаться в работу системы ИИ, чтобы помешать другим пользователям или процессам получать своевременный и постоянный доступ к её выходным результатам и другим функциональным возможностям.
Атаки для нарушения целостности: злоумышленник пытается вмешаться в работу системы ИИ, чтобы заставить её работать не по назначению и выдавать результаты, соответствующие его целям.
Атаки для нарушения приватности: злоумышленник стремится получить несанкционированный доступ к персональным данным или иной чувствительной информации — как через обучающие данные, веса, архитектуру модели, так и через иные базы знаний, например, если используется RAG.
Злоупотребления при работе с системой ИИ: злоумышленник старается обойти ограничения работы системы ИИ (например, системный промт, RLHF-подсказки).
Также атаки характерны для разных стадий жизненного цикла систем ИИ: разработки (причём могут различаться как для пре-, так и посттрейнинга) и эксплуатации.
В документе выделяются и основные векторы атак:
Отравление данных и моделей: злоумышленник может испортить данные или внедрить в них бэкдор (это может произойти на любом этапе жизненного цикла). Также в интернете могут распространяться заранее инфицированные модели ИИ (например, под видом известных брендов).
Прямые атаки через промт: злоумышленник напрямую взаимодействует с системой ИИ через запросы. Результатом этого может стать как обход ограничений модели, так и “вылавливание” фрагментов обучающих данных или получение информации об инфраструктуре системы.
Непрямые атаки через промт: в том случае, если система ИИ взаимодействует с интернетом или используется RAG, то злоумышленник может воздействовать на информацию, которая в дальнейшем поступает модели на вход.
Атаки внутри цепочки поставки: для систем ИИ характерны дополнительные риски относительно традиционного ПО. Например, для создания наборов данных используется массовый сбор информации из интернета, которая может быть заражена (причём может попадать и в сторонние наборы данных). Также дополнительные риски создаются на этапе посттрейнинга (помимо обучающих наборов данных могут быть инфицированы инструкции и наборы данных для дообучения).
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5❤3
Британский добровольный кодекс практик и техническая спецификация ETSI по кибербезопасности в сфере ИИ
Продолжаем тему информационной безопасности. В начале года Правительство Великобритании опубликовало добровольный Кодекс практик по кибербезопасности в сфере ИИ. Документ основывается на лучших международных практиках и состоит из 13 ключевых принципов. Также можно изучить его имплементационный гайд.
Далее на его основе Европейский институт телекоммуникационных стандартов (ETSI) разработал техническую спецификацию, которая определяет базовые требования для кибербезопасности систем и моделей ИИ. Документ также включает глоссарий терминов и 13 принципов, которые в целом совпадают с Кодексом, однако сформулированы как более конкретные предписания, привязанные к стадиям жизненного цикла систем ИИ.
Кратко пройдемся по основным принципам:
Безопасное проектирование (Secure Design)
- Осведомлённость о рисках: организация внедряет обучение по ИИ-безопасности, адаптированное под роли сотрудников (включая разработчиков), с регулярным обновлением материала при появлении новых угроз.
- Проектирование с учётом безопасности: системы ИИ проектируются так, чтобы быть устойчивыми к атакам, неожиданным вводам и сбоям; все компоненты (модели, данные, промпты) документируются и подлежат аудиту, а внешние — проходят проверку и оценку рисков.
- Управление угрозами и рисками: проводится моделирование угроз, включающее разнообразные типы атак (их мы разбирали в предыдущем посте). Пользователям сообщаются о рисках и возможных последствиях.
- Ответственность человека: в систему закладываются механизмы по человеческому контролю. Запрещённые сценарии использования доводятся до пользователей.
Безопасная разработка (Secure Development)
- Учёт и защита активов: создаётся полный реестр моделей, данных и интерфейсов, с учётом их взаимосвязей между собой. Применяются контроль версий, средства защиты, механизмы восстановления, а также очистка и валидация данных.
- Безопасность инфраструктуры: ограничивается доступ к API, внедряется разделение сред (разработка, обучение), реализуются планы реагирования на инциденты и политики раскрытия уязвимостей. Контракты с провайдерами облачных услуг должны учитывать эти требования.
- Безопасность цепочек поставок: все сторонние компоненты (например, модели) проходят повторную проверку и оценку рисков, а информация о происхождении и ограничениях раскрывается пользователям.
- Документирование моделей и данных: разработчики должны документировать источники данных (включая URL и дату для публичных), цели и ограничения моделей, настройки и промпты, фиксировать изменения и публиковать хеш-суммы компонентов, чтобы обеспечить проверяемость и передачу этой информации операторам и администраторам данных.
- Тестирование и оценка: все системы ИИ должны проходить обязательное тестирование на безопасность до и после внедрения, по возможности — с участием независимых экспертов, включая проверку на утечки данных и уязвимости в выводах модели.
Безопасное внедрение (Secure Deployment)
- Коммуникация с пользователями и третьими лицами: операторы обязаны информировать пользователей о целях, способах и месте использования их данных, ограничениях системы и возможных рисках. Обновления доводятся до пользователей в доступной форме.
Безопасное обслуживание (Secure Maintenance)
- Обновления и патчи: разработчики выпускают обновления и патчи, а операторы обеспечивают их доставку конечным пользователям. При невозможности обновления — реализуются меры по снижению рисков. Крупные изменения требуют повторного тестирования.
- Мониторинг поведения: собираются и анализируются логи действий пользователей и системы для выявления атак, дрейфа модели и аномалий. По возможности анализируются внутренние состояния модели и её производительность во времени.
Безопасный вывод из эксплуатации (Secure End-of-Life)
- Утилизация моделей и данных: при передаче или выводе модели из эксплуатации удаляются веса, конфигурации и данные.
Продолжаем тему информационной безопасности. В начале года Правительство Великобритании опубликовало добровольный Кодекс практик по кибербезопасности в сфере ИИ. Документ основывается на лучших международных практиках и состоит из 13 ключевых принципов. Также можно изучить его имплементационный гайд.
Далее на его основе Европейский институт телекоммуникационных стандартов (ETSI) разработал техническую спецификацию, которая определяет базовые требования для кибербезопасности систем и моделей ИИ. Документ также включает глоссарий терминов и 13 принципов, которые в целом совпадают с Кодексом, однако сформулированы как более конкретные предписания, привязанные к стадиям жизненного цикла систем ИИ.
Кратко пройдемся по основным принципам:
Безопасное проектирование (Secure Design)
- Осведомлённость о рисках: организация внедряет обучение по ИИ-безопасности, адаптированное под роли сотрудников (включая разработчиков), с регулярным обновлением материала при появлении новых угроз.
- Проектирование с учётом безопасности: системы ИИ проектируются так, чтобы быть устойчивыми к атакам, неожиданным вводам и сбоям; все компоненты (модели, данные, промпты) документируются и подлежат аудиту, а внешние — проходят проверку и оценку рисков.
- Управление угрозами и рисками: проводится моделирование угроз, включающее разнообразные типы атак (их мы разбирали в предыдущем посте). Пользователям сообщаются о рисках и возможных последствиях.
- Ответственность человека: в систему закладываются механизмы по человеческому контролю. Запрещённые сценарии использования доводятся до пользователей.
Безопасная разработка (Secure Development)
- Учёт и защита активов: создаётся полный реестр моделей, данных и интерфейсов, с учётом их взаимосвязей между собой. Применяются контроль версий, средства защиты, механизмы восстановления, а также очистка и валидация данных.
- Безопасность инфраструктуры: ограничивается доступ к API, внедряется разделение сред (разработка, обучение), реализуются планы реагирования на инциденты и политики раскрытия уязвимостей. Контракты с провайдерами облачных услуг должны учитывать эти требования.
- Безопасность цепочек поставок: все сторонние компоненты (например, модели) проходят повторную проверку и оценку рисков, а информация о происхождении и ограничениях раскрывается пользователям.
- Документирование моделей и данных: разработчики должны документировать источники данных (включая URL и дату для публичных), цели и ограничения моделей, настройки и промпты, фиксировать изменения и публиковать хеш-суммы компонентов, чтобы обеспечить проверяемость и передачу этой информации операторам и администраторам данных.
- Тестирование и оценка: все системы ИИ должны проходить обязательное тестирование на безопасность до и после внедрения, по возможности — с участием независимых экспертов, включая проверку на утечки данных и уязвимости в выводах модели.
Безопасное внедрение (Secure Deployment)
- Коммуникация с пользователями и третьими лицами: операторы обязаны информировать пользователей о целях, способах и месте использования их данных, ограничениях системы и возможных рисках. Обновления доводятся до пользователей в доступной форме.
Безопасное обслуживание (Secure Maintenance)
- Обновления и патчи: разработчики выпускают обновления и патчи, а операторы обеспечивают их доставку конечным пользователям. При невозможности обновления — реализуются меры по снижению рисков. Крупные изменения требуют повторного тестирования.
- Мониторинг поведения: собираются и анализируются логи действий пользователей и системы для выявления атак, дрейфа модели и аномалий. По возможности анализируются внутренние состояния модели и её производительность во времени.
Безопасный вывод из эксплуатации (Secure End-of-Life)
- Утилизация моделей и данных: при передаче или выводе модели из эксплуатации удаляются веса, конфигурации и данные.
👍3🔥3❤2
В мае прошла первая очная встреча сообщества по AI Governance
Друзья, мы начали серию очных встреч для всех, кто профессионально связан с AI Governance или просто интересуется этой темой. Первая встреча прошла в мае — лично я участвовал онлайн, но именно мне случайно довелось сделать самую первую фотографию встречи (её прикрепляю).
Сейчас уже планируем новое мероприятие в конце лета. Пока что встречи проходят в Москве, но надеемся постепенно расшириться на другие страны и регионы.
Подробнее о сообществе и о том, как к нему присоединиться, можно узнать по ссылке.
Кроме того, мои друзья из RPPA в июле запускают второй поток программы Cyber in Privacy (а также провели мастер-класс про моделирования угроз безопасности персональных данных). Это не совсем про ИИ, но темы сильно пересекаются — будет полезно.
И, конечно, продолжается запись на третий поток курса по AI Governance — будем рады видеть вас там😺 .
Друзья, мы начали серию очных встреч для всех, кто профессионально связан с AI Governance или просто интересуется этой темой. Первая встреча прошла в мае — лично я участвовал онлайн, но именно мне случайно довелось сделать самую первую фотографию встречи (её прикрепляю).
Сейчас уже планируем новое мероприятие в конце лета. Пока что встречи проходят в Москве, но надеемся постепенно расшириться на другие страны и регионы.
Подробнее о сообществе и о том, как к нему присоединиться, можно узнать по ссылке.
Кроме того, мои друзья из RPPA в июле запускают второй поток программы Cyber in Privacy (а также провели мастер-класс про моделирования угроз безопасности персональных данных). Это не совсем про ИИ, но темы сильно пересекаются — будет полезно.
И, конечно, продолжается запись на третий поток курса по AI Governance — будем рады видеть вас там
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9
Смотрим интервью Сундара Пичаи у Лекса Фридмана
Что посмотреть на выходных? Рекомендую интервью CEO Google и Alphabet Сундара Пичаи у Лекса Фридмана — всего 2 часа (а не 5, как у Лекса бывает🐱 ).
Google в последнее время делает многое, чтобы вернуть лидерство в сфере ИИ у стартапов, так что разговор получился насыщенным. Кстати, сам замечаю, что NotebookLM и Gemini всё чаще занимают место в моём рабочем пайплайне.
Что посмотреть на выходных? Рекомендую интервью CEO Google и Alphabet Сундара Пичаи у Лекса Фридмана — всего 2 часа (а не 5, как у Лекса бывает
Google в последнее время делает многое, чтобы вернуть лидерство в сфере ИИ у стартапов, так что разговор получился насыщенным. Кстати, сам замечаю, что NotebookLM и Gemini всё чаще занимают место в моём рабочем пайплайне.
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Sundar Pichai: CEO of Google and Alphabet | Lex Fridman Podcast #471
Sundar Pichai is CEO of Google and Alphabet.
Thank you for listening ❤ Check out our sponsors: https://lexfridman.com/sponsors/ep471-sb
See below for timestamps, transcript, and to give feedback, submit questions, contact Lex, etc.
*Transcript:*
https:/…
Thank you for listening ❤ Check out our sponsors: https://lexfridman.com/sponsors/ep471-sb
See below for timestamps, transcript, and to give feedback, submit questions, contact Lex, etc.
*Transcript:*
https:/…
🔥4❤3
Разбираем китайский стандарт с методиками маркировки синтетического контента
Сегодня наконец-то дошли руки разобрать важный документ, которому, на мой взгляд, уделено неоправданно мало внимания. Также советую изучить картинки к посту — их будет много. Важные моменты я для вас выделил красным.
Итак, в конце февраля этого года китайский орган по стандартизации опубликовал обязательный стандарт, определяющий методы маркировки синтетического контента. Напомню, что ранее в КНР были приняты нормативные правовые акты, устанавливающие требования по маркировке для различных систем ИИ (генеративных систем ИИ, систем глубокого синтеза, рекомендательных алгоритмов). В частности, в марте Cyberspace Administration of China (CAC) приняла финальную версию Мер по маркировке синтетического контента. Таким образом, данный стандарт направлен на разъяснение требований этих мер в практической плоскости.
В данном стандарте на конкретных примерах объясняется, каким образом должны размещаться метки о том, что контент сгенерирован системой ИИ, для разных видов контента.
Всего стандартом определяются два вида маркировки: явная (эксплицитная) и неявная (имплицитная).
Начнем с явной маркировки:
- текст — текстовая вставка "сгенерировано ИИ" или надстрочные буквы “ИИ”;
- изображения — текстовая вставка "сгенерировано или синтезировано ИИ”;
- аудио — голосовая метка или звуковой ритм, размещённые в начале, середине или конце записи. Голосовая метка должна содержать сообщение “сгенерировано или синтезировано ИИ”, а звуковой ритм — последовательность “короткий — длинный — короткий — короткий”, что соответствует "ИИ” в азбуке Морзе;
- видео — текстовая вставка "сгенерировано или синтезировано ИИ”, расположенная на превью видео, в середине или в конце;
- виртуальные сцены — текстовая вставка “сгенерировано или синтезировано ИИ”, размещённая на начальном экране виртуальной сцены, а также в отдельных местах в ходе её демонстрации;
- при взаимодействии с человеком — текстовая вставка “сгенерировано или синтезировано ИИ”, размещённая рядом с текстом, позади текста или постоянно присутствующая в части интерфейса.
Неявная маркировка:
- метаданные — метки должны содержать сведения о генерации и синтезе ИИ, поставщике этой услуги, уникальном номере контента при создании, а также о поставщике и идентификаторе при распространении;
- маркировка в контенте — вотермарки и иные цифровые идентификаторы.
Документ начнет действовать с 1 сентября 2025 года.
Оригинал документа можно найти по ссылке.
Также в одном из блогов опубликован неофициальный перевод на английский.
Сегодня наконец-то дошли руки разобрать важный документ, которому, на мой взгляд, уделено неоправданно мало внимания. Также советую изучить картинки к посту — их будет много. Важные моменты я для вас выделил красным.
Итак, в конце февраля этого года китайский орган по стандартизации опубликовал обязательный стандарт, определяющий методы маркировки синтетического контента. Напомню, что ранее в КНР были приняты нормативные правовые акты, устанавливающие требования по маркировке для различных систем ИИ (генеративных систем ИИ, систем глубокого синтеза, рекомендательных алгоритмов). В частности, в марте Cyberspace Administration of China (CAC) приняла финальную версию Мер по маркировке синтетического контента. Таким образом, данный стандарт направлен на разъяснение требований этих мер в практической плоскости.
В данном стандарте на конкретных примерах объясняется, каким образом должны размещаться метки о том, что контент сгенерирован системой ИИ, для разных видов контента.
Всего стандартом определяются два вида маркировки: явная (эксплицитная) и неявная (имплицитная).
Начнем с явной маркировки:
- текст — текстовая вставка "сгенерировано ИИ" или надстрочные буквы “ИИ”;
- изображения — текстовая вставка "сгенерировано или синтезировано ИИ”;
- аудио — голосовая метка или звуковой ритм, размещённые в начале, середине или конце записи. Голосовая метка должна содержать сообщение “сгенерировано или синтезировано ИИ”, а звуковой ритм — последовательность “короткий — длинный — короткий — короткий”, что соответствует "ИИ” в азбуке Морзе;
- видео — текстовая вставка "сгенерировано или синтезировано ИИ”, расположенная на превью видео, в середине или в конце;
- виртуальные сцены — текстовая вставка “сгенерировано или синтезировано ИИ”, размещённая на начальном экране виртуальной сцены, а также в отдельных местах в ходе её демонстрации;
- при взаимодействии с человеком — текстовая вставка “сгенерировано или синтезировано ИИ”, размещённая рядом с текстом, позади текста или постоянно присутствующая в части интерфейса.
Неявная маркировка:
- метаданные — метки должны содержать сведения о генерации и синтезе ИИ, поставщике этой услуги, уникальном номере контента при создании, а также о поставщике и идентификаторе при распространении;
- маркировка в контенте — вотермарки и иные цифровые идентификаторы.
Документ начнет действовать с 1 сентября 2025 года.
Оригинал документа можно найти по ссылке.
Также в одном из блогов опубликован неофициальный перевод на английский.
🔥7❤2👍1
Подпадают ли ИИ-агенты под Регламент ЕС по ИИ?
Именно таким вопросом задались исследователи из The Future Society в своей статье Ahead of the Curve: Governing AI Agents under the EU AI Act. Давайте разберемся в их основных выводах (будет много Регламента).
- Поставщики моделей ИИ, которые лежат в основе ИИ-агентов, будут подпадать под Регламент ЕС в части требований, предъявляемых к поставщикам моделей ИИ общего назначения (глава V Регламента).
Также авторы считают, что большинство таких моделей также будут относиться к моделям ИИ, представляющим системные риски, что налагает повышенные обязательства на их поставщиков. Также по большей части ИИ-агенты будут квалифицироваться как системы ИИ общего назначения.
Однако открытым вопросом является отнесение ИИ-агентов к системам ИИ повышенного риска. Так, авторы считают, что всё будет зависеть от конкретных юзкейсов, а также от того, ограничил ли поставщик такого ИИ-агента потенциальные сценарии его использования, которые можно было бы отнести к повышенному риску. Также авторы отмечают, что Регламент создавался, когда тренды создания ИИ-агентов не были очевидны, поэтому их распространение может потребовать донастройки регуляторных подходов (в том числе в плане классификации систем и моделей ИИ, а также круга запрещенных практик и систем ИИ повышенного риска).
Странно, что авторы никак не затронули требования по прозрачности (глава IV Регламента), хотя во многих местах отмечается, что способность взаимодействия с физической средой как раз отличает ИИ-агентов🐱 .
- ИИ-агенты также потенциально будут отличаться и по взаимоотношению между субъектами внутри цепочек поставок. Так, авторы отмечают, что по-прежнему сохранится дисбаланс между поставщиками моделей и поставщиками и эксплуатантами систем, так как первые по-прежнему будут обладать моделями и инфраструктурой, на которой они развернуты, включая лучшие кадры. Однако также очевидно, что цепочки поставок ИИ-агентов будут более многослойными и включать большее число последующих поставщиков. Усложнение отношений между ними должно повлечь и увеличение внимания со стороны законодателей.
- Также авторы проанализировали литературу и составили таблицу, в которой они попытались адаптировать требования Регламента к поставщикам моделей ИИ, представляющих системные риски, поставщикам и эксплуатантам систем ИИ повышенного риска применительно к специфике ИИ-агентов.
Саму таблицу вместе с другими полезными материалам я вам прикладываю в скриншотах.
Именно таким вопросом задались исследователи из The Future Society в своей статье Ahead of the Curve: Governing AI Agents under the EU AI Act. Давайте разберемся в их основных выводах (будет много Регламента).
- Поставщики моделей ИИ, которые лежат в основе ИИ-агентов, будут подпадать под Регламент ЕС в части требований, предъявляемых к поставщикам моделей ИИ общего назначения (глава V Регламента).
Также авторы считают, что большинство таких моделей также будут относиться к моделям ИИ, представляющим системные риски, что налагает повышенные обязательства на их поставщиков. Также по большей части ИИ-агенты будут квалифицироваться как системы ИИ общего назначения.
Однако открытым вопросом является отнесение ИИ-агентов к системам ИИ повышенного риска. Так, авторы считают, что всё будет зависеть от конкретных юзкейсов, а также от того, ограничил ли поставщик такого ИИ-агента потенциальные сценарии его использования, которые можно было бы отнести к повышенному риску. Также авторы отмечают, что Регламент создавался, когда тренды создания ИИ-агентов не были очевидны, поэтому их распространение может потребовать донастройки регуляторных подходов (в том числе в плане классификации систем и моделей ИИ, а также круга запрещенных практик и систем ИИ повышенного риска).
Странно, что авторы никак не затронули требования по прозрачности (глава IV Регламента), хотя во многих местах отмечается, что способность взаимодействия с физической средой как раз отличает ИИ-агентов
- ИИ-агенты также потенциально будут отличаться и по взаимоотношению между субъектами внутри цепочек поставок. Так, авторы отмечают, что по-прежнему сохранится дисбаланс между поставщиками моделей и поставщиками и эксплуатантами систем, так как первые по-прежнему будут обладать моделями и инфраструктурой, на которой они развернуты, включая лучшие кадры. Однако также очевидно, что цепочки поставок ИИ-агентов будут более многослойными и включать большее число последующих поставщиков. Усложнение отношений между ними должно повлечь и увеличение внимания со стороны законодателей.
- Также авторы проанализировали литературу и составили таблицу, в которой они попытались адаптировать требования Регламента к поставщикам моделей ИИ, представляющих системные риски, поставщикам и эксплуатантам систем ИИ повышенного риска применительно к специфике ИИ-агентов.
Саму таблицу вместе с другими полезными материалам я вам прикладываю в скриншотах.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7👍3
Изучаем китайские стандарты по кибербезопасности в сфере ИИ
Делюсь с вами ещё одной порцией важных документов из Китая. К сожалению, не все из них переведены даже на английский. Но мы разберёмся👀 . Так вот, Комитет по стандартизации в сфере информационной безопасности TC260 утвердил весной после публичных обсуждений несколько обязательных стандартов:
Базовые требования безопасности для сервисов генеративного ИИ (есть перевод на английский проекта стандарта)
Документ устанавливает общие требования для всех стадий жизненного цикла систем ИИ, которые должны выполнять все поставщики. Требований довольно много, включая обширные аспекты из менеджмента информационной безопасности, качества, данных. Во многом он является общим и для других двух стандартов, которые направлены на отдельные стадии жизненного цикла.
Из интересного:
- все наборы данных должны проверяться, допускается только не более 5% противоправного и незаконно полученного контента;
- модель должна обеспечивать корректные, безопасные, соответствующие социалистическим ценностям ответы;
- системы ИИ должны демонстрировать для несовершеннолетних контент, направленный на их физическое и психологическое здоровье;
- система должна принимать меры по предотвращению повторного ввода противоправных запросов. Например, пользователя нужно банить, если он ввёл три раза подряд или пять раз за день нарушающий закон или вредный промт;
- число ключевых слов для отбора контента должно быть не менее 10 тыс., причём не менее 100 на каждый из обозначенных в документе рисков;
- поставщики должны создать банк из примерных вопросов для системы ИИ из не менее чем 2000 фраз. При этом не менее 500 из них должны входить в банк запрещённых вопросов. Сюда включены и национальная безопасность, и имидж государства. Мы все с вами помним, на какие вопросы отказывается отвечать DeepSeek. Вот вам и подробное нормативное объяснение, каким образом это работает.
Спецификация по безопасности для аннотирования данных для генеративного ИИ
Из интересного:
- сотрудники, осуществляющие аннотирование данных, должны быть обучены, а их роли чётко распределены, чтобы избегать негативных последствий. Безопасность рабочих мест должна быть обеспечена как с точки зрения информационной безопасности, так и физической;
- на всех этапах аннотирования должно быть обеспечено логирование и отслеживание всех действий и вовлечённых субъектов;
- не менее 3% данных должны быть размечены с целью безопасности. При этом если при проверке окажется, что более 5% данных с такой аннотацией некорректны или содержат опасные элементы, вся партия подлежит аннулированию и переразметке;
- стандарт содержит образцы правильных и неправильных аннотаций, чтобы исключить двусмысленную интерпретацию (например, как корректно отклонять запросы, связанные с нарушением закона).
Спецификация по безопасности для предварительного обучения и дообучения генеративного ИИ
Из интересного:
- стандарт предусматривает выборочную проверку данных на соответствие законодательным требованиям, включая случайную ручную выборку не менее 10% записей для проверки источников данных на наличие незаконной и нежелательной информации во время сбора. Однако это относится к проверке источников данных, а не ко всему объёму данных обучения в целом. При этом установлено, что если в выборке доля незаконной или нежелательной информации превышает 5%, источник данных подлежит исключению;
- если в партии данных содержится информация из зарубежных источников, то в неё должна быть добавлена ещё и разумная доля отечественных;
- необходимо проводить фильтрацию и оценку данных на предмет наличия отравленных данных.
Документы начнут действовать 1 ноября 2025 года.
Делюсь с вами ещё одной порцией важных документов из Китая. К сожалению, не все из них переведены даже на английский. Но мы разберёмся
Базовые требования безопасности для сервисов генеративного ИИ (есть перевод на английский проекта стандарта)
Документ устанавливает общие требования для всех стадий жизненного цикла систем ИИ, которые должны выполнять все поставщики. Требований довольно много, включая обширные аспекты из менеджмента информационной безопасности, качества, данных. Во многом он является общим и для других двух стандартов, которые направлены на отдельные стадии жизненного цикла.
Из интересного:
- все наборы данных должны проверяться, допускается только не более 5% противоправного и незаконно полученного контента;
- модель должна обеспечивать корректные, безопасные, соответствующие социалистическим ценностям ответы;
- системы ИИ должны демонстрировать для несовершеннолетних контент, направленный на их физическое и психологическое здоровье;
- система должна принимать меры по предотвращению повторного ввода противоправных запросов. Например, пользователя нужно банить, если он ввёл три раза подряд или пять раз за день нарушающий закон или вредный промт;
- число ключевых слов для отбора контента должно быть не менее 10 тыс., причём не менее 100 на каждый из обозначенных в документе рисков;
- поставщики должны создать банк из примерных вопросов для системы ИИ из не менее чем 2000 фраз. При этом не менее 500 из них должны входить в банк запрещённых вопросов. Сюда включены и национальная безопасность, и имидж государства. Мы все с вами помним, на какие вопросы отказывается отвечать DeepSeek. Вот вам и подробное нормативное объяснение, каким образом это работает.
Спецификация по безопасности для аннотирования данных для генеративного ИИ
Из интересного:
- сотрудники, осуществляющие аннотирование данных, должны быть обучены, а их роли чётко распределены, чтобы избегать негативных последствий. Безопасность рабочих мест должна быть обеспечена как с точки зрения информационной безопасности, так и физической;
- на всех этапах аннотирования должно быть обеспечено логирование и отслеживание всех действий и вовлечённых субъектов;
- не менее 3% данных должны быть размечены с целью безопасности. При этом если при проверке окажется, что более 5% данных с такой аннотацией некорректны или содержат опасные элементы, вся партия подлежит аннулированию и переразметке;
- стандарт содержит образцы правильных и неправильных аннотаций, чтобы исключить двусмысленную интерпретацию (например, как корректно отклонять запросы, связанные с нарушением закона).
Спецификация по безопасности для предварительного обучения и дообучения генеративного ИИ
Из интересного:
- стандарт предусматривает выборочную проверку данных на соответствие законодательным требованиям, включая случайную ручную выборку не менее 10% записей для проверки источников данных на наличие незаконной и нежелательной информации во время сбора. Однако это относится к проверке источников данных, а не ко всему объёму данных обучения в целом. При этом установлено, что если в выборке доля незаконной или нежелательной информации превышает 5%, источник данных подлежит исключению;
- если в партии данных содержится информация из зарубежных источников, то в неё должна быть добавлена ещё и разумная доля отечественных;
- необходимо проводить фильтрацию и оценку данных на предмет наличия отравленных данных.
Документы начнут действовать 1 ноября 2025 года.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6