これから来るAIの規則：海外に販売するタイ企業が準備すべきこと

要点

法律で義務づけられる前から、海外の顧客はAIの使い方を尋ねる質問票を送ってくるようになります。
大量の書類を用意するより、システムが最初から作業の証拠を自動で記録するようにしておくほうが役に立ちます。
法律の解釈は法律顧問の仕事です。私たちがお手伝いできるのは、システムが証拠を確実に残せるようにするところです。

1. 顧客に聞かれる前に、タイ企業が備えておくべき理由

法律より先に届くことが多いのは、大口顧客からの質問票です。AIをどこで使っているのか、顧客データをどこに送っているのか、AIの結果を誰が確認しているのかを尋ねてきます。1週間以内に答えられない会社は、気づかないうちに商談を失っていることがよくあります。

規則が適用されるかどうかは、開発者の所在地のほかに、販売先の市場や影響の大きさでも決まることがあります。ヨーロッパの企業顧客は、規則の施行日より前に、質問票や契約上の要件をサプライチェーンの取引先へ送ってきます。システムの一覧も文書もない会社は、製品の品質がよくても商談を失うおそれがあります。

EUのAI法（EU AI Act）のほかにも、タイの個人情報保護法（PDPA）、消費者保護法、知的財産法、業界ごとの規則が関係します。分析はユースケースごとに行う必要があります。「うちはAPIを使っているだけ」と言って、自社には義務がないと考えてはいけません。

注意点この記事は、事業の準備を進めるための枠組みを示すものです。法律もスケジュールも変わる可能性があるため、判断の前に、実際の製品、市場、自社の役割、契約を法律顧問に確認してもらってください。

2. 製品計画に組み込むべきスケジュール

よい知らせもあります。準備すべきことの多くは、本来どの会社もやっておくべきことです。データがどこにあり、誰がアクセスでき、システムが判断を誤ったときにどう元に戻すかを把握しておく、といったことです。

開発者、利用者、販売者のどれにあたるかで規則上の義務が違うため、自社の立場を先に確かめる

EUの公式情報によると、この規則は段階的に適用されます。透明性に関する要件と執行の大部分は2026年に始まります。附属書III（Annex III）に挙げられた一部の高リスクシステムに関する要件は2027年後半、規制対象の一部の製品に組み込まれた高リスクAIに関する要件は2028年に適用される予定です。

会社は期限まで待つべきではありません。データガバナンス、品質管理、技術文書の整備、監視には時間がかかるからです。とくに販売サイクルの長い製品では、顧客が早い段階から準備状況（Readiness）を求めてくることがあります。

時期	企業がやるべきこと
現在〜2026年	AIの棚卸し、リテラシー、透明性、契約
2027年	高リスクの分類、証跡、QMS（品質マネジメントシステム）、サプライヤーの準備状況
2028年	適用範囲に応じた製品のコンプライアンス、監視、監査

3. 自社が提供者（Provider）、導入者（Deployer）、仲介者のどれにあたるかを先に確かめる

義務は役割によって異なります。自社の名前でシステムを作る会社は提供者（Provider）にあたる可能性があり、業務プロセスの中でシステムを使う会社は導入者（Deployer）です。輸入業者や販売業者にも固有の義務がある場合があります。システムに大きな変更を加えたり、意図された目的（Intended Purpose）を変えたりすると、役割が変わることがあります。そのため、サプライチェーン全体にわたる契約マップ（Contract Map）が必要です。

システムに組み込まれたコンプライアンスのワークフローが、作業を増やさずに証拠を自動で集める

ユースケースの棚卸し（Use-case Inventory）を作り、目的、影響を受ける人、意思決定の流れ、データ、モデル、市場、人による監督（Human Oversight）を記録します。そのうえで法務部門に分類してもらいます。技術の名前だけでリスクを判断するのは避けてください。同じシステムでも、マーケティングに使う場合と社員の選考に使う場合では、リスクがまったく違うことがあります。

4. どのリスク区分になっても用意しておくべき証拠

承認された目的と制約
データソース、利用の権利、品質、保存期間
モデルとバージョン、ベンダー、変更履歴
グループ別、高リスクケース別の評価
人による監督と、停止・修正の権限
ログ、インシデント、苦情、是正措置
利用者への説明と、必要に応じたAI生成コンテンツの開示

開発チーム向け · 技術的な詳細

Documentation as Codeの考え方で、証拠をリリースごとにひもづけます。年に1回、あとから文書をまとめて書くやり方はやめましょう。モデル、ナレッジ、意図された用途（Intended Use）を変えるたびに、影響を評価し、意思決定の記録（Decision Record）を残します。

5. ベンダー契約では、稼働率のSLAに加えて証拠の提出も求める

開発チーム向け · 技術的な詳細

学習とデータの扱い（Training/Data Policy）、セキュリティ、モデルの変更、評価、再委託先（Subprocessor）、データの保管場所、インシデントの通知、契約終了時の扱いとデータ削除（Exit/Deletion）について確認します。自社が義務を果たすのに必要な文書を受け取る権利も、契約で確保しておきます。ベンダーが情報を出さなければ、自社製品のコンプライアンスを証明できなくなるおそれがあります。

開発チーム向け · 技術的な詳細

影響の大きさに応じてサプライヤーを区分します（Supplier Tier）。社内の下書きに使うモデルと、高リスク製品に組み込むモデルでは、必要なデューデリジェンスの深さが違います。ベンダーが条件を変えたり、要件を満たせなくなったりしたときに備えて、モデルの切り替え計画（Model Replacement Plan）も用意します。

6. 透明性は、UXと業務プロセスの中に組み込む

利用者がAIとやり取りしているときは、状況に応じてそのことを伝え、AIが対応する範囲と、人に連絡する方法を説明します。影響の大きい判断では、使ったデータを示し、関係する場合は異議を申し立てる権利や見直しを求める権利も示します。免責事項を長い利用規約の中に隠してはいけません。

生成したコンテンツには出どころの情報（Provenance）を付け、リスクに応じて承認を通します。下流のチャネルに渡っても消えないラベルやメタデータを付け、社員がAIに頼りすぎないよう研修を行い、顧客に率直に説明するためのトーク台本も用意します。

コンプライアンスは販売の武器になる企業顧客が買っているのは安心です。どのエージェントがどのデータを使い、誰が責任を負い、インシデントが起きたらどうするかを答えられれば、セキュリティや法務の審査にかかる時間が短くなります。デモしか用意できない競合との差もつきます。

7. ボトルネックにならないコンプライアンス体制をつくる

開発チーム向け · 技術的な詳細

リスク区分に応じたワークフロー（Risk-tier Workflow）を使います。低リスクは自己評価、中リスクはデータ・セキュリティ担当によるレビュー、高リスクは部門横断の評価です。テンプレート、承認済みのパターン、サンドボックスを用意して、チームがガードレールの内側で速く動けるようにします。法務には、本番公開の直前ではなく設計の段階から関わってもらいます。

開発チーム向け · 技術的な詳細

AIガバナンス委員会は適度な規模で設け、方針と例外の扱いに集中させます。プロンプトを1つずつ承認する場にはしません。AI台帳（AI Register）には責任者と見直し日を記録し、インシデントと証跡のダッシュボードも用意します。実際の運用は抜き取りで確認します。

8. 法律の細部がすべて固まるのを待たずに、今日からできること

すべてのAIシステムと、関係する市場を台帳に登録します。
責任者、意図された用途、暫定のリスク区分を決めます。
データとモデルのリネージ（来歴）と、バージョンの記録をつくります。
人による監督、インシデント対応、苦情対応の方法を決めます。
調達契約やベンダー契約に、AIに関する条項を加えます。
重要なユースケースと市場展開のロードマップを、法務部門に確認してもらいます。

まとめ：海外に販売するタイ企業は、顧客や規則に迫られる前に、証拠とガバナンスを整えておくべきです。AIの棚卸し、リスク分類、来歴の記録、評価、人による監督は、法律がどう変わっても役に立つ土台になります。目指すのは、チェックリストを通すための書類をそろえることより、説明でき、管理でき、誤りを直せるシステムをつくることです。

公式の参考資料European Commission: EU AI Act implementation timeline
European Commission: Navigating the AI Act

DNA MAKER · SOLUTION BLUEPRINT

顧客にも監査人にも初日から答えられる、業務の記録をつくる

法的な要件の解釈は、法律顧問と社内のコンプライアンスチームの仕事で、ソフトウェア会社が代わりに担うものではありません。DNA Makerにできるのは、チームがすでにまとめた要件を、システムが自動で行う処理に変えることです。たとえば、判断にどのデータを使ったかの記録、その時点で使っていたモデルとルールのバージョンの保存、同意の取得と記録、自動化されたシステムと話していることを利用者に示す表示などです。こうした記録は、あとから誰かが集めて回る追加の作業にせず、ふだんの業務から自然に生まれるようにしておくべきです。

システムに自動で残してほしい記録

私たちが設計するシステムには、たいてい中核のロジックから切り離した記録用のレイヤーがあります。モデルやプロバイダーを替えても、証拠が途切れないようにするためです。コンプライアンスチームが開発チームを待たずに自分でレポートを出せるダッシュボードと、何かを変えるたびに実行し直して品質が落ちていないことを示せるテストセットも用意します。海外の顧客からAIの利用に関する質問票が届き始めていて、答えるたびに複数のチームに聞いて回っているなら、そこはシステムで本当に楽になる部分です。

SOFTWARE ENGINEERING GLOSSARY

ソフトウェア開発用語集

ここに挙げる用語は、証拠やさかのぼっての確認について開発チームと話すときに役立ちます。

用語	意味	わかりやすい例	開発チームへの質問
Traceability	ある結果が、どのデータとルールから導かれたのかをさかのぼって確認できること	この申請を却下したときに、どのバージョンの基準を使ったかを確認できる	どこまでさかのぼって確認できますか？記録はどれくらいの期間保存していますか？
Versioning	モデル、ルール、文書のバージョンを残し、ある時点で何を使っていたかがわかるようにすること	先月はルールのバージョン3を使っていた、とシステムに記録が残っている	3か月前の結果を説明しなければならなくなったら、十分な情報がありますか？
Consent	データを集めたり使ったりする前に、利用者の同意を求め、それを記録すること	顧客が会話の保存にいつ同意したかを記録する	同意を得たことを、あとからどう証明できますか？
PII	個人を特定できる情報。特に慎重な扱いが必要	顧客の氏名、電話番号、書類の番号	個人データは、社外のどのシステムに送られていますか？
Model Card	モデルの用途、制約、評価の方法をまとめた文書	利用できる範囲と、使うべきでないケースをまとめたもの	いま使っているシステムについて、こうした文書はありますか？