EU AI法が8月2日に施行：エンジニアリングチェックリスト
EU AI法は2026年8月2日に全面施行され、高リスクAIシステムに具体的な義務を課します。本記事では、コンプライアンスをシステム設計とパイプラインに組み込むための実践的なエンジニアリングチェックリストを提供し、分類、リスク管理、データガバナンス、ログ記録、人間による監視などの主要分野をカバーします。
欧州連合のAI法（EU AI法、規則(EU) 2024/1689）は、2026年8月2日に全面施行されます。貴社のAIシステムが、採用、信用スコアリング、教育、重要インフラ、必須サービスなどの高リスクカテゴリに該当する場合、具体的で監査可能な一連の義務が「近々施行される規制」から、システムが従うべき法律へと変わります。
多くのチームは、2018年のGDPRへの対応と同様の方法でこれに取り組んでいます。つまり、弁護士が主導し、文書を作成するコンプライアンスプロジェクトです。しかし、このアプローチはAIシステムでは単純な理由で失敗します。システムの変化が書類作業よりも速いからです。前四半期のモデルの適合性評価は、今朝出荷したものについて規制当局にほとんど情報を提供しません。
これを解決するのが「コンプライアンスエンジニアリング」です。規制遵守を、事後的に書かれたレポートではなく、システムのプロパティとして扱い、設計に組み込み、パイプラインで強制し、継続的に証拠を示すことです。信頼性はこの移行を経てSREを生み出し、セキュリティはDevSecOpsを生み出しました。次はコンプライアンスです。
以下は実用的なバージョンです。高リスクシステムに関するEU AI法のコア義務を、それぞれを満たすエンジニアリングプラクティスと生成すべき証拠成果物にマッピングしたものです。各項目は同じパターンに従います：条項 → プラクティス → 証拠。
まず、重要な日付を把握しましょう：
- 2025年2月2日：禁止されるAI慣行が発効、AIリテラシー義務。
- 2025年8月2日：汎用AIモデルの義務、ガバナンス機関の運用開始。
- 2026年8月2日：全面施行（以下の高リスク義務を含む、附属書IIIシステム）。
- 2027年8月2日：規制製品に組み込まれた高リスクAI（附属書I）。
罰則は違反の程度に応じて、禁止慣行では最大3500万ユーロまたは全世界年間売上高の7％、その他のほとんどの義務違反では最大1500万ユーロまたは3％となります。これらはGDPR並みの数字であり、まさに取締役会が法務だけでなくエンジニアリングにも計画を尋ね始めている理由です。
チェックリスト：条項 → プラクティス → 証拠
- システムを正直に分類する（第6条および附属書III）
以降のすべては、システムが高リスクかどうかに依存します。プラクティス：分類をバージョン管理されたエンジニアリング上の決定とし、リポジトリに文書化し、重要な機能変更のたびに再評価します。第3四半期に追加したユースケースが、低リスクシステムを高リスクに変える可能性があります。証拠：理由を記載した日付入りの分類メモをバージョン管理に保存。
- 継続的なリスク管理システムを運用する（第9条）
法律はリスク管理をライフサイクル全体にわたって「継続的」かつ「反復的」であることを要求します。これはプロセス要件であり、文書要件ではありません。プラクティス：リスクレジスタをコードとして維持し、リリースごとにレビューします。軽減されていない既知のリスクがあるリリースはブロックします。証拠：リリースタグに関連付けられたレジスタの変更履歴。
- 監査可能なデータ管理を行う（第10条）
トレーニング、検証、テストデータは品質基準を満たし、バイアスの可能性を調査する必要があります。プラクティス：データセットごとにデータセットカードを作成し、ソースからモデルまでの系列を追跡し、パイプラインステップとしてバイアス検査を実行します（一度きりの調査ではありません）。証拠：トレーニング実行ごとに生成されるデータセット文書とバイアステストレポート。
- 技術文書を「作成」ではなく「生成」する（第11条および附属書IV）
附属書IVの文書は、市場投入前に存在し、最新の状態を保つ必要があります。手書きの文書は定義により古くなります。プラクティス：ドキュメントをコードとして扱い、ビルド時にシステム自体（アーキテクチャ、モデルバージョン、評価結果）から附属書IVパッケージを生成します。証拠：リリースごとに再現可能なドキュメントビルド。
- まだ監査を頼まれていない監査のためにログを記録する（第12条）
高リスクシステムは、そのライフサイクルにわたってイベントを自動記録する必要があります。プラクティス：初日から監査可能性を中心に、構造化された追記専用のログを設計します。入力、決定、モデルバージョン、オーバーライド、保存ポリシーを含めます。証拠：不変でクエリ可能なログ自体。
- 仮定ではなく指示を出荷する（第13条）
デプロイヤーはシステムを正しく解釈して使用できなければなりません。プラクティス：バージョン管理されたシステムカードと使用説明書を、チェンジログのようにリリースごとに提供します。証拠：バージョンごとの説明書アーカイブ。
- 人間による監視をポリシーではなく機能にする（第14条）
効果的な監視とは、人間が理解し、介入し、オーバーライドできることです。プラクティス：承認/オーバーライド/停止パスを製品サーフェスに組み込みます。ポリシーPDFにのみ存在する監視は「効果的」ではありません。証拠：人間が実際に制御を使用したことを示す監視インタラクションログ。
- リリースごとに正確性、堅牢性、セキュリティを証明する（第15条）
これらは測定可能な特性です。プラクティス：CIに回帰しきい値を持つ評価スイート、定期的な敵対的テストとレッドチームテスト、モデル固有の攻撃（ポイズニング、プロンプトインジェクション）に拡張された標準的なサイバーセキュリティ衛生。証拠：各リリースに添付される評価レポート。
- SDLCを品質管理システムとして機能させる（第17条）
プロバイダーはQMSを必要とします。ほとんどのエンジニアリング組織は、コードレビュー、CI/CD、インシデント対応など、QMSの80％をすでに運用していますが、名前を付けていないだけです。プラクティス：既存のライフサイクルを形式化し、ギャップを埋め、パイプラインに強制させます。証拠：プロセス文書とそれを強制するCI設定。
- 適合性評価をリリースゲートとして扱う（第43条、第47～49条）
市場投入前：適合性評価、EU適合宣言、CEマーキング、EUデータベースへの登録。プラクティス：これをリリースプロセスの最終ゲートとしてモデル化します。前述の9項目で既に生成された証拠を入力とします。これが、文書化するのではなくコンプライアンスをエンジニアリングすることの成果です。証拠：署名済みの宣言と登録記録。
- ローンチ後も真剣に監視する（第72条～第73条）
市販後監視は必須であり、重大なインシデントは報告する必要があります。最速で15日以内、より深刻なカテゴリではさらに迅速に。プラクティス：本番監視をインシデントプロセスに結び付け、規制報告を明確なランブックステップとします。証拠：監視ダッシュボードとインシデント記録。
今週から始めるべきこと：
- 分類（項目1）。実際に適用される義務がわかると、不安は半減します。
- チェックリストに対するギャップ評価。各項目について：プラクティスは存在するか？自動的に証拠を生成するか？ほとんどのチームはログと評価は近いが、文書とリスク管理はそうではないと感じています。
- 最もギャップが大きい2つを選んでエンジニアリングします。パイプランチェックと生成成果物であり、文書ではありません。生成された附属書IVパッケージは、手書きの10倍の価値があります。
8月2日に落ち着いていられるチームは、最も厚いバインダーを持っているチームではありません。システムが稼働の副作用として独自のコンプライアンス証拠を生成するチームです。これが分野全体を一言で表したものです。
完全なコンプライアンスエンジニアリングガイドは現在作成中です。
リリース時に入手するには、ウェイティングリストにご登録ください。
本記事はエンジニアリングガイドであり、法的アドバイスではありません。義務は役割（プロバイダーとデプロイヤー）、セクター、および加盟国の実施状況によって異なります。具体的な状況については資格のある法律顧問にご確認ください。