EU AI Act の義務発効スケジュールの全体像は？

2024年8月1日：法案発効。2025年2月2日：禁止 AI 実践（ソーシャルスコアリング、潜在意識操作）と AI リテラシー義務が発効。2025年8月2日：GPAI モデル義務が発効。2026年8月2日：Annex III 高リスク AI システム義務が発効（雇用、信用スコアリング、教育など）。2027年8月2日：Annex I 高リスク AI（医療機器など規制製品に組み込まれたもの）義務が発効。Digital Omnibus 法案が可決された場合、Annex III の期限は2027年末まで延長される可能性があります。

法務チームがない小規模スタートアップが使える無料ツールは？

まずは EU AI Act 公式 Compliance Checker（artificialintelligenceact.eu/assessment/）で5分間の Annex III 自己評価を行うのがおすすめです。EuConform も追加のコンプライアンスチェックを提供しています。ISO 42001 フレームワークを AI ガバナンス文書の基盤として活用し、スペインの AESIA ガイダンスを最も包括的な実装リファレンスとして参照できます。これらのリソースで、一人でも AI マッピング、役割特定、リスク分類の3ステップを完了できます。

EU AI Act エンジニア向けコンプライアンスガイド：リスク分類から最小限の準拠パスまで

あなたの AI 機能のうち、どれが「高リスク AI」に該当するか把握していますか？履歴書スクリーニングツール、信用スコアリングモジュール、AI カスタマーサービスシステム。ほとんどのエンジニアはその答えを知りませんが、2026年8月2日までにやるべきことの全てがこの答えにかかっています。

EU AI Act の高リスク AI 義務は2026年8月2日に全面発効し、違反した場合の罰則は最大1,500万ユーロまたはグローバル売上の3%です。GDPR と同様に、この規制は会社の所在地を問いません。AI の出力が EU 域内の人々に影響を与えれば、適用範囲内です。

このガイドではエンジニアに実践的なパスを提示します：5分間のリスク自己評価 → 法規上の役割確認 → 最小コストでの技術文書準備 → 4ヶ月カウントダウン行動計画。最初の3ステップは弁護士なしでも完了できます。

TL;DR

AI 製品の出力が EU ユーザーに影響を与える限り、会社の所在地に関係なく EU AI Act の適用対象
高リスク AI（履歴書スクリーニング、信用スコアリング、医療判断など）のコンプライアンス期限は 2026年8月2日
Claude/GPT API で製品を構築すると、Deployer（モデルに対して）と Provider（自社製品に対して）の両方の義務が発生
現在のコンプライアンスの最大の推進力は B2B 顧客の調達要件であり、罰金への恐怖ではない（現時点で罰金実績ゼロ）
まず公式 Compliance Checker で5分間の自己評価を実施

あなたの SaaS は EU AI Act の適用範囲内か？

EU 域外のエンジニアの最初の反応は「うちの会社はヨーロッパにないのに、なぜ関係があるの？」というものです。答えは：EU AI Act は GDPR と同様に出力地主義（output-based jurisdiction）を採用しています。Provider の設立場所に関係なく、AI システムが「EU 市場に投入」されるか「EU でサービスとして使用」されれば、規制対象です。

簡単に言うと、あなたの SaaS にヨーロッパのユーザーがいて、AI の出力が EU 域内の自然人に影響を与えていれば、適用範囲内です。

義務が発生する具体的なシナリオ：

HR SaaS がヨーロッパのオフィスで履歴書スクリーニングに使用されている
FinTech 製品が EU 顧客の信用評価に使用されている
AI チャットボットがヨーロッパのユーザーからの問い合わせを処理している

「EU ユーザーは数人しかいないけど、それでも準拠が必要？」正直なところ、規制には「小さすぎて気にしなくていい」という閾値がありません。高リスク AI の義務は規模に関係なく適用されます。ただし、まず Annex III の自己評価を完了してください。システムが高リスクでなければ、重い義務のほとんどは適用されません。

Annex III 自己評価：5分で高リスクかどうかを判断

これはコンプライアンスプロセス全体で最も重要な最初のステップですが、最もスキップされがちです。エンジニアコミュニティの観察によると、多くの開発者がコンプライアンスチェックリストを受け取った後、リスク分類を完全にスキップして Annex IV の技術文書作成に直行します。問題は、システムが高リスク AI でなければ、そのドキュメント作業は全て無駄になることです。

Annex III は8カテゴリの高リスク AI システムを列挙しています。SaaS 製品で最も頻繁に該当するカテゴリ：

カテゴリ	Annex III 分類	一般的な SaaS の例
雇用管理	第4類	履歴書スクリーニング、業績評価、昇進・解雇の判断
基本サービス	第5類	信用スコアリング、ローン審査、保険の価格設定
生体認証	第1類	顔認識、本人確認システム

注目すべき例外：純粋な不正検知目的の AI は高リスクに分類されません。FinTech 製品が信用スコアリングを行わず、異常取引の検出のみに AI を使用している場合、高リスクの範囲外になる可能性があります。

実践的なステップ：EU AI Act 公式 Compliance Checker を開いてください。これは SME 向けに設計された無料のインタラクティブツールで、5-10分で自己評価が完了します。結果は以下を示します：

高リスクではない → 基本的な透明性要件のみ適用（AI と対話していることをユーザーに通知）。負担が大幅に軽減
高リスク → 以下の技術文書とヒューマンオーバーサイト要件に進む

まず分類、それからドキュメント。この順序が重要です。

Provider か Deployer か？API で構築する場合の責任境界

高リスクであることが確認された後、次の重要な質問は：AI バリューチェーンにおけるあなたの役割は何か？

Article 3 は2つのコアロールを定義しています：

Provider：自らの名前で AI システムを開発し市場に投入する個人または法人
Deployer：職業活動において AI システムを使用する自然人または法人

一見明確ですが、実際には：Claude や GPT API を使って SaaS 製品を構築する場合、あなたは同時に両方の役割を担います。

基盤モデル（Claude/GPT）に対しては Deployer であり、Article 26 の義務（指示に従った使用、入力データ品質の確保、運用監視）に従います。自社ブランドで出荷する完成 AI 製品に対しては Provider であり、Articles 9-22 の全義務（技術文書、CE マーキング、リスク管理、EU データベース登録）の対象です。

役割	主な義務	適用条文
Provider	技術文書、リスク管理、CE マーキング、EU データベース登録、適合性評価	Articles 9-22
Deployer	指示に従った使用、入力データ品質、運用監視、適格な監督者の配置	Article 26

よくある誤解：「OpenAI の API を使っているから、コンプライアンスは OpenAI の責任だ」。そうではありません。OpenAI には独自の GPAI 義務がありますが、自社製品に対する Provider 義務は独立しており、相互に相殺できません。

エスカレーションルール：サードパーティの GPAI モデルに実質的な変更を加えたり、新しい用途でリブランディングした場合、完全な Provider にエスカレートし、全義務セットの対象になります。

推奨アクション：AI Inventory を作成し、各 AI 機能の役割特定と義務マッピングを行ってください。

Annex IV 技術文書 MVP：小規模チームの最小実行可能バージョン

高リスク AI の Provider であることが確認された場合、Annex IV 技術文書の準備が必要です。核心は：すでに記録してある設計判断を整理することであり、ゼロから本を書くことではありません。

Annex IV は9つのセクションで構成されています。各セクションの最小実行可能バージョン：

セクション	内容	すでに持っている可能性のある文書
1. 一般的な説明	システムの目的、バージョン、想定ユーザー	製品 README、PRD
2. 開発要素	アーキテクチャ、学習方法、データソース	アーキテクチャ図、設計文書
3. 監視と制御	機能限界、特定グループの精度	テストレポート、監視ダッシュボード
4. 性能指標	精度、偽陽性/偽陰性率、公平性	モデル評価レポート
5. リスク管理	特定されたリスクと緩和策	リスク文書、インシデントログ
6. 変更履歴	バージョン履歴、主要な更新	Git ログ、changelog
7. 適用標準	採用した標準または代替案	コンプライアンスマッピング表
8. 適合性宣言	EU 適合性宣言の写し	新規作成が必要
9. 市販後モニタリング	継続的な監視計画	監視 SOP

規制は SME が「簡素化された方法」で文書を提出することを明示的に許可しており、欧州委員会は SME 専用の簡素化フォームを公開予定です（2026年4月現在未公開）。

業界の見積もりでは、設計判断を継続的に記録してきたシステムで40〜80時間の準備が必要です。最も大変な作業は新しい文書を書くことではなく、散在する既存の記録を Annex IV フレームワークにマッピングすることです。

実務上の現実：CEN-CENELEC の harmonized standards は2026年末に完成予定ですが、コンプライアンス期限は2026年8月2日です。つまり、期限前に完全な公式技術標準は存在しません。

現在の最善の代替パス：ISO 42001（AI マネジメントシステム標準）をフレームワークとして使用し、スペイン AESIA ガイダンス（現時点で唯一の完全な EU AI Act 実装ガイド）で補完します。

Article 14 ヒューマンオーバーサイトの実装：ボタン一つでは足りない

Article 14 は、高リスク AI システムが効果的なヒューマンオーバーサイトを可能にするよう設計されることを要求しています。多くのエンジニアの最初の反応は「オーバーライドボタンを追加すればいい」ですが、それでは全く不十分です。

エンジニアコミュニティのコンセンサス：meaningful override はアーキテクチャ設計の問題であり、UI の問題ではない。監査証跡が異常時に許可モード（allow-mode）にフォールバックする場合、それは虚偽のコンプライアンス記録を作成していることになります。

Article 14 の5つのエンジニアリング要件：

HMI ツール：ダッシュボードやアラートで、オペレーターが AI 決定の異常をリアルタイムで監視
中断メカニズム：オペレーターがシステムレベルで AI 出力を真に停止できること（UI での「無視」だけではない）
自動化バイアス防止設計：AI への過度の依存を認識させるシステム設計
解釈性ツール：AI が特定の判断を下した理由を監督者が理解できる説明可能性機能
機能限界の開示：システムの限界を監督者に明確に伝達

設計原則は fail-closed：AI システムが不確実な場合、デフォルトで判断を拒否すべきであり、デフォルトで承認すべきではありません。

チェックリスト：

異常時にシステムが判断を拒否（fail-closed）し、デフォルトで承認しない（fail-open）
監査証跡が全てのヒューマン介入を記録し、自動的にバイパスされない
監督者がオーバーライドを実行する実際の権限と技術的能力を持つ
オーバーライドメカニズムがフロントエンド UI だけでなく、システムアーキテクチャレベルで機能する

2026年8月2日カウントダウン：4ヶ月行動計画

Orrick のコンプライアンスガイドに基づく6つのステップ。良いニュース：ステップ1〜3は一人で完了できます。

ステップ1：AI マッピング（今週中に実行可能）

組織全体の全 AI システムと GPAI モデルを棚卸し。API 経由でアクセスするツールも含めます。各システムの目的、データソース、影響を受ける人物をリスト化。

ステップ2：役割特定（今週中に実行可能）

各システムについて Provider、Deployer、またはその両方かを判断。

ステップ3：Annex III リスク分類（今週中に実行可能）

公式 Compliance Checker で各 AI 機能の自己評価を完了。全て高リスクでなければ、重い義務は適用されません。

ステップ4：技術文書（4〜5月）

高リスクシステムについて、既存の設計文書を Annex IV の9セクションフレームワークにマッピング開始。ISO 42001 をガバナンスアーキテクチャの基盤として使用。

ステップ5：契約更新とデューデリジェンス（5〜6月）

AI サービス契約を改訂し、サードパーティ API の修正権限に対処。上流 GPAI プロバイダーのコンプライアンス状態を確認。

ステップ6：AI ガバナンスフレームワーク（6〜7月）

社内 AI ポリシー、AI リテラシー研修、部門横断の協力プロセスを確立。なお、AI リテラシー義務は2025年2月2日からすでに発効しています。

EU 域外企業で高リスク AI Provider として欧州市場に参入する場合、追加コストがあります：EU 域内認定代理人（Authorized Representative）。業界の見積もりでは、サードパーティの代理人サービスの年間費用は約2,000〜5,000ユーロです。

執行状況とコンプライアンスの真の推進力

正直な評価として：2026年時点で EU 27加盟国のうち AI Act 執行機関を正式に設立したのは8カ国のみで、罰金実績はゼロです。欧州委員会の Digital Omnibus 提案は高リスク義務を2027年末まで延長する可能性があります。

では、なぜ今行動すべきか？

本当の推進力は罰金への恐怖ではなく、B2B 顧客のプレッシャーです。 欧州企業は SaaS ツールの調達時にすでに AI Act コンプライアンス声明を要求しています。先にコンプライアンスを達成した企業は B2B 営業で直接的な競争優位を得られます。

見落とされがちなリスク：

LLM API + GDPR の交差領域：個人データを含むプロンプトをサードパーティ LLM API に送信する場合（例：Claude で EU ユーザーの履歴書を処理）、GDPR のデータ処理協定義務が同時に発生します。最低コストの解決策：LLM に送信する前に個人識別情報を除去すること。

法規の重複：FinTech 分野では DORA + GDPR + AI Act の3つの規制に同時に直面する可能性があります。DORA の4時間インシデント報告ウィンドウは AI Act の文書要件とエンジニアリング上の競合を引き起こす可能性があります。

Digital Omnibus は免罪符ではない：可決されたとしても、期限を最大16ヶ月延長するだけです。今 AI マッピングと文書整理を始めるコストは無駄になりません。ISO 42001 フレームワークはどの時点でも有効です。

まとめ

EU AI Act のエンジニアへの影響は現実のものですが、コンプライアンスパスは法律文書が示唆するよりも実行可能です。最もよくある間違いは、分類をスキップして直接ドキュメントに取りかかること、または「サードパーティ API を使っているから自分は準拠する必要がない」と思い込むことです。

今日できる最初のステップ：公式 Compliance Checker を開いて、5分間で Annex III の自己評価を完了してください。実際にどの程度の対応が必要か、結果が教えてくれます。思ったより軽いかもしれません。