AI 継続性計画
目的
GitLab は、サードパーティの AI ベンダーを選定する前に、そのベンダーがベンダー自身の言語モデルの開発、トレーニング、再トレーニング、またはファインチューニングのために GitLab または GitLab の顧客のコンテンツを使用するかどうかを評価します。
AI 継続性計画は、GitLab が (i) サードパーティの AI ベンダーが上記のコミットメントと矛盾するように条件や慣行を変更した時点を特定し、(ii) 上記のコミットメントを満たす代替の AI ベンダーへ移行・実装するために使用するプロセスを概説しています。
ロールと責任
| ロール | 責任 |
|---|---|
| GitLab チームメンバー | この手順の要件に従う責任を負います |
| AI Powered ステージ | この手順を実装・実行する責任を負います |
| 法務・コーポレートアフェアーズ (LACA) | この手順に対する重要な変更や例外を承認する責任を負います |
| セキュリティリスク | 定期的なビジネスインパクト分析を実施し、テックスタックシステムに Critical System Tier を適用する責任を負います |
手順
Subprocessor リストを使用して AI ベンダーの変更を特定する
GitLab は、顧客データを処理する AI ベンダーを Subprocessors リストに文書化しています。このリストでは、Subprocessor の変更通知に登録することもできます。この配信リストに登録している人は、GitLab が Subprocessor リストを修正するイベントが発生するたびに通知を受け取ります。これには、条件が顧客に悪影響を及ぼす可能性のある AI ベンダーの削除も含まれる場合があります。
AI モデルを追加するプロセス
GitLab は、現在および将来の GitLab AI 機能を支えるのに有用となり得るプロプライエタリおよびオープンソースの AI モデルを特定するために、AI 市場を継続的に評価しています。
GitLab には、新しいモデルをテストするための技術を開発する専任のモデル評価グループがあります。このグループは、GitLab のニーズを満たすことを保証するため、AI モデルの品質とパフォーマンスを特定、選定、検証することを任務としています。彼らのプロセスについてはこちらを参照してください。
モデルが検証されると、選定されたモデルを GitLab AI アーキテクチャ内に実装するように、AI Framework グループに推奨が行われます。これにより、以下を含むさまざまなタスクが発生します。
- 新しい AI モデルの調達
- これには、GitLab の既存の調達プロセスを通じたプライバシー、セキュリティ、契約レビューが含まれます。
- GitLab 法務・コーポレートアフェアーズは、選定されたモデルを提供する AI ベンダーとの顧客データ利用に関する契約条件を評価します。また、GitLab の AI データ保持ポリシーと顧客データ利用ポリシーに準拠するために必要に応じて条件を交渉します。
- AI ベンダーがアカウントを必要とする場合、GitLab 法人アカウントがプロビジョニングされ、GitLab テックスタックに追加されます。これにより、GitLab はどの従業員がアクセス権を持っているかを追跡し、必要のある従業員のみにアクセスを制限できます。GitLab は、リスクを軽減するために、可能な限り開発と本番のアカウントアクセスを分離します。
- 新しい AI モデルの通知
- GitLab Subprocessor 配信リストを活用して、新しい AI ベンダーの 30 日前通知を提供します。この待機期間により、顧客は新しい、または重大に異なるサードパーティによるデータ処理に異議を申し立てる契約上の権利を行使し、サードパーティ処理を無効にできない場合にサービスを終了する機会を得ます。また、顧客が計画されている利用を監査し、可能な場合は望まない AI 機能をオプトアウトできる時間枠も提供します。
- AI モデルの実装
- AI Framework グループは、プロビジョニングされた GitLab アカウントを使用し、GitLab 開発フローに従って新しい AI モデルのサポートを実装します。
- この新しい AI モデルに基づいて GitLab AI 機能を実装した、または実装するさまざまなチームと調整を行います。これには、すべての GitLab ディストリビューションでモデルがサポートできることを確保するため、Cloud Connector グループとの連携も含まれます。
- AI モデルのロールアウト
- 30 日間の Subprocessor 通知期間が経過し、コード変更がレディネスレビューに合格した後、GitLab は新しい AI ベンダーのロールアウトを進めます。GitLab は、新機能の有効化を制御・監視するために、機能フラグとパーセンテージロールアウトを活用するのが一般的です。
AI モデルを切り替えるプロセス
GitLab は AI 抽象化レイヤーを開発しており、これを使用して AI 機能を支える基盤モデルを切り替えています。この抽象化レイヤーは、変更の技術的複雑さを軽減し、GitLab が AI ベンダーからの変更や障害に対応できる速度を高め、GitLab Rails アプリケーションが AI モデルとやり取りする方法を標準化します。AI 抽象化レイヤーは、すべての AI ベンダーが GitLab AI 機能の本番ニーズを満たすことを保証するための一元的なテレメトリーとモニタリングも提供します。
GitLab の AI 機能を支える AI モデルを切り替える必要があると GitLab が判断した場合、そのモデルが既存の AI ベンダーのものであり、処理に他の重大な変更がない限り、顧客への変更通知は発生しません。ただし、AI 機能に関する透明性ポリシーの一環として、AI モデルの変更を反映するために関連ドキュメントは更新されます。
モデルが新しい AI ベンダーのものである場合、AI ベンダーを追加するプロセス (上記参照) が発生します。
AI ベンダーの条件が重大に変更された場合のプロセス
GitLab は、Subprocessor ポリシーと条件通知・レビュープロセスを確立しています。AI ベンダーが条件を変更した場合、GitLab 法務に通知され、その変更が顧客に重大な影響を与えるかどうかを判断するためにレビューが行われます。条件変更が顧客に重大な悪影響を与える場合、以下のように進めます。
- 影響を受ける AI ベンダーのモデルを使用している AI 機能の一時的な無効化を検討します。無効化が必要な場合、GitLab はステータスページに機能制限を示す更新を投稿します。同時に以下のステップが実行されます。
- AI 抽象化レイヤーに既に実装されている代替モデルを評価します。代替モデルが置き換え候補となる場合、関連するユースケースに対してモデルが機能することを確認するために小規模なテストが行われます。これは、その AI 機能の実装チームと AI Model Validation グループの両方によって実施されます。これにより、AI 機能が機能の品質やパフォーマンスに重大な悪影響を及ぼす可能性のあるモデルに切り替わらないことが保証されます。
- 代替モデルが AI 機能の合理的な置き換えとして検証された場合、トラフィックをこの新しいモデルにルーティングするためのコード変更が直ちに実装されます。ほとんどの場合、GitLab AI アーキテクチャは GitLab の月次リリースサイクル外でデプロイできるため、GitLab のバージョンリリースは不要となります。
- 現在関連する置き換えモデルが存在しない場合、調達は GitLab の AI 機能ニーズに適したモデルを持つ新しい AI ベンダーを特定・選定するために開始されます。これにより、AI ベンダーを追加するプロセス (上記参照) が発生します。
- AI 抽象化レイヤーに既に実装されている代替モデルを評価します。代替モデルが置き換え候補となる場合、関連するユースケースに対してモデルが機能することを確認するために小規模なテストが行われます。これは、その AI 機能の実装チームと AI Model Validation グループの両方によって実施されます。これにより、AI 機能が機能の品質やパフォーマンスに重大な悪影響を及ぼす可能性のあるモデルに切り替わらないことが保証されます。
AI ベンダーのセキュリティインシデントのプロセス
GitLab に報告される他のあらゆるセキュリティインシデントと同様に、Security Incident Response Team (SIRT) がトリアージと是正の促進のために関与します。詳細は SIRT インシデント対応プロセスを参照してください。
コミュニケーション計画と役割の割り当て
GitLab の AI 機能を支える AI ベンダーの移行においては、コミュニケーションが極めて重要です。計画は、すべてのチームメンバーが同じ認識を持ち、すべてのコミュニケーションが明確に概説されるようにするために不可欠です。
ドキュメントには、すべての最新のチームメンバーの連絡先情報を含め、各チームメンバーは AI 継続性計画が発動された後の数日間における自分の役割を正確に理解する必要があります。
各 GitLab チームは、AI 継続性計画を発動する状況が発生した場合に対応できるよう、トレーニングを受けて準備しておく必要があります。
計画の配布と検証 / シニアマネジメントからの承認
- AI 継続性に関する手順とガイドラインの詳細を記した GitLab ドキュメントは、プロダクト、エンジニアリング、LACA リーダーシップによってレビュー、更新、正式に承認されなければなりません。
- 基本的なガイドラインを開発した後、この計画は進行中の作業としてコアチームに配布されます。
- コアチームは、すべての技術的な詳細がカバーされており、不備がないことを検証するためにレビューを行います。
- コアチームはガイドラインをレビューおよび追加し、すべての関連DRI が、すべての状況で何が要求されるかを明確に把握できるようにします。
- マネージャーまたはチームリードは、計画の関連部分を役割と部門に基づいてすべての GitLab チームメンバーに共有し、計画が発動された場合に何をすべきかを彼らが理解していることを確認します。
c955a93f)