知っておくべきことはおそらく 3 つ以上ありますが、まずはこの 3 つから始めましょう。
まず、AI が現実に存在することに注意することが重要です。 はい、誇張されすぎです。 はい、10年以上前にすべてが突然「クラウド」製品になったのと同じように、ポートフォリオ全体が「AIウォッシュ」されています。 しかし、 AIに焦点を当てた最新の調査に参加した意思決定者など、事情を知る人々によると、それは現実だそうです。
ほとんどの組織 (69%) がテクノロジーとユースケースに関する調査を実施していますが、43% が AI を大規模に実装していると回答しています。 それは生成的または予測的のいずれかです。
何らかの AI をすでに実装している企業の 47% が AI に関する明確な戦略をまったく持っていない (ゼロ、ゼロ、ゼロ) という調査結果は、いくぶん当惑させられます。パブリック クラウドへの急速な移行から私たちが学んだことがあるとすれば、戦略なしに飛び込むと将来的に問題を引き起こすことになるということでしょう。
その戦略を定義する際、特に運用とセキュリティへの影響を理解しようとするときに役立つように、考慮すべき 3 つの項目のリストをまとめました。
言う必要はないはずですが、とにかく言っておきます。 AI アプリケーションは最新のアプリケーションです。 AI アプリケーションの中核はモデルですが、「AI アプリケーション」を構成するコンポーネントは他にも多数あります(推論サーバー、データ ソース、デコーダー、エンコーダーなど)。
これらのコンポーネントは通常、最新のアプリケーションとしてデプロイされます。つまり、スケーラビリティ、スケジューリング、さらにはセキュリティのために Kubernetes とその構成要素を活用します。 コンポーネントごとにリソースのニーズが異なるため (一部のワークロードは GPU アクセラレーションの恩恵を受けますが、他のワークロードでは従来の CPU のみが必要です)、最新のアプリケーションとして展開するのが最も理にかなっており、AI アプリケーション内の各ワークロードが特定のコンピューティング ニーズに基づいて最適に展開および拡張されるようにする柔軟性が向上します。
つまり、AI アプリケーションは他の最新のアプリケーションと同じ課題の多くに直面しているということです。 既存の最新アプリケーションの拡張とセキュリティ保護から学んだ教訓は、AI アプリケーションでも同様に役立ちます。
戦略的なポイント: アプリケーション配信とセキュリティに関する既存の知識と実践を活用しながら、AI アプリケーションのさまざまなコンポーネントには、コンピューティング集約型タスク用の GPU アクセラレーションや、コンピューティング集約型のワークロードが少ない場合の CPU リソースなど、さまざまなリソース ニーズがあることを認識したアプローチを含めるように拡張します。 最新のアプリケーション展開により、各コンポーネントの特定の要件に基づいてリソースを柔軟に割り当てることができ、パフォーマンスとコスト効率が最適化されます。
はい、私は「これらは最新のアプリケーションである」という点を強調したばかりですが、アーキテクチャ、運用、セキュリティに影響する違いがあります。
まず、AI アプリケーションは非構造化データを交換します。 これらのプロンプトにはフォーマット、長さ、データ型の要件がなく、マルチモーダル LLM の熱心な採用は「リクエスト」の混乱をさらに増大させるだけです。 ほとんどの AI アプリケーションはプロンプトと応答を JSON ペイロードにラップするので、構造化されていると言えると思いますが、実際のペイロードは未定義であるため、構造化されているわけではありません。
2 つ目は、AI アプリケーションは、ほぼ例外なく API 経由でモデルと通信します。つまり、アクセスの基本基準として「人間」または「マシン」を使用するボット検出ソリューションは、それほど役に立ちません。 「良いボット」から「悪いボット」を選別するのに役立つセキュリティ サービスは、あらゆる AI 戦略の重要な部分になります。 API への依存は、当社の年次調査で、AI モデルを保護するために計画されている最上位のセキュリティ サービスが API セキュリティであることが判明した理由でもあります。
最後に、AI アプリケーションのインタラクション パターンは、動的、可変的、予測不可能な場合が多くあります。 一般的に、今日のセキュリティ サービスでは、確立された人間の平均基準からの逸脱に基づいて「ボット」の動作を推測できるため、ページあたりのマウス クリック率と入力率の異常を監視します。 これは、会話型インターフェースを使用しているユーザーにとっては機能しません。ユーザーは、質問を入力、再入力、送信することが非常に不規則になる可能性があります。 今日の多くのセキュリティ ソリューションは API セキュリティを含む動作分析に依存しているため、何らかの調整が必要になります。
戦略的なポイント: AI アプリケーションを適切に管理するには、追加のセキュリティ機能が必要になります。 会話のニュアンスを適切に捉えられない可能性がある従来のセキュリティ アプローチを再考します。 インタラクション パターンのリアルタイム監視やコンテキスト キューに基づく適応型アクセス制御メカニズムなどの革新的なアプローチを検討します。 AI モデルとの通信を容易にする上での API の重要な役割を認識します。 不正アクセス、データ侵害、悪意のある攻撃から保護するために、強力な API セキュリティ ソリューションに投資してください。
マルチクラウドが最終的に現実となるように、組織が単一の AI モデルを標準化する可能性は非常に低いです。 これは、特定のユースケースでは異なるモデルがより適している可能性があるためです。
そのため、平均的な企業がすでにオープンソース モデルと独自モデルを含めてほぼ 3 つ (2.9) の異なるモデルを使用していることは驚くことではありません。 ユースケースに基づいてモデルの使用を見ると、パターンが見えてきます。 たとえば、セキュリティ運用やコンテンツ作成など、企業の機密データやアイデアに大きく依存するユースケースでは、オープンソース モデルへの大きな傾向が見られます。 一方、自動化のユースケースを見ると、多くの組織ですでに使用されているツールやプロセスと統合できる能力が主な理由で、Microsoft が利用され始めていることがわかります。
SaaS 管理型 AI モデルの提供とセキュリティ保護に必要なプラクティス、ツール、テクノロジは、クラウド管理型 AI モデルや自己管理型 AI モデルとは異なるため、これを理解することが重要です。 確かに類似点はありますが(特にセキュリティに関しては)、使用される展開パターンごとに対処する必要がある大きな違いもあります。
戦略的なポイント: 組織内のユースケースを分析し、さまざまな AI モデルの採用におけるパターンを特定します。 データの機密性、統合機能、既存のツールやプロセスとの整合性などの要素を考慮してください。 各デプロイメント パターンの特定の特性に基づいて、デプロイメントとセキュリティへのアプローチをカスタマイズします。
AI アプリケーションの構築、運用、セキュリティ保護には多くの考慮事項がありますが、その中でも特に重要なのは、モデルのセキュリティとスケーラビリティに関する新しい要件です。 しかし、過去 10 年間にコア、クラウド、エッジにわたって最新のアプリケーションを導入することで得られた教訓の多くは、組織にとって役立つでしょう。 中核となる課題は変わりませんが、AI アプリケーションの拡張とセキュリティ保護に同じレベルの厳格さを適用することは、実装の成功に大きく貢献します。
しかし、違いに注意を払わず、配信とセキュリティの課題に対処するための少なくとも準正式な戦略なしに飛び込むと、将来的に失望することになるでしょう。