モデル更新を社内で承認する時の確認軸は何ですか？

出力の使われ方、対象者、入力データ、リスク分類、既存テストの有効性を確認します。開発工数の大小ではなく、評価前提が変わるかを見ることが大切です。

変更履歴にはどこまで残すべきですか？

変更内容、理由、承認者、再テスト結果、利用開始日を最低限そろえると説明しやすくなります。後から軽微な修正だったと示すにも、記録が必要です。

Substantial Modification (AI Act)とは、EU AI Actで、AIシステムの当初の適合性や想定された使い方に影響する大きな変更を指す言葉です。2026年6月時点では、AIを更新し続けるほど変更管理が重要になることを示す規制用語として理解できます。

AIシステムは、モデル、データ、プロンプト、接続する業務システムを変えるだけで振る舞いが変わる設計です。画面上は小さな改修でも、判断結果や利用目的が変わるなら、Substantial Modificationとして扱われる論点になり得ます。

たとえば採用選考で使うAIを別職種に広げる、与信審査AIの入力項目を増やす、モデルを別系統へ差し替えるといった変更は、初回の適合性評価の前提を崩すかを確認すべきです。

Substantial Modificationが問題になるのは、変更後も同じ評価でよいのかという場面です。Conformity Assessment Procedure (AI Act)で確認した前提が変わるなら、文書更新や再評価が必要になる可能性があります。

ここで大切なのは、変更の大小を開発工数だけで測らないことです。利用目的、対象者、リスク、出力の使われ方が変わるかを見ます。経営層には、AI改善のスピードと規制対応の記録をセットで考える視点が必要です。

AI導入後は、いつ、誰が、何を、なぜ変えたかを残す運用が欠かせません。変更履歴がなければ、軽微な修正だったと説明する根拠も弱くなります。

モデル更新のたびに法務確認を重くする必要はありません。ただし高リスクAIシステムでは、変更を分類する基準、再テストの条件、承認者、利用停止の判断を事前に決めておくと、事業スピードと安全性を両立しやすくなります。

Article 3(23)は、作業量の大きさではなく、事前に見ていた適合性への影響を軸にこの言葉を置いています。開発チケットでは小さく見える更新でも、利用者や判断場面が変われば、経営会議で扱うべき差分になるかもしれません。

モデル更新を社内で承認する時の確認軸は何ですか？: 出力の使われ方、対象者、入力データ、リスク分類、既存テストの有効性を確認します。開発工数の大小ではなく、評価前提が変わるかを見ることが大切です。
変更履歴にはどこまで残すべきですか？: 変更内容、理由、承認者、再テスト結果、利用開始日を最低限そろえると説明しやすくなります。後から軽微な修正だったと示すにも、記録が必要です。