LLM (大規模言語モデル) は、一見無限の数のエンタープライズ タスクを処理できると期待されていますが、IT エグゼクティブは、LLM が非常に繊細で、ちょっとしたきっかけでガードレールやその他の制限を無視してしまう可能性があることに気づき始めています。
たとえば、エンド ユーザーが無害に、または攻撃者が悪意を持って LLM クエリ ウィンドウに大量のデータを入力すると、エラー メッセージは返されず、システムがクラッシュする様子もありません。しかし、LLM は多くの場合、即座にプログラミングを上書きし、すべてのガードレールを無効にします。
「問題は、膨大な数のコードを追加できないことです。[LLM] に関する最大の脅威の 1 つは、オーバーフローの効率的な脱獄です」と、HackerOne のシニア ソリューション アーキテクトである Dane Sherrets 氏は語ります。「大量の情報を与えると、オーバーフローします。システムのプロンプト、トレーニング、微調整を忘れてしまいます」(Claude ファミリーの LLM を製造している AI 研究のスタートアップ Anthropic は、このセキュリティ ホールについて詳細に説明しています)。
未報告の財務情報へのアクセスを厳しく制限しなければならない上場企業のケースを考えてみましょう。あるいは、特定の許可レベルを持つ人だけが兵器の設計図にアクセスできるように制限する必要がある軍事請負業者のケースを考えてみましょう。LLM が過負荷になり、これらの制限を無視した場合、結果は深刻になります。
これは、LLM ガードレールが機能しない可能性がある方法の 1 つにすぎません。これらのシステムは通常クラウドベースであり、特定の LLM アルゴリズムのライセンスを所有するベンダーによって制御されます。少数の企業 (政府のために働く兵器メーカーなど) は、LLM コードを取得し、オンプレミスのエアギャップ環境でのみ実行していますが、これらはまれな例外です。
LLM を導入している IT リーダーは、システムやデータを危険にさらしたり、有用な結果を提供できなかったりする、その他の微妙だが重大な欠陥を発見しました。手遅れになる前に認識し、回避する必要がある 5 つの主要な LLM の問題を以下に示します。
今日の LLM システムの大きな欠陥の 1 つは、共有を意図していないさまざまな SharePoint ファイルにアクセスできることです。これは、Microsoft が 3 月 6 日に Copilot LLM で使用するための新しい SharePoint 機能を発表したときに認めました。
Copilot では、「ユーザーにアクセスを有効にすると、そのユーザーが持つアクセスが複製されます。その後、ユーザーが知っているかどうかに関係なく、ユーザーがアクセスできるすべてのものにアクセスできるようになります」と、フォーチュン 500 保険会社の IT ガバナンス マネージャーである Nick Mullen 氏は述べています。
「SharePoint リポジトリはバックグラウンドで実行されますが、エコシステム全体で公開されているものすべてにアクセスできます。これらのサイトの多くはデフォルトで公開されています」と、Sanguine Security というセキュリティ会社も経営している Mullen 氏は言います。
パブリック プレビューで利用可能なこの新機能は、「制限付き SharePoint 検索」と呼ばれます。Microsoft によると、この機能により、「組織全体の検索と Copilot エクスペリエンスの両方を、選択した厳選された SharePoint サイトのセットに制限できます」とのことです。
現在の既定のオプションは、パブリック アクセスです。Microsoft のサポート ドキュメントによると、「組織が制限付き SharePoint 検索を使用する前、Alex [架空のユーザー] は、OneDrive ファイル、チャット、メール、所有またはアクセスしたコンテンツなどの自分の個人コンテンツだけでなく、アクセス許可のレビューやアクセス制御リスト (ACL) の衛生管理が行われておらず、データ ガバナンスが適用されていない一部のサイトのコンテンツも表示できます。」Alex は機密情報にアクセスできるため (本人が気づいていなくても)、Copilot も同様に機密情報にアクセスできます。
同じ問題は、あらゆる企業のデータ ストレージ環境に当てはまります。IT 部門は、LLM によるクエリの実行を許可する前に、ユーザーのデータ アクセス権限を徹底的に監査し、機密データをロックダウンする必要があります。
今日の LLM の問題の 1 つは、すべてのエンタープライズ システムへの広範な、あるいは無制限のアクセス権が意図せず付与されることが多いことです。さらに悪いことに、現在のエンタープライズ防御システムのほとんどは、LLM が不正行為を行ったとしてもそれを検出できず、ブロックも行いません、と Mullen 氏は言います。
これは、企業が「あらゆるものを検索できる最も強力で直感的な検索エンジン」を持つことを意味します、と彼は言います。「歴史的に、この種の内部スキャンはアラートを発していました。しかし、LLM は違います。これはまったく新しい脅威ベクトルであり、検出が非常に困難です。EDR [エンドポイント検出および対応] は、想定どおりに動作しているため、これを検出しません。現時点では、それを保護する良い方法はありません。誰が侵害されたかに応じて、攻撃者は宝の山にアクセスできる可能性があります。」
マレン氏はさらにこう付け加えた。「LLM は非常に気まぐれで、人々は少し先走りすぎています。この技術は非常に新しいため、多くのリスクはまだわかっていません。実際に目にするまではわからないという状況です。これは意図せざる結果の法則です。[IT] は [LLM] を有効にし、膨大な量のリソースへのアクセスを許可していますが、これはすべての組織に一考の余地を与えるはずです。」
AI問題に焦点を当てた非営利研究機関PolyAgentの創設者、アルトゥール・キウリアン氏は、多くの企業が適切な管理を導入する前にLLMをあまりにも急いで導入しつつあると見ている。
「LLM を実装している企業のほとんどは、まだ実験段階です」と Kiulian 氏は言います。「ほとんどの企業は、迅速なエンジニアリングのガードレールを使用しています。それだけでは十分ではありません。許可ベースの制御が必要です。ほとんどの企業はまだそこまで到達していません。」
HackerOne の Sherrets 氏は、現在の LLM がいかに危険であるかに同意しました。「LLM は他のアプリケーションと相互作用する可能性があります。社内インフラストラクチャでの操作をブラック ボックス制御に委ねることになるので、恐ろしいことです。LLM はどのようなユーティリティに影響を及ぼしているのでしょうか?」
EY アメリカズ テクノロジー コンサルティングのプリンシパルで、GenerativeAI イニシアチブを率いる David Guarrera 氏も、初期のエンタープライズ LLM 導入がもたらすリスクを懸念しています。「LLM を騙してガードレールを回避できる新しい攻撃が数多く登場しています。LLM を狂わせるランダムな文字列です。組織はこうしたリスクを認識する必要があります」と Guarrera 氏は言います。
同氏は、企業に対し、給与計算やサプライ チェーンなどの機密システムに対して、独立した隔離された保護を構築するようアドバイスしています。「IT には、LLM の [アクセス] の外部で処理される権限が必要です。これらのシステムへのアクセスをどのように設計するかを深く考える必要があります。LLM には見えないデータ レイヤーでそれを行う必要があります。また、堅牢な認証レイヤーを設計する必要もあります」と同氏は語りました。
もう 1 つの懸念は、LLM をプログラムして、必要最小限のルールを管理することです。これは、システムが一部のデータを制限し、会社内で特定の役割を持つ人や特定の部署で働く人とのみデータを共有するという考えです。
これは、公務員のメンタリティ問題と呼ばれる問題にぶつかります。つまり、ルールについて訓練を受け、ルールを暗記している人でも、ルールが最初に作成された理由について訓練を受けていないということです。その背景知識がなければ、例外が正当化されるかどうかについて十分な情報に基づいた判断を下すことができず、ルールを厳格かつ文字通りに解釈する傾向があります。
これは LLM にも当てはまります。しかし、機密性の高い企業データの多くは、それほどバイナリではありません。
先ほど挙げた株式公開会社の財務の例を見てみましょう。確かに、今四半期の未発表の財務データは、権限のある少数の人に限定する必要があります。しかし、LLM は、データが発表され SEC に提出されるとすぐに、そのデータが瞬時に世界中に読み取れるようになることを認識するようにプログラムされているのでしょうか。また、報告されたデータだけが現在公開されており、報告されていないデータは依然として独自のデータであるのでしょうか。
関連する問題: 財務書類の提出準備が急務で、CFO が会社のさまざまな事業部門から 30 名の追加人員を一時的に書類提出の手伝いに派遣する許可を要求し、許可されたとします。30 名の臨時人員に一時的なデータ アクセスを許可するように LLM を再プログラムすることを誰かが考えるでしょうか? また、通常の役割に戻ったときに、アクセスを削除することを誰かが覚えているでしょうか?
LLM に関するもう 1 つの懸念は、より現実的なものです。ベテランの IT マネージャーは、あらゆる種類のソフトウェアを扱った長年の経験を持っています。その経験から、システムがクラッシュしたときに速度が低下したり、停止したり、エラー メッセージが生成されたり、文字化けした画面が表示されたりする様子を学んでいます。しかし、LLM に不具合 (LLM のクラッシュの一種) が発生すると、そのようには動作しません。
「従来のソフトウェアが壊れると、画面が読み込まれず、エラーメッセージがそこら中に出回って、一目瞭然です。一方、LLM ソフトウェアが壊れると、はるかにわかりにくくなります。明らかなエラーは発生せず、予測が間違っているモデルが表示されるだけです」と、HubSpot の人工知能部門責任者、ケビン・ウォルシュ氏は語る。「LLM を実世界に導入してから数週間から数か月経って初めて、ユーザーから、LLM が本来の問題を解決していないという声が聞こえてくるかもしれません。」
これは重大な問題となる可能性があります。なぜなら、IT 部門が問題を迅速に認識しないと、システムの修復や制限の試みが遅れ、被害を食い止めるには対応が遅すぎる可能性があるからです。
LLM の障害は従来のソフトウェアとは異なり、はるかに隠れた形で発生するため、IT 部門ははるかに多くの追跡、テスト、監視を設定する必要があります。毎朝 LLM をテストすることが、誰かの日常的な仕事になるかもしれません。
Forrester の SecOps および AI セキュリティ ツール担当主席アナリスト、アリー・メレン氏は、LLM が人間の思考を非常に巧みに模倣するため、LLM に対する認識が不正確であることが多いと述べています。
「生成型AIは人間に似ているため、私たちはAIに対して誤った認識を持っています。AIは独自の考えを持つことはできません。次の言葉を予測するだけです。AIがコードを書けるという期待は大げさすぎます」と彼女は語った。
LLM は非常に慎重に扱う必要があると彼女は付け加えた。「ガードレールを回避する方法は数多くあります。プログラムされた制限を回避するために、個人が少し異なるプロンプトを思いつく可能性があります」と彼女は述べた。
「IT 部門は、現実的なユースケースで実際に実装できるものに焦点を当てる必要があります」とメレン氏は言います。「LLM をハンマー、すべての問題を釘のように扱わないでください。[LLM] の機能は、投資家や経営幹部など、ビジネス界のほとんどの人々によって過大評価されています。」
エヴァン シューマンは、自分でも認めないほど長い間、IT 問題を取り上げてきました。小売テクノロジー サイト StorefrontBacktalk の創刊編集者であり、CBSNews.com、RetailWeek、Computerworld、eWeek のコラムニストを務め、BusinessWeek、VentureBeat、Fortune から The New York Times、USA Today、Reuters、The Philadelphia Inquirer、The Baltimore Sun、The Detroit News、The Atlanta Journal-Constitution まで、さまざまなタイトルに署名記事が掲載されています。エヴァンへの連絡先は eschuman@thecontentfirm.com で、フォローするには twitter.com/eschuman にアクセスしてください。彼のブログは週 2 回更新されます。このブログで表明されている意見はエヴァン シューマンのものであり、IDG Communications, Inc.、その親会社、子会社、関連会社の意見を必ずしも代表するものではありません。
Evan Schuman は、自分でも認めないほど長い間、IT 問題を取り上げてきました。小売テクノロジー サイト StorefrontBacktalk の創刊編集者であり、CBSNews.com、RetailWeek、Computerworld、eWeek のコラムニストを務め、BusinessWeek、VentureBeat、Fortune から The New York Times、USA Today、Reuters、The Philadelphia Inquirer、The Baltimore Sun、The Detroit News、The Atlanta Journal-Constitution まで、さまざまなタイトルに署名記事が掲載されています。Evan への連絡先は eschuman@thecontentfirm.com で、フォローするには twitter.com/eschuman にアクセスしてください。彼のブログは週 2 回更新されます。
このブログで述べられている意見は Evan Schuman のものであり、必ずしも IDG Communications, Inc. やその親会社、子会社、関連会社の意見を代表するものではありません。
