規制業界のサポートでAIが機能するのは、チャネルではなく、回答に何が必要かでチケットを仕分けるときです。手続き系の質問（明細書、ログイン、どのフォームを送るか）は、承認済みのヘルプコンテンツからAIが回答できます。アカウント固有の質問は、AIが下書きを作り、人が確認して送信します。紛争、苦情、臨床に関する質問、与信判断は最初から人に回し、そこでのAIの仕事はそれらを素早く見分けることだけです。
多くのチームが見落とす落とし穴があります。ヘルプデスクのBAAは、そのAIを自動的に対象に含むわけではありません。ZendeskはAI機能を対象範囲として明記し、Salesforceは患者データを名前の挙がったAIサービスに限定し、FreshworksはEnterpriseでBAAを名前の挙がった製品に限定していてFreddy AIには触れていません。確認すべきはヘルプデスクではなく、AI機能そのものです。
これがコンプライアンス審査を通る証拠は、すでに本番で動いています。ドイツのローン比較プラットフォームsmavaは、月に約27,000件のZendeskチケットでeeselを稼働させています。eeselがすべてのチケットを仕分けて承認済みマクロから下書きし、送信は人が行います。医療、金融、保険の方は、eeselがお使いのヘルプデスク上で下書きモードから始まり、EnterpriseでBAAに署名します。
規制業界のサポートでAIを使えますか？
はい。コンプライアンス部門が本当に尋ねているのは、もっと絞り込んだ問いです。どのチケットで、どの段階で、どのデータを使い、お客様が読む前に誰が承認するのか、ということです。
私はeeselのAIエージェントを作っていて、この会話を反対側の立場で何度も経験してきました。2026年3月、Zendeskを使う米国の医療機関のサポートチームが、たった一つの質問でeeselのデモを止めました。eeselはBusiness Associate Agreementに署名するのか、という質問です。これは軽い懸念ではなく、完全なストップであり、そう扱うのは正しい判断でした。同じ月に話した医療ローンのチームが求めていたのは別のものでした。AIが自力で返信するのは、本当に対応できるチケットだけだという保証です。規制対象の2つの買い手に、2つの異なる障害があり、どちらも「AIは危険すぎる」ではありませんでした。
これがパターンです。コンプライアンスチームがAIを全面的に止めることはまれです。止めるのは、誰も承認していない生成された文面、契約のないままベンダーに渡るデータ、そして個人に関する判断のように見える回答です。この3点を踏まえて設計すれば、反対の大半は消えます。
このガイドの残りは、その会議に臨むサポートリーダーに私が渡す内容そのものです。業界別のプレイブックが必要なら、医療サポート向けAIについても書いています。フィンテックのチームはフィンテックのサポートから、保険会社は保険のサポートのガイドから始められます。
規制対象のサポートで、AIはどのチケットを扱えますか？
まず、正しい回答に何が必要かでキューを仕分けます。リスクを決めるのはチャネルよりもこちらだからです。
私が見てきた規制対象のキューには、必ず3種類のチケットがあります。
- 手続き系。 答えはどのお客様にも同じで、ヘルプセンターに載っています。「明細書はどうやってダウンロードしますか？」「保険金請求にはどのフォームを送りますか？」。返信に本人の情報が要らないので、AIが回答できます。
- アカウント固有。 答えが1人のお客様のレコード、つまり支払い、申請、請求の状況、請求書に左右されます。AIはレコードを読んで下書きできますが、返信が出る前に人が本人確認とアカウントを確認すべきです。ここでヒューマン・イン・ザ・ループが効いてきます。
- 判断または規制対象の決定。 症状や薬、与信の否決、保険金の支払い拒否、紛争、苦情。これらは最初の1秒から人のものです。AIの仕事は回答ではなく、タグ付けとルーティングです。
実際のリスクがあるのは3つ目のレーンで、しかも多くの人が想像するリスクとは違います。CFPBの2023年の消費者金融におけるチャットボットの報告書は、ボットが失礼なことを言う心配より、ボットが紛争に気づけない問題を重く見ており、"only specific words or syntax may trigger the recognition of a dispute." と警告しました。「この請求に異議を申し立てたい」ではなく「これは買っていません」と書いたお客様も、紛争を抱えていることに変わりはありません。
"And even then the risk of AI misclassifying it as a routine question and not an urgent payments related question."
つまり最初にテストすべきなのは、AIの文章のうまさではありません。触れてはいけないチケットをどれだけ確実に見分けられるかです。ルーティング側を作るなら、AIによるチケットのトリアージのメモがさらに詳しく、支払い紛争のためのAIのガイドも参考になります。
業界ごとによくあるチケットタイプを、私ならどのモードで始めるかを示します。ご自身の業界を選んでください。
あなたの業界で、AIはどのチケットに触れてよいか
業界を選ぶと、よくあるチケットタイプと、私ならどのモードで始めるか、その理由が表示されます。
これらのモードは固定ではありません。自社の過去チケットでのテストで、AIが正しく処理できると確認できたら、チケットタイプは「下書き」から「回答」に移ります。そして、そのテストこそ、コンプライアンス部門に見せるものです。
カスタマーサポートでのAIについて、規則は実際に何と言っていますか？
心配するほどではなく、ベンダーのページが認めるより具体的です。以下の規制当局のどれも、サポートでのAIを禁止してはいません。どれも、機械が作業をしても既存の義務は変わらないと言っています。
| 規則 | 適用対象 | チケット上のAIにとっての意味 |
|---|---|---|
| HIPAAのビジネスアソシエイト | 米国の医療提供者、保険プラン、およびそのベンダー | 患者データを読むAIベンダーは、事前に署名済みのBAAが必要 |
| HIPAAの最小限の必要性 | 同上 | AIは返信に必要なものだけを読み、記録全体は読まない |
| CFPBのチャットボット報告書 | 米国の消費者金融 | チャットボットは "must comply with all applicable federal consumer financial laws"。紛争対応も含む |
| FTCセーフガード規則 | 米国の非銀行系金融会社 | AIベンダーとの契約でセキュリティ要件を定め、監視を可能にする必要がある |
| PCI DSSのメッセージングFAQ | カード決済を受け付けるすべての事業者 | チャットやメールにカード番号があると、そのチャネルがPCIの対象範囲になる |
| EU AI法 第50条 | EUの人々と対話するAI | AIと話していることをお客様に伝える必要があり、2026年8月2日から適用 |
| GDPR 第22条 | EUの人々にサービスを提供するすべての事業者 | 与信の拒否のような、法的効果を持つ完全自動の判断は不可 |
| FCAのAIグッドプラクティス | 英国の金融会社 | 企業は "remain responsible for consumer outcomes"。サポートも含む |
このうち3つは、署名する内容だけでなく、AIの設定方法まで変えます。
暗号化してもBAAは免除されません。 HHSはクラウドコンピューティングのガイダンスではっきり述べています。"Lacking an encryption key does not exempt a CSP from business associate status." AIが患者データに少しでも触れるなら、暗号化されているかどうかにかかわらず、契約が必要です。医療面はHIPAA準拠のAIでさらに詳しく扱っています。
FCAは、うまくいくパターンを書き出しました。 2026年の金融サービスにおけるAIのレビューは、良い実務として、"limited chatbots and generative AI assistants to approved source material, with checks and escalation routes." としている企業を挙げています。上で示したレーンのモデルを、規制当局の言葉で述べたものです。
開示はEUでは法律になりました。 2026年8月2日以降、EUでAIと話すお客様には、明らかな場合を除き、その旨を伝える必要があります。私が書いたEU AI法のガイドで、チャットウィジェットとメール返信にとっての意味を解説しています。
正直な注意点が1つあります。この表はコンプライアンスチームにとっての出発点であり、法的助言ではありません。お使いの分野には独自の規則（州の保険規制当局、銀行監督機関、各国の医療データ法）が加わることがあり、どれが適用されるかは法務チームがご存じです。
ヘルプデスクのBAAは、そのAI機能も対象にしていますか？
自動的には対象になりません。何かに署名する前に確認すべき最も有用な点であり、多くのチームがつまずくところです。ベンダーはBAAを名前の挙がった製品を軸に書き、AI機能はその一覧に1つずつ、しばしばリリースの数か月後に追加されます。
| ヘルプデスク | BAAの取得方法 | AIは対象範囲に明記されているか | 確認すべき点 |
|---|---|---|---|
| Zendesk | Advanced Compliance、Suite Professional以上 | はい：Copilot、AI Agents、Answer Botの解決が記載されている | アーリーアクセス機能は "should not be used with PHI" |
| Salesforce | サービスごとの制限付きBAA | はい：Agentforceと、Einsteinの他の13の名前付きサービス | エージェントではTrust Layerのマスキングがオフ |
| Freshdesk | Enterpriseプランのみ | BAAはFreshdesk、Freshchat、Freshcaller、Omnichannelを列挙。Freddy AIへの言及なし | Freddy AIについて書面で確認する |
| HubSpot | EnterpriseとSensitive Data設定 | Breezeは制限付きで利用可。BAAで名前を挙げているページはない | チャットボットはSensitive Dataに非対応 |
| Zoho Desk | メールでBAAのテンプレートを依頼 | PHIフィールドはZiaに渡らない | チケット本文に入力したPHIは "will NOT be masked" |
| Gorgias | ページに記載なし | AI Agentのドキュメントに "HIPAA compliant" とある | どのプランに署名済みBAAが含まれるか確認する |
いくつかは、もう少し詳しく見る価値があります。
Zendeskが最も明確です。対象製品のページにはAI AgentsとCopilotがHIPAAの対象として載っており、BAAはSuite Professional以上のAdvanced Complianceに付いてきます。ただし、HIPAA設定ルールには、多くのチームが読まない条件が付いています。AIは "which could be construed as (i) providing medical or healthcare advice" となるような使い方をしてはならず、チケットにならないAIエージェントの会話は "are still stored in the system and it is the responsibility of Subscriber to delete those." とされています。選択肢を比較するなら、私のZendeskのセキュリティ解説に残りがあります。
Salesforceは、Einsteinプラットフォームのセキュリティの文書で、「PHI-Permitted」のAIサービスを名前で挙げており、Agentforceも含まれます。重要な点が2つあります。医療提供者と医療保険プランが患者データを送信できるのは "where ... Salesforce has expressly permitted such submission contractually" の場合だけです。そしてTrustとAgentforceによれば、エージェントでは "Data masking through the Einstein Trust Layer is disabled to improve the performance and accuracy of agents" となっています。銀行については、同じセキュリティ文書が、銀行口座番号とカード番号はEinsteinサービスに送信してはならないと述べています。この層の仕組みはEinstein Trust Layerの解説にあります。
FreshdeskとHubSpotはどちらもEnterpriseでBAAを提供していますが、AIの扱いは自社ページでは曖昧なままです。FreshworksのガイドはBAAを名前の挙がった製品に限定していて、Freddy AIには触れていません。HubSpotはSensitive DataのアカウントでBreezeを動かせますが、顧客に "avoid sharing any sensitive information in your configured data inputs for Breeze features, including your prompts." とも伝えています。どちらも除外する理由ではありません。患者データを近づける前に、AI機能を書面で明記してもらう理由です。
"If a vendor handles PHI in any capacity you need to have a BAA and a Confidentiality agreement with them. ... A BAA is just a pinky-promise."
このコメントの2つ目の指摘が正しいところです。BAAは必要条件であって、十分条件ではありません。どう設定するかでAIが実際に何を見るかが決まり、それが自分で制御できる部分につながります。
なぜ規制対象のチームは承認済みの文面から下書きすべきなのですか？
コンプライアンスで最もよくある懸念は、データではなく言葉に関するものだからです。金融や医療のサポート返信は、約束をしたり、助言をしたり、判断を説明したりできてしまいます。AIがそれを一から書いた時点で、その文を誰も承認していないことになります。
"User asked "should I dispute this charge." Normal enough question. The bot answered like it had passed the bar. Walked through their rights, grounds for dispute, how to approach it. Clean language, no red flags, passed every content check without a hiccup."
私が関わった設定で最もうまくいった対策は単純です。AIが自分で文章を書くのではなく、承認済みの文面を選ぶことです。その文面は、何年も前にコンプライアンスが承認したマクロやヘルプセンターの記事として、すでにチームにあります。
smavaは、私が挙げられる最も明快な例です。ベルリンの消費者ローン比較プラットフォームで、Finanzcheckを買収して以来、両ブランドのサポートを1つのZendeskで運営しています。導入事例は、その重みをはっきり述べています。"This is regulated finance, so wording matters: a reply that promises something the team will do, names a competitor, or guesses at a loan the company can no longer see does harm."
smavaのeesel設定では、次のように処理しています。
- 分類エージェントがすべての新規チケットにタグを付け、アドバイザー欄を読み、アドバイザーが割り当てられていない場合にのみ、自動返信の対象としてチケットにマークを付けます。カテゴリをZendeskのフィールドに書き込むだけで、ほかには何も触りません。
- 下書きエージェントは、同期された約
820件のマクロとヘルプセンター記事を検索し、候補をそれぞれ全文読み込んで、一致するマクロをプレースホルダーを埋めて一語一句そのまま下書きにします。出力は、承認と却下のボタン付きの下書きだけです。 - ブランドごとに1つ、計2つの返信エージェントが、対象のチケットに対して、固定ルールのもとでお客様にそのまま出せる返信を準備します。チームが確認や手配をするという約束はしない、競合の比較サイトへのリンクは貼らない、締めの文は固定の4文のうち1つ、というルールです。eesel自身が送信することはありません。
2026年8月8日から9月8日までの間に、約27,000件のチケットを処理し、14,600件を分類し、15,300件の下書きを準備しました。人の確認を待つ下書きエージェントは約12,200件のチケットで動き、返信エージェントは約1,100件でした。この月の大半は、eeselが仕分けと下書きを行い、人が送信していました。すでに与信アドバイザーがいるお客様には、自動返信は一切送られません。
同じ形は金融の外でも機能します。Timengoはデンマークの企業で、そのセキュアメール製品は自治体、学校、年金基金に使われています。Freshdeskでeeselを稼働させ、ドキュメントと約5,300件の過去チケットと記事から、すべてのチケットをデンマーク語で下書きしています。サポートエンジニアが確認して送信し、eeselが顧客チケットに自力で返信することはありません。デンマークでオンラインの法律文書を販売するDokument 24では、eeselが月に約670件のデンマーク語の下書き返信を内部メモとして残し、チケットを商品別（遺言書、夫婦財産契約、会社設立）にタグ付けしています。
チームにまだ整ったマクロのライブラリがないなら、最初のプロジェクトはAIではなくそれです。回答を承認済みコンテンツに根拠づけることは、サポートでのAIハルシネーションに対する最も確実な防御でもあります。
どうすればコンプライアンスの承認を得られますか？
節約額の見込みではなく、証拠を持っていきましょう。行き詰まるチームの多くは、見込みの自動解決率だけを持ち込み、「それは具体的に何を見るのか、何をしたかをどう知るのか」という問いに答えられないチームです。
"real blocker, not imagined. the prototype-to-prod gap is almost never engineering, it's the 6 to 10 week back and forth with risk and second line. teams either ship a neutered version (read-only, internal-only) or it dies in committee."
同じコメント投稿者は、第2線が実際に求めるものを挙げていました。プロンプトとツール呼び出しのログ、個人情報のマスキングの証明、あらゆる判断の再現、許可された操作の一覧、お客様のオプトアウト経路です。短いリストで、その大半は最初の会議の前にそろえられます。
私なら次の資料一式をまとめます。
- AIを明記した署名済みの契約。 医療データにはBAA、GDPRにはDPA、そしてFTCセーフガード規則のもとではベンダーに対する "spell out your security expectations" 契約です。上の表のとおり、AI機能を名前で確認します。
- データの経路図。 1ページで、AIがどのヘルプデスクのフィールドを読むか、どのモデルプロバイダーが処理するか、どこでホストされるか、何がどれだけ保持されるかを示します。ひな形が必要なら、ベンダーのセキュリティチェックリストに質問が載っています。
- マスキング設定と、その限界。 AIがインデックスする前に何がマスクされ、何がされないか。抜け穴は具体的に示してください。コンプライアンス部門は、あいまいな約束よりも、把握済みの抜け穴をはるかに信頼します。
- 自社の過去チケットでのテスト。 チームがすでに解決したチケットでAIを動かし、比較します。トピックごとに何件のチケットが必要かも含め、信頼できるシミュレーションテストの進め方を書いています。
- 監査ログのサンプル。 1件のチケットを最初から最後まで見せます。何が届き、AIが何を読み、何を下書きし、誰が承認したか。
"Usually the narrative. Raw logs exist, approvals happen, but nobody documented WHY the decision was made in language compliance can actually audit."
この最後の引用は真剣に受け止める価値があります。AIが何をしたかのログは有用ですが、その理由まで記録するログがあると、監査が早く進みます。購入前に、どのベンダーにも1つ見せてもらってください。審査プロセス全体については、AIサポートのセキュリティレビューのガイドで、各ステップの担当者を説明しています。
コンプライアンスを乗り切る導入はどのようなものですか？
リリース日ではなく、ゲートです。各ゲートは、前のゲートに証拠がそろって初めて開き、それぞれに1段階戻る条件があります。
- すべてを下書きモードで。 AIは下書きを内部メモとして書き、チーム外の誰もAIの文面を目にしません。ここで、何を間違えるかを安全に学べます。
- 解決済みチケットでのテスト。 お客様がAIの出力を目にする前に、チケットタイプごとに、AIの下書きとチームが実際に送った内容を比較します。
- 手続き系のチケットタイプを1つ本番に。 最も地味で件数の多い質問（ログインの案内、明細書のダウンロード）を選び、AIにはそれだけを、AIであることを明確に開示したうえで回答させます。
- 操作は承認の後ろに置く。 レコードを変更する、お金を支払う、チケットをクローズする操作は、人が確認するまで待ちます。
eeselでは、エージェントが実行できるすべての操作を、操作と承認に従って、Auto、Needs approval、Disabledのいずれかに設定します。ドキュメント自身の助言は、規制対象のチームにとって適切な初期設定です。"Start supervised" と、"Keep refunds, cancellations and anything that costs money behind an approval." です。
ステップ2では、eeselのヘルプデスクシミュレーションが、チームが最近解決した20件のチケットで動き、それぞれに自分の返信を下書きし、チームが送った内容と比較して、結果をテーマ別にまとめます。Skillsドキュメントによれば、"It sends nothing to customers." です。このレポートは、コンプライアンス部門が実際に読める種類の証拠です。
どれくらいかかるでしょうか。私の導入スケジュールの記事では2〜8週間としており、規制対象のチームでは、ソフトウェアよりも審査プロセスが変動要因になります。正式なベンダー提案依頼を書くなら、AIサポートのRFPテンプレートが、ゲートとチケットテストをベンダーが答えるべき質問に変えてくれます。
規制対象のサポートで、AIを遠ざけるべき場面はどこですか？
いくつかあり、それをはっきり言うことが、計画の残りを信頼できるものにします。
- 臨床的なアドバイス。 Zendesk自身のHIPAAルールは、診断、治療、または "making decisions scoping them into or out of any healthcare plan." にAIを使わないよう顧客に求めています。どのベンダーにとっても妥当な線引きです。
- 個人に関する判断。 与信の否決、保険金の支払い拒否、資格の判断。GDPR第22条は、人に "not to be subject to a decision based solely on automated processing" という権利を与え、Salesforceの規約は、法的効果を持つ判断について "the final decision is made by a human being" を求めています。
- 会話の中のカード番号。 お客様をお支払いの導線に案内し、インデックスされる前にカード番号をマスクします。チャットにカード番号があると、そのチャネルがPCIの対象範囲に入ってしまうからです。
- ほかに手段のない配慮が必要なお客様。 FCAは、ほかに助けを得る方法を用意せずに "automatically excluded consumers with vulnerability indicators from AI journeys" している企業を指摘しました。必要とする人のために、人へ素早くつなぐ経路を残してください。
どれも、待つ理由にはなりません。ほかのすべてにイエスと言えるようにするための境界線であり、どのキューでもAIエスカレーションで私が勧める境界線と同じです。
規制対象のサポートでeeselを試す
eeselは、ヘルプデスクのためのAIチームメイトです。既存のZendesk、Freshdesk、Salesforceのキューに加わり、過去のチケット、マクロ、ヘルプセンターから学び、下書きモードで始まるため、チームが承認するまで、何もお客様に届きません。操作ごとに、自動で実行するか、承認を待つか、無効にするかを選べ、すべての会話と操作が推論の根拠とともに記録されます。
コンプライアンスチームが尋ねる点について、eesel Trust Centerに基づく現状は次のとおりです。
- HIPAA： eeselは、医療情報をどう扱うかを審査したうえで、Enterpriseのお客様とBAAを締結します。BAAのワークスペースでは、すべてのAIモデル呼び出しを、eesel自身のAWSアカウント内のAWS Bedrockで実行し、Web検索などのツールはオフにします。
- 学習： eeselは、お客様のデータでモデルを学習やファインチューニングしません。
- マスキング： PII（個人情報）のマスキングは、カード番号、銀行口座、国民IDを含む
15のカテゴリを、過去のチケットがインデックスされる前にマスクします。新しいワークスペースではデフォルトでオフで、ライブのチケット参照はマスクされないままモデルに届くため、設定を確認し、アクセス制御と組み合わせてください。 - SOC 2： Type II監査は進行中で、観察期間は2026年10月1日から12月31日、レポートは2027年にNDAのもとで提供される予定です。
これが正直な現状です。ベンダーがデータに触れる前に完成したSOC 2レポートが必要なら、eeselは2027年まで要件を満たしません。承認済みの文面から下書きし、人を待ち、仕事の中身を示すAIが必要なら、smavaの設定が今日、月27,000件のチケットで動いています。ご自身のキューで下書きモードからeeselを試すか、コンプライアンス責任者を同席させてデモを予約してください。