監査対応で止まるAI連携――WorkdayとServiceNowで人事が『回答精度』より権限残存を恐れる理由
監査対応で止まりやすい、WorkdayとServiceNowのAI連携の論点
本稿で想定する、Workdayを人事マスタ、ServiceNowを業務ワークフロー基盤として連携し、各製品のAI機能を活用する構成は、とても魅力的に見えます。人事情報と業務ワークフローがつながれば、問い合わせ対応、申請処理、ナレッジ検索はかなり速くなります。
ですが、人事・ITSMをまたぐAI運用で、監査要件が厳しい組織の人事責任者、HRIS責任者、ITSM責任者、IAM担当者が早い段階で気にするのは、AIがどれだけ賢く答えるかより、退職者や異動者の権限が残ったままにならないか、そしてその状態を監査で説明できるかです。
AIの回答精度は改善余地があります。一方で、権限残存は、状況によっては統制不備と評価される可能性があり、後からの説明が難しくなります。だからこそ、データ連携の前に、権限残存と更新責任を見直す必要があります。
AI連携が便利でも、人事が最初に見るのは回答精度だけではない
多くの議論では、AI連携の価値は検索性や自動化で語られます。たしかに、社員からの問い合わせに即答できたり、申請の案内を自動化できたりする点は大きな利点です。
Workday側でも、人事データと業務プロセスを結び付ける発想は強く打ち出されています。ですが、監査要件が厳しい組織では、人事部門の評価軸は、一般的な業務部門とは少し違います。
人事が扱うのは、組織変更、入退社、兼務、出向、休職といった、人の状態変化です。この変化がシステム権限にきれいに反映されないと、AIが正確に答えていても運用全体は危うくなります。
つまり、監査要件が厳しい組織の人事にとっては、AIの回答精度に加え、AI参照権限の付与と剥奪が人事イベントに連動するかどうかが重要です。ここが曖昧なままでは、便利さより先に統制不安が立ちやすくなります。
https://learn.microsoft.com/en-us/entra/id-governance/identity-governance-overview
WorkdayとServiceNowがつながるほど、権限管理と更新責任の論点は重くなる
本稿が想定する構成では、Workdayは人事マスタに近く、ServiceNowは申請、承認、問い合わせ、運用ワークフローの中心になりやすい製品です。この2つがAIとともにつながると、単なるデータ連携ではなく、判断やアクセスの起点が連動し始めます。
たとえば、異動情報がWorkdayで更新され、両者が適切に統合・設定されている場合には、その結果としてServiceNow上の申請経路、閲覧範囲、タスク権限、ナレッジ参照範囲が変わることがあります。ここで1つでも連動漏れがあると、本人の所属は変わっているのに、前部署の情報に触れられる状態が残ります。
しかもAIが入ると、従来は手で探さなければ見つけにくかった情報にも、自然言語でたどり着きやすくなる可能性があります。これは利便性でもありますが、権限制御が検索インデックスやコネクタに正しく継承されない場合や、誤った権限が残っていた場合には、探索容易性を高める要因にもなります。
だからこそ、少なくとも監査要件が厳しい組織では、AIの回答精度だけを見て導入可否を判断するわけにはいきません。誰が権限更新の責任を持つのかまで含めて、運用の境界を明確にする必要があります。
回答精度は改善できても、権限残存は後から説明しにくい
AIの回答精度に課題があっても、多くの場合は改善策を設計できます。参照先の見直し、プロンプト調整、対象範囲の限定、レビュー導線の追加など、対処の選択肢が比較的わかりやすいからです。
ただし、権限残存は性質が違います。問題が起きた後に問われるのは、なぜ残ったのか、誰が承認したのか、いつ止めるべきだったのか、同様の漏れは他にないのか、という説明責任です。
https://www.nist.gov/itl/ai-risk-management-framework
ここでは、たまたま問題が起きなかったでは済みません。監査や内部統制の場面では、個別事故よりも、再現性のある管理設計があるかが見られます。
つまり、監査要件が強い場面では、AIが80点の回答をしたことよりも、退職や異動のたびに権限剥奪が確実に走る仕組みがあるかのほうが、重要になります。更新停止条件や例外時の再承認者が曖昧だと、説明はさらに難しくなります。
https://owasp.org/www-community/Broken_Access_Control
人事部門が本当に気にするのは、監査で説明できる運用状態かどうか
職務分掌は大事です。たとえば、申請者と承認者を分ける、給与情報と評価情報の閲覧範囲を分ける、といった考え方は基本になります。
ただ、監査要件が厳しい組織で人事責任者が導入判断で強く意識するのは、それを監査で説明できる状態になっているかどうかです。人事部門は制度を作るだけでなく、運用事実を示す必要があるからです。
退職者の権限は当日中に停止されるのか。異動者の閲覧権限はいつ切り替わるのか。休職時はAI参照権限をどこまで止めるのか。例外対応があった場合、誰が承認し、いつまで有効なのか。こうした情報が追えなければ、設計が良くても実務では弱いと判断されます。
https://www.isaca.org/resources
この意味で、AI連携は便利機能の導入ではなく、監査可能な運用変更です。アクセス付与、変更、剥奪の証跡をどう残すかまで含めて設計しないと、導入判断は前に進みにくくなります。
危ないのは退職者アカウントより、異動者の見えにくい権限残り
退職者アカウントの停止は、一般に意識されやすい論点です。退職日は比較的明確で、チェック対象にしやすいからです。
一方で、異動者や兼務者の権限については、見直し漏れが起こりえます。たとえば、営業部から人事部に異動した社員が、旧部署の案件情報やナレッジにそのままアクセスできるケースもあります。
あるいは、一時的な兼務のために付けた権限が、兼務終了後も残ることがあります。AI検索や要約機能が加わると、本人が深い構造を知らなくても、旧権限の範囲で情報へたどり着きやすくなる可能性があります。
https://cloud.google.com/learn/what-is-zero-trust
ここが怖いのは、事故が起きるまで発覚しにくい点です。退職者のような明確な境界と違い、異動はまだ社員であるため、違和感が表面化しにくいのです。
監査要件が厳しい組織で、人事が回答精度以上に権限残存を懸念しやすいのは、この見えにくさがあるからです。
導入を止めないために先に固めるべき人事AI権限表
では、どうすれば前に進めるのでしょうか。結論として、監査要件が強い組織では、AIのPoCを先に回すより、Joiner-Mover-Leaverに休職を加えた、入社・異動・休職・退職の4イベントに沿った権限設計を先に固めるアプローチが有効です。
人事マスタを起点に、どの更新がどの権限変更を引き起こすかを明文化する必要があります。人事イベントに追随するアクセス管理が設計できてはじめて、AI連携の安全性を説明しやすくなります。
https://learn.microsoft.com/en-us/entra/architecture/governance-deployment-intro
実務では、人事AI権限表として少なくとも次の3点を整理することが重要です。
- 入社、異動、休職、退職の4イベントごとに、AI参照権限がどう付与・変更・停止されるかを定義する
- 更新停止条件を明記し、例外的に残す権限は期限付き承認にする
- 再承認者を定め、定期棚卸しで残ってはいけない権限を見つける
この設計があれば、AIの回答精度改善にも安心して取り組めます。逆にここがないと、AIが便利になるほど監査不安も大きくなります。
WorkdayとServiceNowのAI連携で先に問われること
最後に一言でまとめると、監査要件が厳しい組織で、本稿が想定するようにWorkdayとServiceNowを連携し各製品のAI機能を活用する際、先に問われやすいのは、AIの賢さそのものより、人事イベントに追随した権限管理を監査可能な形で運用できるかどうかです。
ここを先に整えた企業ほど、AI連携を安全に前進させやすくなります。検討段階では、入社・異動・休職・退職の4イベントについて、AI参照権限、更新停止条件、再承認者を整理した人事AI権限表を作成することが、最初の一歩になります。