規制下の企業に向くエージェント型AI基盤5選

候補となる5つの基盤

• Jinba：チーム全体で共有でき、決定的でオンプレミス運用が可能なワークフロー自動化を求める銀行・保険会社向け
• UiPath：既存の自動化基盤を持ち、外部遮断環境でセルフホスト型のエージェント型AIを動かしたい企業向け
• IBM watsonx.governance：単一の基盤だけでなく、複数ベンダーにまたがるAIを統制したい金融のGRC部門向け
• Salesforce Agentforce：Salesforce CRMに標準化済みで、コンプライアンス認証を最初から備えた製品を求める企業向け
• Microsoft Copilot Studio：セルフホスト運用の代わりに、地理的なデータ所在地で要件を満たせるMicrosoft 365利用企業向け

エージェント型AI基盤では、従来のRPAが依存してきた固定的でルールベースのスクリプトを実行するのではなく、ソフトウェアエージェントが大規模言語モデルの推論を用いて複数ステップの業務を計画し、実行します。この自律性こそが、コンプライアンス部門やリスク管理部門を慎重にさせている要因です。次に何をするかを自ら決めるエージェントは、決められた手順をたどるスクリプトよりも監査が困難です。エンタープライズのAI支出は2026年までに前年比108%増となりましたが、その支出の多くがいま同じ壁に突き当たっています。サンドボックスでは動いていた実証実験が、「そのエージェントの直近の判断を承認したのは誰か」「そのログは検査で証拠として通用するのか」とコンプライアンス責任者に問われた瞬間に止まってしまうのです。以下で取り上げる各基盤は、エージェントがベンチマークでいくつ勝てるかではなく、この壁を実際に越えられるかどうかで評価しています。

評価基準（重要な順）：

• 決定的な実行とヒューマン・イン・ザ・ループの統制：エージェントの出力が、規制対象の業務プロセスに組み込めるだけの予測可能性と検証可能性を備えているのか、それともリスク委員会が承認しない確率的なブラックボックスなのかを分けます。
• 認証と監査証跡：数か月かかるセキュリティ審査を経ずに、調達部門とコンプライアンス部門が承認できるかどうかを分けます。また「AI対応済み」が本当に「本番環境のセキュリティ監査済み」を意味するのかも問われます。この2つは同じ主張ではなく、混同は購買判断でよく起きる誤りです。
• 展開の柔軟性（SaaS、プライベートクラウド、オンプレミス、外部遮断環境）：データ主権の要件に実際に応えられるかどうかを分けます。指定した地域にデータを置くと約束しつつ、実体は他社のマルチテナントクラウド上で動く構成では要件を満たせません。
• ガバナンスとGRCへの適合：自社が構築したエージェントだけを統制するのか、ベンダーやモデルをまたいでAI資産全体を統制するのかを分けます。AIツールを複数運用している企業にとっては、この違いが候補そのものを変えます。

1. Jinba

Jinbaは、Y Combinatorの出資を受け、SOC 2 Type IIに準拠したワークフロー構築基盤です。銀行、保険会社、法律事務所、医療機関、製薬企業など、従業員2万人以上、とりわけ3万人規模の規制下の企業に向けて設計されています。この認証が重要なのは、実証実験が本番データに触れることを許される前に、コンプライアンス部門が必ず確認する資格だからです。加えてY Combinatorの出資は、企業自体が第三者の審査を受けたことを示す、ベンダーの自己申告ではない検証可能なシグナルになります。

Jinbaが狙う課題は具体的です。Microsoft Power AutomateやUiPathをすでに試したものの、硬直的でスクリプト偏重の実装に行き当たった企業。あるいは、市民開発者が数日で公開できるはずのワークフローに、コンサルティング会社へ30万ドルと3か月を費やしてしまった企業です。Jinbaの答えは、8割をルールベースの決定的な処理で構成し、大規模言語モデルによる推論は本当に必要な箇所だけに適用するアーキテクチャです。これは第一の評価基準に直接応える設計判断です。KYCの手続きや融資審査であれば、この決定性があるからこそ、コンプライアンス責任者はエージェントがなぜその案件を要確認としたのか、あるいは承認したのかを正確にたどれます。実行のたびに大規模言語モデルのその場の判断を信用する必要はありません。出力を監査可能にするのと同じアーキテクチャが、実行コストを低く保つことにもつながります。この二重の効果については決定的なワークフローが監査対応とLLMコストを同時に解決する理由で解説しています。

展開面では、Jinbaは外部遮断環境向けのオンプレミス導入に対応しています。これにより、地域を指定できるSaaSではなくセルフホストの選択肢を持つ、本記事で2つだけの基盤のひとつとしてUiPathと並びます（選択肢の全体像は銀行・保険会社向けオンプレミスLLM基盤の選択肢をご覧ください）。あわせて、規制下の買い手が標準として期待するエンタープライズ向けの統制機能も備えています。ロールベースのアクセス制御（RBAC）、シングルサインオン（SSO）、Active Directory連携、バージョン管理、フィーチャーフラグ、そしてワークフロー実行ごとの監査ログです。

Jinbaが構造的に差別化しているのはチーム利用の層です。この基盤は2つの製品で構成されます。ひとつはJinba Flowで、技術者や一定の技術知識を持つ担当者がチャットからのフロー生成やビジュアルエディタでワークフローを構築し、API、バッチ処理、MCPサーバーとして公開します。もうひとつはJinba Appで、専門知識のない業務部門の担当者が、自動生成されるフォームと対話型の画面から同じ共有ワークフローを実行します。一度作れば、権限管理のもとで業務チーム全体が使えます。これは、ベンダー自身の公式ドキュメントが監査ログを備えず規制対象の業務を想定していないと認めている個人向けAIツールとの構造的な違いです。この差については規制下の銀行業務におけるClaude CoworkとJinbaの比較で整理しています。Jinbaの決定的なアーキテクチャは、コストにも直接効いてきます。ルールベースのワークフローを大規模に動かす費用は、確率的なエージェント実行を月次で回す費用の何分の一かに収まります。エンタープライズのAI支出が伸び続けるなか、API請求額の増加を精査するCFOにとっては重要な点です。

強み：

• 8割をルールベースとする決定的な実行により、確率的な経路ではなく、たどれる判断経路をコンプライアンス部門に提供できる
• オンプレミス展開が、データ所在地の指定にとどまらない真の外部遮断環境に対応する
• 共有ワークフロー、RBAC、SSO、Active Directoryといったチーム利用の層により、AIを個人利用から業務基盤へ広げられる

弱み：

• 売上と導入実績が日本市場に大きく偏っており、米国の信用組合や日本の銀行拠点への展開はまだ初期段階
• IBMやUiPathが示せるような、GartnerやForrester Waveといった独立系アナリストの評価掲載がない
• AIコンサルティング部門は新しい提供領域であり、大手ファームやMcKinseyのような数十年の実績はない

向いている相手：数か月ではなく数日でワークフローを構築・公開したい規制下の企業。担当者一人のチャット画面に閉じるのではなく、業務チーム全体で共有したい場合に適します。

2. UiPath

UiPathは、本記事の他のどの基盤も主張していない資格を掲げています。同社は、ISO/IEC 42001（AIマネジメントシステムの規格）とAIUC-1の両方の認証を取得した最初のエンタープライズ自動化基盤であり、ガバナンスと敵対的挙動のテストについてSchellmanの監査を受けたとしています。これは従来のSOC 2やISO 27001の監査とは性質が異なります。ISO/IEC 42001が認証するのは、組織としてAIリスクを管理する仕組みであり、特定の本番環境がセキュリティ監査に合格したことではありません。一部のAzure AI製品でISO/IEC 42001を取得しているMicrosoftとUiPathを比較検討する買い手は、この2つの認証を同じ証明として扱わず、区別しておく必要があります。

UiPathが応えているのは、大規模なRPA資産と厳格な主権要件を併せ持つ企業が直面する状況です。すなわち、ベンダーのクラウドではなく、自社が管理するインフラの内側で動かさなければならないエージェント型AIです。UiPath Automation Suiteは公共部門向けにオンプレミスのエージェント型AIを提供し、規制対象の組織や政府機関が、クラウド上または自社でホストする大規模言語モデルを用いて、自らのインフラ内でエージェント型AIを展開できるようにします。これにより、UiPathはJinbaと並び、所在地設定付きのSaaSではなく本来のオンプレミス展開を提供する2つの基盤のひとつとなります。

ガバナンスについて、UiPathは別個のコンプライアンス層を新たに作るのではなく、企業がすでに信頼している統制を広げる方針を取っています。基盤のガバナンスは、内部のすべてのエージェント、モデル、操作にわたって、認証基盤、監査、コンプライアンスの仕組みを拡張する位置づけです。これはベンダー横断のガバナンス層より範囲が狭い設計です。UiPathは自社のエージェントをうまく統制しますが、IBMの製品のように、複数ベンダーが混在するAI資産の上に立つことは想定していません。

強み：

• ISO/IEC 42001とAIUC-1の二重認証をSchellmanの独立監査付きで取得しており、コンプライアンス部門に2種類の保証を提供できる
• Automation Suiteによる本来のオンプレミス展開とセルフホストのLLM運用に対応し、公共部門や金融サービスの主権要件に適する
• 並行するシステムを別に用意させるのではなく、既存の認証基盤と監査の仕組みを広げる形でガバナンスを提供する

弱み：

• ガバナンスの範囲がUiPath自身のエージェントに限られ、企業が併用する他社モデルやエージェントには及ばない。複数ベンダーの資産の上に立つ設計ではない
• RPA基盤としての出自から、エージェント機能はスクリプト前提のアーキテクチャの上に重ねられており、当初からエージェント志向で作られてはいない
• 公開されている認証情報はガバナンスとセキュリティでは充実しているが、IBMのような金融GRCに特化したアナリスト評価は公表していない

向いている相手：すでに自動化の基盤を持ち、自社が管理するインフラから業務を移すことなく、それをエージェント型AIへ広げたい企業。

3. IBM watsonx.governance

本記事のなかで、自動化の買い手一般ではなく規制業種の買い手を明確に想定して製品を設計している唯一のベンダーがIBMであり、アナリストの評価もその位置づけを裏づけています。watsonx.governanceは、GartnerがAIガバナンス基盤について初めて公表したMagic Quadrantでリーダーに、2026年のIDC MarketScapeのAI活用型金融GRC分野でリーダーに、そしてThe Forrester WaveのAIガバナンスソリューション分野でもリーダーに位置づけられています。3社の独立したアナリストからリーダー評価を得ている点は、本記事のどの基盤よりも重い外部評価です。ただしこれはガバナンスの範囲についての評価であり、ワークフローの実行についてではありません。直接の比較は金融サービス企業におけるIBM watsonx.governance、OneTrust、Jinbaの比較をご覧ください。

IBMが扱うのは、複数のツールにまたがってAIを本番運用し始めた企業に現れる課題です。すなわち、どのモデルがどこで動いているのか、それぞれにどの方針が適用されるのか、その方針が守られた証跡はあるのかを、一箇所で答えられる人がいないという状態です。watsonx.governanceはこの課題を3つの柱に整理しています。AIエコシステムを常に最新の状態で可視化するガバナンスグラフとしての「可視性」、方針の自動適用と義務の対応づけ、コンプライアンス証跡の取得を担う「統制」、そして成果とリスクをリアルタイムに追跡する「説明責任」です。IBMは、この方式を用いる顧客において2,700件を超えるAIユースケースを統制し、処理時間62%削減、内部監査費用50%削減、業務効率150%向上という結果を報告しています。コンプライアンス責任者にとっては、抽象的な「コンプライアンス対応済み」という主張ではなく、取締役会に持ち込める投資対効果の根拠になります。

重要なのは、IBMがwatsonx.governanceをIBM OpenPagesと組み合わせている点です。これにより、財務、リスク、監査の各部門が、すでに運用している全社のリスク・コンプライアンス業務にAIの統制を接続できます。金融GRCとの結びつきを最も明確に示している基盤だと言えます。その位置づけは展開面では逆に働きます。watsonx.governanceは「あらゆるAIを、どこにあっても統制する」という方針のもと、ハイブリッドかつマルチクラウドのガバナンス層として設計されており、それ自体がセルフホストのエージェント実行基盤というわけではありません。IBMを採用する企業が買うのは、AI資産全体にまたがるガバナンス層であって、ワークフロー構築やエージェント実行の基盤を置き換えるものではありません。

強み：

• Gartner、IDC、Forresterからそれぞれ独立にリーダー評価を得ており、本記事で最も強い第三者評価
• OpenPagesとの組み合わせで金融GRCとの結びつきが明確であり、AIの統制を全社のリスク・監査プロセスに直接つなげられる
• 監査費用の削減や処理の高速化といった成果指標が報告されており、認証の主張だけでなく説明可能な投資判断の根拠になる

弱み：

• AIを統制するものであり、エージェント型のワークフローを構築・実行するものではないため、ワークフロー基盤の代わりではなく併用が前提になる
• 真にセルフホストの外部遮断環境ではなく、ハイブリッドかつマルチクラウドの層として位置づけられている
• エージェント型ワークフローをゼロから始める企業より、統制すべき複数ベンダーのAI資産をすでに抱える企業に向く

向いている相手：すでに複数の基盤でAIを運用しており、その全体の上に監査・リスク管理の機能を備えた単一のガバナンス層を置きたい金融のGRC部門。

4. Salesforce Agentforce

Salesforceはコンプライアンスを注釈ではなく前面の主張として扱っており、専用のコンプライアンスサイトを設けて、これを同社の「第一の価値である信頼」と位置づけ、包括的と称する認証・保証の一覧を維持しています。Agentforceについては、SOC 2 Type II、SOC 1、ISO 27001、FedRAMP、HIPAAが含まれ、40を超える標準搭載のコンプライアンス認証としてまとめて訴求されています。この幅広さは本記事で最も広い従来型の認証群であり、規制下の買い手にとって意味があります。銀行や保険会社自身のセキュリティ審査で名指しで求められる可能性が最も高いのが、SOC 2 Type IIとISO 27001だからです。

ただし、Salesforceが解く課題は見た目ほど広くありません。すでにSalesforce CRM上で業務を運用している企業が、別の基盤にエージェント型AIを後付けしようとすると、実際の連携負担が生じます。顧客レコード、案件データ、サービスの処理経路に触れるワークフローはすべて、別のシステムへつなぎ直さなければなりません。Agentforceは、企業がすでに持つCRMのデータモデルの内側でエージェント型AIを動かすことで、この負担を取り除きます。その買い手にとっては実際の効率向上になります。

代償は展開面に出ます。AgentforceはSalesforceのHyperforceクラウド基盤上で動作し、オンプレミスや外部遮断環境の選択肢はありません。主権要件が認証チェックリストで足りる企業にとっては問題になりません。認証群がその役割を果たします。一方、規制当局がデータを自社管理下のインフラに物理的にとどめることを求める企業では、認証だけでは要件を満たせず、Agentforceは適した基盤ではありません。

強み：

• 本記事で最も広い従来型のコンプライアンス認証群（SOC 2 Type II、SOC 1、ISO 27001、FedRAMP、HIPAA）を備え、セキュリティ審査の摩擦を減らせる
• Salesforce CRMのデータとの標準連携により、すでに同基盤に標準化している企業の連携負担を取り除ける
• コンプライアンスを全社的な優先事項と位置づけ、継続的に更新される専用の証明ポータルを用意している

弱み：

• オンプレミスや外部遮断環境の選択肢がなく、Salesforce自身のクラウド基盤上でのみ動作する
• 価値がSalesforce CRMへ投資済みの企業に集中しており、その外では説得力が弱まる
• 認証の幅はインフラのセキュリティを十分に押さえているが、UiPathやMicrosoftがAI関連製品で取得しているAIマネジメントシステムの認証（ISO/IEC 42001）は含まれない

向いている相手：Salesforce CRMに標準化しており、セキュリティの根拠を一から組み立てるのではなく、既存の広い認証群をエージェント型AIにも引き継ぎたい企業。

5. Microsoft Copilot Studio

Microsoftの認証一覧は、単純な数では本記事で最も長いものです。Copilot StudioはHIPAA（事業提携契約による）、HITRUST CSF、FedRAMP、SOC、ISO 27001:2013、PCI DSS、CSA STAR、G-Cloud、OSPAR、K-ISMS、MTCS Level 3、そしてスペインのENS High認定に準拠または対応しており、SOCとISO 27001:2013の監査報告書はMicrosoftのService Trust Portalから直接ダウンロードできます。この「監査報告書を実際に入手できる」という点は実務で効いてきます。認証を掲げるだけのベンダーと、デューデリジェンスの場でコンプライアンス部門に実際の監査文書を取得させるベンダーとの違いだからです。

Copilot Studioが解く課題は、すでにMicrosoft 365、Teams、Azureを運用している企業における導入の速さです。この構成を持つ企業は、認証基盤、データ分類、ライセンスの仕組みをそのまま利用でき、Copilot Studioのエージェント機能は従業員が日常的に使っているツールの中に収まります。新しい画面を覚える必要がありません。名前の挙がった認証と既知の監査証跡を軸にコンプライアンス戦略を組み立てている企業にとって、Microsoftの一覧は範囲の広さで比肩しにくいものです。

制約はデータ主権に現れます。Microsoft自身の管理者向けドキュメントは、Copilot Studioがオンラインサービス規約上の「オンラインサービス」に分類されること、つまりSaaSであることを明記しており、主権要件を満たす主な手段は、指定した地域内にデータを保存・処理する地理的なデータ所在地であって、セルフホストのオンプレミス構成ではないとしています。この違いが重要な理由はSalesforceの場合と同じです。所在地は「データがどこに保存されているか」には答えますが、「外部ネットワーク経路を持たないインフラの内側で動かせるか」には答えません。外部遮断の要請が実際に問うているのは後者です。後者の答えが必要な企業に必要なのは、Copilot StudioではなくUiPathかJinbaです。

強み：

• HIPAA、FedRAMP、HITRUST、ISO 27001:2013、複数の地域規格にまたがり、単純な数では本記事で最も長い認証一覧
• SOCとISO 27001:2013の監査報告書をMicrosoft自身のService Trust Portalから直接ダウンロードでき、デューデリジェンスの期間を短縮できる
• すでにその構成を採用している企業にとって、Microsoft 365とAzureの認証基盤との標準連携が深い

弱み：

• 「オンラインサービス」すなわちSaaSに分類され、セルフホストやオンプレミスでの展開経路が存在しない
• データ主権への対応が地理的な所在地に限られ、外部遮断や完全なセルフホストの要請には応えられない
• 広い認証範囲は主にインフラ層のものであり、Copilot Studio製品全体としてはAIマネジメントシステム固有のISO/IEC 42001認証を含まない。取得しているのはAzure AI Foundry ModelsやSecurity Copilotなど一部の周辺製品に限られる

向いている相手：幅広く独立監査が可能な認証一覧と地域内のデータ所在地でコンプライアンス要件を満たせ、オンプレミスの必須要件を持たないMicrosoft構成の企業。

5つの基盤の比較

展開の柔軟性の行には、順位を並べただけの一覧では見えにくい傾向が表れています。真にセルフホストで外部遮断が可能なのはJinbaとUiPathだけで、IBMはハイブリッドなガバナンスの位置に、SalesforceとMicrosoftは主権への答えが隔離ではなく所在地であるSaaS製品に位置づけられます。規制当局からの問いが「外部ネットワークに依存せず動かせるか」である企業にとっては、認証やガバナンス機能を検討する前に、この行だけで候補が絞られます。

エージェント型AI基盤とは何ですか。従来の自動化やRPAとどう違うのですか。

エージェント型AI基盤は、ソフトウェアエージェントに対して、大規模言語モデルの推論を用いて複数ステップの業務を計画し遂行する能力を与えます。各段階で、その時点の状況に応じて次に何をするかを判断します。対して従来の自動化やRPAは、固定的でルールベースのスクリプトを実行します。同じ起点からは毎回同じ順序の処理が生じます。この違いこそが、規制業種がエージェント型AIを生産性の機能ではなくガバナンスの課題として扱う理由のすべてです。スクリプトの失敗は予測でき、たどることもできます。一方、推論の結果として想定外の行動に至るエージェントは、KYCの書類や保険金請求の判断に触れる前に、承認、監査証跡、そして決定的な代替経路を周囲に用意しておく必要があります。本記事のどの基盤も、エージェントにどれだけ自律性を与えるかではなく、その自律性をどう制約するかで評価しているのはこのためです。これらが証拠として通用するために銀行が備えるべき構成要素については2026年に銀行が備えるべきAIガバナンス体制の7つの構成要素をご覧ください。

規制業種では、どの評価基準が最も重要ですか。

エージェントの素の能力よりも、実行の決定性とヒューマン・イン・ザ・ループの承認を優先し、その次に認証、展開の柔軟性、ガバナンスとGRCへの適合という順に重みを置いてください。エージェントの素の能力、つまりモデルの推論の質や呼び出せるツールの数は、一般的な基盤比較が真っ先に取り上げる軸ですが、規制下の買い手にとっては誤った出発点です。監査可能な判断の証跡を残せない高性能なエージェントは、銀行や病院では資産ではなく負債になります。上記の順序は、規制下の導入を実際に止めているものを反映しています。監査できない業務プロセスは、価格や連携をめぐる調達の話に至る前に、コンプライアンス審査で落ちるからです。

銀行、保険、医療といった規制業種で、エージェント型AI基盤はどう活用されますか。

どの規制業種でも、活用される業務の種類は共通しています。KYCをはじめとする本人確認、契約書レビュー、書類処理、保険金請求や事前承認の手続き、融資審査、取引の照合です。業種によって異なるのは、基盤が組み込まれる先の統制された業務の具体的な中身です。保険会社の事故受付、銀行の銀行間KYC手続き、病院の事前承認の待ち行列といった違いがあります。一方で要件は共通しています。実行は自動化されるだけでなく、統制されている必要があるということです。IBMがwatsonx.governanceとOpenPagesを組み合わせて財務・リスク・監査の各部門に向け、金融GRCを明確に狙っているのはそのためです。また、これらの業種でオンプレミス展開の重要性が相対的に高いのも同じ理由です。扱うデータ（口座情報、診療記録、引受査定の書類）は、規制当局が管理下の環境から出ることを最も望まないデータだからです。

これらの基盤は、セキュリティ、ガバナンス、展開についてどのような選択肢を提供していますか。

展開の選択肢は2つではなく3つに分かれます。地理的な所在地を指定するSaaS（Microsoft Copilot Studio、Salesforce Agentforce）は、データを指定地域内にとどめますが、動作するのはベンダーのマルチテナントクラウドです。あらゆるAI環境にまたがるハイブリッドなガバナンス（IBM watsonx.governance）は、既存のインフラを置き換えるのではなくその上に位置します。真のオンプレミスまたは外部遮断環境での展開（UiPathのAutomation Suite、Jinba）は、企業自身が管理するインフラの内側で動作し、外部ネットワークへの依存を必要としません。認証の側でも同じ3つの区分が現れます。従来型のセキュリティ監査（SOC 2 Type II、ISO 27001、SOC 1、米国市場向けのHIPAAやFedRAMP）は、本番環境がデータセキュリティの観点で監査されたことを証明します。一方ISO/IEC 42001は、組織がAIリスクを管理する仕組みを備えていることを証明する、より新しく別種の規格です。UiPathは自動化基盤全体で、Microsoftは一部のAzure AI製品で取得しており、Copilot Studio全体では取得していません。「この基盤は認証を取得しているか」と問うコンプライアンス部門は、2つのどちらを指しているのかまで確認する必要があります。

規制のガイドラインを満たすために、エージェント型AIのコンプライアンスとガバナンスをどう確保すればよいですか。

エージェント型の導入におけるコンプライアンスは、単一の監査ではありません。エージェントの周囲に構築するか、調達してくる層です。この市場には構造の異なる2つのやり方があります。ひとつは、企業がすでに信頼している認証基盤、監査、コンプライアンスの仕組みを、すべてのエージェント、モデル、操作へ広げる方法です。UiPathの方針であり、Jinbaが自前のRBAC、SSO、Active Directory、監査ログの仕組みで取っている方法でもあります。ワークフローを動かす基盤の内側にガバナンスを保てる点が特徴です。もうひとつは、ガバナンスを切り離せる層として扱い、ベンダーを問わず企業が動かすあらゆるAIの上に置く方法です。IBMの「あらゆるAIを、どこにあっても統制する」という位置づけがこれにあたり、ガバナンスグラフ、方針の自動適用、リアルタイムのリスク追跡を軸に構成されています。単一のエージェント基盤を運用する企業には通常、基盤に組み込まれたガバナンスが適します。複数ベンダーのAIツールを併用する企業には、切り離せる層が必要になるのが一般的です。ひとつの基盤に組み込まれた統制だけでは、他の基盤で起きていることを把握できないからです。自社の統制環境に照らしてどちらの道を選ぶか検討するチームは、CISOとコンプライアンス責任者のためのエンタープライズAIコンプライアンス導入ガイドから始めるとよいでしょう。