信頼を築く：AI におけるセキュリティ、安全性、透明性の基盤

このブログは、同名の Red Hat の研究論文 (Bestavros, Chen、Fox、Mollett & Sidhpurwala、2024 年) を改編したものです。論文には、こちらからアクセスできます。

一般に公開されている人工知能 (AI) モデルが急速に進化するにつれて、セキュリティや安全性に関する潜在的な影響も広がる可能性があるため、それらのリスクと脆弱性に対するより深い理解が必要です。AI モデルの開発と運用における標準化されたセキュリティ、安全性および透明性の基盤を開発し、そのオープンなエコシステムやコミュニティを強化するには、モデルに関する情報の一貫性やセキュリティと安全性に関する区分けの欠如、またモデルメーカーによる適切かつ標準化された安全性評価項目が使用されていないなどの現状の課題に対する取り組み方を変えていく必要があります。

リスクと脆弱性

AI のセキュリティと安全性は、どちらも似ていますが、AI システムにおけるリスク管理のそれぞれ異なる側面を構成するものです。AI セキュリティはシステムを内外の脅威から保護するものですが、AI の安全性は、システムとデータがモデルの運用、トレーニングまたは使用によってユーザーや社会および環境を脅かしたり、危険にさらしたりしないようにすることを指します。しかし、AI のセキュリティと安全性の関係は曖昧にされることがよくあります。

通常、セキュリティ上の懸念と見なされる攻撃は、モデルが有害なコンテンツを生成したり、個人情報を漏洩させたりするなどの安全性の問題につながる可能性があります (その逆も同様です)。AI のセキュリティと安全性が交差する分野では、セキュリティと安全性の問題に同時に対応できる、AI リスク管理への包括的なアプローチが非常に重要になります。

現状の課題とトレンド

AI 業界はセキュリティおよび安全性の問題に対処するための措置を講じてきましたが、安全性よりもスピードを優先することや、不十分なガバナンス、報告プロセスが十分に確立されていないなどのいくつかの重要な課題が残されています。新たな傾向として、AI において安全性、セキュリティ、透明性のある効果的なプラクティスを開発するには、これらの分野での改善に取り組むことが重要であることが示唆されています。

安全性よりもスピードを優先すること

AI テクノロジーを迅速に開発し、デプロイしてより多くの市場シェアを「確保」しようとする傾向が見られる中で、多くの組織は安全性のテストや倫理上の検討よりも市場投入のペースを加速することを優先しています。過去のセキュリティインシデントからわかるように、セキュリティは多くの場合、新たなテクノロジーの導入から何年も遅れため、通常は業界で自己修復が可能になる前に大きなインシデントが生じかねません。AI におけるリスク管理を推進する個人が不在の場合には、安全およびセキュリティに関する重大なインシデントが発生する可能性があると予測するのは妥当なことです。現在、セキュリティと安全性を考慮した新しいモデルが導入されていますが、安全性と透明性に関する必要な情報の伝達方法についてのコンセンサスが得られていないため、評価を実施することは困難になっています。しかし、安全性を考慮したモデルは増加しており、これは AI 業界にとって前向きな一歩となっています。

ガバナンスと自主規制

政府による関連する法律がほとんど制定されていないため、AI 業界は自主的な自主規制と法的拘束力のない倫理ガイドラインに依存していますが、これらはセキュリティおよび安全性に関する懸念点に対応する上で不十分です。さらに、提案されている法案は、テクノロジー業界の現状や業界のリーダーやコミュニティが提起する懸念と一致していないことが多々あります。また、企業の AI の取り組みについては、自社利用のために特別に開発されるケースなどのために、構造的な問題に対処できなかったり、有意義な説明責任を果たせなかったりすることがあります。

セルフガバナンスの成功は限定的であり、傾向としては、主要な機能の開発とは別に一連のベストプラクティスが定義されます。歴史的に振り返って見ると、多くの場合、機能を犠牲にしてセキュリティを優先することは、ステークホルダーが望んでいないトレードオフとなっています。AI の場合、これは安全性に直接的な影響を与える課題にまで発展するため、状況をさらに複雑にします。

報告方法が確立されていないこと

業界の現状では、ユーザーが報告するモデルの不具合に対応するための一般的な方法やプラクティスがありません。これは、ソフトウェアの脆弱性に関する業界の開示および報告システム (欠陥ありだが機能している方法) が、AI における報告に適したソリューションではないという事実に一部起因しています。AI は、データサイエンスと機械学習 (ML) が技術的に進化した形であり、データと計算に重点を置き、脅威のモデリング、ユーザー・インタラクションおよびシステムのセキュリティのための方法論を確立したユーザー向けのシステムを構築することに重点を置いていないため、従来のソフトウェア・エンジニアリングや技術開発のアプローチとは異なります。安全上のハザードに関する開示および報告システムが十分に理解され、共有されていない場合、モデルメーカーに直接連絡して問題を報告することは手間のかかる非現実的な方法になります。さらに、報告プロセスが十分に理解され、標準化されていなければ、調整や解決の遅延により、AI の安全性に関するインシデントの影響は必要以上に大きくなるでしょう。

ソリューションと戦略

Cattel, Ghosh & Kafee (2024)による前述の研究内容に基づき、我々は、モデル/システムカードの導入やハザードの追跡を拡張することは、AI 業界におけるセキュリティと安全性の向上に不可欠であると考えます。

モデル/安全性カードの拡張

モデルカードは、AI モデルの使用方法とそのアーキテクチャを文書化し、ときにモデルに使用されるトレーニングデータについても文書化するために使用されます。現在モデルカードは、モデルに関する人が生成する初期資料を提供するために使用されおり、その後はモデルの実行可能性を評価するために使用されます。しかし、モデルカードは、移動先やデプロイ先に関係なく、現在の使用方法を超えて、より多くの可能性と適用性を持っている可能性があります。

モデルを効果的に比較するために、導入担当者とエンジニアは、カード上の一貫したフィールドとコンテンツのセットを使用する必要がありますが、これは仕様によって可能になります。Barnes, Gebru, Hutchinson, Mitchell, Raji, Spitzer, Vasserman, Wu & Zaldivar, 2019 で推奨されているフィールドに加えて、我々は以下の変更と追加を提案しています。

• 意図と用途のフィールドを拡張して、モデルのユーザー (誰が) とユースケース (何を) を記述し、モデルをどのように使用するかを記述する。
• 範囲 (scope) を追加して、モデルの作成者が意図していない、または解決できない既知の問題を除外する。これにより、ハザード報告者は、定義された用途に対して対処不可能と指摘された懸念を報告する前に、モデルの目的を理解することができます。
• 評価データを調整して、フレームワークも使用されたかどうかや、モデルで実行された評価の出力を伝えるためのネストした構造を提供する。安全性評価が標準化されていれば、熟練したユーザーは持続的に同等のモデルを構築できます。
• 導入担当者や利用者がモデルメーカーとやり取りする方法やモデルがどのように作成されたかを把握できるように、モデルに関するガバナンス情報を追加する。
• アーティファクトやその他のコンテンツなど、任意で参照できる情報を提供する。これにより、潜在的な顧客がモデルの運用について理解し、特定のモデルの成熟度と専門性を実証できます。

モデルカードにこれらのフィールドの追加を求めることで、業界は推論、意思決定、およびモデルの再現に不可欠なコンテンツを確立することができます。モデルカードの業界標準を開発することで、エコシステム全体でのモデルとそのメタデータの相互運用性を促進できるようになります。

ハザードの追跡

セキュリティ上の欠陥の追跡に使用される一般的な脆弱性開示プロセスは、従来のソフトウェアのセキュリティには効果的ですが、AI システムに適用する場合には、いくつかの課題に直面します。まず、ML モデルの問題は統計上の有効性のしきい値を満たす必要があります。つまり、AI モデルで特定されたバイアスなどの問題は、それらが意味のある有意なものであることを確認するために、確立された統計の基準に対して測定して評価する必要があります。次に、信頼性やバイアスに関連する懸念は、セキュリティの脆弱性の範囲を超えた問題であることが多く、合意済みの定義とは一致しない可能性があります。これらの限界を認識した上で、Red Hat は一元的かつ中立的に調整されたハザードの開示および公開委員会と共通欠陥識別子 (CFE: common flaws and exposure) 番号によってエコシステムを拡張することで、これらの懸念に対応できると考えています。これは、ソフトウェアとファームウェアの脆弱性を識別し、分類するために MITER が 1999 年に導入した CVE と同様のアプローチです。

安全性の問題を発見したユーザーは、モデル提供者と協力して問題の優先順位を明確にし、さらに分析することが求められます。問題が安全上のハザードであると判断されると、委員会は CFE 番号を割り当てます。またモデルメーカーと販売業者は、自社のモデルで見つかった安全上のハザードを追跡するために CFE 番号をリクエストできます。調整されたハザードの開示および公開委員会は、CFE 番号の管理者であり、安全上のハザードに CFE 番号を割り当て、これらを追跡し、公開する役割を担います。さらに補助委員会を設置して、異議のあった安全上のハザードについて解決を促進することができます。

次のステップ

オープンソースの原則に基づいて開発されたモデルは、AI の将来において重要な役割を担う面でのポテンシャルがあります。業界や消費者の期待に応えてモデルを開発し、管理するために必要なフレームワークとツールには、組織がリスクを合理的に評価するためのオープン性と一貫性が必要です。透明性と重要な機能へのアクセスが向上することで、安全性とセキュリティ上のハザードが広範囲に影響を与える前に発見し、追跡し、解決する能力が向上します。Red Hat の提案は、既存のガバナンス、ワークフローおよび構造を通じて柔軟性と一貫性を確保することを目的としています。これらが実装されると、AI の安全性を効果的に管理するという差し迫ったニーズを解決するためのより効率的な手段を提供できます。