本記事はEU AI Act 第12条を実装観点で整理したものであり、法的助言ではありません。実際の対応判断は法務・専門家に確認してください。
2026年8月2日から、EU AI Actの高リスクAI向けの義務が本格的に適用されます。EU市場にAIを載せたプロダクトを出している場合、日本企業でも域外適用で対象になり得ます。
前回は第14条(人による監督)を扱いました。第14条の記事で「介入はログに残す」と書きましたが、その残し先のルールにあたるのが今回の第12条(記録・ログ保持)です。
第12条も、読んだだけでは何を作ればいいのかが見えにくい部類です。求めているのは「イベントを自動で記録できるように作ること」と「追跡可能性を確保すること」。ただ、記録する中身も、形式も、保存期間も、責任の所在も、本文には書かれていません。そこを実装に落として考えてみます。
条文が要求していること
条文の要求は、性質の異なるいくつかの点に分かれます。まず、記録は自動であること。システム自身がイベントを残す必要があり、人が手で書き起こす運用は該当しません。対象期間も決まっていて、ログを取り始めた時点からではなく、デプロイから廃止までの全期間が範囲です。そして、用途に見合った追跡可能性(traceability)。これは、リスクを生みうる状況や重大な変更の特定、市販後モニタリング、運用監視に使えるイベントを残すこと、という意味です。
実装に引き直すと、狙いははっきりしています。ある判断について、あとから何が起きたかを再構成できる状態にしておくことです。いつ実行され、どの入力に対して、どのモデルが何を返し、人がどう関与したか。監査やインシデント調査で「この判断はなぜこうなったのか」を辿れること、それがゴールになります。
何を記録するか
何を記録するかは、保存先の技術から考えるより、「あとで見返したい一番小さな単位は何か」から考えるほうが決めやすいです。高リスクな判断、推奨、アクション、上書き、エスカレーション、モデル更新のようなライフサイクルイベント——このあたりが記録の単位になります。
1件のイベントに持たせるフィールドは、だいたいこのあたりです。
- タイムスタンプ
- システムID／モデルのバージョン
- イベント種別(推論・上書き・設定変更・リスク検知など)
- 判断ID／相関ID(後述)
- 入力の参照(生の個人データそのものではなく、ハッシュや参照キー)
- 出力／判断結果
- 根拠・理由
- 関与した人(第14条の介入記録とつながる)
- 完全性メタデータ(後述)
JSONにすると、たとえばこんな形です。前回の第14条の記事で出した「上書きの記録」は、そのまま第12条のログ1件になります。
{
"event_id": "evt_20260610_0001",
"timestamp": "2026-06-10T09:30:00Z",
"system_id": "credit-scoring-v3",
"model_version": "v3.2.1",
"event_type": "human_override",
"decision_id": "dec_88231",
"correlation_id": "req_5f2a9c",
"input_ref": "sha256:9b1c...",
"ai_output": { "score": 0.82, "recommendation": "reject" },
"human_decision": "approve",
"operator_id": "user_4471",
"reason": "AIが見落とした補足書類を確認したため",
"prev_hash": "sha256:71de...",
"record_hash": "sha256:0a4f..."
}
相関ID(correlation_id)を通しておくと、推論から人の介入(第14条)、最終結果までを一本の線でつなげられます。監査では個別のログより「この判断がたどった流れ全体」が問われるので、この串刺しがあると後の対応が楽になります。
なお、入力に個人データが含まれる場合、ログには生データではなく参照(ハッシュやキー)を残し、生データは元のシステム側でその保持ルールに従って持つ、という分け方が無難です。理由は次の保持期間のところとつながります。
保持期間:最低6ヶ月、ただしGDPRと引っ張り合う
ログの保持には別の条文があります。プロバイダーは第19条、デプロイヤーは第26条6項で、自社の管理下にあるログを、用途に見合った期間、最低でも6ヶ月保持することが求められます(金融機関は、金融規制側で保持している文書の一部として扱う形になっています)。
「自社の管理下にあるログ」という言い方なので、責任はアーキテクチャで分かれます。SaaSとして提供しているならプロバイダー側、自社環境で動かしているならデプロイヤー側に、管理下のログの保持義務が寄ります。両方にまたがることもあります。
ここで引っ張り合いが起きます。AI Act側は「最低6ヶ月は残せ」と言い、GDPR側は「個人データは必要以上に持つな(保存制限)」と言う。条文自身も、保持期間は「特に個人データ保護に関するEU法による別段の定めを除く」と逃げ道を残しています。実装での落とし所は、さきほどの「ログには参照を、生の個人データは元システムに」という分離です。これなら、判断の追跡に必要なログは6ヶ月以上持ちつつ、個人データを過剰に溜め込まずに済みます。
改ざんされにくさをどう担保するか
第12条そのものには、「ログを改ざんできないようにせよ」という文言はありません。そこは正直に切り分けておきます。ただ、追跡可能性も「当局に出せる証跡」も、ログが信頼できることが前提です。あとから誰かに書き換えられるログでは、証跡として成り立ちません。さらに第15条(正確性・堅牢性・サイバーセキュリティ)が、挙動や性能を勝手に変えられないことへの耐性を求めているので、ログの完全性もそのセキュリティ要件の延長線上にあります。
実装としては、追記専用(append-only)やWORMで保存し、ハッシュチェーンや署名をかけて、記録が後から書き換えられていないことを検証できるようにします。先ほどのJSONの prev_hash／record_hash がそれにあたります。読み出し側も野放しにせず、誰がログを参照・エクスポートしたかも残します。繰り返しになりますが、これらは条文に書かれた要件ではなく、目的を満たすための実装上の判断です。
取り出せること
記録して終わりではなく、必要なときに取り出せることまでが実装に含まれます。当局やインシデント対応で問われるのは、ある高リスクイベントについて、誰がどの判断をいつ下し、その理由は何だったのかを、その場でまとめて出せるかどうかです。あとから手作業で継ぎ接ぎしないと再現できないログでは、間に合いません。判断IDや対象、期間で検索でき、レビューに耐える形式でエクスポートできる——そこまでが範囲です。
生体識別は別建て(第12条3項)
附属書III 1(a)の遠隔生体識別システムは、追加で記録すべき項目が決まっています。最低でも、各利用の期間(開始・終了の日時)、照合した参照データベース、一致した入力データ、そして結果を確認した人物(第14条5項の2人確認)の特定、です。前回触れたfour-eyesは、ここで記録の対象にもなっている、という対応関係です。該当する場合は、これらを専用のフィールドとして足します。
チェックリスト
実装に落とすとき、論点になるのはだいたいこのあたりです。
- イベントが自動で(手作業に頼らず)記録されるか
- デプロイから廃止までの全期間が対象になっているか
- ログ1件で、その判断の経緯を後から再現できるか
- 相関IDで推論〜介入〜結果がつながるか
- 入力の個人データは参照で残し、生データは元システムに分離しているか
- 管理下のログを最低6ヶ月保持できるか(プロバイダー＝第19条／デプロイヤー＝第26条6項)
- 改ざん耐性(追記専用・ハッシュ・署名)とアクセス記録があるか
- 判断ID・期間で検索し、エクスポートできるか
- (生体識別なら)利用期間・参照DB・一致入力・確認者を記録しているか
まとめ
まとめると、第12条が求めているのは、記録の運用ルールではなく、システム自身が証跡を残せるように設計しておくことです。その証跡が信頼でき、必要なときに取り出せることまでが一体になっています。今回触れたのは、記録するイベントの決め方、保存期間(最低6ヶ月とGDPRの折り合い)、それと完全性・エクスポートの担保でした。いずれも、できあがってから後付けするのが難しい部分です。
なお罰則として、第12条のような高リスク義務の違反は、第99条で最大1,500万ユーロまたは全世界売上高の3%が上限とされています(禁止行為に対する7%の枠とは別です)。罰を避けるために作るというより、後から付け足しにくい領域なので、最初の設計に織り込んでおくのが結局は楽だと思います。
出典
- EU AI Act / Regulation (EU) 2024/1689, Article 12 (Record-keeping), Article 19 (Automatically generated logs), Article 26(6) (Obligations of deployers), Article 72 (Post-market monitoring), Article 79(1), Annex III point 1(a)