Сегодня компания Red Hat анонсировала asago — совместный проект с открытым исходным кодом, посвященный безопасности ИИ. Партнерами проекта стали Alquimia AI, Brave Software, коалиция EvalEval, IBM Research, Междисциплинарный университет трансформации (Австрия), Microsoft, MIT Lincoln Laboratory, Университет штата Северная Каролина, NVIDIA и Институт Алана Тьюринга. В этой статье я хотел бы подробнее рассказать о том, почему мы посчитали необходимым создание нового сообщества, чего мы стремимся достичь и каково текущее положение дел.
Экосистема безопасности ИИ с открытым исходным кодом весьма обширна. Существует множество отличных и зрелых проектов в таких областях, как защитные барьеры (guardrails), оценка (evals), red teaming и безопасность агентов, которые дополняются комплексными системами оценки рисков, онтологиями и классификациями. Это важные проекты, требующие дальнейшего развития. Наша команда по безопасности ИИ в Red Hat сотрудничает со многими из этих сообществ и вносит свой вклад в их работу, и мы продолжим это делать.
Дополнительные корпоративные проблемы в области безопасности ИИ
Однако, если посмотреть на типичную корпоративную организацию, можно увидеть, что она сталкивается с проблемами, выходящими за рамки этих инструментов. При изучении процесса внедрения нового, потенциально кастомного ИИ-агента обнаруживается множество заинтересованных сторон, активов и процессов, которые не охвачены существующими инструментами.
Внедрение нового агента обычно проходит по следующему пути:
- Разработка политики: команды создают письменные документы, определяющие правила использования ИИ в организации, часто ссылаясь на внешние нормативные акты, такие как EU AI Act, и иногда дополняя их ограничениями для конкретных сценариев использования (например, более строгие правила для агентов, взаимодействующих с клиентами).
- Выявление рисков: кто-то должен прочитать эти документы и определить, какие теоретические риски они содержат.
- Классификация рисков: из этих теоретических рисков кто-то должен решить, какие из них применимы к данному конкретному агенту, а какие являются техническими рисками, которые можно проверить на практике.
- Генерация сценариев и red teaming: технические команды должны разработать сценарии тестирования для этих рисков и прогнать их через существующие фреймворки red teaming.
- Итерация: результаты интерпретируются, применяются защитные барьеры или другие исправления, и агент повторно тестируется до тех пор, пока не будет готов к развертыванию. Если процесс выполняется вручную, это каждый раз создает значительные накладные расходы.
Этот процесс приводит к медленному согласованию и разрозненному аудиторскому следу, что затрудняет демонстрацию внутренним или внешним аудиторам того, что именно было сделано.
asago стремится решить эти проблемы совместными усилиями
Проект asago призван облегчить эту задачу. Мы хотим помочь организациям пройти путь от политик в области ИИ до промышленной эксплуатации, не требуя при этом глубоких знаний в области безопасности ИИ. Важно отметить, что наша цель — не заменить существующие инструменты безопасности ИИ, а выступить в качестве уровня оркестрации, объединяющего компоненты экосистемы. Мы будем интегрироваться с лучшими существующими инструментами и заполнять пробелы там, где их нет.
Конечно, это должен быть совместный процесс. Мы не считаем, что одна организация может или должна делать это в одиночку. Учитывая широкий спектр политических документов, типов моделей и агентов, контекстов развертывания, нормативных требований и многого другого, такой проект требует широкого круга мнений — разнообразие опыта здесь является обязательным условием.
Именно поэтому у нас есть отличные первоначальные партнеры, представляющие технологические компании, исследовательские институты, общественные коалиции и государственные организации. Вместе мы будем не только писать код, но и следить за тем, чтобы мы задавали правильные вопросы и находили на них ответы. Как глобальное сообщество, мы должны обеспечить достаточную лингвистическую и географическую представленность. Мы запускаемся с партнерами из США, Великобритании и Европы и настоятельно призываем других участников присоединиться к нам, чтобы расширить этот охват, перейдя по ссылкам ниже.
Развивающаяся техническая архитектура
Техническая архитектура будет развиваться вместе с проектом, но вот наш первоначальный взгляд. Процесс разделен на 2 части:
Рисунок 1: Синие узлы представляют данные. Желтые узлы представляют функциональные компоненты.
От документа политики к сценариям
В первой части риски извлекаются из документов политики и сопоставляются с IBM Risk Atlas. Эти риски, индексированные в карте рисков, представляют собой весь спектр теоретических рисков, затрагиваемых политикой. Некоторые из них будут техническими рисками, которые можно автоматизировать и устранить с помощью asago. Основным компонентом для этого является сопоставитель политик (policy mapper).
Следующая задача — создание правильного сценария для проведения red teaming. Это еще не привязано к конкретной библиотеке, но задача генератора сценариев — оценить специфику рассматриваемого агента в отношении выявленных рисков и определить, какие типы тестов и вспомогательного контекста необходимы. Они формируют сценарий. На этом этапе процесса у нас есть набор сценариев, которые можно оценить и использовать для защиты конкретного агента в контексте политик организации.
Рисунок 2: Синие узлы представляют данные. Желтые узлы представляют функциональные компоненты.
Итеративный путь от сценария к рекомендациям через red teaming
Во второй части, которая представляет собой итеративный цикл, мы берем эти сценарии и генерируем артефакты выполнения для соответствующих фреймворков red teaming и/или оценки. Именно здесь начинается подход, основанный на данных. Популярные фреймворки оценки и red teaming будут запускаться (на EvalHub) с использованием синтетически сгенерированных наборов данных и сред, соответствующих сценариям.
Результаты передаются в процесс рекомендаций для предоставления вариантов исправлений при сбоях в ходе red teaming. Мы предполагаем гибкий спектр рекомендаций, начиная с защитных барьеров, но, вероятно, развиваясь в сторону дополнительных компонентов по всему стеку. Важно, что эти компоненты будут пригодны для развертывания (например, с помощью пользовательских ресурсов Kubernetes (CR) или config maps) и повторного тестирования.
Важно отметить, что это лишь начальная архитектура. По мере развития сообщества эта архитектура будет развиваться вместе с ним.
Что вы можете сделать сегодня?
Хотя то, что мы анонсировали сегодня, подчеркивает дорожную карту и путь для сообщества, разработка идет активно, и вы уже можете начать экспериментировать с нашей работой. На GitHub asago вы уже можете ознакомиться с работой по сопоставлению политик here с примерами here. Вы также можете ознакомиться с midojo — фреймворком с открытым исходным кодом для тестирования безопасности ИИ-агентов на предмет непрямых инъекций промптов.
Наконец, вы и ваша организация можете присоединиться к нам в качестве соавторов. Нам нужен вклад многих организаций, особенно с представленностью разных языков, культур и географических регионов. Узнайте больше и примите участие here.
Наилучший результат для безопасности ИИ — это тот, который не контролируется ни одной компанией. asago — это наш вклад в эту цель, с инфраструктурой, созданной открыто сообществом с по-настоящему разнообразными взглядами. Проект находится на ранней стадии, и предстоит еще многое построить. И именно поэтому сейчас самое лучшее время, чтобы принять участие.
