AIシステムインベントリ（AIシステムレジストリとも呼ばれます）は、組織全体で利用されているすべてのAIシステム、モデル、エージェントを包括的かつ一元的に管理するカタログです。業務目的、所有責任、リスクレベルを追跡し、あらゆるエンタープライズ・ガバナンス・プログラムの基盤となります。完全なAIインベントリの構築は、現在ではEU AI法、ISO 42001、NIST AI RMF、ならびに財務省が新たに定めた金融サービスAIリスク管理フレームワークへの準拠において、厳格な前提条件となっています。

多くの組織は、いかにも単純に見える問いに答えられません。すなわち、現在、ビジネス全体で稼働しているAIシステムは何件あるのか、という問いです。信頼できる回答を示せないこと、そして包括的なAIインベントリが存在しないことは、単なる管理上の欠落ではありません。コンプライアンス上の責任問題であり、リスク管理上の盲点であり、世界各国の規制フレームワークが任意の指針から法的拘束力のある義務へと移行する中で、ますます持続不可能な状態です。

2024年8月に施行され、2027年にかけて順次適用が進むEU AI法は、高リスクAIシステムの導入者に対し、EUデータベースへの登録（第71条）と、適用対象となるすべてのシステムを完全に把握していることを前提とした文書管理を求めています。[1] AI管理システムの国際規格であるISO/IEC 42001は、認証の前提として、組織に対しAIシステムの適用範囲と文脈を文書化することを求めており、体系的な台帳化を実務上の必須事項としています。[2] NIST AIリスク管理フレームワークは、AIシステムの識別と分類をMap機能における基盤活動と位置付け、その後続のすべてのリスク測定と管理の流れにつなげています。[3] 2026年2月に公表された財務省の金融サービスAIリスク管理フレームワークは、AIインベントリを独立した管理目的（GV-1.6）として定義し、シャドーITの発見からポートフォリオレベルのリスク分析までを網羅する6つの副目標を設けています。[4] 包括的なAIインベントリがなければ、これらいずれのフレームワークへの準拠も構造的に不可能です。

しかし、企業内のすべてのAIシステムを台帳化する作業は、見た目以上にはるかに複雑です。本ガイドでは、ゼロからAIインベントリを構築するための体系的なアプローチを示します。何を記録すべきか、中央ガバナンスから見えにくいシステムをどのように発見するか、そして時間の経過とともにインベントリの正確性をいかに維持するかを含みます。

AIインベントリがガバナンスの基盤である理由

規制上の義務はさておき、完全なAIシステムインベントリは、事実上あらゆる下流のガバナンス活動の前提条件です。リスク評価は、存在が把握されていないシステムに対しては実施できません。バイアス監査は、調達部門が記録していないAIツールには到達できません。インシデント対応計画は、IT部門が可視化できていないAI主導プロセスを考慮に入れることができません。

インベントリなしで運用することの実務上の影響は、すでに明らかです。EU AI法の適用対象となる組織は、高リスクシステムについて欧州データベースへの登録義務を負います。[1] ISO 42001認証を目指す組織は、組織全体でAIシステムを特定し管理する体系的プロセスを示さなければなりません。[2] イングランド銀行、FCA、欧州中央銀行を含む金融規制当局は、企業がどの意思決定がアルゴリズムやAIベースのツールによって影響を受けているかを正確に把握していることを前提とした監督上の期待事項を発出し始めています。[5] そして2026年2月時点で、米国の金融機関は、ベースラインとなるAIインベントリなしには完了できない財務省FS AI RMFの質問票に対応できる状態である必要があります。[4]

この課題は、AI導入のスピードによってさらに複雑化しています。マッキンゼーの2024年グローバルAI調査によると、72%の組織が少なくとも1つの業務機能でAIを導入しており、導入率は前年比でほぼ倍増しています。その多くは中央の監督を伴わず部門レベルで進行しています。[6] Enzaiのようなプラットフォームは、エンタープライズ規模で動的なAIインベントリを維持する複雑さに対処するために特化して登場しており、発見、リスク分類、継続監視を単一のガバナンス層で接続します。

AIインベントリはコンプライアンスのチェックボックスではありません。あらゆる他のガバナンス活動が依拠する唯一の成果物です。

2026年版AIインベントリに含めるべき項目：更新要件

多くの組織が最後にインベントリ仕様を見直してから、2つの点が変化しました。規制水準が引き上げられ、台帳化の対象となるシステムそのものが進化したのです。2024年にEU AI法への備えを目的として設計されたインベントリは、2026年の要件には実質的に不十分です。

2026年の規制環境

EU AI法 - 高リスク義務は2026年8月2日に適用開始。 第9条から第15条に基づく高リスクシステム要件一式、第43条に基づく適合性評価、第50条に基づく透明性義務、および第71条に基づくEUデータベース登録は、2026年8月2日に発効します。[7] 2025年11月に提案されたDigital Omnibusは、Annex IIIの期限を2027年12月まで延長する案ですが、提案は現在もトリローグ協議中であり、結果は不透明です。したがって、対応計画は8月を基準とし、延長はあくまで不確実性への備えとして扱うべきです。インベントリ上の意味は明確です。Annex IIIのいずれかに該当しうるすべてのシステムは、識別可能であり、分類済みであり、登録可能な状態にしておく必要があります。

財務省金融サービスAIリスク管理フレームワーク - 2026年2月19日公表。 米国財務省は2026年2月19日、AIレキシコンと併せて金融サービスAIリスク管理フレームワーク（FS AI RMF）を公表し、NIST AI RMFを金融機関向けに230の管理目的へ適用可能な形で調整しました。[4] AIインベントリの構築は独立した管理目的、すなわちGV-1.6であり、シャドーITの発見からポートフォリオレベルのリスク分析までをカバーする6つの副目標を含みます。現時点では任意フレームワークですが、監査人の期待を急速に形成すると見込まれています。金融サービス組織にとって、インベントリは今やFS AI RMF質問票を完了するための基盤として機能しなければなりません。

コロラドAI法および並行する州法。 コロラドAI法は当初2026年2月1日施行で、現在は改正案が係属中ですが、重要な意思決定においてアルゴリズム差別を回避するため、高リスクAIシステムの開発者および導入者に合理的注意義務を課しています。[8] コロラド準拠を支えるインベントリには、意思決定への影響、影響を受ける集団、および重要意思決定フラグを記録する必要があり、これらは旧来のAIインベントリには必ずしも含まれていない項目です。

ISO/IEC 42001およびNIST AI RMF。 継続的な任意フレームワークです。ISO 42001認証では、AIシステムを特定し管理するための体系的プロセスを示す必要があります。NIST AI RMFは、Map機能における基盤活動として識別と分類を位置付けています。[2][3]

2026年に新たに記録すべき項目

2026年に特に追加される項目と考慮事項は以下のとおりです。

• エージェンティックシステムのフラグ。 システムが自律エージェントであるかどうか、自律性レベル（EnzaiのエージェンティックAIガバナンスガイドを参照）、およびそのシステムが動作する限定された行動空間。

• 基盤モデル依存関係。 サードパーティの基盤モデル上に構築されたシステムについては、モデル提供元、モデルバージョン、バージョン固定ポリシー、ならびに提供元が更新を行った際の再検証トリガー。

• EU AI法のリスク分類項目。 Annex IIIカテゴリ（該当する場合）、高リスク分類の理由、適合性評価の経路、EUデータベース登録状況、市場投入後監視計画の参照先。完全な義務区分については、EnzaiのEU AI法コンプライアンスガイドをご参照ください。

• FS AI RMFマッピング（金融サービス）。 関連する管理目的、特にGV-1.6の副目標への割り当て。これには、対外的な露出、機微データまたは規制対象データの使用、顧客や市場への影響、重要度が含まれます。

• シャドーエージェント発見フラグ。 正式な調達手続きを経ずに採用された自律エージェントの個別追跡。SaaSプラットフォームに埋め込まれている、あるいはデータサイエンスチームが非公式に構築したケースが頻繁に見られます。

• 大幅変更のトリガー。 既存システムへの変更が、EU AI法第3条第23項における「大幅変更」に該当し、再評価を引き起こす条件の定義。

これらは、以下に示すフィールドフレームワークへの追加項目です。すでに下位の基本項目をカバーしている組織は、ゼロから作り直すのではなく、2026年固有のデータを追加するためのターゲットを絞った拡張作業を計画すべきです。

発見の難しさ

インベントリ自体を構築する前に、なぜAIシステムの台帳化が難しいのかを理解することが不可欠です。AIは、可視性の観点で従来のソフトウェアのようには振る舞いません。既存ツールに埋め込まれ、サードパーティAPIを介して動作し、調達部門を一度も通らない個々の従業員の判断によって拡散していきます。

シャドーAI - 最も大きな発見課題はシャドーAI、すなわち正式承認なしに従業員やチームが採用したシステムです。マーケティング担当者が個人のクレジットカードでAI搭載のコピーライティングツールを契約するケース、営業チームがAI会議文字起こしサービスを使うケース、財務チームがブラウザ拡張機能を通じて大規模言語モデルを試験利用するケースなどです。これらはいずれも、いかなるガバナンスフレームワークの外側で組織データを処理するAIシステムを意味します。

SaaSプラットフォームに組み込まれたAI - 大手エンタープライズソフトウェアベンダーは、既存製品にAI機能を驚異的なスピードで統合しています。予測リードスコアリングを導入したCRMプラットフォーム、履歴書スクリーニングを追加したHRシステム、自動応答生成を展開したカスタマーサポートツールなどです。これらはAIシステムですが、多くの場合、新規調達ではなく機能アップデートとして提供されるため、従来のソフトウェア監査では見逃されます。

ベンダーおよびサードパーティAI - 組織が、サービス提供にAIを使用するベンダーを利用する場合、EU AI法などの規制フレームワークの下で、そのAIシステムの導入者になる可能性があります。候補者スクリーニングにAIを使う身元調査サービス、申請の一次振り分けにAIを使う保険金請求処理の外部委託先、経路最適化にAIを使う物流パートナーなどです。いずれも、そのシステムの存在を把握することから始まるガバナンス義務を生み出します。

社内構築AI - データサイエンスチーム、イノベーションラボ、ソフトウェアエンジニアリング部門が、正式なリリース管理プロセスを通らないままAIモデルを構築・展開することがあります。Jupyterノートブックが本番環境へ昇格するケース、部門サーバー上で稼働する機械学習モデル、概念実証から業務上重要な意思決定へと誰にも正式な発注を受けないまま発展した自動意思決定スクリプトなどです。

発見の難しさは、本質的に可視性の問題です。従来のIT資産管理はAIを想定して設計されておらず、多くの組織が依拠するツールやプロセスでは、AI資産の大部分を見落としてしまいます。

AIインベントリに記録すべき内容

実用的なAIインベントリは、網羅性と運用性のバランスが取れていなければなりません。少なすぎる記録では、リスク評価やコンプライアンスに十分対応できません。多すぎる記録は保守負荷を生み、インベントリの劣化を招きます。以下のテンプレートフレームワークは、規制要件、業界標準、および実務上のガバナンス要件が求める項目をカバーしています。

基本識別項目

所有責任と説明責任

リスクおよびコンプライアンス分類

技術的・運用的詳細

エージェンティック固有項目（該当する場合）

ライフサイクルとステータス

すべてのシステムについて、初回入力時にすべての項目が埋まるとは限りません。実務的なアプローチとしては、受け入れ時に必須とする項目（システム名、オーナー、導入形態、リスク分類）と、最初のガバナンスレビューサイクルまで繰り延べ可能な項目を定義します。EnzaiのAIインベントリスキーマはこの段階的アプローチを実装しており、必須の受け入れ項目と段階的な拡張項目を区別することで、チームがすべてを飛ばしてしまうことも、200のシステムごとに22項目のフォームで身動きが取れなくなることも防ぎます。目的は、すべての項目を完璧に埋めるまでインベントリを遅らせることではなく、構造を確立し、ギャップを体系的に埋めていくことです。

発見手法

何を記録すべきかを明確にしたら、次の問いは、組織内で稼働しているすべてのAIシステムをどのように見つけるかです。単一の手法だけで完全な網羅は達成できません。効果的な発見プログラムは、複数のアプローチを組み合わせて用います。

自動スキャンと技術的発見 - ネットワークトラフィック分析により、OpenAI、Google、Anthropic、AWSなどの主要クラウドAIエンドポイントを含む、既知のAIサービス提供元へのAPI呼び出しを特定できます。DNSログ、プロキシサーバーの記録、CASB（クラウドアクセスセキュリティブローカー）ツールは、正式承認されていないAIサービスへの接続を検出できます。ソフトウェア構成解析は、社内開発アプリケーション内のAIライブラリやフレームワークを特定できます。

Enzaiのようなプラットフォームを利用する組織は、自動発見機能をガバナンスワークフローに直接組み込むことで、必要な手作業を削減し、新たに検出されたシステムが直ちに分類・レビュー対象としてフラグ付けされるようにできます。

調達およびベンダー監査 - 調達記録、ソフトウェアライセンス契約、ベンダー契約を体系的に見直すことで、正式なチャネルを通じて導入されたAIシステムを洗い出せます。多くのベンダーが、もともとAI機能を持たない製品に後からAI機能を追加しているため、既存契約の遡及レビューも含めるべきです。調達チームには、AIまたは機械学習機能を含む新規導入を必ずフラグ付けするよう周知すべきです。

従業員アンケートと自己申告 - シャドーAIを発見するうえで、業務部門への直接的な働きかけは依然として最も有効な手法の1つです。AI、機械学習、自然言語処理、自動意思決定を含むツール、サービス、モデルの利用有無をチームに尋ねる構造化アンケートは、技術的スキャンでは検出できないシステムを確実に明らかにします。正直な申告を促すため、アンケートは取締りではなくガバナンス支援を重視する建設的な表現にするべきです。

ベンダー質問票 - 既存のサードパーティ関係については、サービス提供にAIが使われているか、使われているならその種類と目的は何かをベンダーに尋ねる的を絞った質問票が、組み込みAIおよびサードパーティAIの特定に有効です。これは特に、顧客への明示的通知なしにAIが導入される可能性のあるアウトソース業務プロセスで重要です。

ネットワークおよびAPIトラフィック分析 - 既知のAIエンドポイントのスキャンにとどまらず、APIトラフィックパターンをより深く分析することで、目立たない経路で通信するAIシステムを発見できます。外部エンドポイントに送信される構造化JSONペイロードや、ML推論特有の遅延プロファイルなど、モデル推論呼び出しに一致するパターンを監視することで、他の手法では見逃されるシステムを浮かび上がらせられます。

最も堅牢な発見プログラムは、これらの手法を並行して実行し、定期的に繰り返します。単一のスイープで大半のシステムは捕捉できますが、新しいAIツールが組織に入る速度に追随するには、継続的な発見が不可欠です。

インベントリ運用プロセスの構築

AIインベントリの耐久性は、それを支えるプロセスとガバナンス構造に左右されます。明確な責任分担、部門横断の関与、定義されたワークフローがなければ、どれほど入念に作った初期台帳でも数か月で劣化します。

責任の確立 - 企業資産としてのAIインベントリは、単一の機能部門が所有しなければなりません。多くの組織では、Chief AI Officer（役職が存在する場合）、Chief Information Security Officer、Chief Compliance Officerのいずれかがこれを担います。重要なのは、すべての事業部門に情報開示を求めるのに十分な権限と、分類およびリスク評価についてエンジニアリングチームと協働できる十分な技術的信頼性を備えていることです。

部門横断の関与 - インベントリ運用には、複数機能の積極的な参加が必要です。

• ITおよびエンジニアリングは、技術的発見能力を提供し、社内構築AIシステム、インフラ詳細、統合ポイントを特定できます。

• 調達は、新規AI導入をフラグ付けし、既存ベンダー関係を遡及的に見直します。

• 法務およびコンプライアンスは、EU AI法のリスクカテゴリ、FS AI RMFの管理目的、データ保護義務を含む規制要件に照らしてシステムを分類します。

• 事業部門リーダーは、各チームで利用中のAIツールを特定し、各システムの業務上の所有責任を割り当てます。

• データ保護／プライバシーは、個人データ処理を評価し、GDPRおよび同等のフレームワークとの整合性を確保します。

• 内部監査は、定期的にインベントリの完全性と正確性を検証します。

受け入れワークフローの定義 - 調達、内製、またはスキャンによって発見された新しいAIシステムは、すべて標準化された受け入れワークフローを通過させるべきです。このワークフローには、初期登録（基本識別項目の入力）、暫定的なリスク分類、業務オーナーおよび技術オーナーの割り当て、そして正式なガバナンスレビューの予定設定を含めるべきです。受け入れプロセスは、回避したくなるような手間を生まない程度に軽量である一方、基本的なガバナンス文書なしにはいかなるシステムも本番環境に入らない程度には厳格でなければなりません。

ガバナンスの頻度設定 - インベントリは、少なくとも四半期ごとに正式レビューすべきです。各レビューでは、完全性（前回以降に新しいシステムが追加されたか）、正確性（既存システムの詳細は依然として正しいか）、コンプライアンス状態（承認済みのリスク範囲外で稼働しているシステムはないか）を評価します。

明確な責任のないプロセスは、単なる願望にすぎません。責任、部門横断の合意、定義された頻度を備えたプロセスこそが、真のガバナンスプログラムです。

時間経過に伴うインベントリの維持

初期構築は、課題の前半にすぎません。正確で生きたインベントリを維持するには、トリガー、自動化、そしてより広範な組織変更管理との統合が必要です。

インベントリ更新のトリガー - 以下のいずれかが発生した場合、インベントリを更新すべきです。

• 新しいAIシステムが調達、構築、または導入された

• 既存システムが実質的に変更された（新しいデータソース、意思決定範囲の変更、モデル再学習、基盤モデルのバージョン変更）

• システムが廃止または停止された

• ベンダーが、既存製品へのAI機能追加を通知した

• 規制変更により、既存システムのリスク分類が変わった

• AIシステムに関するインシデントが報告された

• 組織再編により、システムの業務上の所有責任が変更された

継続的な発見 - 技術的発見手法は、定期的な作業ではなく継続的に実行すべきです。AI APIトラフィックの自動スキャン、新しいAI SaaSツールに対するCASBアラート、新規リリース内のAIコンポーネントを検知するソフトウェア配備パイプラインとの統合は、システムが組織に入ってからインベントリに現れるまでの遅延を短縮するうえで貢献します。

変更管理との統合 - AIインベントリは、既存の変更管理およびITサービス管理プロセスに組み込むべきです。変更諮問委員会は、標準評価項目としてAIインベントリへの影響を含めるべきです。ソフトウェア配備プロセスには、AIコンポーネントの有無確認を組み込むべきです。ベンダー管理ワークフローには、AIの開示を標準の契約・レビュー要件として含めるべきです。

バージョン履歴と監査証跡 - インベントリエントリへの変更はすべて、タイムスタンプ、変更者の識別情報、更新理由を添えて記録すべきです。この監査証跡は、単に望ましい運用ではありません。複数の規制フレームワークで明示的に求められており、監査人や監督当局からも期待されます。

維持運用こそが、多くのAIインベントリが失敗する局面です。成功する組織は、インベントリを年1回見直す静的な文書ではなく、業務ワークフローに統合された生きたシステムとして扱っています。

よくある落とし穴

十分なリソースを持つ組織であっても、AIインベントリの構築・維持では予測可能な失敗パターンに直面します。これらの傾向を事前に認識することで、持続可能な成果が得られる可能性は大きく高まります。

AIの定義を狭くしすぎる。 インベントリを「機械学習モデル」に限定すると、ルールベースの自動意思決定システム、認知要素を含むロボティック・プロセス・オートメーション、エージェンティックシステム、業務全体で非公式に使われる生成AIツールを見逃します。インベントリ目的で何をAIシステムとみなすかは、EU AI法第3条第1項のような広範な定義に整合する形で、意図的に広く設定すべきです。[1]

インベントリをITプロジェクトとして扱う。 インベントリがIT部門のみに所有されていると、事業部門によるAI導入は体系的に過少報告されます。逆に、コンプライアンス部門のみに所有されていると、技術的詳細は乏しく不確実になります。部門横断の所有は任意ではありません。

初回入力で完璧を目指しすぎる。 インベントリ公表前にすべてのシステムについてすべての項目を埋めようとする組織は、永遠に公表できません。現実的なアプローチは、初期構築で部分的な記録を許容し、その後のレビューサイクルでギャップを埋める体系的プログラムを実施することです。

ベンダーAIを軽視する。 組織に最も大きな影響を与えるAIシステムは、第三者が運用しているもの、すなわち身元調査プロバイダーのAI、信用スコアリング機関のモデル、クラウドプラットフォームの自動セキュリティツールであることが少なくありません。これらは、可視性が低いぶん、社内構築システムと同等、あるいはそれ以上のガバナンス注意を必要とします。

エージェンティックシステムを見落とす。 多くのレガシーインベントリは、静的AI、すなわち人が結果を解釈する予測やコンテンツを出力するモデル向けに作られています。複数ステップのワークフローにわたり自律的に行動するエージェンティックシステムには、追加項目（自律性レベル、アクションのホワイトリスト、エスカレーショントリガー、監査証跡の保存場所）と追加のガバナンス手法が必要です。静的モデルと別にエージェンティックシステムを明示しないインベントリでは、適切なガバナンスを支えられません。完全なフレームワークについては、EnzaiのエージェンティックAIガバナンスガイドをご参照ください。

インベントリを行動につなげない。 年1回レビューされるスプレッドシートとして存在し、リスク評価、インシデント管理、規制報告プロセスから切り離されたAIインベントリは、ガバナンス価値がほとんどありません。インベントリはAIガバナンスプログラムの運用上の背骨でなければならず、その付録であってはなりません。

維持負荷を過小評価する。 多くの組織におけるAI導入の速度を考えると、今日完成したインベントリは、積極的な維持プロセスがなければ3〜6か月以内に実質的に不完全になります。組織は、初期構築だけでなく、継続的な保守作業にも予算を確保すべきです。

ガバナンス価値を生み出すAIインベントリと、棚ざらしになるインベントリの違いは、初期台帳の洗練度ではありません。重要なのは、最新性を保ち、意思決定に接続し続けるプロセスの厳格さです。

実務上の意味合い

規制の方向性は明白です。EU AI法、ISO 42001、NIST AI RMF、財務省FS AI RMF、そして拡大し続ける業界別の監督上期待事項は、すべて同じ基礎要件に収斂しています。すなわち、組織は自社がどのAIを持ち、どこで稼働し、誰が責任を負い、どのようなリスクをもたらすのかを把握しなければなりません。この能力を構築するコストは、遅れるほど増大します。なぜなら、あらゆる企業におけるAIシステムの数は、過去に遡って台帳化できる能力よりも速く増えるからです。

不完全であっても今すぐ着手する組織は、規制期限に追い立てられて行動するまで待つ組織よりも、明らかに有利な立場に立てます。本ガイドで示したテンプレートフレームワーク、発見手法、プロセス構造は、具体的な出発点を提供します。

監査可能な記録システムを維持するうえで、適切なAIシステムインベントリツールを選定することは極めて重要です。AIガバナンス、リスク、コンプライアンスのために特化して設計されたプラットフォーム内でAIインベントリを運用したい組織に対し、Enzaiは発見、分類、継続保守のための体系的なアプローチを提供します。実際の動作を確認するには、デモを予約してください。

Enzaiは、組織が抽象的な方針から運用上の監督へ移行するのを支援するために特化して構築された、業界をリードするエンタープライズAIガバナンスプラットフォームです。当社のAIリスク管理プラットフォームは、エージェンティックAIガバナンスを管理し、包括的なAIインベントリを維持し、EU AI法コンプライアンスを確保するために必要な専用インフラを提供します。複雑なワークフローを自動化することで、Enzaiは企業がグローバル標準である ISO 42001 およびNISTとの整合性を保ちながら、自信を持ってAI導入を拡大できるよう支援します。

参考文献

1. 人工知能に関する調和された規則を定める規則（EU）2024/1689（人工知能法）。欧州連合官報、2024年8月。

2. ISO/IEC 42001:2023 - 情報技術 - 人工知能 - マネジメントシステム。国際標準化機構、2023年12月。

3. Artificial Intelligence Risk Management Framework（AI RMF 1.0）、NIST AI 100-1。米国国立標準技術研究所、2023年1月。

4. 米国財務省、「財務省、金融セクターにおけるAI利用を導く2つの新しいリソースを公開」、2026年2月19日。金融サービスAIリスク管理フレームワークおよびAIレキシコンを含む。AIインベントリは管理目的GV-1.6。

5. イングランド銀行、FCA、PRA、PSR、「人工知能と機械学習」、DP5/22、2022年10月。PRA監督声明SS1/23、2023年。

6. McKinsey & Company、「2024年初頭のAIの状況：生成AIの導入が急増し、価値創出が始まる」、2024年5月。

7. 規則（EU）2024/1689、第113条〜第114条（施行および適用日）。欧州委員会のAIに関するDigital Omnibus案（2025年11月提出）は、トリローグ協議を条件にAnnex IIIの期限を延長する可能性があります。

8. Colorado SB 24-205、人工知能に関する消費者保護について、2024年5月署名。元の施行日は2026年2月1日。現在、立法改正案が係属中です。