asago のご紹介：オープンソースの AI の安全性とガバナンスのオーケストレーション

本日、Red Hat は、Alquimia AI、Brave Software、EvalEval連合、IBM Research、オーストリア学際変革大学、マイクロソフト、MITリンカーン研究所、ノースカロライナ州立大学、NVIDIA、およびアラン・チューリング研究所と提携し、共同のオープンソース AI 安全性プロジェクトである asago を発表しました。このブログ記事では、Red Hat が新しいコミュニティが必要であると考えた理由、達成を目指している目標、および現在の状況について、詳しく説明します。

オープンソース AI の安全性のエコシステムは充実しています。ガードレール、評価手法、レッドチーム活動、エージェント型セキュリティといった分野には、優れた成熟したプロジェクトが数多く存在し、それらを包括的なリスクフレームワーク、オントロジー、マッピングが補完しています。これらは、継続的な開発が必要な重要なプロジェクトです。Red Hat では、当社の AI 安全性チームがこうした多くのアップストリームコミュニティと協力し、貢献しており、今後もその姿勢を継続していきます。

AI の安全性に関する企業のさらなる課題

しかし、一般的な企業組織では、これらのツール以外にもさらなる課題を抱えています。新しい (場合によってはカスタム構築された) AI エージェントを導入するプロセスを検討すると、既存のツールでは対応できない、より広範なステークホルダー、資産、プロセスが存在することがわかります。

新しいエージェントの導入は、通常、次のような流れで進められます。

• ポリシーの策定：チームは、組織の AI に関する推奨事項と禁止事項を規定したポリシー文書を作成します。これらは多くの場合、EU AI 法などの外部規制を参照し、ユースケース固有の制約 (顧客対応エージェント向けのより厳格なルールなど) によって補完されます。
• リスクの抽出：誰かがこれらの文書を読み込み、そこに含まれる理論上のリスクを特定する必要があります。
• リスクの優先順位付け：これらの理論的リスクのうち、特定のエージェントに該当するものはどれか、実際にテスト可能な技術的リスクはどれかを判断する必要があります。
• シナリオの生成とレッドチーミング：技術チームは、それらのリスクに対するテストシナリオを構築し、既存のレッドチームング・フレームワークを通じて実行する必要があります。
• 反復：その後、結果を分析し、ガードレールやその他の修正を適用し、エージェントがデプロイ可能な状態になるまで再テストを繰り返します。このプロセスが手作業である場合、その都度大きなオーバーヘッドが発生します。

このプロセスにより、承認に時間がかかり、監査証跡が断片化してしまうため、社内外の監査人に対して実際に何が行われたかを証明することが困難になります。

asago は協働によるこれらの問題解決を目指す

asago プロジェクトは、こうした課題の解消を目指しています。Red Hat は、組織が AI の安全性に関する専門家でなくても、AI ポリシーの策定から本番環境への導入まで進められるよう支援したいと考えています。重要なのは、Red Hat の目標が既存の AI 安全性ツールを置き換えることではなく、エコシステムの構成要素を結びつけるオーケストレーションレイヤーとして機能することにあります。Red Hat は、優れたツールが存在する場合はそれらと統合し、存在しない場合はそのギャップを埋めていきます。

もちろん、これは協働によるプロセスでなければなりません。Red Hat は、単一の組織だけで単独で達成できる、あるいは達成すべきであるとは考えていません。ポリシー文書、モデルとエージェントのタイプ、デプロイメント環境、規制環境などが多岐にわたるため、このようなプロジェクトには幅広い視点が必要であり、多様な専門知識は不可欠です。

だからこそ、私たちはテクノロジー企業、研究機関、コミュニティ連合、政府機関を代表する優れた初期パートナーを擁しています。Red Hat はパートナーと協力して、単にコードを書くだけでなく、適切な質問を投げかけ、それに回答できるようにします。また、グローバルコミュニティとして、言語的および地理的な代表性が十分に確保されていることを確認する必要があります。現在、米国、英国、ヨーロッパ各地のパートナーと共にプロジェクトを立ち上げていますが、以下のリンクから、より多くの協力者が参加し、この取り組みの範囲を拡大してくれることを強く期待しています。

進化する技術アーキテクチャ

技術アーキテクチャはプロジェクトの進行に伴い変化していくものですが、ここでは当初の構想をご紹介します。このプロセスは 2 つのセクションに分かれています。

図 1：青色のノードはデータを表します。黄色のノードは機能コンポーネントを表します。

ポリシー文書からシナリオへ

最初のセクションでは、ポリシー文書からリスクを抽出し、IBM Risk Atlas にマッピングします。リスクカードにインデックス化されたこれらのリスクは、ポリシーが言及している理論的リスクの全範囲を表します。これらの中には、asago で自動化して対処できる技術的リスクも含まれます。このための主なコンポーネントはポリシーマッパーです。

次の課題は、レッドチーム活動を推進するための適切なシナリオを作成することです。これはまだ特定のライブラリに依存するものではありませんが、シナリオジェネレーターの役割は、特定されたリスクに関して対象となるエージェントの詳細を評価し、どの種類のテストとそれを支えるコンテキストが必要かを検討することです。これらがシナリオを構成します。プロセスのこの段階で、組織のポリシーのコンテキストにおいて、特定のエージェントに対して評価および防御可能な一連のシナリオが揃います。

図 2 ：青色のノードはデータを表します。黄色のノードは機能コンポーネントを表します。

レッドチームングを通じた、シナリオから推奨事項への反復プロセス

第 2 セクションでは、反復ループを通じて、これらのシナリオを取り込み、関連するレッドチームングや評価フレームワーク用の実行アーティファクトを生成します。ここからデータ駆動型アプローチが始まります。一般的な評価およびレッドチーミングのフレームワークが、シナリオに対応する合成生成されたデータセットと環境を使用して (EvalHub 上で) 実行されます。

これらの結果は推奨プロセスに渡され、レッドチーミングで失敗した箇所に対する修正候補が提供されます。Red Hat では、ガードレールから始まり、スタック全体のさらなるコンポーネントへと進化する、柔軟な推奨事項を想定しています。重要なのは、これらのコンポーネントが (Kubernetes カスタムリソース (CR) や設定マップなどを使用して) デプロイ可能であり、再テスト可能であることです。

これは初期のアーキテクチャにすぎない点に注意してください。コミュニティの進化に合わせて、このアーキテクチャも進化していきます。

今すぐできること

本日発表した内容は、コミュニティのロードマップと進むべき道を示すものですが、開発は活発に行われており、すでに Red Hat の成果を試すことができます。asago の GitHub では、ポリシーマッピングの作業をこちらで確認でき、その例もご確認いただけます。また、間接的なプロンプトインジェクションに対して AI エージェントのセキュリティテストを行うためのオープンソースフレームワークである midojo もぜひご覧ください。  

最後に、皆様や皆様の組織もコラボレーターとして Red Hat に参加いただけます。Red Hat は、とくに異なる言語、文化、地域を代表する多くの組織からの意見やご提案を必要としています。詳細は、こちらをご覧いただき、ぜひご参加ください。

AI の安全性における最良の結果とは、単一の企業が支配しない状態です。asago は、真に多様な視点を持つコミュニティによってオープンに構築されたインフラストラクチャを通じて、その目標に貢献します。プロジェクトは初期段階にあり、構築すべきものが数多くあります。だからこそ、今が参加するのに最適なタイミングなのです。