この記事は EU AI Act 第14条を実装の観点から読み解いた解釈です。条文の逐語訳でも、法的助言でもありません。正確な要件は原文（出典は末尾）にあたってください。

EU AI Act の高リスク AI 向け義務は、2026年8月2日から本格的に適用されます。EU 市場に AI を組み込んだプロダクトを出していれば、日本企業でも域外適用の対象になり得ます。

その中で、第14条「人による監督（Human Oversight）」は実装に落とすのに手間取った条項でした。監督という言葉が指す状態を、コードやアーキテクチャの何に対応させればいいのか、条文だけでは決めきれません。この記事では、第14条のうち実装に直結する部分を取り上げます。

「全件を人が承認」ではない

第14条を初めて読むと、AI の判断をすべて人が事前に承認しなければならないのか、と身構えるかもしれません。条文を読み直すと、求めているのはそこではありません。人が AI を監視でき、必要なときに介入して止められること、そしてそれが可能なようにシステム側が設計されていること。判断ごとに事前承認を挟むかどうかは、ユースケースとリスクに応じて決める部分です。

ここを取り違えると、両方向に外します。全機能に承認フローを入れてプロダクトが重くなるか、ポリシー文書に「人が監督する」と書いて済ませるか。後者が通らないのは、第14条が運用ルールではなく設計要件だからです。中身の見えないモデルの上に手順書を載せても、設計要件は満たせません。

設計要件として読み替えると、見るべき点ははっきりします。AI の挙動を人が理解できること、人が結果に介入できること、稼働中の AI を止められること。14条4項が並べる監視・出力解釈・不採用・上書き・中断は、おおむねここに収まります。

挙動を理解できる状態にする

担当者が AI の限界を把握し、挙動を監視し、おかしな動きに気づける。出力をどう解釈するかも、ここに含まれます。

実装の側では、スコアだけを返すのではなく、根拠・確信度・結果に影響した主な要因を一緒に出します。なぜその結果になったのかが見えなければ、人は承認も却下も判断できません。

加えて、入力分布の変化・エラー率・想定外パターンを拾う監視とアラート、いわゆるドリフト検知が要ります。動作状況をダッシュボードで見られるようにしておく、というところです。

結果に介入できるようにする

状況に応じて、人が AI を使わない・出力を採らない・上書きする・取り消す、といった手を打てること。実装の軸はレビュー画面で、AI の出力と根拠を人が見て、承認・却下・修正できるようにします。事前確認を挟みたいユースケースなら、出力をいったん保留にして、人が承認してはじめて確定する流れにします。

ここで抜けやすいのが、上書きした判断が下流まで届くかどうかです。AI の出力がそのままパイプラインを流れてしまい、人の上書きがどこにも反映されない、という構成は実際にあります。レビュー UI を作った時点で満足しやすいので、上書きの反映先は別途確認しておくのが無難です。

安全に止められるようにする

稼働中の AI に介入して止められること。stop / kill switch を用意し、安全側の状態へ落とせるようにします。連続処理や自動制御のように即時停止が物理的に難しい場合は、止める代わりに「安全に停止させる手順と、その間の状態」を設計に含めておきます。

自動化バイアス対策は、ほぼ UI の問題

第14条には、担当者が AI の出力を鵜呑みにしないこと、つまり自動化バイアスを抑える要求も入っています（14条4項(b)）。これは「気をつけましょう」という運用の心がけではなく、UI 設計で潰す対象です。

たとえば、人が判断を入力する欄を AI の答えで初期値として埋めない。埋めた瞬間、人はほぼそのまま承認します。確信度や「ここは不確実」という情報も併せて出す。重要な判断はワンクリック承認にせず、能動的な確認をもう一段挟む。この作り込みの差が、「監督している」が実態を伴うかどうかを分けます。

介入の記録を残す（第12条と地続き）

監督は、記録が残ってはじめて証跡になります。誰がいつ何に介入したかのログです。第12条の記録保持要件ともつながる部分で、たとえば次の粒度で残しておけば、監査が入ったときに人がどう監督していたかを示せます。

{
  "event_id": "ovr_20260610_0001",
  "timestamp": "2026-06-10T09:30:00Z",
  "system_id": "credit-scoring-v3",
  "decision_id": "dec_88231",
  "ai_output": { "score": 0.82, "recommendation": "reject" },
  "human_action": "override",
  "human_decision": "approve",
  "operator_id": "user_4471",
  "reason": "AIが見落とした補足書類を確認したため",
  "model_version": "v3.2.1"
}

具体例：採用スクリーニング

採用は附属書 III の高リスク用途に当たります（附属書 III 第4号）。応募者をスコアリングする AI を例にすると、こうなります。

担当者はスコアと並べて主な要因を見られる。「不採用」の推奨はそのまま確定せず、人が確認してから確定する。推奨は上書きでき、理由はログに残る。スコアの偏りは監視し、必要ならアラートが上がる。介入はすべて記録される。

要素は多く見えますが、各所に「人が判断へ関与できる余地」を設計として埋め込んでいるだけです。

なお、顔認証のような遠隔生体識別は扱いが別です。識別結果に基づいて動く前に、2人以上が別々に確認すること（four-eyes）が求められます（14条5項）。該当する場合は、2人承認のフローを足します。

チェックリスト

手元の実装を点検するなら、見るのはこのあたりです。

出力に根拠・確信度・主な要因が含まれているか
ドリフトや異常を検知する監視とアラートがあるか
必要な箇所に「保留 → 承認」のフローがあるか
人の上書きが下流の処理に反映されるか
安全に止められるか
自動化バイアスを誘発する UI になっていないか（初期値埋め、ワンクリック承認）
介入の監査ログが残るか
（生体識別なら）2人での確認フローがあるか

まとめ

第14条は、監督の手順を後から書き足すのではなく、人が介入できる余地をシステムに組み込んでおくことを求めています。具体的には、挙動が人に見える出力と監視、人が結果を覆せるレビューと反映経路、安全に止める停止機構、そして介入のログ。UI と停止機構とログに落ちる話で、モデルができてから上に乗せるのは難しい部分です。

適用開始の2026年8月2日まで、それほど余裕はありません。まずは手元の AI に、人が割って入れる経路があるかを見るところからで十分だと思います。

出典

EU AI Act / Regulation (EU) 2024/1689, Article 14 (Human oversight)（14条4項(a)〜(e)＝監視・出力解釈・不採用・上書き・中断、14条4項(b)＝自動化バイアス、14条5項＝遠隔生体識別の2名確認）
関連条項：Article 12 (Record-keeping)（介入ログ）、Annex III 第1号(a)（遠隔生体識別）、Annex III 第4号（雇用・採用）