SandiaのAIセキュリティ指針、Tri-Valleyのスタートアップに警鐘

Sandia National Laboratoriesは、Tri-Valleyのスタートアップに4人の研究者を送り込み、警告を発した。急速なAI導入によって、従来のソフトウェアレビューでは見落とされるリスクが生まれているという。7月29日のパネルでは、SandiaのAIセキュリティ手法がビジネスの文脈で取り上げられた。小規模チームでは、正式な保証プログラムを整備する前にモデルを導入することが少なくない。

このイベントで新製品、拘束力のある標準、あるいは規制が発表されたわけではない。重要だったのは、Sandiaが提示した運用モデルにある。スタートアップは、データ、モデル、統合、人間による意思決定を、相互につながる一つのシステムとして検討し、そのシステムを現実的な障害や攻撃に対してテストすべきだという。

この立場は、導入スピードとセキュリティを裏付ける証拠との間に明確な緊張関係を生む。スタートアップは、早期に機能をリリースし、ユーザーから学び、素早く方向転換することで競争する。一方Sandiaは、説明できない障害がシステム全体を損ない得る、高い影響度を持つ環境からAIに取り組んでいる。

パネルは、スタートアップにありがちな前提にも異議を唱えた。信頼できるプロバイダー経由でモデルを利用しても、すべてのリスクがそのプロバイダーへ移転するわけではない。最終アプリケーションを構築する企業は、依然としてデータアクセス、検索レイヤー、ツール、権限、ユーザー体験、対応手順を管理している。

つまりAI保証は、最後に行うコンプライアンス対応ではなく、製品上の責任である。創業者にとって当面の問いは、顧客、規制当局、あるいは攻撃者から要求される前に、自社チームがシステムの挙動に関する証拠を示せるかどうかだ。

SandiaのAIセキュリティ、研究所からスタートアップ運用へ

このイベントは、国家安全保障上の懸念を、若い企業がすでに直面している運用上の課題へと翻訳した。

Daybreak Labsは、カリフォルニア州リバモアで、午前11時30分から午後1時30分まで無料のLunch and Learnを開催した。この非営利インキュベーターは、Tri-Valley地域のライフサイエンスおよびディープテックのスタートアップを支援している。

パネルには、SandiaのAmanda Dodd、Gayle Thayer、Philip Kegelmeyer、Jonathan Crussellが登壇した。各人の専門領域は、国家安全保障分析、セキュアなアルゴリズム、敵対的データ分析、ソフトウェアセキュリティ、エージェント型AIワークフローに及んだ。

Sandiaで国家安全保障向けComputation and Analysis部門のディレクターを務めるDoddは、急速な導入が生み出す脆弱性を軸に議論を組み立てた。彼女は現在のAI拡大を、1990年代に広く進んだインターネット導入になぞらえた。

彼女の比較が焦点を当てたのは、ノスタルジーではなく不確実性だった。インターネット接続は価値あるサービスを生んだ一方、多くの組織が予見していなかった攻撃や障害モードにシステムをさらした。AIは今、コンテンツを生成し、意思決定を推奨し、ときには行動も起こすシステムの内部に、同様の不確実性を加えている。

イベントプログラムによると、議論はスピードとセキュリティ、イノベーションと規制、人間とAIのチームに関わるリスクを扱った。また、政府と民間部門の優先事項がどのように重なるかも検討した。

Sandiaが後に発表したパネル報告では、AIの脅威による事業上の影響として、知的財産の喪失、業務の中断、規制上のエクスポージャーの3点が挙げられた。これらの結果は、技術的な弱点に直接的な財務・戦略上の意味を与える。

SandiaのSecure Algorithms部門を率いるThayerは、セキュリティ上の注目がハードウェアや従来型ソフトウェアの域を超えて移りつつあると説明した。研究者はますます、アルゴリズムそのものと、その利用から生じる振る舞いを検討している。

この変化は重要だ。AIアプリケーションは設計どおりに動作していても、安全でない結果を生む可能性がある。モデルが機密性の高い文脈を開示したり、悪意ある指示を受け入れたり、当初のテスト条件を外れた場面で予測不能な挙動を示したりすることがある。

攻撃がなくても、アプリケーションは失敗し得る。曖昧な指示、未知のデータ、不十分な評価基準、不適切な自律性の水準は、重大なエラーを引き起こす可能性がある。従来の脆弱性スキャンでは、こうした問題をすべて特定できない。

Sandiaのアプローチには、敵対者に発見される前にシステムの弱点を積極的に探るレッドチーミングが含まれる。研究者はまた、定義された条件下で信頼性、セキュリティ、性能の境界をベンチマークする。

境界をテストすることは、好ましい精度スコアを一つ報告することとは異なる。有用な評価では、システムが許容可能な挙動をやめる地点、その変化を引き起こす入力、監視によって検知できるかどうかを問う。

したがって、このパネルはAIリスクを列挙しただけではない。リスクの特定を、再現可能なテスト、緩和策、セキュア設計と結び付けた。この順序により、抽象的な警告がエンジニアリングの規律へと変わる。

公開された報告には、Sandiaが参加スタートアップを認証した、あるいはその製品を評価したことを示す記述はない。このセッションは監査ではなく、アプローチと懸念事項の交換だった。

この区別は重要である。2時間のパネルで、特定のAIシステムが安全かどうかを確立することはできない。しかし、創業者がシステムを出荷する前に問うべき質問を変えることはできる。

急速なAI導入がスタートアップに保証のギャップを残す

スタートアップは、すべてのモデル挙動を理解するのに必要な時間よりも短いリリースサイクルという圧力に直面している。

若い企業は、そのモデルを訓練せずとも、ホスト型モデルを製品に追加できる。短い開発サイクルの中で、アプリケーションプログラミングインターフェースを通じて、顧客文書、社内記録、外部ツールを接続することも可能だ。

こうして生まれるアプリケーションは、複数の不確実性の層を引き継ぐ。その挙動は、基盤モデル、システム指示、取得データ、ソフトウェア統合、権限、ユーザー入力に左右される。

どの層での変更も、システムを変化させ得る。モデルプロバイダーが挙動を更新することもあれば、検索インデックスに新たな文書が追加されることもあり、顧客が新しい統合を有効化することもある。

こうした変更は、チームがしばしば「保証のギャップ」と呼ぶものを生む。製品の開発速度が、セキュリティ、信頼性、許容可能な挙動に関して企業が持つ証拠を上回る状態だ。

AIシステムが行動できる場合、このギャップはさらに深刻になる。エージェント型ワークフローとは、限定的な人間の介入のもとで、モデルが手順を計画しツールを呼び出せるようにするアプリケーションである。メッセージ送信、記録編集、コード実行、業務プロセスの起動が可能になる。

権限が一つ追加されるごとに、誤った、または操作された応答の影響は増大する。チャット画面内の不十分な回答は不便にとどまる。同じ回答が実行ツールに渡れば、データを変更したり情報を露出させたりする可能性がある。

プロンプトインジェクションは、この違いをよく示している。攻撃者はユーザー入力や外部コンテンツに指示を埋め込み、開発者が意図したルールではなく、モデルにその指示を従わせようとする。

OWASPが管理する現在のLLMリスクリストでは、プロンプトインジェクションを主要なアプリケーション脆弱性として位置付けている。機密情報の開示、サプライチェーンの弱点、不適切な出力処理、過剰な自律性も扱われている。

これらのリスクは組織の境界をまたぐ。モデルプロバイダーは自社プラットフォームを保護する一方、アプリケーション開発者はプロンプト、検索、ツール、アクセスルールを管理する。そして顧客は、ユーザーの行動、接続データ、ローカル設定を管理する。

単一の参加者がシステム全体を見渡せるわけではない。そのため、インシデントが起きるまで責任は容易に拡散する。

Sandiaのパネルは、責任を導入組織へと戻した。政府は研究、フレームワーク、独立評価を提供できる。しかし企業は依然として、自社製品と運用上の選択が生むリスクを負う。

この責任は、スタートアップに国家研究所を再現することを求めるものではない。自社のユースケースにとって安全な挙動が何を意味するかを定義することを求めている。

臨床研究アシスタントとマーケティングコピー生成ツールが、同じ受け入れ基準を共有すべきではない。前者はより重大な影響を伴う情報を扱うため、より厳格な証拠、アクセス制御、レビューが必要となる。

スタートアップは、モデルの品質とシステムのセキュリティも分けて考える必要がある。モデルは日常的なタスクで高い性能を示しても、敵対的な入力の下では失敗する可能性がある。正確に回答しても、ユーザーが受け取るべきでない情報を明らかにすることがある。

逆もまた起こり得る。アプリケーションは一般的な攻撃を防げても、信頼できない推奨を生成する可能性がある。セキュリティと有用性は重なるものの、一方がもう一方を保証するわけではない。

そのため、単一のベンチマークスコアがもたらす保証は弱い。チームには、意図するタスク、予見可能な悪用、アクセス境界、実際の導入条件に結び付いたテストが必要だ。

記録も必要となる。検索可能なナレッジベースは、エンジニアリングチームとプロダクトチームをまたいで、モデルのバージョン、評価結果、インシデント、受容済みリスクを保持できる。

文書化は、開発後に追加する事務作業ではない。チームが挙動の変化を特定し、以前の緩和策が現在も機能するかを確認するための手段である。

圧力は、短期的でもあり長期的でもある。エンタープライズの買い手はすでに、データ処理、モデルプロバイダー、アクセス制御、インシデント対応についてベンダーに尋ねている。将来のルールにより、その証拠はさらに正式なものとなる可能性がある。

こうした質問に答えられないスタートアップは、技術的侵害を受ける前に取引を失うかもしれない。その意味で、信頼できるAIは製品の信頼性の一部となる。

中心的なトレードオフはスピードと証拠にある

Sandiaのメッセージはイノベーションの減速を求めるものではないが、AIにより大きな権限を与える前に、より強固な証拠を求めている。

創業者は通常、スピードを生存の条件として捉える。迅速な出荷はユーザーフィードバックを生み、需要を証明し、予算規模の大きい組織との競争を小規模企業に可能にする。

セキュリティチームは、同じリリースを別の角度から見る。システムが機密データに触れる前に、脅威モデル、テスト、ログ、アクセス境界、対応計画を求める。

どちらの立場にも正当な懸念がある。すべての実験的機能を、高い影響度を持つ基準に達するまで遅らせれば、多くのスタートアップにとって負担となる。有意義なテストなしに自律型システムを導入すれば、顧客を見えないリスクにさらすことになる。

実務的な答えは、影響に応じた保証である。低影響の文章作成アシスタントには、財務、研究室、または本番環境の記録を変更できるエージェントとは異なる管理策が必要だ。

影響に応じた保証は、定義された文脈から始まる。チームは、誰がシステムを使うのか、どのデータにアクセスできるのか、どの行動を取れるのか、どの失敗が許容できないのかを文書化する。

次に企業は、信頼できる脅威と通常の障害モードをマッピングする。脅威には、悪意あるプロンプト、汚染されたデータ、盗まれた認証情報、侵害された依存関係、非公開の文脈を抽出しようとする試みが含まれる。

通常の障害にも同等の注意が必要だ。モデルは要求を誤解したり、出典を捏造したり、誤ったツールを選択したり、前提が無効になった後も動作を続けたりする可能性がある。

次に測定を行う。チームは現実的なタスク、既知のエッジケース、敵対的な例から評価セットを構築する。テストを実行する前に、期待される結果を記録する。

有用なテストには、観測可能な合格条件がある。「モデルは安全であるべきだ」は測定できない。「アシスタントは、認証済みユーザーのワークスペース外にある記録を返してはならない」は、テストできるほど具体的である。

サンディアのレッドチーム手法は、攻撃者の視点を加えるものだ。テスターは、指示、接続されたデータ、インターフェース、ツールを含むアプリケーション全体を通じて、想定外の経路を探す。

エネルギー省の研究所コミュニティ全体でも、同様の取り組みが説明されている。複数の研究所によるAI安全性レポートは、既知の条件外における挙動を予測するには、静的なベンチマークだけでは不十分だとしている。

同レポートは、リソース上の制約も指摘している。包括的な評価には、計算能力、専門家の労力、時間が必要となる。新しいモデルは、評価者が個々を十分に検証できる速度を上回って登場している。

この制約は、特にスタートアップにとって重要だ。小規模企業は、あらゆる可能性のある入力をテストしたり、プロバイダーが社内で実施する評価を再現したりすることはできない。

それでも、自社が管理するアプリケーションはテストできる。焦点を絞った評価では、企業のデータ、ツール、ユーザーロール、そして影響の大きいワークフローを対象にすべきだ。

テストの後には緩和策が続く。チームは権限を制限し、信頼できないコンテンツを隔離し、出力を検証し、人による承認を必須にしたり、モデルが呼び出せるツールを制限したりできる。

最も強力な統制は、多くの場合、失敗した場合の影響を小さくする。アシスタントが行動案を作成するだけなら、人間が確認できる。アシスタントがその行動を直接実行するなら、企業にはより強力な認可と監視が必要になる。

人によるレビューが自動的に有効になるわけではない。大半の出力が正しく見える場合、特に時間的なプレッシャーの下では、レビュアーが油断するおそれがある。

そのため、チームはレビューが最も重要となる判断を特定すべきだ。また、人が疑わしい結果を認識できるだけの文脈を提示する必要がある。

監視によって循環が閉じる。ログには、重要な出力にどのモデル、指示、データソース、ツールが寄与したかを示す必要がある。その文脈がなければ、インシデント調査は推測に頼ることになる。

これらの手順はいずれも、恒久的な保証を生むものではない。モデルの挙動、アプリケーションコード、データ、攻撃者はいずれも変化する。テストはシステムのライフサイクル全体を通じて継続しなければならない。

ここで、スピードと証拠の対立は管理可能になる。スタートアップは、制限された環境で迅速に進み、証拠が整うにつれて権限を拡大できる。

まずは社内ユーザー、合成データ、読み取り専用ツールから始められる。その後、システムが明確な基準を満たした段階で、顧客データや限定的な操作を追加できる。

この道筋は、セキュリティを製品開発の一部として扱うものだ。すべての実験を止めることと、制限なしにあらゆる機能をリリースすることの間にある誤った二者択一を避けられる。

フレームワークは役立つが、製品を認証するものではない

既存のフレームワークはAIリスクへの取り組みを体系化するが、特定のスタートアップのアプリケーションが十分に安全かどうかを判断することはできない。

NIST AIリスク管理フレームワークは、組織に対して、ガバナンス、マッピング、測定、管理という4つの相互に結び付いた機能を提示している。ガバナンスは最後にだけ現れるものではなく、ほかの機能すべてにまたがって適用される。

このフレームワークは任意であり、幅広い用途を想定して設計されている。そのAIリスク管理フレームワークは、組織がAIの設計、開発、導入、利用、評価に信頼性を組み込むのを支援する。

スタートアップにとって「govern」は、意思決定権限を割り当て、リスク許容度を文書化することを意味する。どのユースケースを許可し、どのような証拠がリリースを裏付けるかを、誰かが決めなければならない。

「map」は文脈を理解することを意味する。チームはユーザー、影響を受ける当事者、データ、依存関係、期待される便益、起こり得る害を特定する。

「measure」はテストと分析を対象とする。パフォーマンス評価、セキュリティテスト、不確実性評価、定義済みの基準に照らした監視が含まれる。

「manage」は、調査結果を優先順位と行動に変換する。企業は、重大度と利用可能な統制に基づき、リスクを受容、低減、移転、または回避する。

NISTは2024年7月、生成AIプロファイルも公表した。このプロファイルは、生成システムが新たに持ち込む、または増幅させるリスクに合わせて、より広範なフレームワークを適応させている。

これらのリソースは、語彙と構造を提供する。製品を検査したり、コンプライアンスを保証したり、モデルの挙動を認証したりするものではない。

サンディアの立場は、単にフレームワークの用語を採用することよりも技術的に厳格に見える。研究者らは、レッドチーミング、ベンチマーキング、安全な設計、性能限界の理解を強調した。

この強調は重要だ。なぜなら、ガバナンス文書はソフトウェアから乖離し得るからだ。リスク台帳にはプロンプトインジェクションに対処済みと書かれていても、導入済みの検索システムが依然として信頼できない指示をモデルに渡しているかもしれない。

証拠は、特定された各リスクを統制とテストに結び付けるべきだ。企業はまた、緩和策の後にも残るリスクを把握しておくべきである。

独立した評価は、そのプロセスを強化できる。サンディアは、連邦政府の資金を受ける研究開発センターを、偏りのない技術分析の提供元として説明した。

ただし、この公開パネルのレポートは、スタートアップ向けの一般的なサンディア認証サービスを発表したわけではない。業界が保証ニーズを満たせる領域と、国立研究所がギャップに対応できる領域を見いだすことへの関心を示した。

これは協業への招待であり、完成済みの道筋の証明ではない。アクセス、対象範囲、知的財産の取り扱い、調達の取り決めが、個々のスタートアップが参加できるかを左右する。

サンディアはすでに、研究所、大学、小規模企業を結び付けるプログラムを運営している。同研究所のRAIICE programは、レジリエントなエネルギーに関わるAIおよび機械学習の取り組みに向けて、オープンデータセットと技術ロードマッピングを提供することを目指している。

RAIICEはパートナーシップモデルを示すが、7月のセキュリティパネルと混同すべきではない。パネルは、参加者が同プログラムに参加したとは発表していない。

この区別は、サンディアのメッセージにある懐疑的な側面を浮き彫りにする。技術的な専門性は存在し、創業者がそれを明らかに必要としている。一方で、その専門性が商業チームにどこまで広く届くかは不確実なままだ。

国立研究所は、特定の任務、契約ルール、リソースの制約の下で活動する。スタートアップは短いスケジュールで動き、数日以内に答えを必要とする場合もある。

協業モデルは、こうした異なるリズムを橋渡ししなければならない。研究手法を、小規模チームでも実行、再現、顧客への説明ができるテストへと変換する必要がある。

規制も別の不確実性を生む。パネリストは、業界がAIリスクを責任を持って担える明確なルールを支持したと報じられているが、このイベントで法的基準案が示されたわけではない。

ルールは期待を明確にできる一方、モデルやアプリケーションの変化に伴って時代遅れになる可能性もある。規範的な要件は、実際の挙動を改善せずにチェックリストの達成だけを促すおそれがある。

成果重視のルールは別の問題を生む。企業に達成すべき結果を示せても、それを証明する手頃な手段を提供しない可能性がある。

短期的に最も有力なシグナルとなるのは、実用的な証拠だ。公開されたテスト手法、再利用可能な評価ツール、利用しやすいデータセット、文書化されたスタートアップとの協業は、パートナーシップの構想が実運用に移りつつあることを示すだろう。

それまでは、企業はフレームワークの採用が安全性を証明すると主張すべきではない。自社が使う統制、実施したテスト、依然として認識している限界を説明すべきだ。

創業者と購入者が次に注目すべきこと

次の試金石は、サンディアのリスクに関する言葉が、再現可能な実践、信頼できるパートナーシップ、より明確な市場の期待へと結び付くかどうかだ。

最初のシグナルは、小規模企業向けの具体的な協業経路である。サンディアは、業界が保証ニーズを満たせる領域と、国立研究所がギャップを埋められる領域を特定したいとしている。

有用な経路には、対象となるプロジェクト、利用可能な専門性、データ取り扱い要件、想定される成果物、協業のタイムラインが定義されるだろう。公開されたケーススタディがあれば、モデルを評価しやすくなる。

こうした詳細が明らかになれば、パネルの中心的な主張は強まる。国立研究所の手法が議論の域を超え、商業開発を支援できることを示すからだ。

経路が現れなければ、このイベントは価値あるアウトリーチにとどまり、運用面での支援は限られる。スタートアップは依然として、自前のテストプログラムを構築するか、外部の専門家を雇う必要がある。

2つ目のシグナルは、実際のアプリケーションに結び付いた技術的検証だ。創業者は、プロンプトインジェクション、データ漏えい、モデル操作、安全でないツール利用、通常のテスト条件外での挙動を対象とする公開評価に注目すべきである。

最も有用な取り組みは、好意的なスコアだけでなく、失敗条件と残存リスクを報告する。テスト後に何が変わったのか、緩和策が次の攻撃サイクルにも耐えたのかを説明すべきだ。

そうした証拠は、信頼できるAIが競争優位性を生むという主張を強化する。企業が再現可能な結果を示せれば、購入者はベンダーをより自信を持って比較できる。

証拠がなければ、この議論は弱まる。すべてのベンダーが似た約束をする状況では、セキュリティに関する言葉だけで製品を差別化することはできない。

3つ目のシグナルは、広範なフレームワークから、より明確な顧客および規制上の期待への移行だ。NISTはAI RMF 1.0を改訂中であり、サイバーセキュリティと重要インフラ向けの追加プロファイルを開発している。

創業者は、エンタープライズ向け質問票、調達要件、保険審査、業界別ルールが、類似した証拠を求め始めるかを追うべきだ。収束すれば、どの統制に早期投資する価値があるかを巡る不確実性は減る。

分断が続けば、負担は重くなる。スタートアップは、顧客、規制当局、パートナーごとに異なる評価形式に直面するかもしれない。

購入者も、その結果を形作る役割を担う。ベンダーに対し、どのモデルとデータソースがワークフローを支えているのか、システムがどのような行動を取れるのか、ベンダーがアクセス境界をどのようにテストしているのかを尋ねるべきだ。

また、モデル更新後に何が起こるのかも尋ねるべきである。プロバイダーが挙動を変更したり、アプリケーションに新しいツールが追加されたりすれば、以前の評価がもたらす保護は限定的になる。

開発者は、追加するすべての権限を新たなセキュリティ判断として扱うべきだ。アシスタントをメール、ソースコード、顧客記録、研究所データに接続すると、失敗時の影響が変わる。

ナレッジワーカーも、こうした境界を理解すべきだ。どの情報をAIシステムに入力できるのか、どの出力に独立したレビューが必要なのかについて、明確なシグナルが必要である。

サンディアのパネルは、これらの問題を解決したわけではない。スタートアップにとって、先延ばししにくい問題にした。

最も持続的な教訓は、AIセキュリティがモデルを取り巻く完全な運用システムを対象とするという点だ。データ、指示、ソフトウェア、権限、ユーザー、監視のすべてが結果に影響する。

この教訓は、創業者が今すべきことも明確にする。システムを定義し、最も影響の大きい失敗を順位付けし、その失敗をテストし、権限を減らし、証拠を保持することだ。

次に、新しい機能の一つひとつが、与えられる権限に見合うかを問うべきだ。説得力のあるデモは保証の根拠ではなく、プロバイダーの評判はアプリケーションテストの代わりにはならない。

サンディアのAIセキュリティガイダンスは、企業がこの規律を日常的な製品開発に組み込む場合に最も重要になる。創業者はまず、影響の大きいワークフローを1つ選び、そのリスク、統制、テスト、未解決の限界を文書化すべきだ。