AI と ML の視点: セキュリティ

Last reviewed 2026-10-29 UTC

このドキュメント（Google Cloud Well-Architected Framework: AI と ML の視点）では、AI と ML のデプロイが組織のセキュリティとコンプライアンスの要件を満たすようにするための原則と推奨事項の概要について説明します。このドキュメントの推奨事項は、Well-Architected Framework のセキュリティの柱に沿っています。

AI ワークロードと ML ワークロードの安全なデプロイは、特に企業環境において重要な要件です。この要件を満たすには、AI と ML ソリューションの初期コンセプトから、開発、デプロイ、継続的な運用に至るまで、包括的なセキュリティ アプローチを採用する必要があります。 Google Cloud には、AI と ML ワークロードの保護に役立つように設計された堅牢なツールとサービスが用意されています。

このドキュメントの推奨事項は、次の基本原則にマッピングされています。

AI セキュリティの詳細については、次のリソースもご覧ください。

  • Google Cloudのセキュア AI フレームワーク（SAIF）は、安全で責任ある AI システムを構築するための包括的なガイドを提供します。このドキュメントでは、AI ライフサイクル全体を通してセキュリティとコンプライアンスの考慮事項に対処するための重要な原則とベスト プラクティスについて説明します。
  • AI の信頼性に対する Google Cloudのアプローチの詳細については、コンプライアンス リソース センターをご覧ください。

明確な目標と要件を定義する

効果的な AI と ML のセキュリティは、ビジネス戦略全体の重要な要素です。必要なセキュリティとコンプライアンスのコントロールは、開発後に追加するよりも、設計と開発プロセスの早い段階で統合するほうが簡単です。

設計と開発のプロセスの開始から、特定のリスク環境と特定のビジネスの優先事項に適した決定を行います。たとえば、過度に制限的なセキュリティ対策はデータを保護するかもしれませんが、イノベーションを阻害し、開発サイクルを遅らせる可能性もあります。しかし、セキュリティが不十分だと、データ侵害、評判の低下、経済的損失につながり、ビジネスの目標に悪影響を及ぼします。

明確な目標と要件を定義するには、次の推奨事項を考慮してください。

AI と ML のセキュリティをビジネス目標に合わせる

AI と ML のセキュリティ対策をビジネス目標と整合させるには、AI ライフサイクルのすべてのステージにセキュリティを統合する戦略的なアプローチを使用します。この方法を使用する手順は次のとおりです。

  1. 明確なビジネス目標とセキュリティ要件を定義する:

    • 主要なビジネス目標を特定する: AI と ML のイニシアチブが達成するように設計された明確なビジネス目標を定義します。たとえば、カスタマー エクスペリエンスの向上、オペレーションの最適化、新製品の開発などが目標になります。
    • 目標をセキュリティ要件に変換する: ビジネス目標を明確にしたら、それらの目標をサポートする具体的なセキュリティ要件を定義します。たとえば、AI を使用して顧客へのおすすめをパーソナライズすることが目標であるとします。この目標をサポートするために、顧客データのプライバシーを保護し、レコメンデーション アルゴリズムへの不正アクセスを防止することがセキュリティ要件になる場合があります。

  2. セキュリティとビジネスニーズのバランスを取る:

    • リスク評価を実施する: AI システムに潜むセキュリティ上の脅威と脆弱性を特定します。
    • セキュリティ対策に優先順位を付ける: これらのセキュリティ対策の優先順位は、ビジネス目標に与える潜在的な影響に基づいて決定します。
    • 費用とメリットを分析する: 最も効果的なソリューションに投資します。さまざまなセキュリティ対策の費用とメリットを検討します。
    • セキュリティのシフトレフト: 設計フェーズの早い段階でセキュリティのベスト プラクティスを実装し、ビジネスニーズの変化や脅威の出現に応じて安全対策を調整します。

潜在的な攻撃ベクトルとリスクを特定する

データ ポイズニング、モデル反転、敵対的攻撃など、AI システムに影響を与える可能性のある攻撃ベクトルを検討します。AI システムの開発に伴い、進化する攻撃対象領域を継続的にモニタリングして評価し、新しい脅威と脆弱性を追跡します。AI システムの変更によって、攻撃対象領域も変化する可能性があることに注意してください。

潜在的な法的リスクや評判リスクを軽減するには、データ プライバシー、アルゴリズム バイアス、その他の関連規制に関連するコンプライアンス要件にも対処する必要があります。

潜在的な脅威や脆弱性を早期に予測し、リスクを軽減する設計を選択するには、安全性を重視した設計アプローチを採用します。

Google Cloud には、安全性を重視した設計アプローチの実装に役立つ包括的なツールとサービスが用意されています。

  • クラウド ポスチャー管理: Security Command Center を使用して、AI インフラストラクチャの潜在的な脆弱性と構成ミスを特定します。
  • 攻撃の発生可能性スコアと攻撃パス: Security Command Center が生成する攻撃の発生可能性スコアと攻撃パスを調整して使用します。
  • Google Threat Intelligence: AI システムを標的とする新しい脅威や攻撃手法に関する最新情報を把握します。
  • ロギングとモニタリング: AI システムのパフォーマンスとセキュリティを追跡し、異常や不審なアクティビティを検出します。定期的にセキュリティ監査を実施して、AI インフラストラクチャとモデルの潜在的な脆弱性を特定して対処します。
  • 脆弱性の管理: 脆弱性の管理プロセスを実装して、AI システムのセキュリティ脆弱性を追跡して修正します。

詳細については、Google の Secure by Design と Security by Design を実装するをご覧ください。

データを安全に保ち、損失や不正使用を防止する

データは貴重で機密性の高い資産であり、安全に保つ必要があります。データ セキュリティは、ユーザーの信頼を維持して、ビジネス目標をサポートし、コンプライアンス要件を満たすのに役立ちます。

データを安全に保護するため、次の推奨事項を考慮してください。

データの最小化の原則を遵守する

データのプライバシーを確保するには、データの最小化の原則を遵守します。データを最小限に抑えるため、ビジネス目標に厳密に必要でないデータは収集、保持、使用しないでください。可能であれば、合成データまたは完全に匿名化されたデータを使用してください。

データの収集は、ビジネス インサイトと分析の推進に役立ちますが、データ収集プロセスでは慎重に判断することが重要です。顧客に関する個人情報（PII）を収集したり、機密情報を開示したり、バイアスや論争を引き起こしたりすると、バイアスのある ML モデルが構築される可能性があります。

Google Cloud 機能を使用すると、さまざまなユースケースでデータの最小化とデータ プライバシーを改善できます。

  • データを匿名化し、その有用性を維持するには、仮名化、匿名化、バケット化などの一般化などの変換方法を適用します。これらのメソッドを実装するには、Sensitive Data Protection を使用します。
  • リソースを長期間のアクセスや操作から保護するには、Cloud Storage の機能を使用してデータ ライフサイクルを制御します。

データ暗号化の実装方法に関するベスト プラクティスについては、Well-Architected Framework の保存データと転送データの暗号化をご覧ください。

データの収集、保存、変換をモニタリングする

AI アプリケーションのトレーニング データは、バイアスやデータ漏洩の導入に最大のリスクをもたらします。コンプライアンスを維持し、異なるチーム間でデータを管理するには、データフロー、変換、アクセスをモニタリングするデータ ガバナンス レイヤを確立します。データアクセスと操作アクティビティのログを保持します。ログは、データアクセスの監査、不正アクセスの試みの検出、不要なアクセスの防止に役立ちます

Google Cloud の機能を使用して、データ ガバナンス戦略を実装できます。

  • 組織全体または部門全体のデータ ガバナンス プラットフォームを確立するには、Knowledge Catalog を使用します。データ ガバナンス プラットフォームを使用すると、データ プラットフォーム全体でデータと AI アーティファクトを一元的に検出、管理、モニタリング、統制できます。データ ガバナンス プラットフォームは、信頼できるユーザーにアクセス権を付与します。Knowledge Catalog では、次のタスクを実行できます。
    • データリネージを管理します。BigQuery では、列レベルのリネージも提供できます。
    • データ品質チェックとデータ プロファイルを管理します。
    • さまざまなデータマートにわたるデータの検出、探索、処理を管理する。
    • 特徴メタデータとモデル アーティファクトを管理する。
    • ビジネス用語集を作成してメタデータを管理し、標準化された用語集を確立します。
    • アスペクトとアスペクト タイプを使用して、コンテキストでメタデータを拡充します。
    • BigLake と、Iceberg や Delta などのオープン フォーマット テーブル間でデータ ガバナンスを統合します。
    • データメッシュを構築して、異なるチームまたはドメインのデータオーナー間でデータ所有権を分散します。この方法はデータ セキュリティの原則に準拠しており、データのアクセス性と運用効率の向上に役立ちます。
    • BigQuery から Knowledge Catalog にセンシティブ データの検査結果を送信します。
  • 適切に管理された統合オープン レイクハウスを構築するには、データレイクとウェアハウスを Dataproc Metastore や Lakehouse ランタイム カタログなどのマネージド メタストア サービスと統合します。オープン レイクハウスは、さまざまなデータ処理エンジンと互換性のあるオープン テーブル形式を使用します。
  • 特徴と特徴グループのモニタリングをスケジュールするには、Agent Platform Feature Store を使用します。
  • 組織、フォルダ、プロジェクトのいずれかのレベルで Agent Platform データセットをスキャンするには、Agent Platform の機密データの検出を使用します。BigQuery に保存されているデータ プロファイルを分析することもできます。
  • リアルタイム ログをキャプチャし、データ パイプラインに関連する指標を収集するには、Cloud Logging と Cloud Monitoring を使用します。API 呼び出しの監査証跡を収集するには、Cloud Audit Logs を使用します。テストや別のログサーバーに PII や機密データを記録しないでください。

最小権限の原則に基づいてロールベース アクセス制御を実装する

ロールベース アクセス制御（RBAC）を実装して、ユーザーロールに基づいて異なるレベルのアクセス権を割り当てます。ユーザーには、ロール アクティビティの実行に必要な最小限の権限のみを付与する必要があります。最小権限の原則に基づいて権限を割り当て、ユーザーが必要なアクセス権（アクセスなし、読み取り専用、書き込みなど）のみを持つようにします。

組織がデータレイク、Feature Store、モデル トレーニングのハイパーパラメータに存在する機密データを使用する場合、最小権限の RBAC はセキュリティにとって重要です。この方法により、データの盗難を防ぎ、モデルの整合性を維持し、事故や攻撃の対象領域を制限できます。

これらのアクセス戦略を実装するには、次のGoogle Cloud 機能を使用します。

  • アクセスを細かく設定するには、次のオプションを検討してください。

    • さまざまなプロダクトの Identity and Access Management（IAM）ロールをユーザー、グループ、サービス アカウントにマッピングして、きめ細かいアクセスを可能にします。プロジェクトのニーズ、アクセス パターン、タグに基づいて、これらのロールをマッピングします。
    • 条件付きの IAM ポリシーを設定して、データ、モデル、モデル構成（コード、リソース設定、ハイパーパラメータなど）へのきめ細かいアクセスを管理します。

    • アプリケーション レベルのきめ細かいアクセスを調べて、チーム外で監査して共有する機密データを保護します。

  • 特定のリソースへのアクセスを制限するには、プリンシパル アクセス境界（PAB）ポリシーを使用します。Privileged Access Manager を使用して、特定のプリンシパルに対するジャストインタイムの一時的な権限昇格を制御することもできます。後で、この Privileged Access Manager アクティビティの監査ログを表示できます。

  • IP アドレスとエンドユーザーのデバイス属性に基づいてリソースへのアクセスを制限するには、Identity-Aware Proxy（IAP）アクセス ポリシーを拡張します。

  • さまざまなユーザー グループのアクセス パターンを作成するには、IAM による Agent Platform のアクセス制御を使用して、事前定義ロールまたはカスタムロールを組み合わせます。

  • コンテキストアウェア アクセス制御を使用して Gemini Enterprise Agent Platform Workbench インスタンスを保護するには、Access Context Manager と Chrome Enterprise Premium を使用します。このアプローチでは、ユーザーがインスタンスに対して認証されるたびにアクセスが評価されます。

データ移動のセキュリティ対策を実装する

安全な境界と、暗号化やデータ移動の制限などの対策を実装します。これらの対策は、データの引き出しとデータ損失の防止に役立ちます。データの引き出しとデータ損失は、財務上の損失、風評被害、法的責任、ビジネス オペレーションの中断を引き起こす可能性があります。

Google Cloudでのデータの引き出しと損失を防ぐには、セキュリティ ツールとサービスを組み合わせて使用します。

暗号化を実装する場合は、次の点を考慮してください。

  • 暗号鍵をより細かく制御するには、Cloud Key Management Service で顧客管理の暗号鍵（CMEK）を使用します。CMEK を使用すると、次の CMEK 統合サービスで保存データが暗号化されます。
  • Cloud Storage のデータを保護するには、サーバーサイド暗号化を使用して CMEK を保存します。独自のサーバーで CMEK を管理している場合、CMEK ストレージ システムが侵害されても、サーバーサイド暗号化により CMEK と関連データを保護できます。
  • 転送中のデータを暗号化するには、AI サービスと ML サービスへのすべての API 呼び出しに HTTPS を使用します。アプリケーションと API に HTTPS を適用するには、HTTPS ロードバランサを使用します。

データを暗号化する方法に関するその他のベスト プラクティスについては、Well-Architected Framework のセキュリティの柱にある保存データと転送データを暗号化するをご覧ください。

境界を実装する際は、次の点を考慮してください。

  • AI リソースと ML リソースの周囲にセキュリティ境界を作成し、Virtual Private Cloud（VPC）からのデータの引き出しを防ぐには、VPC Service Controls を使用してサービス境界を定義します。AI と ML のリソースと機密データを境界に含めます。データフローを制御するには、境界の上り（内向き）ルールと下り（外向き）ルールを構成します。
  • AI リソースと ML リソースへのインバウンド トラフィックとアウトバウンド トラフィックを制限するには、ファイアウォール ルールを構成します。デフォルトですべてのトラフィックを拒否し、条件を満たすトラフィックのみを明示的に許可するポリシーを実装します。ポリシーの例については、例: 特定のポートへの接続を除き、すべての外部接続を拒否するをご覧ください。

データ移動に制限を実装するには、次の点を考慮してください。

  • 安全な環境でデータを共有し、プライバシーの境界を越えてスケーリングするには、堅牢なセキュリティとプライバシーのフレームワークを提供する BigQuery Sharing と BigQuery データ クリーンルームを使用します。
  • ビジネス インテリジェンス ダッシュボードから組み込みの宛先にデータを直接共有するには、安全なクラウド環境を提供する Looker Action Hub を使用します。

データ汚染を防ぐ

データ ポイズニングは、攻撃者がトレーニング データセットに悪意のあるデータを挿入して、モデルの動作を操作したり、パフォーマンスを低下させたりするサイバー攻撃の一種です。このサイバー攻撃は、ML トレーニング システムにとって重大な脅威となる可能性があります。データの有効性と品質を保護するには、データを保護するプラクティスを維持します。このアプローチは、モデルの一貫したバイアスの排除、信頼性、整合性を確保するために不可欠です。

データに対する不整合な動作、変換、予期しないアクセスを追跡するには、データ パイプラインと ML パイプラインの包括的なモニタリングとアラートを設定します。

Google Cloud 機能を使用すると、データ ポイズニングに対する保護を強化できます。

  • データの完全性を検証するには、次の点を考慮してください。

    • トレーニングにデータを使用する前に、堅牢なデータ検証チェックを実装します。データ形式、範囲、分布を確認します。Knowledge Catalog の自動データ品質機能を使用できます。
    • Model Armor で Sensitive Data Protection を使用して、包括的なデータ損失防止機能を活用します。詳細については、Model Armor の概要をご覧ください。Model Armor で Sensitive Data Protection を使用すると、知的財産などの機密データを検出、分類、保護できます。これらの機能は、LLM のインタラクションで機密データが不正に公開されるのを防ぐのに役立ちます。
    • データ ポイズニングを示す可能性のあるトレーニング データの異常を検出するには、統計的手法または ML モデルで BigQuery の異常検出を使用します。

  • 堅牢なトレーニングを準備するには、次の操作を行います。

    • アンサンブル手法を使用して、ポイズニングされたデータポイントの影響を軽減します。ハイパーパラメータ チューニングを使用して、データの異なるサブセットで複数のモデルをトレーニングする。
    • データ拡張手法を使用して、データセット間のデータの分布をバランスよく調整します。このアプローチにより、データ ポイズニングの影響を軽減し、敵対的な例を追加できます。

  • トレーニング データまたはモデル出力に人間によるレビューを組み込むには、次の操作を行います。

    • モデル評価指標を分析して、データ ポイズニングを示す可能性のある潜在的なバイアス、異常、予期しない動作を検出します。詳細については、Agent Platform でのモデル評価をご覧ください。
    • ドメインの専門知識を活用してモデルまたはアプリケーションを評価し、自動化された方法では検出できない不審なパターンやデータポイントを特定します。詳細については、Gen AI Evaluation Service の概要をご覧ください。

インフラストラクチャとデータ セキュリティに重点を置いたデータ プラットフォームを作成するためのベスト プラクティスについては、Well-Architected Framework のセキュリティ バイ デザインを実装する原則をご覧ください。

AI パイプラインの安全性を確保し、改ざんに対して堅牢性を維持する

AI コードと ML コード、コード定義パイプラインは重要なアセットです。保護されていないコードは改ざんされる可能性があり、データ漏洩、コンプライアンス違反、重要なビジネス アクティビティの中断につながる可能性があります。AI コードと ML コードを安全に保つことは、モデルとモデル出力の完全性と価値を確保するのに役立ちます。

AI コードとパイプラインの安全性を維持するには、次の推奨事項を考慮してください。

安全なコーディング手法を使用する

脆弱性を防ぐには、モデルの開発時に安全なコーディング手法を使用します。AI 固有の入力と出力の検証を実装し、すべてのソフトウェア依存関係を管理して、安全なコーディング原則を開発に一貫して組み込むことをおすすめします。データの事前処理から最終的なアプリケーション コードまで、AI ライフサイクルのあらゆる段階にセキュリティを組み込みます。

厳格な検証を実装するには、次の点を考慮してください。

  • モデルの操作やシステムのエクスプロイトを防ぐには、コードで入力と出力を検証してサニタイズします。

    • Model Armor またはファインチューニングされた LLM を使用して、一般的なリスクについてプロンプトとレスポンスを自動的にスクリーニングします。
    • データ取り込みスクリプトと前処理スクリプト内で、データ型、形式、範囲のデータ検証を実装します。Gemini Enterprise Agent Platform Pipelines または BigQuery の場合、Python を使用してこのデータ検証を実装できます。
    • CodeMender などのコーディング支援 LLM エージェントを使用して、コードのセキュリティを強化します。人間参加型で、提案された変更を検証します。

  • AI モデルの API エンドポイントを管理して保護するには、Apigee を使用します。これには、リクエスト検証、トラフィック制御、認証などの構成可能な機能が含まれています。

  • AI ライフサイクル全体にわたってリスクを軽減するために、AI 保護を使用して次のことができます。

    • 環境内の AI インベントリを検出します。
    • インベントリの潜在的な脆弱性を評価します。
    • 制御、ポリシー、保護によって AI アセットを保護します。
    • 検出、調査、対応の機能を使用して AI システムを管理します。

CI / CD パイプラインでコードとアーティファクトの依存関係を保護するには、次の点を考慮してください。

  • オープンソース ライブラリの依存関係がプロジェクトにもたらすリスクに対処するには、Artifact Registry で Artifact Analysis を使用して、既知の脆弱性を検出します。承認されたバージョンのライブラリを使用し、維持します。カスタム ML パッケージと検証済みの依存関係をプライベート Artifact Registry リポジトリに保存します。
  • Cloud Build MLOps パイプラインに依存関係スキャンを埋め込むには、Binary Authorization を使用します。コードのコンテナ イメージがセキュリティ チェックに合格した場合にのみデプロイを許可するポリシーを適用します。
  • ソフトウェア サプライ チェーンに関するセキュリティ情報を取得するには、 Google Cloud コンソールのダッシュボードを使用します。このダッシュボードには、ソース、ビルド、アーティファクト、デプロイ、ランタイムに関する詳細が表示されます。この情報には、ビルド アーティファクト、ビルドの来歴、ソフトウェア部品構成表（SBOM）の依存関係リストの脆弱性が含まれます。
  • ソフトウェア サプライ チェーンのセキュリティの成熟度を評価するには、ソフトウェア アーティファクトのためのサプライ チェーン レベル（SLSA）のフレームワークを使用します。

開発のすべての段階で安全なコーディングの原則を一貫して組み込むには、次の点を考慮してください。

  • モデルのインタラクションから機密データが公開されないようにするには、Sensitive Data Protection でロギングを使用します。これらのプロダクトを組み合わせて使用すると、AI アプリケーションとパイプライン コンポーネントがログに記録するデータを制御し、機密データを非表示にできます。
  • 最小権限の原則を実装するには、Agent Platform のカスタムジョブ、パイプライン、デプロイされたモデルに使用するサービス アカウントに、必要な最小限の IAM 権限のみが付与されていることを確認します。詳細については、最小権限の原則を使用してロールベース アクセス制御を実装するをご覧ください。
  • パイプラインとビルド アーティファクトを保護するには、コードが実行される環境のセキュリティ構成（VPC と VPC Service Controls）を理解します。

パイプラインとモデル アーティファクトを不正アクセスから保護する

モデル アーティファクトとパイプラインは知的財産であり、トレーニング データにも専有情報が含まれています。モデルの重み、ファイル、デプロイ構成を改ざんや脆弱性から保護するには、セキュリティを強化してこれらのアーティファクトを保存してアクセスします。ユーザーのロールとニーズに基づいて、アーティファクトごとに異なるアクセスレベルを実装します。

モデル アーティファクトを保護するには、次の点を考慮してください。

  • モデル アーティファクトやその他の機密ファイルを保護するには、Cloud KMS で暗号化します。この暗号化により、基盤となるストレージが侵害された場合でも、保存データと転送中のデータが保護されます。
  • ファイルへのアクセスを保護するには、ファイルを Cloud Storage に保存し、アクセス制御を構成します。
  • 不適切な構成や不十分な構成、定義された標準からの逸脱を追跡するには、Security Command Center を使用してセキュリティ ポスチャーを構成します。
  • きめ細かいアクセス制御と保存データの暗号化を有効にするには、モデル アーティファクトを Gemini Enterprise Agent Platform の Model Registry に保存します。セキュリティを強化するには、承認されたビルドプロセス中に生成されるパッケージとコンテナのデジタル署名を作成します。
  • Google Cloudのエンタープライズ グレードのセキュリティを活用するには、Model Garden で利用可能なモデルを使用します。Model Garden は、Google 独自のモデルを提供し、注目のパートナーのサードパーティ モデルを提供します。

  • すべてのユーザーとグループのライフサイクルの一元管理を適用し、最小権限の原則を適用するには、IAM を使用します。

    • MLOps パイプライン専用の最小権限のサービス アカウントを作成して使用します。たとえば、トレーニング パイプラインのサービス アカウントには、特定の Cloud Storage バケットからデータを読み取り、モデル アーティファクトを Model Registry に書き込む権限があります。
    • IAM Conditions を使用して、条件付きの属性ベースのアクセス制御を適用します。たとえば、信頼できる Cloud Build トリガーからリクエストが送信された場合にのみ、サービス アカウントが Agent Platform パイプラインをトリガーできるようにする条件を設定できます。

デプロイ パイプラインを保護するには、次の点を考慮してください。

  • Google Cloud サービスとリソースで MLOps ステージを管理するには、Agent Platform Pipelines を使用します。Agent Platform Pipelines は、他のサービスと統合して、低レベルのアクセス制御を提供できます。パイプラインを再実行するときは、モデル アーティファクトをデプロイする前に、説明可能性の評価（特徴アトリビューションなど）と責任ある AI のチェックを行ってください。これらのチェックは、次のセキュリティ問題の検出または防止に役立ちます。

    • 不正な変更。モデルの改ざんを示している可能性があります。
    • クロスサイト スクリプティング（XSS）。コンテナ イメージまたは依存関係が侵害されていることを示す可能性があります。
    • 安全でないエンドポイント。これは、サービス提供インフラストラクチャの構成ミスを示している可能性があります。

  • 推論中のモデルのやり取りを保護するには、ビルド済みコンテナまたはカスタム コンテナで Private Service Connect に基づくプライベート エンドポイントを使用します。事前定義された入力スキーマと出力スキーマを使用してモデル署名を作成する。

  • コード変更の追跡を自動化するには、ソースコード管理に Git を使用し、バージョン管理を堅牢な CI / CD パイプラインと統合します。

詳細については、セキュア AI フレームワーク（SAIF）をご覧ください。

リネージとトラッキングを適用する

規制遵守要件を満たすために、AI アセットと ML アセットのリネージとトラッキングを適用します。データリネージとトラッキングにより、データ、モデル、コードの広範な変更レコードが提供されます。モデルの来歴は、AI と ML のライフサイクル全体にわたって透明性と説明責任を提供します。

Google Cloudでリネージとトラッキングを効果的に適用するには、次のツールとサービスを検討してください。

  • 保存データの暗号化が自動的に行われるモデル、データセット、アーティファクトのリネージを追跡するには、Agent Platform ML Metadata を使用します。データソース、変換、モデル パラメータ、テスト結果に関するメタデータをログに記録します。
  • Agent Platform Pipelines からパイプライン アーティファクトのリネージを追跡し、モデルとデータセットのリソースを検索するには、Knowledge Catalog を使用します。デバッグ、トラブルシューティング、根本原因分析を行う場合は、個々のパイプライン アーティファクトを追跡します。パイプライン アーティファクトのリネージを含む MLOps パイプライン全体を追跡するには、Agent Platform ML Metadata を使用します。Agent Platform ML Metadata を使用すると、リソースと実行を分析することもできます。Model Registry は、保存する各モデルのバージョンを適用して管理します。
  • API 呼び出しと管理アクションを追跡するには、Agent Platform の監査ログを有効にします。オブザーバビリティ分析で監査ログを分析して、データやモデルにアクセスまたは変更したユーザーと、その日時を把握します。サードパーティの宛先にログを転送することもできます。

安全なツールとアーティファクトを使用して安全なシステムにデプロイする

コードとモデルが安全な環境で実行されるようにします。この環境には、堅牢なアクセス制御システムが実装され、デプロイするツールとアーティファクトのセキュリティが保証されている必要があります。

安全なシステムにコードをデプロイするには、次の推奨事項を検討してください。

安全な環境でモデルをトレーニングしてデプロイする

AI システムと ML システムのシステムの整合性、機密性、可用性を維持するには、不正なリソース操作を防ぐ厳格なアクセス制御を実装します。この防御により、次のことが可能になります。

  • 予期しない結果や競合する結果を生成する可能性のあるモデルの改ざんを軽減します。
  • プライバシー侵害からトレーニング データを保護します。
  • サービスの稼働時間を維持する。
  • 規制遵守を維持する。
  • ユーザーの信頼を構築する。

セキュリティが強化された環境で ML モデルをトレーニングするには、Cloud Run、Google Kubernetes Engine（GKE）、Managed Service for Apache Spark などの Google Cloud のマネージド サービスを使用します。Agent Platform サーバーレス トレーニングを使用することもできます。

このセクションでは、トレーニング環境とデプロイ環境のセキュリティをさらに強化するための推奨事項について説明します。

環境と境界を保護するには、次の点を考慮してください。

デプロイを保護するには、次の点を考慮してください。

  • モデルをデプロイするときは、Model Registry を使用します。コンテナにモデルをデプロイする場合は、GKE Sandbox と Container-Optimized OS を使用して、セキュリティを強化し、ワークロードを分離します。ユーザーのロールと責任に応じて、Model Garden のモデルへのアクセスを制限します。
  • モデル API を保護するには、Apigee または API Gateway を使用します。不正使用を防ぐには、API キー、認証、認可、レート制限を実装します。モデル API へのアクセスを制御するには、API キーと認証メカニズムを使用します。
  • 予測中にモデルへのアクセスを保護するには、Gemini Enterprise Agent Platform Inference を使用します。データの引き出しを防ぐには、VPC Service Controls の境界を使用してプライベート エンドポイントを保護し、基盤となるモデルへのアクセスを管理します。プライベート エンドポイントを使用して、VPC ネットワーク内のモデルへのアクセスを有効にします。IAM はプライベート エンドポイントに直接適用されませんが、ターゲット サービスは IAM を使用してモデルへのアクセスを管理します。オンライン予測には、Private Service Connect を使用することをおすすめします。
  • モデルのデプロイに関連する API 呼び出しを追跡するには、Agent Platform の Cloud Audit Logs を有効にします。関連する API 呼び出しには、エンドポイントの作成、モデルのデプロイ、構成の更新などのアクティビティが含まれます。
  • Google Cloud インフラストラクチャをエッジ ロケーションに拡張するには、Google Distributed Cloud ソリューションを検討してください。完全に切断されたソリューションの場合は、Distributed Cloud エアギャップを使用できます。これには Google Cloudへの接続は必要ありません。
  • デプロイを標準化し、規制とセキュリティのニーズを確実に遵守するには、Assured Workloads を使用します。

AI アーティファクトに関する SLSA ガイドラインに沿う

モデルやソフトウェア パッケージなどの AI 固有のアーティファクトについては、標準のソフトウェア アーティファクトのためのサプライチェーン レベル（SLSA）ガイドラインに従います。

SLSA は、ソフトウェア アーティファクトの完全性を向上させ、改ざんを防止するためのセキュリティ フレームワークです。SLSA ガイドラインに準拠すると、AI と ML のパイプラインと、パイプラインが生成するアーティファクトのセキュリティを強化できます。SLSA に準拠すると、次のようなメリットがあります。

  • AI アーティファクトと ML アーティファクトの信頼性の向上: SLSA は、モデルやソフトウェア パッケージの改ざんを防ぐのに役立ちます。ユーザーは、モデルやソフトウェア パッケージをソースまで追跡することもできます。これにより、アーティファクトの整合性と信頼性に対するユーザーの信頼が高まります。
  • サプライ チェーン攻撃のリスクの低減: SLSA は、悪意のあるコードを挿入する攻撃やビルドプロセスを侵害する攻撃など、ソフトウェア サプライ チェーンの脆弱性を悪用する攻撃のリスクを軽減するのに役立ちます。
  • セキュリティ ポスチャーの強化: SLSA は、AI システムと ML システムの全体的なセキュリティ ポスチャーを強化するのに役立ちます。この実装により、攻撃のリスクを軽減し、貴重なアセットを保護できます。

Google Cloudで AI アーティファクトと ML アーティファクトに SLSA を実装する手順は次のとおりです。

  1. SLSA レベルを理解する: さまざまな SLSA レベルとその要件を理解します。レベルが上がるにつれて、提供される整合性も向上します。
  2. 現在のレベルを評価する: SLSA フレームワークに照らして現在のプラクティスを評価し、現在のレベルを判断して改善点を特定します。
  3. 目標レベルを設定する: リスク許容度、セキュリティ要件、AI システムと ML システムの重要度に基づいて、適切な SLSA レベルを決定します。

  4. SLSA 要件を実装する: 目標の SLSA レベルを達成するには、必要な制御とプラクティスを実装します。これには、次のものが含まれます。

    • ソース管理: Git などのバージョン管理システムを使用して、コードと構成の変更を追跡します。
    • ビルドプロセス: Cloud Build などのビルドの保護に役立つサービスを使用し、ビルドプロセスがスクリプト化または自動化されていることを確認します。
    • 来歴の生成: ビルドプロセス、ソースコード、依存関係など、アーティファクトのビルド方法に関する詳細をキャプチャする来歴メタデータを生成します。詳細については、メタデータを追跡すると実行とアーティファクトを追跡するをご覧ください。
    • アーティファクトの署名: アーティファクトに署名して、その真正性と完全性を検証します。
    • 脆弱性の管理: アーティファクトと依存関係の脆弱性を定期的にスキャンします。Artifact Analysis などのツールを使用します。
    • デプロイのセキュリティ: このドキュメントで説明されているプラクティスなど、システムの保護に役立つデプロイ プラクティスを実装します。

  5. 継続的な改善: SLSA の実装をモニタリングして改善し、新しい脅威と脆弱性に対処して、より高い SLSA レベルを目指します。

検証済みのビルド済みコンテナ イメージを使用する

MLOps ステージの単一障害点を回避するには、異なる依存関係管理を必要とするタスクを異なるコンテナに分離します。たとえば、特徴量エンジニアリング、トレーニングまたはファインチューニング、推論タスクに別々のコンテナを使用します。このアプローチでは、ML エンジニアが環境を柔軟に制御、カスタマイズすることもできます。

組織全体で MLOps の整合性を促進するには、ビルド済みコンテナを使用します。次のベスト プラクティスに沿って、検証済みで信頼できるベース プラットフォーム イメージの中央リポジトリを維持します。

  • 組織内に、標準化されたベースコンテナを構築して管理する一元化されたプラットフォーム チームを維持します。
  • Agent Platform が AI と ML 専用に提供するビルド済みコンテナ イメージを拡張する。組織内の中央リポジトリでコンテナ イメージを管理します。

Agent Platform には、トレーニングと推論用のさまざまなビルド済みコンテナが用意されています。また、カスタム コンテナを使用することもできます。モデルが小さい場合は、コンテナにモデルを読み込むと、推論のレイテンシを短縮できます。

コンテナ管理のセキュリティを向上させるには、次の推奨事項を検討してください。

  • Artifact Registry を使用して、さまざまな形式のコンテナ イメージのリポジトリを作成、保存、管理します。Artifact Registry は IAM でアクセス制御を処理し、オブザーバビリティと脆弱性評価機能を統合しています。Artifact Registry を使用すると、コンテナ セキュリティ機能を有効にし、コンテナ イメージをスキャンして、脆弱性を調査できます。
  • Cloud Build で継続的インテグレーションの手順を実行し、コンテナ イメージをビルドします。この段階で、依存関係の問題が明らかになることがあります。Cloud Build によってビルドされたイメージのみをデプロイする場合は、Binary Authorization を使用できます。サプライ チェーン攻撃を防ぐため、Cloud Build でビルドされたイメージを Artifact Registry にデプロイします。SonarQube、PyLint、OWASP ZAP などの自動テストツールを統合する。
  • AI ワークロードと ML ワークロードの GPU または Cloud TPU 向けに最適化された GKE や Cloud Run などのコンテナ プラットフォームを使用します。GKE クラスタ内のコンテナの脆弱性スキャン オプションを検討します。

GPU 向けの Confidential Computing を検討する

使用中のデータを保護するには、Confidential Computing を使用します。従来のセキュリティ対策では、保存データと転送中のデータが保護されますが、Confidential Computing では処理中のデータが暗号化されます。GPU 向け Confidential Computing を使用すると、機密性の高いトレーニング データとモデル パラメータを不正アクセスから保護できます。また、特権クラウド ユーザーや、基盤となるインフラストラクチャにアクセスする可能性のある攻撃者による不正アクセスを防止することもできます。

GPU 向け Confidential Computing が必要かどうかを判断するには、データの機密性、規制要件、潜在的なリスクを考慮します。

Confidential Computing を設定する場合は、次のオプションを検討してください。

  • 汎用 AI / ML ワークロードには、NVIDIA T4 GPU を搭載した Confidential VM インスタンスを使用します。これらの VM インスタンスは、使用中のデータのハードウェア ベースの暗号化を提供します。
  • コンテナ化されたワークロードの場合は、Confidential Google Kubernetes Engine Node を使用します。これらのノードは、Pod に安全で隔離された環境を提供します。
  • ワークロードが正規の安全なエンクレーブで実行されていることを確認するには、Confidential VM が提供する構成証明レポートを検証します。
  • パフォーマンス、リソース使用率、セキュリティ イベントを追跡するには、Monitoring と Logging を使用して、Confidential Computing リソースと Confidential GKE Node をモニタリングします。

入力を検証して保護する

エンドユーザーからの入力か、他の自動システムからの入力かにかかわらず、AI システムへのすべての入力を信頼できないものとして扱います。AI システムの安全性を確保し、意図したとおりに動作させるには、潜在的な攻撃ベクトルを早期に検出してサニタイズする必要があります。

入力を検証して保護するには、次の推奨事項を検討してください。

生成 AI システムのセキュリティを確保するための手法を導入する

プロンプトは、コードと同様にセキュリティにとって重要なアプリケーション コンポーネントとして扱います。プロアクティブな設計、自動スクリーニング、規律あるライフサイクル管理を組み合わせた多層防御戦略を実装します。

生成 AI プロンプトを保護するには、セキュリティを考慮して設計し、使用前にスクリーニングして、ライフサイクル全体で管理する必要があります。

プロンプトの設計とエンジニアリングのセキュリティを向上させるには、次のプラクティスを検討してください。

  • プロンプトを明確に構成する: Gemini Enterprise Agent Platform の Agent Studio のプロンプト管理機能を使用して、すべてのプロンプトを設計してテストします。プロンプトは、明確であいまいさのない構造にする必要があります。ロールを定義し、少数ショットの例を含め、具体的で限定的な指示を与えます。これらの方法により、モデルがユーザーの入力を誤って解釈し、セキュリティ上の抜け穴が生じるリスクを軽減できます。

  • 堅牢性とグラウンディングについて入力をテストする: クラッシュや安全でない出力を防ぐため、予期しない入力、不正な入力、悪意のある入力に対して、すべてのシステムを事前にテストします。レッドチーム テストを使用して、実際の攻撃をシミュレートします。Agent Platform Pipelines の標準ステップとして、堅牢性テストを自動化します。次のテスト手法を使用できます。

    • ファズテスト。
    • PII、機密性の高い入力、SQL インジェクションに対して直接テストします。
    • マルウェアが含まれている可能性や、プロンプト ポリシーに違反している可能性があるマルチモーダル入力をスキャンします。

  • 多層防御を実装する: 複数の防御策を使用し、単一の防御策に依存しないようにします。たとえば、検索拡張生成（RAG）に基づくアプリケーションの場合、別の LLM を使用して、受信したユーザー インテントを分類し、悪意のあるパターンをチェックします。その後、その LLM は、最終的なレスポンスを生成する、より強力なプライマリ LLM にリクエストを渡すことができます。

  • 入力をサニタイズして検証する: 外部入力やユーザー提供の入力をプロンプトに組み込む前に、アプリケーション コードですべての入力をフィルタして検証します。この検証は、間接的なプロンプト インジェクションを防ぐために重要です。

プロンプトとレスポンスの自動スクリーニングについては、次の方法を検討してください。

  • 包括的なセキュリティ サービスを使用する: Model Armor などの専用のモデルに依存しないセキュリティ サービスを、LLM の必須の保護レイヤとして実装します。Model Armor は、プロンプト インジェクション、ジェイルブレイクの試み、有害なコンテンツなどの脅威がないか、プロンプトとレスポンスを検査します。モデルのレスポンスでセンシティブなトレーニング データや知的財産が漏洩しないようにするには、Model Armor と Sensitive Data Protection のインテグレーションを使用します。詳細については、Model Armor フィルタをご覧ください。
  • インタラクションをモニタリングしてロギングする: モデル エンドポイントのすべてのプロンプトとレスポンスの詳細なログを保持します。Logging を使用して、これらのやり取りを監査し、不正使用のパターンを特定して、デプロイされたモデルに対して発生する可能性のある攻撃ベクトルを検出します。

プロンプトのライフサイクル管理を保護するには、次の方法を検討してください。

  • プロンプトのバージョニングを実装する: すべての本番環境プロンプトをアプリケーション コードのように扱います。Git などのバージョン管理システムを使用して、変更の完全な履歴を作成し、コラボレーション標準を適用して、以前のバージョンへのロールバックを可能にします。このコア MLOps プラクティスは、安定した安全な AI システムの維持に役立ちます。
  • プロンプト管理を一元化する: 中央リポジトリを使用して、バージョニングされたすべてのプロンプトを保存、管理、デプロイします。この戦略により、環境間の一貫性が確保され、アプリケーションを完全に再デプロイすることなくランタイムを更新できます。
  • 定期的な監査とレッドチーム テストを実施する: LLM アプリケーションに関する OWASP トップ 10 に記載されているような既知の脆弱性に対して、システムの防御を継続的にテストします。AI エンジニアは、攻撃者に悪用される前に弱点を発見して修正するために、プロアクティブに独自のアプリケーションをレッドチーム テストする必要があります。

AI システムへの悪意のあるクエリを防止する

このドキュメントで前述した認証と認可に加えて、悪意のある入力から AI システムを保護するための追加の対策を講じることができます。攻撃者が認証プロトコルと認可プロトコルの両方をバイパスし、システムを内部から攻撃しようとする認証後のシナリオに備えて AI システムを準備する必要があります。

認証後の攻撃からシステムを保護するための包括的な戦略を実装するには、次の要件を適用します。

  • ネットワーク レイヤとアプリケーション レイヤを保護する: すべての AI アセットに多層防御を確立します。

    • Model Registry からのモデルのデータ漏洩や、BigQuery からの機密データの漏洩を防ぐセキュリティ境界を作成するには、VPC Service Controls を使用します。境界を適用する前に、必ずドライラン モードを使用して境界の影響を検証してください。
    • ノートブックなどのウェブベースのツールを保護するには、IAP を使用します。
    • すべての推論エンドポイントを保護するには、エンタープライズ グレードのセキュリティとガバナンスを実現する Apigee を使用します。API Gateway を使用して、簡単な認証を行うこともできます。

  • クエリパターンの異常を監視する: たとえば、システムの脆弱性を探る攻撃者は、わずかに異なるクエリを順番に何千回も送信する可能性があります。通常のユーザー行動を反映していない異常なクエリパターンにフラグを立てます。

  • リクエストの量をモニタリングする: クエリ量が急増した場合は、サービス拒否（DoS）攻撃またはモデルの盗難攻撃（モデルのリバース エンジニアリングを試みる攻撃）の可能性が強く示唆されます。レート制限とスロットリングを使用して、単一の IP アドレスまたはユーザーからのリクエスト量を制御します。

  • 地理的および時間的な異常をモニタリングしてアラートを設定する: 通常のアクセス パターンのベースラインを確立します。通常とは異なる地理的位置や時間帯での突然のアクティビティに対してアラートを生成します。たとえば、午前 3 時に新しい国からのログインが急増した場合などです。

出力のモニタリング、評価、対応の準備

AI システムは、人間の意思決定を補完、最適化、自動化する出力を生成するため、その価値があります。AI システムとアプリケーションの完全性と信頼性を維持するには、出力が安全で、想定されるパラメータ内にあることを確認します。また、インシデントに対応するための計画も必要です。

出力を維持するには、次の推奨事項を検討してください。

指標とセキュリティ対策を使用してモデルのパフォーマンスを評価する

AI モデルがパフォーマンス ベンチマークを満たし、セキュリティ要件を満たし、公平性とコンプライアンスの基準を遵守していることを確認するには、モデルを徹底的に評価します。デプロイ前に評価を行い、本番環境でモデルの評価を定期的に継続します。リスクを最小限に抑え、信頼できる AI システムを構築するには、パフォーマンス指標と特定の AI セキュリティ評価を組み合わせた包括的な評価戦略を実装します。

モデルの堅牢性とセキュリティ ポスチャーを評価するには、次の推奨事項を考慮してください。

  • MLOps パイプラインにモデルの署名と検証を実装する。

    • コンテナ化されたモデルの場合は、Binary Authorization を使用して署名を検証します。
    • Agent Platform エンドポイントに直接デプロイされるモデルの場合は、デプロイ スクリプトでカスタム チェックを使用して検証します。
    • どのモデルでも、モデルの署名には Cloud Build を使用します。

  • 予期しない入力や敵対的な入力に対するモデルの復元力を評価します。

    • すべてのモデルで、一般的なデータ破損や悪意のあるデータ変更の可能性についてモデルをテストします。これらのテストをオーケストレートするには、Agent Platform Managed Training または Agent Platform Pipelines を使用します。
    • セキュリティが重要なモデルの場合は、敵対的攻撃シミュレーションを実施して、潜在的な脆弱性を把握します。
    • コンテナにデプロイされているモデルの場合は、Artifact Registry の Artifact Analysis を使用して、ベースイメージの脆弱性をスキャンします。

  • Gemini Enterprise Agent Platform の Model Monitoring を使用して、デプロイされたモデルのドリフトとスキューを検出します。次に、これらの分析情報を再評価サイクルまたは再トレーニング サイクルにフィードバックします。

  • Agent Platform Pipelines では、パイプライン コンポーネントとして Agent Platform のモデル評価を使用します。モデル評価コンポーネントは、単独で、または他のパイプライン コンポーネントと一緒に実行できます。定義した指標とデータセットに対してモデル バージョンを比較します。評価結果を Agent Platform ML Metadata に記録して、リネージとトラッキングを行う。

  • Gen AI Evaluation Service を使用または構築して、選択したモデルを評価するか、カスタムの人間による評価ワークフローを実装します。

公平性、バイアス、説明可能性、事実性を評価するには、次の推奨事項を検討してください。

  • ユースケースに一致する公平性の指標を定義し、さまざまなデータスライスにわたって潜在的なバイアスがないかモデルを評価します。
  • モデルの予測を促進する特徴を把握して、特徴と結果の予測がドメイン知識と倫理ガイドラインに沿っていることを確認します。
  • 説明可能性手法を使用して、モデルの特徴アトリビューションを取得する。
  • Gen AI Evaluation Service を使用して指標を計算する。テストのソース検証フェーズでは、サービスのグラウンディング指標が、提供されたソーステキストに対して事実性をチェックします。
  • ユーザーレベルで 2 番目のソース検証を容易にするために、モデルの出力に対してグラウンディングを有効にします。
  • Google の AI に関する原則を確認し、AI アプリケーションに適用します。

本番環境で AI モデルと ML モデルの出力をモニタリングする

本番環境で AI モデルと ML モデル、およびそれらをサポートするインフラストラクチャを継続的にモニタリングします。モデル出力の品質やパフォーマンスの低下、発生するセキュリティの脆弱性、コンプライアンス要件からの逸脱を迅速に特定して診断することが重要です。このモニタリングは、システムの安全性、信頼性、信頼性を維持するのに役立ちます。

AI システムの出力で異常、脅威、品質の低下をモニタリングするには、次の推奨事項を検討してください。

  • Agent Platform で Model Monitoring を使用してモデル出力をモニタリングし、予測分布の予期しない変化や、信頼度の低いモデル予測の急増を追跡します。生成 AI モデルの出力を積極的にモニタリングして、安全でない、バイアスのある、トピックから外れた、または悪意のある生成コンテンツを検出します。Model Armor を使用して、すべてのモデル出力をスクリーニングすることもできます。
  • 特定のエラーパターンを特定し、品質指標をキャプチャします。また、アプリケーション レベルで有害な出力やコンプライアンス違反の出力を検出します。これらの問題を見つけるには、Monitoring ダッシュボードでカスタム モニタリングを使用し、Logging のログベースの指標を使用します。

セキュリティ固有のシグナルと不正な変更をモニタリングするには、次の推奨事項を検討してください。

  • AI モデル、Cloud Storage または BigQuery のデータセット、MLOps パイプライン コンポーネントへの不正アクセスの試みを特定します。特に、AI リソースの IAM 権限で予期しない変更や不正な変更を特定します。これらのアクティビティを追跡し、不審なパターンを調べるには、Cloud Audit Logs の管理アクティビティ監査ログとデータアクセス監査ログを使用します。Security Command Center の検出結果を統合します。これにより、セキュリティ構成ミスにフラグを付け、AI アセットに関連する潜在的な脅威にフラグを付けることができます。
  • 大量のリクエストや不審なソースからのリクエストがないか出力をモニタリングします。これらは、モデルのリバース エンジニアリングやデータの引き出しを試みている可能性があります。また、Sensitive Data Protection を使用して、機密性の高いデータの漏洩をモニタリングすることもできます。
  • ログをセキュリティ運用に統合します。Google Security Operations を使用して、AI システムからのサイバー脅威を検出、オーケストレート、対応します。

AI モデルを提供するインフラストラクチャの運用の健全性とパフォーマンスを追跡するには、次の推奨事項を検討してください。

  • サービス提供やモデルのパフォーマンスに影響を与える可能性のある運用上の問題を特定する。
  • Agent Platform エンドポイントのレイテンシ、エラー率、トラフィック パターンをモニタリングします。
  • MLOps パイプラインの実行ステータスとエラーをモニタリングします。
  • 既製の指標を提供する Monitoring を使用します。カスタム ダッシュボードを作成して、エンドポイントの停止やパイプラインの障害などの問題を特定することもできます。

アラートとインシデント対応の手順を実装する

パフォーマンス、セキュリティ、コンプライアンスに関する潜在的な問題を特定した場合は、効果的な対応が不可欠です。適切なチームにタイムリーに通知されるように、堅牢なアラート メカニズムを実装します。AI を考慮した包括的なインシデント対応手順を確立して運用し、これらの問題を効率的に管理、封じ込め、修正します。

特定した AI の問題に対して堅牢なアラート メカニズムを確立するには、次の推奨事項を検討してください。

  • プラットフォームのモニタリング アクティビティに基づいて、関連チームに通知するアクション可能なアラートを構成します。たとえば、Agent Platform の Model Monitoring が重大なドリフト、スキュー、予測の異常を検出したときにトリガーされるようにアラートを構成します。また、Model Armor またはカスタムの Monitoring ルールが悪意のある入力や安全でない出力をフラグ付けしたときにトリガーされるようにアラートを構成することもできます。
  • 明確な通知チャンネルを定義します。これには、Pub/Sub 統合を介した Slack、メール、SMS などがあります。アラートの重大度と担当チームに応じて通知チャンネルをカスタマイズします。

AI を考慮したインシデント対応計画を策定し、運用します。潜在的な影響を最小限に抑え、復旧を確実にするには、構造化されたインシデント対応計画が不可欠です。この計画をカスタマイズして、モデルの改ざん、ドリフトによる不正確な予測、プロンプト インジェクション、生成モデルからの安全でない出力など、AI 特有のリスクに対処します。効果的な計画を作成するには、次の主要なフェーズを含めます。

  • 準備: 資産とその脆弱性を特定し、ハンドブックを作成して、チームに適切な権限があることを確認します。このフェーズには、次のタスクが含まれます。

    • モデル、データセット、エンドポイントや Feature Store インスタンスなどの特定の Agent Platform リソースなど、重要な AI アセットを特定します。
    • アセットの潜在的な障害モードまたは攻撃ベクトルを特定する。

    • 組織の脅威モデルに一致するインシデントに対応する AI 固有のハンドブックを作成します。たとえば、ハンドブックには次のようなものがあります。

      • Model Registry のバージョニングを使用するモデルのロールバック。
      • Agent Platform マネージド トレーニングの緊急再トレーニング パイプライン。
      • BigQuery または Cloud Storage で侵害されたデータソースの分離。

    • IAM を使用して、インシデント中に必要なツールへの必要最小限のアクセス権を対応チームに付与します。

  • 特定とトリアージ: 構成されたアラートを使用して、潜在的なインシデントを検出して検証します。組織が AI 関連のインシデントを調査または宣言する方法について、明確な基準としきい値を設定します。詳細な調査と証拠収集を行うには、アプリケーション ログとサービスログに Logging を使用し、管理アクティビティとデータアクセス パターンに Cloud Audit Logs を使用します。セキュリティ チームは、Google SecOps を使用してセキュリティ テレメトリーをより詳細に分析できます。

  • 封じ込め: 影響を受けた AI システムまたはコンポーネントを隔離して、さらなる影響やデータの引き出しを防ぎます。このフェーズには、次のタスクが含まれる場合があります。

    • 問題のある Agent Platform エンドポイントを無効にする。
    • 特定の IAM 権限を取り消す。
    • ファイアウォール ルールまたは Google Cloud Armor ポリシーを更新します。
    • 動作に問題がある Agent Platform パイプラインを一時停止する。

  • 根絶: インシデントの根本原因を特定して除去します。このフェーズには、次のタスクが含まれる場合があります。

    • カスタムモデル コンテナの脆弱なコードにパッチを適用する。
    • 特定された悪意のあるバックドアをモデルから削除する。
    • Agent Platform マネージド トレーニングで安全な再トレーニング ジョブを開始する前に、ポイズニングされたデータをサニタイズします。
    • 安全でない構成を更新します。
    • 入力検証ロジックを改良して、特定のプロンプト インジェクション手法をブロックする。

  • 復旧と安全な再デプロイ: 影響を受けた AI システムを、既知の良好で安全な運用状態に復元します。このフェーズには、次のタスクが含まれる場合があります。

    • 以前に検証され、信頼されているモデル バージョンを Model Registry からデプロイします。
    • コードまたはシステムに存在する可能性のある脆弱性に対するセキュリティ パッチをすべて見つけて適用します。
    • IAM 権限を最小権限の原則にリセットします。

  • インシデント後のアクティビティと教訓: 重大な AI インシデントを解決したら、インシデント後のレビューを徹底的に実施します。このレビューには、AI と ML、MLOps、セキュリティ、データ サイエンス チームなど、関連するすべてのチームが関与します。インシデントのライフサイクル全体を把握します。これらの分析情報を使用して、AI システム設計の改良、セキュリティ管理の更新、Monitoring 構成の改善、AI インシデント対応計画とハンドブックの強化を行います。

AI インシデント対応を、IT やセキュリティ インシデント管理などのより広範な組織フレームワークと統合して、協調的な取り組みを実現します。AI 固有のインシデント対応を組織のフレームワークに合わせるには、次の点を考慮してください。

  • エスカレーション: 重大な AI インシデントを中央 SOC、IT、法務、または関連するビジネス ユニットにエスカレーションするための明確なパスを定義します。
  • コミュニケーション: 社内外のすべてのインシデント レポートと更新には、確立された組織チャネルを使用します。
  • ツールとプロセス: AI インシデントに既存のエンタープライズ インシデント管理システムとチケット発行システムを使用して、一貫したトラッキングと可視性を確保します。
  • コラボレーション: AI と ML、MLOps、データ サイエンス、セキュリティ、法務、コンプライアンスの各チーム間のコラボレーション プロトコルを事前に定義して、効果的な AI インシデント対応を実現します。

寄稿者

著者:

  • Kamilla Kurta | 生成 AI / ML スペシャリスト カスタマー エンジニア
  • Vidhi Jain | クラウド エンジニア、アナリティクスおよび AI
  • Mohamed Fawzi | ベネルクス セキュリティ / コンプライアンス リード
  • Filipe Gracio, PhD | カスタマー エンジニア兼 AI / ML スペシャリスト

その他の寄稿者:

  • Lauren Anthony | カスタマー エンジニア、セキュリティ スペシャリスト
  • Daniel Lees | クラウド セキュリティ アーキテクト
  • John Bacon | パートナー ソリューション アーキテクト
  • Kumar Dhanagopal | クロス プロダクト ソリューション デベロッパー
  • Marwan Al Shawi | パートナー カスタマー エンジニア
  • Mónica Carranza | シニア生成 AI 脅威アナリスト
  • Tarun Sharma | プリンシパル アーキテクト
  • Wade Holmes | グローバル ソリューション ディレクター

前へ
効果的な運用
次へ
信頼性