EU AI Actの規則、コンプライアンス期限を運用上の試練へと変える
EU AI Actは、Google Newsの見出しでは単なる新たな規制期限として扱われがちだが、決定的なコンプライアンス段階に入った。
この法律は現在、企業がAIシステムをどう分類し、保護措置を文書化し、利用者に情報を提供し、規制当局向けの証拠を準備するかに影響を及ぼしている。その適用範囲は欧州の開発者にとどまらない。システムまたはその出力が欧州連合に入る場合、海外の提供者も対象となり得る。
最も重要なのは3点だ。リスク分類によって適用義務が決まる。コンプライアンスには方針声明ではなく、運用上の証拠が求められる。執行は、AIサプライチェーン全体にわたる提供者、導入者、輸入者、販売事業者、その他の参加者に及び得る。
ここに中心的な緊張関係が生まれる。企業は多様なワークフローに適応可能なAIを導入したい一方、法律は各システムの意図された用途と実際の利用に応じて義務を割り当てる。
その結果、モデルをローンチするか撤回するかという単純な選択にはならない。組織は法的分析を、製品設計、データガバナンス、セキュリティ、調達、市販後監視と結び付けなければならない。
EU AI Actは政策論争から運用上の期限へ移行した
最も重要な変化は、AI Actが仮想的な将来の製品ではなく、実際の導入判断を規律するようになったことだ。
この規則は2024年8月1日に発効した。その要件は単一の共通開始日ではなく、段階的なスケジュールを通じて適用され始めた。
一部の容認できない用途を対象とする禁止規定は、2025年2月2日から適用された。同日には、提供者と導入者に対するAIリテラシー義務も導入された。
欧州委員会はAIリテラシーを、十分な情報に基づいてAI利用を判断するために必要なスキルと理解と説明している。この義務は専門のコンプライアンスチームにとどまらない。
汎用AIモデルに関する規則は2025年8月2日から適用され始めた。ガバナンス規定と加盟国の罰則枠組みも、法律の段階的な実施を通じて関連性を持つようになった。
残る規定の大半は2026年8月2日前後に予定されていた。規制対象製品に接続されるハイリスクシステムに関する一部の義務は、より遅いスケジュールに従う。
AI Actはシステムをリスクと機能によって分けているため、正確な時期が重要になる。企業はモデルベンダーを特定しただけでは、自社に適用される期限を理解できない。
公式のAI Act timelineが出発点となる。ただし企業はなお、このスケジュールを自社の役割と導入状況に対応付ける必要がある。
基盤モデルは、通常の文章作成アシスタント、採用スクリーニングツール、医療製品を支援できる。これらの用途に同一の義務が課されるわけではない。
同じ区別は企業にも当てはまる。モデル提供者、ソフトウェア統合事業者、販売事業者、企業導入者は、1つの製品チェーンの中で異なる義務を負う可能性がある。
この役割ベースの構造により、単一の全社方針だけで法規制に対応することは難しくなる。導入された各システムには、特定可能な責任者、目的、リスク判断、証拠の追跡記録が必要だ。
また、「新たな規則が適用される」と伝える見出しが実務的な指針として限られる理由でもある。有用な問いは、どの要件が、どのシステムと責任当事者に適用されるかだ。
企業はまず、大規模なソフトウェア契約を通じて購入した組み込みツールも含め、AIシステムの棚卸しを行うべきだ。従業員による非公式な導入も、管理されていないリスクを生む可能性があるため、棚卸しに含める必要がある。
次に、システムの意図された目的、影響を受ける利用者、モデルへの依存関係、データフロー、意思決定権限を記録すべきだ。これらの事実が分類の基礎となる。
調達チームも、ベンダーが必要な文書を提供し、インシデント調査を支援するかを把握する必要がある。障害発生後、契約文言だけで不足した技術情報を補うことはできない。
したがって、この変化は運用上のものだ。組織は広範な法的枠組みを、システム、人、データ、統制に関する数百の小さな判断へと落とし込まなければならない。
この作業は、雇用、教育、不可欠なサービス、法執行、移民、司法、特定の安全機能で使われるシステムにとって特に重要になる。
詳細な条件を満たす場合、これらの領域はAI Actのハイリスク分類に該当し得る。システムのマーケティング上の名称が結論を決めるわけではない。
まず覚えておくべきことは単純だ。期限は始まりにすぎない。実際の作業量を決めるのは分類である。
Google Newsの見出しが見落とすリスク分類の要点
AI ActはAIシステムをその目的とリスクに基づいて規制するため、1つのモデルが低リスクとハイリスクの双方の導入を支えることがあり得る。
Google Newsでは、最新規則に関する要約が数多く表示される。しかしそれらの要約が、組織の義務を左右する分類判断を説明することはほとんどない。
法律は複数の大まかなリスク水準から始まる。一部の行為は禁止され、特定のシステムはハイリスクとされ、一定のツールには透明性義務が課される。
他の多くのAI利用には、同じ詳細なコンプライアンス負担は課されない。引き続き適用法、契約上の統制、通常の組織的リスク管理の対象となる。
禁止される行為には、特定の操作、搾取、社会的スコアリング、生体分類、リアルタイムの遠隔生体識別などが含まれる。各禁止には、慎重な解釈を要する定義、条件、例外が含まれている。
例えば、この規則はあらゆる状況におけるすべての感情関連技術を禁止するわけではない。限定的な例外を条件として、職場や学校での感情認識を含む、特定の用途を対象としている。
ハイリスク分類は別の問題を生む。それは必ずしも導入を禁止しないが、システムのライフサイクル全体にわたる構造化された統制を求める。
official regulationは、ハイリスクに至る2つの主要な経路を示している。1つは、列挙された欧州法の対象となる安全コンポーネントおよび製品を対象とするものだ。
もう1つは、附属書IIIに列挙された特定のユースケースを対象とする。これには、雇用、教育、信用力、サービスへのアクセス、移民、司法に関わる一定の判断が含まれる。
したがって、一般的なオフィスアシスタントは、大規模言語モデルを用いるというだけでハイリスクになるわけではない。その目的と利用が法律上の関連条件を満たす場合に、分類が変わる。
雇用主がAIを使って公開求人の説明を要約するケースを考えてみよう。この用途は、雇用へのアクセスに関して候補者を順位付けする用途とは異なる規制上の性質を持つ。
基盤となるモデルは共通かもしれない。しかし、判断の文脈、影響を受ける権利、人への影響は異なる。
この区別は、1つのAIプラットフォームを複数部門に展開しようとする企業に圧力をかける。中央集権的な調達は、1つのベンダー審査ですべての利用を網羅できるという印象を生み得る。
しかし実際にはそうではない。マーケティング支援用に承認された製品が、その後、採用、顧客適格性、従業員評価のプロセスに組み込まれることがある。
企業には、目的の大幅な変更を審査するプロセスが必要だ。また、チームが再評価なしに承認済みツールを別目的で利用することを検知する統制も必要になる。
AI Actは、提供者と導入者の双方に責任を課している。導入者は、システムに自社名を付す、または大幅に変更することで、提供者の義務を負う場合がある。
導入者は、意図された目的を変更することで新たなリスクを生むこともある。このリスクにより、製品構成とワークフロー文書は法的にも重要となる。
人による監督も、しばしば誤解される要件の1つだ。プロセスに従業員を加えただけでは、監督が自動的に有意義なものになるわけではない。
その人には、出力に異議を唱えるために十分な権限、情報、能力、時間が必要だ。形式的な承認手順では、自動化バイアスに対してほとんど保護を提供しない。
したがって、分類プロセスはリスクラベル以上のものを生み出すべきだ。そのラベルがなぜ適用されるのか、どの証拠がそれを支えるのか、どの変更が再評価を引き起こすのかを明記すべきである。
この記録は、エンジニアリングチームが境界を理解する助けとなる。また、管理者がコンプライアンスを抽象的な法的見解として扱うことを避ける助けにもなる。
組織は、境界領域のケースを有資格の法律顧問と技術専門家とともに検討すべきだ。規則本文、欧州委員会のガイダンス、適用される標準はいずれもこの分析に影響する。
これが新たな規則の背景にある最初の大きな教訓だ。AIコンプライアンスは、モデルの一覧ではなく、システムマップから始まる。
ハイリスクAIにはライフサイクル全体にわたる証拠が求められる
ハイリスクシステムには、リリース前、利用中、問題発生後に機能する文書化された統制が必要だ。
AI Actのハイリスク枠組みは、製品ガバナンスと継続的な運用監督を組み合わせている。組織には、単にリスクを開示するのではなく、管理することが期待される。
提供者には、リスク管理、データガバナンス、技術文書、記録保持、透明性、人による監督、正確性、レジリエンス、サイバーセキュリティに関する義務が課される。
これらの要件は相互に結び付いている。リスク評価は予見可能な危害を特定し、テストと監視は統制がその危害に対応しているかを示す。
関連する場合、学習、検証、テスト用データにも厳格な注意が向けられる。組織は、適合性、代表性、品質、潜在的なバイアスといった特性を検討しなければならない。
この作業を完全に法務部門だけに委ねることはできない。データチームは来歴を理解し、エンジニアは故障モードを理解し、利用者は判断が行われる環境を理解している。
採用モデルは有用な例となる。開発者が明示的な保護属性を削除した場合でも、過去の採用データには従来の組織的選好が残り得る。
代理変数は依然として不平等な結果を再生産する可能性がある。したがって技術チームは、現実的なサブグループをテストし、評価の限界を文書化しなければならない。
正確性に関する主張にも同様の規律が必要だ。平均スコアは、まれなケースや特定の集団に対する低い性能を隠すことがある。
チームは、指標、テスト条件、既知の制限、許容可能な運用範囲を記録すべきだ。また、システムの確信度が十分でない場合に利用者が何をすべきかも説明すべきである。
サイバーセキュリティは別の側面を加える。AIシステムは、データ汚染、敵対的入力、プロンプトインジェクション、モデル抽出、接続先リソースへの不正アクセスに直面し得る。
適切な統制はアーキテクチャと文脈に依存する。単独で動作する分類器と、業務システムに接続されたエージェントでは、攻撃対象領域が異なる。
提供者は、ハイリスクシステムを市場またはサービスに投入する前に、技術文書を準備しなければならない。また、システムの変更に応じてその文書を最新に保つ必要がある。
導入者にも実務上の責任がある。利用説明に従い、適切な人による監督を割り当て、運用を監視し、自らの管理下にある場合にはログを保持すべきだ。
一部の公的機関や公共サービスを提供する民間事業体には、基本権影響評価の義務が課される場合がある。この評価では、人々、危害、監督、緩和策が考慮される。
この要件は、抽象的な権利に関する議論を導入時の確認ポイントへと変える。誰がシステムの影響を受けるのか、そして組織がどのように介入できるのかを問うものだ。
消費者信用を評価する銀行は、分かりやすい例を提供する。より分かりにくい例としては、不可欠なサービスへのアクセスの優先順位付けを支援するソフトウェアがある。
組織は、苦情が寄せられてからこの情報を収集すべきではない。インシデント後にシステムの挙動を再構築することは、バージョン、プロンプト、データソースが変わっている場合、困難になる。
AI製品は継続的に進化するため、バージョン管理は重要だ。モデルの更新によって、周辺インターフェースを変更せずに性能が変化することがある。
検索用データが変わる場合にも、同じ問題が生じる。ナレッジソースに新しい文書や権限が追加されると、システムは異なる結果を生成する可能性がある。
検索可能なAIナレッジベースは、チームによる証拠の整理に役立つが、リポジトリには所有責任と保持に関するルールが必要だ。構造化されていない文書保管だけでは、ガバナンスとはいえない。
有用な証拠には、分類判断、テスト報告書、データ記録、承認履歴、インシデントログ、利用者向け指示、ベンダー文書、是正措置が含まれる。
各成果物は、名称が特定されたシステムとバージョンに結び付けるべきだ。そうでなければ、レビュー担当者は、どの証拠が展開済みの構成に適用されるのか判断できない。
市場投入後の監視が、この循環を完結させる。提供者には、リリース後の性能情報を収集・分析する体系的な手法が必要だ。
重大インシデントの報告も求められる場合がある。組織には、カスタマーサポート、セキュリティ、エンジニアリング、法務、上級意思決定者を結ぶエスカレーション経路が必要となる。
このライフサイクル・アプローチが、2つ目の重要な教訓だ。コンプライアンスは、ローンチ時に取得して終わる証明書ではない。
それは、組織がどのようにリスクを特定し、安全対策をテストし、挙動を監視し、障害に対応したかを示す、継続的に維持される証拠の集積である。
汎用AIの規則はサプライチェーン全体に責任を分担させる
汎用AIに関する規則はシステムレベルの義務に取って代わるものではない。多くの下流用途を支えるモデルに対し、追加のコンプライアンス層を加えるものである。
汎用AIモデルは、幅広いタスクを実行し、多くのアプリケーションを支援できる。その柔軟性は商業的価値をもたらす一方、単一の意図された用途だけで統治することを難しくする。
そのためAI法は、これらのモデルの提供者に特定の義務を課している。これらの義務は、多くの高リスクシステム要件より早く適用が始まった。
モデル提供者は、技術文書を作成し、下流の組織に情報を提供しなければならない。その情報は、統合事業者が能力、制約、コンプライアンス上の考慮事項を理解する助けとなるべきだ。
また、欧州の著作権法を尊重するための方針を整備する必要がある。別の要件として、学習内容について十分に詳細な要約を公表することも求められる。
欧州委員会は、この制度を支える資料としてGPAI Codeを含む文書を整備している。このコードは、提供者が関連する義務への適合を示す助けとなることを目的としている。
すべての汎用モデルに同一の要件が課されるわけではない。AI法は、システミックリスクをもたらすと分類されるモデルに追加の責任を割り当てている。
モデルは、委員会の決定、または規制で定められた計算能力の閾値によって、この分類に入る可能性がある。法的枠組みでは、その他の関連する能力や特性も考慮できる。
システミックリスク・モデルの提供者には、モデル評価、敵対的テスト、システミックリスク評価、インシデント報告、サイバーセキュリティ保護に関する義務が課される。
これらの義務は、多数の下流製品へ波及し得るリスクに対処するものだ。1つのモデルの障害や脆弱性が、多数のアプリケーション、企業、利用者に影響を及ぼす可能性がある。
ただし、下流組織がコンプライアンス上の立場全体をモデル開発者に委ねることはできない。特定のシステム内でモデルをどのように機能させるかは、依然として下流組織が決定する。
ベンダーは、モデルの一般的な制約を文書化できる。しかし雇用主は、採用ワークフロー、影響を受ける候補者、監督設計、地域の運用条件を自ら評価しなければならない。
この分担は、上流の透明性と下流の責任との間に緊張を生む。統合事業者にはシステム評価に十分な情報が必要である一方、モデル提供者はセキュリティと商業上の利益を守る必要がある。
契約は重要になるが、あらゆる情報不足を解消できるわけではない。顧客は保証を受け取っても、自らの評価に必要なテストの詳細を受け取れない場合がある。
調達チームは、モデルのバージョン、評価手法、既知の制約、ログ、セキュリティ統制、インシデント通知、文書更新についてベンダーに尋ねるべきだ。
また、再委託についても理解する必要がある。アプリケーション提供者は、別のモデルベンダー、ホスティング企業、データサービスに依存している場合がある。
その連鎖のどこかで生じた変更が、性能やリスクに影響する可能性がある。組織には、重要なモデルおよびインフラの変更を対象とする通知条項が必要だ。
オープンソースでの配布には、さらに注意すべき点がある。規制には、要件を満たす自由・オープンソースライセンスの下で公開されたモデルに対する限定的な扱いが含まれている。
これらの規定は、普遍的な免除ではない。モデルや状況によっては、システミックリスクに関する義務やその他の条件が引き続き関係する。
ここで、単純化した比較は通用しなくなる。中心的な分岐は、オープンかクローズドか、欧州か米国かではない。
真の問題は、すべての参加者が割り当てられた役割を果たすのに十分な情報と統制を持っているかどうかだ。どの当事者もシステムレベルのリスクを担わない場合、その欠落は特に深刻になる。
透明性に関する義務は、特定のAI生成または操作されたコンテンツにも及ぶ。関連システムの提供者は、規制で求められる場合、機械可読な検出および識別を支援しなければならない。
デプロイヤーには、ディープフェイクや一部の公益に関わるテキストについて開示義務が課される可能性がある。例外や編集上の責任は、これらの義務がどのように運用されるかに影響する。
チャットボットや類似のシステムでは、人がAIと対話していることの通知が必要になる場合がある。その目的は、利用者が自動化された対話を人間とのコミュニケーションと誤認することを防ぐことだ。
これらの規則は、メディア、カスタマーサービス、マーケティング、職場向けツールにとって重要である。また、コンテンツが検索・集約サービスを通じて流通する方法にも影響を及ぼす。
Google Newsの報道は、透明性規則が導入されたことを読者に伝えられる。しかし、ある組織のインターフェース、出力、編集プロセスがそれらを満たしているかどうかは判断できない。
その判断は、展開されたシステム、責任主体、対象者、文脈に左右される。したがって3つ目の教訓は、責任の共有に関するものだ。
適合した基盤モデルが、自動的に適合した製品を生み出すと考えるべき組織はない。また企業は、アプリケーションベンダーがすべての下流義務を負うと想定すべきでもない。
執行により文書化は事業上の課題となる
AI法の制裁金は注目を集めるが、運用上の混乱や不十分な証拠も、同程度に深刻な事業リスクを生み得る。
この規制では、多額の行政制裁金が認められている。上限額は、違反の内容と関係する組織によって異なる。
特定の禁止行為に関する違反では、3,500万ユーロまたは全世界年間売上高の7％に達する可能性がある。その他の義務違反では、1,500万ユーロまたは3％に達する可能性がある。
不正確、不完全、または誤解を招く情報を提供した場合には、異なる上限が適用される可能性がある。この計算には事業体に関する規則と、小規模企業に対するより比例的な扱いが含まれる。
こうした上限が、すべての事案で最大の制裁金が科されることを意味するわけではない。当局は、重大性、継続期間、協力、軽減措置、過去の違反などの要素を考慮する。
それでも制裁の構造は、経営幹部の関心を変える。AIインベントリ、テスト予算、ベンダー統制は、資金が配分される他のコンプライアンス・プログラムと競合するようになった。
各国の権限ある当局は、重要な監督・執行機能を担う。欧州AIオフィスも、特に汎用AIに関して中心的な役割を果たす。
European AI Officeは欧州委員会内に置かれ、枠組みの関連部分にまたがる実施、調整、執行を支援している。
この分散した構造は、実務上の不確実性を生む。組織は、各国当局が要件をどのように解釈し、越境事案をどのように調整するかを注視することになる。
標準も実施に影響を与える。整合規格は、特定の法的要件への適合を示すための構造化された道筋を提供し得る。
しかし、標準化作業によって経営上の責任がなくなるわけではない。チェックリストはプロセスの存在を示せても、そのプロセスがシステムの実際のリスクを統制していることまでは証明できない。
独立したテストは引き続き重要だ。システムを運用する、またはその影響を受ける人々からのフィードバックも同様である。
従業員代表、アクセシビリティの専門家、セキュリティチーム、影響を受ける利用者は、実験室での評価が見逃す障害モードを明らかにできる。彼らの意見は、証拠の記録に組み込むべきだ。
最も強い懐疑的な見方は、実施能力に関するものだ。多くの組織は、モデル、組み込み機能、従業員が構築した自動化について、依然として信頼できるインベントリを持っていない。
そのインベントリがなければ、システムを一貫して分類したり、正しい役割を特定したりできない。また、ベンダーがコンポーネントを変更した時期も把握できない。
中小企業は別の圧力に直面する。コンプライアンスの専門家が少ない一方で、第三者プラットフォームへの依存度が高いことが多い。
大手サプライヤーは、顧客の限定的なユースケースに関する質問には答えない標準化文書を提供する場合がある。追加の透明性を交渉することは難しい場合がある。
規制当局も能力上の制約に直面する。一貫した執行には、技術的専門性、国家間の調整、既存の業界当局との明確な関係が必要だ。
この不確実性を、遅延の言い訳にしてはならない。むしろ、前提を記録し、ガイダンスの進展に応じて見直す、証拠に基づくアプローチを形作るべきだ。
企業は、方針のレビューだけに基づいて完全なコンプライアンスを主張すべきではない。展開済みのシステム、利用者の行動、監視プロセス、サプライヤーチェーンのすべてが重要となる。
また、法的な曖昧さを許可とみなすことにも抵抗すべきだ。便宜のために文書化せず下した判断よりも、文書化された合理的な分類の方が、より擁護しやすい。
Google Newsの読者は、即座に見出しになる劇的な制裁金額に触れるだろう。より示唆的なのは、当局が文書の質と測定可能な被害のどちらに重点を置くかである。
初期の事案は、規制当局が人間による監督、技術記録、インシデント対応、ベンダー依存をどのように評価するかを示す。また、デプロイヤーに対する期待も明らかにする。
その執行実績が積み上がるまでは、企業は両方の問いに備えるべきだ。どのような統制が存在するかを説明し、その統制が機能しているかを示す必要がある。
新しい規則が機能するかを示す3つのシグナル
次の段階では、AI法が実用的なガバナンス制度になるのか、それとも形式的な義務が断片的に集まったものになるのかが試される。
第1のシグナルは、欧州AIオフィスと各国当局による執行活動だ。初期の調査は、どの文書化の不足が最も厳しく注目されるかを明らかにする。
禁止行為に焦点を当てれば、この法律の権利に基づく基盤が強調される。高リスク統制に関する事案は、当局が運用上の証拠をどのように解釈するかを示すだろう。
第2のシグナルは、整合規格と関連ガイダンスの採用だ。企業には、リスク管理、ログ記録、データ品質、監督、市場投入後の監視に関する詳細な手法が必要である。
明確な標準は、不確実性を減らし、サプライヤーの比較を容易にする。遅延や相反する解釈は、越境展開のコストを増大させる。
第3のシグナルは、製品の振る舞いだ。主要なAIベンダーは、より優れた文書化、バージョン履歴、評価結果、インシデント通知の仕組みを提供すべきである。
これらの変更は、規制が技術および商業設計に影響を及ぼしていることを示すことになる。最低限の情報開示では、解消されないリスクを下流の組織が抱え込むことになる。
企業の買い手は、こうしたシグナルが完全に現れる前から行動できる。単一のシステム台帳を整備し、重要な導入案件ごとに説明責任を負う担当者を割り当てるべきだ。
各システムは、意図された目的と実際の利用状況に基づいて分類すべきである。各分類がなぜ適用されるのか、簡潔に記録しておく必要がある。
高影響システムについては、予見可能な障害モードに対するテストが必要だ。テストには、実際の対象集団、環境、人間による意思決定プロセスを反映させるべきである。
ベンダー評価では、ブランディングではなく証拠を検証すべきだ。買い手は、どのモデルバージョンが稼働しているのか、何が変更され得るのか、インシデントがどのように通知されるのかを把握する必要がある。
組織はまた、役割に応じて従業員を教育すべきである。一般的な意識向上セッションでは、レビュアー、開発者、調達チーム、インシデント対応者に必要な専門的トレーニングの代わりにはならない。
人による監督についても、独自のテストが必要だ。レビュアーが出力を理解できるか、拒否できるか、懸念をエスカレーションできるか、システムを停止できるかを確認する。
ログは、不必要なプライバシー上の露出を生まずに調査を支援できるようにすべきだ。アクセス制御と保存期間は、システムのリスクおよび法的要件に見合う必要がある。
そのうえでリーダーは、これらの統制をリリース管理に結び付けるべきである。モデル、目的、データ、またはワークフローに重要な変更があれば、再レビューを実施すべきだ。
Google Newsでこの動向を追う読者は、報道と並行して一次的な規制当局の情報源にも注目すべきである。締め切りはニュースになるが、実務上の意味を決めるのはガイダンスと執行だ。
欧州委員会のAI Act guidanceは、有用な参照点を提供している。組織はこれを、自らの役割と業界に合わせた法的助言と組み合わせるべきである。
EU AI Actは、提出期限を過ぎれば終わる単発のコンプライアンス対応ではない。企業が適応的なシステムを説明可能な形で管理できるかを継続的に問う試験である。
3つの重要な問いは、依然として具体的だ。そのシステムはどのように分類されるのか。安全対策が機能していることを示す証拠は何か。その挙動が変化したとき、誰が行動するのか。
まず、重要なAI導入案件を1件選び、これらの問いへの回答を書面でまとめるべきだ。回答が前提条件に依存する場合は、それを解消する担当者と期限を割り当てる。
この演習は、また1本の方針メモよりも、準備状況を多く明らかにする。また、次に到来する規制上のシグナルに組織が備える助けにもなる。
