2026年8月2日以降、カスタマーサポートにおけるEU AI法は、ほとんどのチームが午後のうちに満たせる一つのルールに集約されます。顧客が自社のAIと直接話すなら、会話の最初にAIであることを伝えること。利用規約に書くだけでは不十分で、あいまいな「アシスタント」という名前でも不十分です。違反すると最大1,500万ユーロまたは全世界売上高の3%の制裁金が科される可能性があります。
多くのガイドが見落としているのは、対象外となるものです。担当者が確認して送信するAIの下書き、チケットのタグ付け、ルーティング、要約にはAIラベルは不要です。顧客がAIと直接やり取りしないからです。チャットボット以上に注意が必要なものが二つあります。音声から感情を読み取ること（自社エージェントの監視目的では2025年2月から禁止）と、エージェントの成績を採点したり融資・保険の結果を決めたりするAIで、こちらは2027年12月2日に高リスクとなります。
私はeesel自身のサポートキューを担当していますが、eeselを使うEUのチームの多くは、法律にきれいに対応する形でAIを分けて使っています。smavaでは、eeselが月に約15,300件のドイツ語返信を下書きし、アドバイザーが承認します。一方、フェリー会社のNorden-Frisiaは、顧客向けのCaptAInというボットを運用しています。開示が必要なのは後者だけです。このガイドは法的助言ではありませんが、どのAIツールから確認すべきかははっきり分かるはずです。
EU AI法はサポートチームに何を求めているのか？
AI法は責任を二つの役割に分けています。提供者は、AIシステムを作って自社名で市場に出す者で、AIエージェントを提供するヘルプデスクベンダーがこれに当たります。導入者は、自らの権限でAIシステムを使う者で、そのエージェントを顧客向けに有効にしたときの自社がこれに当たります。ほとんどのサポートチームは導入者ですが、社内でボットを自作したり、他社のボットを再学習してブランドを付け替えたりすると、提供者になることがあります。
サポートチームにとって重要なのは法律の四つの部分です。それ以外（汎用モデルの規則、製品安全、法執行）は他の人の問題です。
| ルール | サポートにとっての意味 | 適用開始 | 最大制裁金 |
|---|---|---|---|
| 第50条 透明性 | AIと話していることを伝える。感情認識を使う場合はその旨を伝える | 2026年8月2日 | 1,500万ユーロまたは売上高の3% |
| 第5条 禁止事項 | 従業員の感情を推測するAIは禁止。つまり、自社エージェントの音声感情スコアリングは不可 | 2025年2月2日 | 3,500万ユーロまたは売上高の7% |
| 第4条 AIリテラシー | AIを使う従業員がそれを理解できるよう措置を講じる | 2025年2月2日 | 各国が設定 |
| 附属書III 高リスク用途 | AIがエージェントや融資・保険リスクを採点する場合の追加義務 | 2027年12月2日 | 1,500万ユーロまたは売上高の3% |
制裁金の上限は第99条に基づいており、同条は各国に、中小企業の利益を考慮し、中小企業には低い方の上限を適用するよう求めています。執行を担うのは各国の市場監視当局で、欧州委員会は8月2日の解説で、当局がすでにこれらの制裁金を科せると述べています。
デジタル・オムニバスですべて延期されたのでは？
一部だけで、多くのチームが誤解したのはまさにそこです。Digital Omnibus on AI（規則2026/1744、2026年7月8日採択）は高リスク規則を先送りしましたが、チャットボットの開示日はそのままにしました。改正後の第113条によると、日程は次のとおりです。
動いた透明性の期限は技術的なものだけです。2026年8月2日より前にすでに市場にあるAIシステムは、欧州委員会の第50条FAQによれば、生成するコンテンツに機械可読のマーカーを加えるまで2026年12月2日までの猶予があります。これはベンダーのエンジニアの仕事です。「AIと話しています」という通知は8月から有効です。
どのサポートAIに「AIです」の通知が必要か？
ここが最も手間を省ける部分です。2026年7月20日に公表された欧州委員会の第50条ガイドラインは、開示ルールが適用される前にすべて満たすべき四つの条件を挙げています。AIシステムであること、やり取りを目的としていること、やり取りが直接的であること、相手が人であることです。重要なのは直接という言葉です。
ガイドラインは、カスタマーサービスが線の両側で典型的な例であることを明記しています。顧客に答えるヘルプデスクのチャットボットは対象です。担当者が返信作成の補助にAIを使う場合は対象外です。
"Direct interaction excludes indirect or mediated human interaction where a natural person is exposed to AI outputs without directly interacting with the system (for example, if customer service representatives use AI assistance tools to help them communicate with natural persons...)"
ツールを二つの山に分ければ、不安の大半は消えます。
右の山に入れる前に知っておきたい、ガイドラインの三つのポイントがあります。
- 「人が介入できる」は抜け穴ではありません。 ガイドラインは、人が出力を確認する可能性があるというだけでは、ルールを回避できないとしています。下書きが対象外になるのは、人が実際に確認し、会話の主たる発信者として送信する場合だけです。
- 混在する会話ではAI部分にラベルが必要です。 チャットがボットから人にエスカレーションされる場合や、人がボットに戻す場合、AIが生成したターンには開示が必要です。
- 自動送信メールも対象です。 やり取りは「via technical communication means including online interfaces, phone or e-mail」で行われうるとされ、ガイドライン自身の良い開示例は、冒頭にAIラベルを付けたAI作成のメールです。ルールベースの自動返信や従来型の不在通知はAIシステムではないため、対象外です。
訓練を受けた従業員向けの社内ボットも対象外です。ガイドラインは「internal employee-facing assistant for properly trained staff」（人事、法務、ITサポート）を、AIであることが十分に明らかなためラベルが不要なケースとして挙げています。
eeselの顧客はどこに当てはまるか
毎週目にする分け方がこれです。デンマークの法務書類サービスDokument 24では、eeselが月に約670件のデンマーク語の返信案をZendeskの内部メモとして用意し、チームの誰かが編集して一件ずつ送信しています。これは媒介されたやり取りです。北欧4か国でeバイクや移動用スクーターを販売するNordbutikerは、ストアのウェブサイトで、ブランドと言語ごとに別々の顧客向けボットを運用しています。これらのボットは顧客と直接話すため、それぞれが自分の言語で独自の通知を必要とします。
よい開示とは何か？
第50条(5)は、情報が「clear and distinguishable」で、「at the latest at the time of the first interaction」に提供され、アクセスしやすいことだけを求めています。細部はガイドラインが補っており、驚くほど実用的です。ほとんどの場合、最初のやり取りの前に目立つ通知を一つ出せば足ります。
| 有効なもの | それだけでは不十分なもの |
|---|---|
| 最初のターンでAIだと伝える挨拶（「〜のAIアシスタントです」） | 利用規約やプライバシーポリシーの一文 |
| メッセージ入力欄の近くにあるわかりやすい表示（「AIシステムとチャットしています」） | 「アシスタント」や「サポート」のような一般的な名前 |
| ボットの返信の横に常時表示されるAIバッジやアイコン | ボットのアバターに人の写真や人間らしい名前を使うこと |
| AIが書いたメールの冒頭のAIラベル | サイト全体に出す「このサイトのサービスはAIを使用しています」 |
| 通話の冒頭の音声案内（「こちらはAIアシスタントです」） | 「LLM搭載」などの技術用語 |
| 顧客が「これはボットですか？」と聞いたときに正直に答えること | 顧客に見えない隠しメタデータや透かし |
ガイドラインは、「より危険な状況」では複数回の通知を求めており、その例のうち二つはまさにサポート業務です。苦情対応と、金融助言、保険、法律、健康に関する会話です。これらでは、特に会話の担当が替わるときやAIの役割が変わるときに、定期的なリマインダーを求めています。一般向けのものは、障害のある人、高齢の顧客、子どもにも機能しなければならないため、灰色の9pxの注意書きでは足りません。
開発者のスレッドでは、文脈だけで足りるという読みもよく見られます。
"The main point is that it is trying to prevent deception, e.g. in a "live support chat" where a website claims you're talking to a human when in fact you're not... if it's clear from the context, that you're interacting with AI, it doesn't need to be explicitly said. No cookie banners."
前半は正しいです。サポートチームがつまずくのは後半です。自明性の例外は、顧客向けボットを救ってくれません。ガイドラインはこれを「restrictively」読むべきだとし、顧客が「may perceive as human-generated」と受け取りうる返信をするヘルプデスクのチャットボットを、ルールが適用される例として挙げています。
適合して見える基本的な設定は次のようになります。eeselのチャットバブルでは、各返信の横にエージェント名が表示され、メッセージ入力欄の下に別の注意書きの行があります。
このスクリーンショットの落とし穴に注意してください。「Shop Assistant」という名前は、ガイドラインが曖昧とみなす一般的なラベルそのものです。法的な役割を果たしているのは、入力欄の下の注意書きです。両方でメッセージを伝えたいなら、ウェルカムメッセージにもAIと入れてください。eeselはエージェント名を空にすると、返信に「AI Agent」と署名します。
罰金以外にも、これを行うビジネス上の理由があります。人間を装うボットに気づいた顧客は、ボットだけでなく会社そのものを信用しなくなります。
"I think a voice agent trying to appear as a human is actually hurting the business that’s deploying it. I can tell within 5 seconds that it’s not a real human and then my sentiment is they’re 1. being cheap and 2. trying to play me."
ちなみに、名前付きのペルソナは問題ありません。Norden-FrisiaのボットはCaptAIn（「Captain」と「AI」）といい、専用のアバターと地元の方言の挨拶があります。名前にAIが入ったペルソナは良いスタートです。挨拶に「AIアシスタントです」という平易な一文を添えれば、言葉遊びに気づかない乗客の疑いも消えます。失敗パターンは、ラベルなしで人間の名前を付けることで、2025年にあるコーディングツールのサポートボットがHacker Newsで集中砲火を浴びたのがこれです。
"LLMs pretending to be people (you named it Sam!) and not labeled as such is clearly intended to be deceptive."
このサポートAIには開示が必要？
構成を選ぶと、どのEU AI法のルールがいつから適用され、何を変えるべきかがわかります。
最初のメッセージにAIである旨を入れ、メッセージ入力欄の近くに見えるAIラベルを、ボットが話すすべての言語で表示してください。ボットかどうか聞かれたら正直に答えるようにします。
人の確認なしにAIが送信するすべてのメールの冒頭にAIラベルを入れてください。ルールベースの自動返信や不在通知はAIシステムではないため、不要です。
人が実際に下書きを確認し、主たる発信者として送信する限り、開示ルールの対象外です。形だけで実態のない確認ステップは認められません。
通話の冒頭で「こちらはAIアシスタントです」のように声で伝えてください。転送や長い保留のあとにも繰り返し、ビープ音やトーン音だけに頼らないでください。
テキストは生体データではないため、言葉づかいから怒っている顧客のチケットを見つけることは、AI法上の感情認識に当たりません。ただし個人データの処理ではあるため、GDPRの記録に含めるべきです。
医療または安全上の理由を除き、従業員の感情を推測することは禁止されています。音声から、どれだけストレスを感じているか、愛想がよいかでエージェントを評価するツールはオフにしてください。
従業員の成績を監視・評価するAIは高リスクの一覧に入っています。スコアが昇進や解雇の判断に使われるなら、今のうちにベンダーの分類を書面で求めてください。
信用力の評価や生命保険・医療保険の価格設定は高リスクです。申込フォームを説明するだけのボットはこれに当たりませんが、顧客に資格があるかどうかを伝えるボットは当たります。
感情分析は感情認識に当たるのか？
通常は当たりません。そして、これはサポートチームの間で最も誤解されている部分です。同法は感情認識システムを、「on the basis of their biometric data」で感情や意図を推測するAIと定義しています。テキストは生体データではありません。したがって、ヘルプデスクがチケット本文に対して実行し、怒っている顧客を見つける感情分析は、AI法上の感情認識ではありませんが、GDPR上は個人データの処理に当たります。
音声は別です。声は生体データだからです。ここからルールが厳しくなります。
- 声から自社エージェントの感情をスコア化することは禁止されています。 第5条(1)(f)は、医療または安全上の理由を除き、「in the areas of workplace and education institutions」で人の感情を推測するAIを禁じています。エージェントのストレスや愛想のよさを評価するコールセンターツールはこれに該当し、禁止は
2025年2月2日から適用されており、同法で最も高い制裁金の区分です。 - 声から通話者の感情を検出することは許可されていますが、重い扱いです。 2026年8月から、第50条(3)に基づき、稼働していることを通話者に伝える必要があります。またガイドラインは、感情認識システムはすべて高リスクでもあると確認しているため、高リスクの全義務が
2027年12月2日から適用されます。
「感情AI」や「トーンコーチング」を備えたコールセンターソフトウェアを購入する場合は、ベンダーに一つ質問してください。声の音声を分析するのか、文字起こしの言葉を分析するのか。その答えで、どちらに該当するかが決まります。
サポートAIはいつ高リスクになるのか？
まれですが、境界ケースは多くのガイドが認めるよりサポート業務に近いところにあります。附属書IIIの高リスク一覧が問うのは、AIが何を決めるかであり、どの業界かではありません。サポート業務に触れる項目が三つあります。
- 従業員を監視・評価するAI。 第4項(b)は、雇用関係において「to monitor and evaluate the performance and behaviour of persons」ためのAI、または個人の特性に基づいて業務を割り当てるAIを対象とします。すべてのエージェントの会話を採点し、昇進や解雇の判断に使われるAI QAツールは、この線に近い位置にあります。
- 融資と保険の判断。 第5項(b)と(c)は、信用力と生命・医療保険の価格設定を対象とします。フォームを説明するのではなく、顧客がローンの資格があるかどうかを伝えるサポートボットは、高リスクの仕事をしています。
- 公的給付と緊急通報のトリアージ。 第5項(a)と(d)は、公的支援の受給資格の判断と、緊急通報のトリアージを対象とします。
第6条(3)は、「narrow procedural task」または「preparatory task」だけを行い、結果に実質的な影響を与えないAIに逃げ道を用意しています。ただし、人のプロファイリングを行うものにはこの逃げ道を閉じています。自然人をプロファイリングする附属書IIIのシステムは、常に高リスクです。
ここで参考になるのがsmavaです。ベルリンのローン比較プラットフォームで、サポートとしてはこれ以上ないほど規制の厳しい業界ですが、3つのeeselエージェントはチケットを分類し、承認済みマクロの文言どおりに返信を下書きし、自分では一切送信しません。誰の信用力も評価しないため、業界だけでサポートAIが高リスクになるわけではありません。
2027年12月から高リスクシステムの導入者になる場合、第26条は、指名された人による監督、システムのログを少なくとも6か月保管すること、従業員に使う前に従業員代表へ通知すること、AIが顧客に関する判断を支援する場合に顧客へ通知することを求めます。チャットボットのラベルより負担が重いため、QAやルーティングのツールが第4項(b)の近くにあるなら、今からベンダーとの話し合いを始めてください。
責任を負うのは自社かヘルプデスクのベンダーか？
両方で、それぞれ異なる形です。第50条(1)は開示義務を提供者に課しており、提供者は人々に伝わるようにシステムを設計しなければなりません。ベンダーのAIエージェントを有効にするなら、ベンダーには開示できるシステムを提供する義務があります。しかし、挨拶文を書き、ボットの名前とアバターを選び、どのチャネルで動かすかを決めるのは自社なので、実際には、設定の不備は自社が直すことになります。
自社が提供者になることもあります。ガイドラインは、社内でチャットボットを作って自社名で運用する企業は提供者であり、他の提供者のシステムを取り込み、変更し（たとえば新しい学習データで）、自社名で稼働させる企業も提供者だとしています。モデルAPIの上に自社のサポートボットを作った場合、開示は完全に自社の仕事です。
ベンダーの契約も通常は同じことを述べています。ZendeskのAI Services Addendumは、顧客が「will ensure any requirements of notice, transparency, and choice are met」と述べ、SalesforceのAI Acceptable Use Policyは、顧客が「must disclose to end users when they are interacting directly with automated systems」と述べています。そのため、各ヘルプデスクが標準で何を提供するかを知っておく価値があります。各ベンダー自身のドキュメントで確認できたことは次のとおりです。
| ヘルプデスクのAIエージェント | ボット名の変更 | チャットのAIラベル | メールのAIラベル | 独自のEU AI法に関する声明 |
|---|---|---|---|---|
| Zendesk AI agents | 可 | 可、デフォルトで有効（「Zara · AI」） | 標準では未対応 | あり |
| Freshdesk Freddy AI Agent | 可、アバター付き | 記載なし。導入メッセージを使用 | 標準では未対応 | 記載なし |
| Gorgias AI Agent | 可 | 可、AIメッセージの下に「Automated」 | AI署名はオプトイン | 記載なし |
| HubSpot Customer Agent | 可、アバター付き | 可、ヘッダーに「Powered by AI」 | チーム署名のみ | 記載なし |
| Salesforce Agentforce | 可 | 記載なし。ウェルカムメッセージを使用 | 記載なし | あり |
| Help Scout Scout | 記載なし | 可、「clearly labeled as AI」 | 記載なし | 記載なし |
| Front AI agents | 可、アバター付き | Resolveウィジェットでコンプライアンス用の注意書きを任意で設定可 | 記載なし | 記載なし |
| Kustomer Concierge | 記載なし | 記載なし。挨拶文を使用 | 記載なし | 記載なし |
Zendeskの標準設定が最も充実しています。2026年3月から、WebウィジェットはメッセージのグループごとにボットのAIタグを一度表示し、ソーシャルチャネルやモバイルアプリではラベルが表示名の一部になります。無効にできるのはAPI経由でチャネル単位のみで、無効にした場合は自社が事業を行う地域のAIルールの順守に責任を負うとZendeskは警告しています。
Freshdeskは名前の付け方で逆のアプローチをとっています。名前付きのエージェントのほうがエンゲージメントが高いため、「Bot」や「AI」のような一般的な名前は避けるよう、ドキュメントで勧めています。製品判断としては妥当ですが、そのぶん開示は導入メッセージに入れる必要があります。これは編集でき、自動翻訳もできます。ドキュメントのデフォルトの文面は「Hello. How can I help you?」なので、自社の設定を確認してください。
表から見えるパターンはこれです。メールは、ほとんどのヘルプデスクが開示を自社任せにしている部分です。Gorgiasはメール用のAI署名をドキュメント化している唯一のベンダーで、それもオプトインです。AIエージェントが自動でメール返信を送るなら、署名かメッセージの冒頭にAIの一行を自分で追加してください。
AIリテラシー規則は、エージェントの研修が必要という意味か？
軽くです。第4条は2025年2月から適用されており、オムニバスで緩和されました。導入者は、AIを使う従業員について、その知識と状況を考慮して「take measures to support the development of AI literacy」する必要があり、条文は現在、これが「does not require providers or deployers to guarantee any specific level of AI literacy of any individual」と述べています。欧州委員会は、中小企業向けの実践例も公表することになっています。
サポートチームにとって妥当な最低ラインは短いものです。どのツールがAIを使っているか、何ができて何ができないか、送信前に下書きをどう確認するか、いつエスカレーションするか、顧客にボットかと聞かれたら何と答えるか。一度書き出して、エージェントのオンボーディングに加えてください。
サポートチーム向け：EU AI法の30日チェックリスト
最もリスクの高いものから低いものへ、私ならこの順で進めます。
- 顧客に触れるAIツールをすべて洗い出す。 ウェブチャット、AI音声エージェント、自動送信のメール返信、SNSやWhatsAppのボット、エージェントが下書きに使うものすべて。
- それぞれを直接か媒介かに分類する。 直接とは、AIの出力が人の確認と送信を経ずに顧客に届くことです。
- まず直接のものを直す。 対応する言語ごとに、最初のターンでのAI表明、見えるラベル、「ボットですか？」への正直な回答を追加します。音声の挨拶と自動送信メールの冒頭も確認します。
- 音声感情機能を探す。 エージェント向けの音声感情スコアリングはすべてオフにします。通話者の感情検出を残すなら、通知を追加し、2027年の高リスク義務に備えます。
- エージェントを採点するもの、資格を判断するものにフラグを立てる。 人事判断に使われるQAスコアリング、融資・保険・給付に関する回答は、ベンダーの高リスク分類を書面で入手します。
- ベンダーに第50条への立場を尋ねる。 チャネルごとの開示の仕組みと、機械可読マーキングがいつ入るかを確認します。
- AIリテラシーの1ページメモを書き、 チームに共有します。
AIベンダーに対してすでにセキュリティレビューやGDPR確認を行っているなら、新しいプロセスを始めるのではなく、それに上乗せしてください。質問は違いより重なりのほうが多く、AI法は明示的にGDPRの上に乗るもので、置き換えるものではありません。
eeselはEU AI法にどう対応するか
eeselは、ヘルプデスク向けのAIチームメイトです。既存のZendesk、Freshdesk、Gorgias、Help Scoutのキューに参加し、過去のチケット、マクロ、ヘルプセンターから学び、指定したチケットを処理します。AI法に関わる部分は次のとおりです。
- アクションごとに直接か媒介かを選べます。 すべてのアクションは、自動で実行、人の承認待ち、オフのいずれかで、エージェントごとにActions and Approvalsで設定します。公開返信を承認制にしておけば、信頼を築く間、AIを媒介の側に置けます。
- チャットバブルにはAI注意書きのフィールドがあります。 注意書きはすべての会話でメッセージ入力欄の下に表示され、エージェント名はデフォルトで「AI Agent」です。
- ルールは平易な言葉の指示に書けます。 「聞かれたら、顧客の言語で必ずAIアシスタントだと伝える」は、エージェントの指示に書く一行であり、エンジニアリングへのチケットではありません。
これはコンプライアンス製品ではなく、そう装うつもりもありません。eeselは自社のAIシステムを分類したり、AIリテラシーのポリシーを書いたりはしません。また、eeselのSOC 2 Type II監査はまだ進行中（観察期間は2026年12月31日まで）であり、EU内での完全なデータレジデンシーはEnterpriseプランの機能であることも、eeselのセキュリティページにあるとおりです。eeselはお客様のデータでモデルを学習しません。
EUのサポートキューでeeselを試す
ドイツ語、デンマーク語、スウェーデン語で顧客に対応していて、AIであることを正直に伝えるAIが欲しいなら、eeselはまさにその構成のために作られています。smavaは月に27,000件のZendeskチケットで、すべての返信をアドバイザーの承認待ちにして運用しており、Norden-FrisiaはウェブサイトとパブリックチャットリンクとZendeskでCaptAInを運用しています。承認制の下書きから始め、準備ができたら明確なAI挨拶つきの名前付きボットを追加し、eeselを7日間無料で試してください。
