1. 取引完了時の運用上の決定を定義する
買収委員会は、統合後の事業が使用する予定の AI システムの文書化された運用基盤を承認する必要があります。この決定では、許可された目的、責任主体、重大な制限、および各サービスを一時停止する権限を与えられた人物を特定する必要があります。収益維持に不可欠なアプリケーションの場合、委員会は、モデルが廃止された場合に利用できるサービスに関する証拠も必要とします。このペーパーでは、その情報を収集し、どの統合を進めることができるかを決定するための取引完了後のフレームワークを提案します。
トランザクションでは、異なるコントラクト、データ ソース、顧客インターフェイスを通じて、同じ基礎モデルを使用するアプリケーションを統合できます。共有サプライヤー名は、最初の比較ポイントとなります。統合チームは、展開された構成と各企業での実際の使用状況を調査する必要があります。これには、従来の予測モデル、ビジネス ソフトウェア内のサードパーティの AI 機能、および情報を取得したりアクションを実行したりする生成システムが含まれます。提案された範囲は、運用上のエクスポージャーと決定権限に従います。
1 つの管理システムというフレーズは、共有されたガバナンス記録と責任ある決定を表します。これにより、契約条件、技術的依存関係、または評価結果がその取り決めをサポートする場合、別個の運用環境が許可されます。共通登録により、これらの環境を同じ承認ポリシーおよびインシデント手順にリンクできます。技術的な統合は、独自のテスト証拠、予算、復旧の取り決めを伴う個別に承認された変更となります。継続的な動作は、個々のサービスに適用される条件によって異なります。
NIST の AI リスク管理フレームワークは、ガバナンス、コンテキスト マッピング、測定、およびリスク処理を組織化するための自主的な分野横断的なリファレンスを提供します。そのインベントリ、監視、説明責任の結果は、この提案された統合設計に関連します。このフレームワークは、買収が準拠していること、または継承されたシステムが安全であることを確立しません。この文書は、公開された結果を使用して、デリジェンス質問と運用記録を作成します。投資委員会は、実際の決定に必要な専門的なアドバイスと証拠を入手する責任を引き続き負います。 [1]
2. アクセスを変更する前に境界を確立する
取引に含まれる法人、ビジネスプロセス、および環境から始めます。取引完了時に何を移転し、何が販売者または第三者に依存したままになるかを記録します。各サービスの対象となるオペレーター、その出力を受け取る顧客、およびその構成を変更できるスタッフを特定します。取引が完了する前に、情報共有または統合の準備は、取引で承認された機密保持および競争法の取り決めに従って行う必要があります。この論文は、取引の法的完了前にシステムを組み合わせる権限を想定していません。
範囲は、購入したソフトウェアに組み込まれている AI 機能まで拡張する必要があります。各プロセス責任者に、推奨事項や自動化されたアクションが価格設定、顧客とのコミュニケーション、生産スケジュール、雇用またはサービスへのアクセスにどのような影響を与えるかを特定するよう依頼します。これらの記述を、承認された技術記録および調達記録と照合してください。発見方法を適切かつ承認されたものに保ちます。目的は、関連する用途の追跡可能な目録です。従業員の個人アカウントおよび無関係な機密資料は、合法的な特定のプロセスに含まれない限り、承認されたレビューの対象外のままです。
デプロイメントごとに、カウントされる運用単位を定義します。有用な提案されたユニットは、承認された目的のために識別されたエンティティによって使用される、指定された環境内のバージョン管理されたアプリケーションです。同じモデル ファミリを使用する 2 つのアプリケーションは、データ、権限、結果が異なるため、2 つのデプロイメントのままになる可能性があります。複数のレジストリ エントリが重複した管理レコードである場合、1 つの展開を説明することがあります。後でカウントを再現できるように、各照合の決定を裏付ける証拠を保存してください。
取得した境界の外側にある依存関係を含めます。調査対象の例には、販売者が管理する ID サービス、共有評価データセット、販売者の契約を通じて提供されるベンダー サポートなどがあります。依存関係の責任者、アクセスの取り決め、計画期間、および置換の受け入れ条件を記録します。実際に必要な支援については移行合意書を検討する必要がある。統合計画では、依存関係の有効期限を、代替案がテストおよび承認される必要がある日付に結び付けることができます。
発見の信頼性を運用上の承認から分離します。責任者が確認したインベントリエントリには、検証済みの監視しきい値や使用可能な回復プロセスがまだ不足している可能性があります。逆に、適切に管理されたサービスが最初のトランザクション レジスタに存在しない場合もあります。両方の条件を明示的に追跡します。これにより、委員会は発見されたものについての見解を得ることができ、また、その継続使用を裏付ける証拠については別の見解が得られる。
3. デプロイメントを失わずにモデルのインベントリを調整する
両社の元の識別子を保持し、それらにリンクされたグループ識別子を追加します。記録には、モデルまたはサービスのバージョン、アプリケーションの目的、運営主体、本番環境の所在、および事業側の責任者を含める必要があります。管理された参照を通じてサポート文書をリンクします。後のインシデントをその時点で動作していた構成に関連付けることができるように、履歴バージョンを保存します。インベントリに変更を加える場合は、編集者、理由、発効日を特定する必要があります。
以下の照合例は、すべて仮定に基づきます。A社が100件、B社が80件の記録を提供したとします。確認の結果、すでに数えた稼働環境を重複して記載した管理記録が15件見つかります。続いて、残りのうち25件について運用終了が確認されたとします。承認された追加調査で、初期一覧にない稼働中の環境が12件見つかります。稼働中の件数は180から15と25を差し引き、12を加えた152件です。すべての数値は説明のための仮定です。
著者による一覧照合の計算例です。同じ供給元を利用しているという理由だけで、共通のモデル群を件数から除外することはありません。
運用終了には明確な証拠基準が必要です。提案されたレコードには、実稼働ルートが無効になっていること、関連する資格情報が対処されていること、継続的な保持義務には責任者がいることが示されている必要があります。開発ツールでクローズとしてマークされたプロジェクトは、アクティブなスケジュールされたプロセスをまだ残している可能性があります。インベントリ責任者は、管理ステータスと認可された運用証拠を照合する必要があります。保持が必要な履歴資産は、アクティブな展開とは別のアーカイブ カテゴリに残すことができます。
照合後、例示した152件の稼働環境を、運用を裏付ける証拠に基づいて分類します。現在の承認済み用途について証拠が揃ったものを82件、期限付きの条件付き承認を得たものを50件、運用判断が未確定のものを20件と仮定します。最初の2区分は合計132件で、一覧全体の86.8%です。この割合は、想定した基準の下で記録された承認状況を表します。残存リスクの重大性や、採用した基準の適切性をこの割合だけで判断することはできません。
4. 各展開を許可された用途に接続する
意図された目的を運用上の言語で記述します。トレーニングを受けた従業員に対する回答の草稿を作成するサービスには、その回答を顧客に直接発行する権限を与えられたサービスとは異なるワークフローがあります。出力、受信者、許可されたアクション、および必要なレビューを記録します。禁止する用途拡大と変更申請のルートを記載します。承認された使用声明は、プロセス責任者が実際の実践がいつそれから逸脱したかを識別できるように、十分に具体的である必要があります。
そのステートメントにデータ アクセス マップを添付します。ソース システム、データ カテゴリ、取得権限、ログまたは出力の宛先を特定します。マップには、各接続に関連する法人と環境が表示される必要があります。弁護士およびプライバシーの専門家は、適用される権利と制限を評価する必要があります。技術スタッフは、承認されたアクセスが実装可能であることを実証する必要があります。グループ レベルの所有権の変更では、すべてのデータセットをすべてのアプリケーションで利用できるという証拠は得られません。
アクションを実行できるシステムの権限を確認します。ドキュメント ストアを検索し、顧客レコードを更新し、支払い関連のワークフローを開始できるアプリケーションには、各機能を個別に説明する必要があります。承認された目的にはどの権限が必要か、誰が追加のアクセスを許可できるかを尋ねます。拒否されたアクションとエスカレーション パス、および成功したリクエストをテストします。提案された受け入れ記録では、どのアクションが人間の承認の対象となるかを特定する必要があります。
生成システムの場合は、取得ソース、プロンプトまたは構成指示、接続されたツール、および関連するモデルのバージョンをアプリケーション コードと一緒に記録します。 NIST の生成 AI プロファイルは、サードパーティの依存関係に対処し、組織のコンテンツにアクセスできるエンティティのインベントリを推奨します。バリューチェーンとコンポーネントの統合についての議論は、モデルのサプライヤーを超えた依存関係のレビューをサポートします。提案されたトランザクション インベントリでは、そのガイダンスを使用して、アクセスとサービスの依存関係に関するバージョン固有の証拠を要求します。 [2]
統合中にアクセスの変更を個別に確認できるようにします。提案された共有 ID グループには、アクセスを取得するユーザーとアプリケーション、ビジネス目的、および一時的なアクセス許可の予想有効期限をリストする必要があります。それらの境界を検証するために使用したテストを保持します。アクセスが未解決のままである場合は、現在許可されているサービス構成と、より広範な運用取り決めに到達するために必要な作業を文書化します。
5. 統合された事業全体に意思決定権限を割り当てる
取締役会または委任された幹部は、リスク選好度を確立し、責任ある統合スポンサーを任命する必要があります。スポンサーには、リソース、期限、ビジネスの優先事項をめぐる対立を解決する権限が必要です。指定された事業側責任者は、承認された各サービスの使用とその結果について引き続き責任を負う必要があります。エンジニアリングは実装と技術的証拠を維持する必要があります。独立した批判的検証は、導入判断から十分な独立性を持つ、適切な能力を備えた担当者に割り当てる必要があります。
次の責任分担表は、実際の組織に合わせて調整するための案です。Rは作業の実行担当、Aは明示された判断の最終責任者、Cは相談先、Iは報告先を表します。各行には最終責任を持つ役割を一つ割り当てます。専門的なレビューの責任は、引き続き組織に適用される法令・規制上の要件に従います。この表によって、法的責任を負う個人や組織からその責任を移すことはできません。
| 決定事項または作業項目 | スポンサー | 事業側責任者 | テクニカルリード | 独立した査読者 |
|---|---|---|---|---|
| インベントリと目的の記録 | I | A | R | C |
| 評価の根拠と独立した検証 | I | C | R | A |
| 承認された範囲内での通常のリリース | I | A | R | C |
| 統合に関する重要な例外 | A | R | C | C |
| 緊急時の技術的封じ込め | I | A | R | C |
| 重大な事件後の再開 | A | R | R | C |
割り当ての例。スポンサー、責任者、技術リーダー、および独立したレビュー担当者は、使用前に名前で特定される必要があります。適用される要件については、法律およびコンプライアンスの専門家に相談します。
マトリックスには、明示的な権限委譲と対応の取り決めが伴う必要があります。不在時の代理担当者を指名し、緊急の判断事項をその担当者へ届ける方法を定めます。ガバナンス委員会の毎月の会合は、即時封じ込めが必要なサービスの唯一のメカニズムとして機能することはできません。定義された条件内で特定の緊急行動を事前に承認し、監査証跡を保持し、その後のレビューを必要とします。指定された責任者は、許可された各アクションの運用上の結果を知っている必要があります。
独立したレビューにより、意思決定者が使用できる結論が得られるはずです。テストした内容、重要な制限事項、再検討が必要な変更点を記載する必要があります。未解決の意見の相違は、決定と根拠とともに承認記録に残すべきです。システムを評価するスタッフは、関連する証拠と、その証拠が不足している場合のエスカレーション チャネルにアクセスする必要があります。 NIST は、ガバナンスの成果の中で明確な役割と執行責任を特定しています。 [1]
登録を完了するためだけに、1 人の個人をすべての展開の恒常的な担当責任者にすることは避けてください。サービスを理解し、その結果に基づいて行動できる組織機能に責任を割り当てます。グループ ガバナンスは、共通の要件を定義し、例外に異議を申し立てながら、運用上の責任を特定し続けることができます。組織再編によりレポートラインが変更されたり、役割が削除されたりする場合は、割り当てを見直してください。
6. 証拠を通じて承認の基準を調和させる
両社のシステムに実際に加えられた変更を使用して、2 社の既存の承認ルールを比較します。関連する例としては、新しいデータ ソースの導入、モデル バージョンの変更、新しい顧客層への拡大、アプリケーションへの新しいアクション機能の付与などが挙げられます。各企業が現在必要としている証拠と、決定に署名した権限を記録します。この比較では、管理上の不足を特定し、統合後も維持すべき有用な統制を明らかにします。
結果と不確実性に関連付けられたしきい値を使用して、共通の変更分類を作成します。定期メンテナンスは、評価された動作範囲内にある場合、確立された技術リリース手順の対象となる場合があります。目的、影響を受ける対象者の範囲、自律性、または法的役割が変更された場合は、追加の見直しを促す必要があります。変更が既存の承認の範囲内であることを証明するために必要な証拠を定義します。変更が軽微であるという開発者の説明は、記録された評価によって裏付けられる必要があります。
承認記録には、測定が適切な場合には、測定可能な合格条件を指定する必要があります。関連するパフォーマンス指標、検査母集団、観察期間、解釈の制限を含めます。検証された契約上の許可や訓練を受けた人間のレビュー担当者などの定性的要件を個別に文書化します。複合スコアにより、欠落している必須条件が隠蔽される可能性があります。提案されたプロセスでは、リリースの決定が行われる前に、必要な各条件とその結論を裏付ける証拠を記録します。
権限を与えられた意思決定者がその取り決めが許容されると考える場合には、定義された運用取り決めに対して期限付きの例外を使用します。未解決の問題、暫定管理、指定された責任者、および有効期限の条件を記載します。ベンダーのバージョン変更や監視違反など、例外を早期にキャンセルするイベントを特定します。有効期限が切れた後も運用を継続するには、現在の証拠に基づいて新たな決定を行う必要があります。この論文では、適用される禁止事項や義務を無効にするために例外を使用する根拠は示されていません。
移行中の変更履歴を保持します。 2 つのリリース カレンダーが重なっている場合は、どのバージョンが評価され、どのバージョンがデプロイされたかを記録します。その間に加えられた変更が証拠に影響を与えたために、承認を再評価する必要がある合意された時点を確立します。共有チケット ID により、エンジニアリング記録、ビジネスの承認、独立したレビューを結び付けることができます。受け入れテストでは、これらの参照が実際のドキュメントと展開された構成につながることを確認する必要があります。
7. 組み合わせた運用コンテキストでのパフォーマンスを評価する
評価計画には、取引完了後に提案された用途が反映されている必要があります。範囲内のユーザー、言語、データ ソース、トランザクション量、意思決定の影響を特定します。販売者の元のワークフローに対して実行されたテストは、取得者が異なる顧客集団やアクションを導入した場合、延長が必要になる場合があります。元の結果を保存し、引き続き適用可能なものを文書化します。レビュー担当者は、変更された使用を承認する前に、どのような追加の観察が必要であるかを明記する必要があります。
出所と使用許可が確認された評価用データセットを使用します。評価設計で区別が必要な場合、独立した批判的検証に使用される証拠から開発資料を分離します。サンプリング方法、関連するサブグループ、既知の制限を記録します。定量的な結果には、分母とテスト条件が含まれている必要があります。評価されたケースの説明のない割合は、2 社の評価記録の信頼できる比較を裏付けることができません。
アプリケーション パス全体をテストします。正しいモデル応答が下流のワークフローによって誤って変換されたり、権限のない受信者に配信されたり、意図したレビューなしに受け入れられたりする可能性があります。テスト設計には、入力処理、取得、ユーザー インターフェイス、承認、および最終アクションを含めます。ツールを使用するシステムの場合、アプリケーションが不適切または悪意ある入力に対して権限の境界を尊重するかどうかを評価します。許可されたレベルのテストは認可され、必要に応じて運用操作から隔離される必要があります。
ビジネス上の意思決定に重要な失敗事例を文書化します。カスタマー サポート アプリケーションでは、根拠のない約束、制限された情報の開示、苦情の誤ったルーティングを個別に評価する必要がある場合があります。生産計画アプリケーションでは、実行不可能なスケジュールと、遅れて人間が介入した場合の結果の評価が必要になる場合があります。これらはユースケース設計の提案例です。実際のテスト スイートは、サービスの目的、契約上の義務、および関連する専門的要件に従う必要があります。
NIST の測定機能には、手法の不確実性と適切性に注意を払った、展開前および運用中のテストが含まれます。統合委員会は、結果とともに評価者の制限を受け取る必要があります。テストが成功すると、そのテスト結果によって支持される特定の結論が裏付けられます。より広範な運用承認には、評価計画で特定された残りの証拠が必要です。レビューの頻度は、アプリケーションとそのパフォーマンスに影響を与える可能性のある変更を反映する必要があります。 [1]
8. 意思決定につながるモニタリングを確立する
各監視手段には定義された対応が必要です。データソース、計算、報告頻度、侵害を調査する担当者を記録します。欠落した観測値がどのように検出されるか、また監視自体が利用できなくなった場合に何が起こるかを特定します。事業側責任者は、その尺度がサービスの可用性、出力の品質、アクセス動作、または顧客に影響を与える結果を表すものであるかどうかを理解する必要があります。これらのディメンションは、1 つのダッシュボードに表示される場合でも、個別に解釈する必要があります。
チームが有効な共通の定義を実証するまで、企業固有の基準を保持します。 2 つのアプリケーションは、異なるサンプル、ラベル、またはレビュー方法を使用して精度をレポートできます。これらのパーセンテージを組み合わせると、解釈できない結果が生じる可能性があります。調和記録では、古い定義、提案された定義、および並行測定の期間について説明する必要があります。レポート指標の変更後に履歴結果を解釈するために必要な情報を保持します。
承認された目的、評価証拠、適用される義務を参照してしきい値を選択します。この論文では、普遍的な精度のしきい値や許容可能なエラー率を提案していません。一部の条件では、合計パフォーマンスが数値制限内に留まっている場合でも、直ちに制限する必要があります。評価すべき例としては、不正アクセス、目的の大幅な変更、必要な人間によるレビュー手順の喪失などが挙げられます。インシデント チームがどちらのタイプにも対応できるように、統計アラートとともにこれらの状況を文書化します。
人間の監視を運用活動として測定します。誰が出力をレビューするか、彼らに割り当てられた作業負荷、および彼らが介入したときに保持される証拠を確立します。レビュー担当者が問題のある結果を認識するのに十分なコンテキストを受け取っているかどうかをテストします。ワークフローを一時停止して支援を得ることができるかどうかを検討します。見直しの要件には、実際の運営スケジュールと照らし合わせてチェックできる人員配置とサービス能力の想定を伴う必要があります。
インシデント、苦情、ニアミスを数値パフォーマンスとともにレビューします。顧客レポートにより、現在のテスト セット以外の問題を特定できます。レポートを関連する展開およびバージョンにリンクし、調査して、評価計画への変更を記録します。苦情の詳細とインシデントの証拠に対するアクセス制御を維持します。モニタリングは、継続的な運用、追加の管理、再評価または一時停止に関する文書化された決定をサポートする必要があります。
9. ベンダーと契約をガバナンスに統合する
ベンダー登録簿は、各サービスについてどのエンティティが契約し、取引完了後にどのエンティティがそれを使用するかを特定する必要があります。適切なアドバイザーとともに、譲渡、支配権の変更、許可されたユーザー、および処理に関する規定を検討します。必要な同意や修正された注文書など、継続的なアクセスを裏付ける証拠を記録します。アクセスを提供するサプライヤーの技術的能力は、そのアクセスを使用するための契約上の許可とは別に考慮する必要があります。
顧客が管理するリリースを使用せずにサプライヤーが行うことができる変更を文書化します。これらは、実際のサービスに応じて、モデル、ホスティングの取り決め、保持設定、またはアプリケーションの機能に関係する場合があります。該当する通知およびバージョン管理条件を取得します。技術責任者は、サプライヤーが行う変更をどのように検出するか、および承認された使用に対するその影響がどのように評価されるかを説明する必要があります。関連する構成を一定に保つことができない依存関係については、代替の運用計画を立ててください。
インシデント情報がサプライヤーと統合されたビジネスの両方にどのように届くかについて合意します。サポート チャネル、承認された連絡先、および各当事者が共有できる情報を特定します。調査、封じ込め、回復に利用できる支援を確認します。 NIST のインシデント対応ガイダンスでは、第三者を責任共有モデルの参加者として扱い、計画と演習に第三者を含めています。提案された統合プロセスでは、共同演習を使用して、実際の契約に記載されている取り決めをテストします。 [3]
依存先の集中とその影響を評価します。いくつかのビジネス アプリケーションは、異なるモデル名を使用している場合でも、1 つのサービス エンドポイントまたは ID プロバイダーに依存する場合があります。依存関係マップは、そのサービスの障害または中止によってどの顧客プロセスが影響を受けるかを示す必要があります。関連するデータの権限、容量、品質の要件に照らして代替案をテストします。テストされていない 2 番目のベンダーは、未処理の受け入れ作業を伴う予備候補として残ります。
検証された範囲と終了コストを条件として調達コストを削減します。契約を統合すると、最低契約、使用権、サポートの取り決めが変更される場合があります。提案された節約額と移行コスト、残りの義務、および追加の評価を調整するよう財務部門に依頼します。ガバナンス記録では、どのサプライヤーの決定が承認されたか、また統合予算におけるその影響を認識する前に必要な証拠を特定する必要があります。
10. 受け入れ条件に従って統制共通化の順序を定める
提案された統合シーケンスは、取引完了時の確かな運用記録から始まります。指定された責任者を確立し、既存の承認された構成を保存し、緊急の決定を特定します。広範な技術的な移行を開始する前に、インシデントの共有連絡先と管理された変更ログを導入します。即時の対応が必要な既知の問題は、適切な対応プロセスに入る必要があります。シーケンスは組織化されたフレームワークを提供します。取引固有の義務やインシデント条件により、早期の介入が必要になる場合があります。
次のフェーズでは、インベントリを照合し、管理証拠を比較します。重要なデプロイメントの目的と依存関係を確認し、ギャップを確認し、期限付きの修復を割り当てます。共通のレコード定義と承認ルートを導入します。この作業は、承認された取り決めに基づいて別個の運用環境が継続されている間に行うことができます。統合計画に最初に印刷された日付に関係なく、必要な証拠と決定が存在するとフェーズは完了します。
証拠に基づいた受け入れ条件を備えたシーケンスの例。統合を完了するまでの固定期間は想定していません。
移行は、明示的な回復決定を伴うテスト済みの設計に従う必要があります。承認されたテスト条件下で、提案された環境での出力とワークフローの動作を比較します。どの差異が予想されるか、どの差異を調査する必要があるかを判断します。移行を停止できる人、ロールバックが可能な最新の時点、および再開に必要な証拠について同意します。技術的なロールバックでは、試行されたカットオーバー中に書き込まれたデータまたは実行されたアクションに対処する必要があります。
スタッフが文書化、アクセス、およびサポートの責任を受け入れた場合にのみ、責任を恒久的な運営組織に引き継いでください。未処理の例外、残りのサプライヤー依存関係、およびレビュー日を記録します。承認された手順に従って、一時的なアカウントと移行期間中の取り決めを終了します。適用される保存要件に従って証拠を保存します。統合スポンサーは、何が受け入れられ、何が運営上の義務として残っているかを特定する終了声明を受け取る必要があります。
11. インシデントの検出から認可された回復までをマッピングする
会社、顧客、関連サプライヤーのいずれかからのレポートを受け入れることができる共有インシデント ルートを使用します。最初の記録では、影響を受けたサービス、観察された動作、レポートの時間およびソースを特定する必要があります。認可された手順に従って証拠を保存します。対応者は潜在的な影響を評価し、即時の封じ込めが必要かどうかを判断する必要があります。情報が改善されるにつれて、分類を再検討する必要があります。初期の説明では重要な結果が省略される可能性があります。
事業側責任者、技術チーム、関連する法律専門家にアクセスできるインシデントリードを割り当てます。リーダーは対応を調整し、決定を記録します。提案されたマップでは、技術的な封じ込めと外部への通知および再開に関する決定が分離されています。適用される法律、契約、および職業上の義務によって、通知要件が決まります。この文書では、普遍的な報告期限を設定しておらず、すべての参加者に個人情報や機密情報を開示する許可があるとは想定していません。
通知要件と回復権限は、実際のサービスと管轄区域に応じて決定する必要があります。矢印は連携を示しており、必要に応じて専門家が同時にレビューします。
新しく接続された取得ソースが、承認されたアクセス範囲外のアプリケーションに情報を公開するという例のインシデントを考えてみましょう。提案されている即時対応は、許可された制御を使用して影響を受ける接続を制限し、関連する証拠を保存し、危険にさらされる範囲を特定することです。調査では、アクセス許可、構成変更、およびダウンストリーム受信者を調査する必要があります。事業側責任者は、より広範な問題を評価しながら、検証された制限内でどのサービスを継続できるかを確立する必要があります。
回復には、承認されたサービスが変更された条件下で動作できるという証拠が必要です。修復と関連する障害パスをテストし、モニタリングを確認して、残っている問題を記録します。影響を受ける機能を再開する前に、必要な許可を取得してください。技術的な可用性への回帰は、その決定における 1 つの観察を提供します。インシデントのレビューでは、顧客への影響、証拠の保持、統合プロセスに必要な変更にも対処する必要があります。 NIST の対応ガイダンスには、回復とリスク管理への教訓のフィードバックが含まれています。 [3]
12. 管轄区域および部門の要件を特定の用途に適用する
重要なデプロイメントごとに法的適用記録を作成します。運営主体、影響を受ける人々、サービスを受ける市場、サプライチェーンにおける目的と役割を特定します。関連する義務と適用日を決定するために資格のあるアドバイザーに依頼してください。その記録を承認された構成にリンクしたままにしておきます。地理、目的、またはブランドの変更は、法的分析に影響を与える可能性がある箇所の見直しを促す必要があります。グループ ポリシーには、ローカルの責任を曖昧にすることなく、結果として得られる要件を組み込むことができます。
2026 年 7 月 27 日付けの EU AI 法の統合文書には、具体的な例が記載されています。第 25 条は、ブランディング、大幅な変更、または意図された目的を含む特定の変更を含む、オペレーターが高リスク システムのプロバイダーとなる状況に対処します。第 26 条は、有能な人間による監督と監視を含む配備者の義務について規定しています。これらの規定は、特定のシステムの現在の義務として扱われる前に、範囲、例外、および適用される移行規則を評価する必要があります。 [4]
欧州委員会の現在の施行ページには、法のさまざまな部分の異なる適用日が記載されており、2026 年の改正が反映されています。統合チームは、統合された法律および関連するアドバイスと照合して、日付の付いた義務登録簿を維持する必要があります。このホワイトペーパーは、すべての高リスク要件が取引完了時のすべての展開に適用されるという包括的な主張を行うものではありません。取引計画には、特定の要件、適用日、責任を負う組織、およびコンプライアンスに必要な証拠を記録する必要があります。 [5]
SDAIA の AI 倫理原則では、システムのライフサイクル全体にわたる説明責任、トレーサビリティ、監視、および第三者に対するデューデリジェンスについて説明しています。 UAE の 2024 年 7 月の憲章には、人間による監督、ガバナンス、説明責任、および適用法の遵守が含まれています。これらの主要な出版物は、提案されているガバナンス設計に関連する地域の参照点を提供します。それらのステータスと特定のエンティティへの適用には、個別の評価が必要です。これらは、国境を越えたデータ転送、規制された金融活動、またはセクター固有の展開に対する一般的な承認を提供するものではありません。 [6],[7]
海外の顧客にサービスを提供する GCC の業務については、法的登録とともに契約上の義務を維持します。顧客の契約上のセキュリティ別紙または調達要件により、継続的な納品に関連する証拠条件が課される場合があります。締結された条件と変更を受け入れる権利のある当事者を確認してください。法的要件、契約上の義務、および社内で選択された管理の区別を維持します。投資委員会は、各条件の根拠とそれを満たさなかった場合の結果を明確に記録する必要がある。
13. 証拠収集と並行運用のための予算
実装予算は、一般的なプログラムのコストと、展開固有の作業および一時的な運用コストを分離する必要があります。数量ベースとして文書化されたインベントリを使用します。実際の評価、修復、移行タスクの見積もりと、その背後にある仮定を取得します。レビューの数や並行運用の期間を変更する可能性がある依存関係を記録します。財務部門は、承認された作業パッケージと予算を調整し、各重要な見積もりの責任者を特定する必要があります。
以下の予算はすべて仮定に基づく例であり、米ドルで示します。登録簿、方針の照合、初期運用手順など、共通のプログラム立ち上げ費用をUSD 180,000と仮定します。例示する152件の稼働環境を、作業量に応じて3区分に分けます。詳細評価を要する32件は1件当たりUSD 4,000、中程度の作業量の評価を要する60件は1件当たりUSD 2,000、限定的なレビューを要する60件は1件当たりUSD 500と仮定します。これらは作業量を計算するための仮定上の区分であり、法的なリスク分類を示すものではありません。
| ワークパッケージ | 計算 | 想定支出額 |
|---|---|---|
| 共通プログラム設定 | 固定想定額 | 180,000 |
| 集中評価 | 32件 × 1件当たり4,000 | 128,000 |
| 中程度の作業量の評価 | 60件 × 1件当たり2,000 | 120,000 |
| 限定的なレビュー | 60件 × 1件当たり500 | 30,000 |
| 一時的な並行運用 | 6か月 × 月額35,000 | 210,000 |
| 基本実施費用の合計 | 5 つの作業パッケージの合計 | 668,000 |
著者による仮定で、金額はUSD建てです。実際に観測した供給元の価格、人件費単価、助言業務の見積額、市場水準を示すものではありません。この計算では評価区分を重複させていません。
この計算では、評価料金が指定されたレビュー作業をカバーし、一時的な運用コストがそれらの料金に追加されることを前提としています。これには、通常の事業運営コスト、税金、資金調達コスト、収益への影響、および記載された作業パッケージを超える修復は含まれません。実際の予算では、同じ人件費を 2 回カウントすることを避けるために、範囲の定義と時間記録が必要になります。例示的な合計は、選択された仮定に基づく支出であり、確率は付加されていません。
並行運用の月額費用を同じUSD 35,000と仮定し、3か月延長する場合を考えます。追加額はUSD 105,000です。構成の重要な変更を受け、8件の詳細評価を1件当たりUSD 4,000で再実施するとも仮定します。この再評価にUSD 32,000が加わり、追加支出はUSD 137,000、延長後の合計はUSD 805,000となります。再評価は既存の稼働環境に対する追加作業であり、一覧に含まれる稼働環境の件数は増えません。
委員会はその延長の原因を調査する必要がある。サプライヤーの同意が遅れたり、証拠が入手できなかったり、移行テストが失敗した場合には、異なる対応が必要になります。予算予備には文書化された目的と承認ルールが必要です。このモデルは、回避される損失を定量化するものではなく、この支出が特定の投資収益を生み出すことを示唆するものでもありません。節約や収益の仮定は別の証拠によって裏付けられ、統合中のサービス維持コストと調整される必要があります。
14. 統合ケースに頼る前に継続性をテストする
重要なサービスごとに、AI コンポーネントが制限されているか利用できないときにビジネスが提供できる内容を確立します。代替ワークフロー、人員配置要件、顧客への影響について説明します。関連する契約および専門的要件の下で、その代替案が許可されているかどうかを確認してください。手動プロセスは、代表的な作業と承認されたデータを使用してテストする必要があります。処理できる量、必要なレビュー、および選択したテスト条件下で蓄積されるバックログを記録します。
技術的な稼働時間と、顧客へのサービス提供が完了したかどうかを分けて評価します。アプリケーションにアクセスできても、出力に大幅な修正が必要な場合や、承認済みの業務手順では出力を使用できない場合があります。顧客に対する実際の義務に結び付いたサービス指標を定義します。継続性のテストでは、入力から確認、提供完了まで、一連の処理を追跡します。例外の解決に必要な時間と、後続チームが追加作業を引き受けられる処理能力も含めます。
フォールバックが不十分になるポイントを特定します。責任者は、どのサービスが優先され、どのコミットメントにエスカレーションが必要かを知っておく必要があります。統合計画では、誰が変更を顧客に伝達するか、誰が一時容量への支出を承認するかを指定する必要があります。提案された代替運用策は、関係者、アクセス、操作手順が利用可能になるまで条件付きのままです。テスト証拠を保持し、条件が変化したときに再検証するようにスケジュールを設定します。
投資ケースには、新旧両方の取り決めが運用される期間を示す必要があります。どのようなコストが継続するのか、どの利点が移行の受け入れに依存するのかを記録します。財務部門は、基盤となるサービスがまだ以前の環境を使用している場合、法的手続きが完了した時点で完全な節約が始まるという想定に異議を唱える必要があります。提案されたモデルでは、一時的な並行運営が可視化されるため、委員会は合意された移行を支援するために必要な資金を評価できます。
重要な切り替えの前に、継続性の証拠を確認します。フォールバックが現在のデータ、ベンダー アクセス、スタッフ配置と依然として一致していることを確認します。組織再編前に作成された復旧計画には、必要な権限をもはや持たなくなった人物の名前が記載されている可能性がある。テスト記録では、実際の参加者と意思決定者を特定する必要があります。委員会の受諾声明には、次の段階で承認されたサービス取り決めを裏付ける証拠を明記する必要があります。
15. 範囲を明確にした統合支援業務を委託する
外部支援を委託する買い手は、判断の支援が必要な事項と、提供を受ける証拠を明確にする必要があります。提案する業務委託の範囲には、インベントリの照合、統制の比較、統合ガバナンス、実施計画の調整を含めることができます。適切な資格を持つ助言者が行う専門評価と、顧客側のチームが担う評価を明記します。運用承認とリスク受容に関する経営陣の責任は、委託後も維持される必要があります。
成果物を受け入れ基準に結び付けます。インベントリ成果物では、元の記録を照合し、未解決の範囲を特定し、重要なデプロイメントを責任者にリンクする必要があります。承認フレームワークは、代表的な変更に対してテストする必要があります。ベンダーのワークストリームでは、締結済みの契約条件と未解決の決定を記録する必要があります。関連する参加者とともにインシデント手順を実行する必要があります。最終報告書では、証拠の限界と、提案された運用モデルに依然として必要な措置について述べる必要があります。
資料を共有する前に、情報へのアクセス、機密保持、保持、および紛争管理の取り決めに同意します。アドバイザは、タスクと付与された権限に応じたアクセス権を受け取る必要があります。この範囲では、調査結果がどのように報告され、緊急の懸念がどのように経営陣に届くのかを説明する必要があります。発見中に特定された追加作業には、変更プロセスを文書化する必要があります。これにより、クライアントはさらなる調査を開始する前に、その費用と目的を承認することができます。
商業条件では、定義された作業に対するリテイナーと、実装支出、ソフトウェア料金、および専門家の料金を区別する必要があります。この文書の仮定に基づく予算は、Matchpoint Partners 料金提案ではありません。クライアント固有の提案には、確認された範囲、管轄区域、導入の複雑さ、証拠へのアクセスが必要になります。この論文も予備的な議論も、規制上のクリアランス、中断のない運営、または財務上の成果を約束するものではありません。
投資委員会にとって有用な業務完了時の成果は、承認された運営取り決め、残りの条件、および指定された責任者を示す決定記録です。この記録は、その後のガバナンス見直しや将来の買収統合をサポートすることができます。取引チームの解散後も、運営組織がその記録にアクセスできる状態を維持する必要があります。委託業務の完了基準には、合意された成果物と実際に提供された証拠が反映されている必要があります。
16. 文書化された運用上の結論に達する
委員会は、照合済みのインベントリと、重要なデプロイメントごとに具体的な運用上の決定を受け取る必要があります。どのシステムが承認された制限内で継続できるか、追加の条件が必要か、未解決の決定を待っているかを確認する必要があります。報告書では、これらのカテゴリーの背後にある証拠、重要な依存関係、および各結論に達した日付を特定する必要があります。集計完了率には、未処理項目の結果が伴う必要があります。
テストと責任ある承認によってサポートされる受け入れ条件を使用して、統合シーケンスを承認します。条件が満たされなくなった場合に特定の機能を制限する機能を保持します。移行期間中、顧客の継続性、法的義務、インシデントの権限を常に可視化します。提案された環境に必要な権限、評価証拠、運用サポートがあれば、技術的な統合を進めることができます。残りの分離には理由と検討条件を文書化する必要があります。
仮定に基づく計算は、2 つの異なる管理上の課題を示しています。インベントリの照合ではガバナンスが必要な母集団が定義され、実装予算では選択された範囲とタイミングの仮定の下での支出が特定されます。どちらの計算も、実際の展開の準備状況や商業的価値を確立するものではありません。買収委員会は、リソースを承認したり統合ケースを評価したりする方法を使用する前に、これらの仮定を取引証拠に置き換える必要があります。
提案されたフレームワークは、結合されたガバナンスプロセスの恒常的な担当責任者、承認された使用の維持記録、および変更とインシデントの決定のための作業ルートで終了します。その有効性には、運用とレビューによる証拠が必要です。したがって、次の投資決定には、初期統合プログラムの終了後にシステムを維持するためのコストと責任を含める必要があります。
付録 A. 導入決定のための最小限の証拠
提案された展開記録では、法人、事業側責任者、承認された目的、および運用環境を特定する必要があります。各企業の元の識別子と、照合後に使用されたグループ識別子を保持します。関連するモデルまたはサービスのバージョン、アプリケーションの構成、および依存関係をリンクします。運用事実を確認した日付とその確認を行った人を記録します。システムの把握が不完全なままの場合は、不足している証拠とその決定への影響について説明します。
承認セクションでは、該当する内部ポリシーと、関連アドバイザーから提供された法的条件または契約条件を特定する必要があります。評価結果にテスト範囲、分母、制限を添付します。監視措置、対応閾値、人間によるレビューの取り決めについて説明します。承認されたアクション機能とデータ アクセスの制限を記録します。決定では、承認者、発効日、有効期限またはレビュー条件、および再評価が必要な変更を特定する必要があります。
継続性セクションでは、フォールバック、そのテストされた容量、およびそれをアクティブ化する権限のある人について説明する必要があります。インシデント対応ルート、ベンダーのサポート手配、証拠保全手順を関連付けます。復旧の決定では、影響を受ける機能を再開する前に必要なテストと承認を指定する必要があります。現在の人員配置および契約上の取り決めに合わせて業務記録を維持します。引き継ぎの演習では、恒常的な担当責任者が証拠を見つけて必要なアクションを実行できることを確認する必要があります。
付録 B. 仮定に基づく計算の再現
インベントリは、A 社の 100 件のレコードと、B 社の 80 件のレコードから始まります。重複した管理レコード 15 件と、確認された廃止されたデプロイメント 25 件を差し引いて、新しく検出されたアクティブなデプロイメント 12 件を追加します。その結果、152 のアクティブなデプロイメントが行われます。 3 つの例示的な承認カテゴリーは、完全な証拠がある 82 件、条件付き承認のある 50 件、決定待ちの 20 件で構成されています。最初の 2 つのカテゴリは合計 132 です。 152 で割ると 86.8421% となり、86.8% と表示されます。
評価作業量の区分は、同じ152件の導入を別の観点から分類したものです。32件にUSD 4,000、60件にUSD 2,000、60件にUSD 500をそれぞれ乗じると、仮定上の評価支出はUSD 278,000となります。共通の立ち上げ費用USD 180,000と、月額USD 35,000の6か月分を加えると、合計はUSD 668,000です。追加の3か月と8件の詳細評価の再実施により、USD 137,000が加算されます。延長後の支出はUSD 805,000となります。割引現在価値、確率加重、インフレ調整、税額計算は含まれていません。
情報源
- 米国国立標準技術研究所。人工知能リスク管理フレームワーク、AI RMF 1.0、NIST AI 100-1、2023 年 1 月。任意のフレームワーク。ガバナンス、マッピング、測定および管理の成果。 一次ソースを読む
- 米国国立標準技術研究所。人工知能リスク管理フレームワーク: 生成人工知能プロファイル、NIST AI 600-1、2024 年 7 月。サードパーティの依存関係、組織のコンテンツ アクセス、およびバリュー チェーンの統合。 一次ソースを読む
- 米国国立標準技術研究所。サイバーセキュリティ リスク管理に関するインシデント対応の推奨事項と考慮事項: CSF 2.0 コミュニティ プロファイル、SP 800-61r3、2025 年 4 月。インシデントの権限、サードパーティの調整、復旧および改善。 一次ソースを読む
- 欧州連合。規則 (EU) 2024/1689、2026 年 7 月 27 日付けの統合文書。第 25 条、第 26 条および第 113 条。役割固有の規定と適用ルールには、トランザクション固有の評価が必要です。 一次ソースを読む
- 欧州委員会。AI法の実施・適用スケジュール。現行の公式概要、2026年9月10日閲覧。 一次ソースを読む
- サウジアラビア・データAI庁。AI倫理原則。説明責任、モニタリング、第三者に対するデューデリジェンス。2026年9月10日閲覧。 一次ソースを読む
- アラブ首長国連邦の人工知能・デジタル経済・リモートワーク応用担当国務大臣室。人工知能の開発と利用に関するUAE憲章、2024年7月。 一次ソースを読む
