整備した形と、機能する形は違う
規程がある、承認フローがある、ログを取っている。整備されている状態と、機能している状態は別のものです。前者だけで止まる型を扱います。
ここで扱う型は、多くの場合意図的な偽装ではありません。規程を作ること自体が目的化した結果として生じます。だから対処も、責任追及ではなく実効性の指標を持つことになります。
型1 ― 形だけの利用規程
規程が存在しても運用されない状態には、はっきりした原因があります。
| 原因 | 現れ方 | 対処 |
|---|---|---|
| 新しいサービスを使う経路がない | 規程に記載のないサービスが各部署で使われる | 申請経路を規程に書く。登録のみで始められる範囲を示す |
| 判断が個人に委ねられている | 「機密情報は入力禁止」だけで、何が機密かの区分がない | 3段階の区分と、迷った場合の連絡先を明記する |
| 技術的な詳細が書かれている | 変化が早く、改定が追いつかない | 製品名や技術の詳細を規程から外す |
| 分量が多い | 読まれない | 2〜3ページに収める |
| 周知されていない | 存在を知られていない | 入社時・異動時の手続きに含める |
| 違反の指摘経路がない | 気づいても報告されない | 相談窓口を明示し、報告を不利にしない |
1行目が最も影響します。表の第16章で述べたとおり、経路がない規程は規程外の利用を生みます。禁止事項をいくら整備しても、この経路がなければ把握は進みません。
実効性の指標
規程が機能しているかを外形的に確認する方法を挙げます。
- 過去1年で、申請または登録が何件あったか(0件であれば経路が機能していない)
- 承認済みサービスの一覧が、いつ更新されたか
- 使用中のサービスの棚卸しと、規程上の一覧が一致しているか
- 現場の担当者が、扱っているデータの区分を答えられるか
4番目が最も端的です。現場が自分の扱うデータの区分を答えられない場合、規程は運用されていません。
型2 ― 承認フローが重く、迂回される
承認の手続きが重いと、次のことが起きます。
- 申請せずに使う判断が合理的になる
- 完成してから相談する形になり、事後承認が通例化する
- 承認を待つ間に他の手段(個人契約など)が使われる
- 「重要でないもの」として申請の対象外だと判断される
対処はリスクに応じた経路の分離です(表の第16章)。登録のみ・簡易確認・正式審査の3経路に分け、多くの利用が1番目で完結するようにします。
加えて、正式審査の所要期間を明示することが有効です。「数週間」ではなく「申請から10営業日以内に回答」といった形にすると、迂回の動機が下がります。
型3 ― 責任分界を曖昧にしたまま進める
本章で最も実害が大きい型です。表の第16章で扱った原則を再掲します。AIの出力を業務に使った結果の責任は、それを使うことを決めた人と組織が負う。
この原則が明文化されていない場合、次の2つが同時に起きます。
- 現場が使わなくなる ― 責任の所在が不明な状態で使うのは、担当者にとって不利益です。使わないことで自衛するのは合理的な判断です。
- 事故が起きたときに争点になる ― 判断者が特定できず、原因の検証もできません。
形だけの明文化を避ける
「最終責任は利用者が負う」と書くだけでは足りません。表の第16章で述べたとおり、根拠が示されない出力の確認を担当者に負わせる設計は機能しません。確認できない責任は、形式的な承認になります。
実効性のある明文化には、次の3点が伴う必要があります。
- どの工程で人が判断するか ― 業務ごとに確認の型を決める。
- 誰が判断したかを記録するか ― 記録がなければ事後の検証ができない。
- 判断者が確認に必要な情報を持っているか ― 出典、根拠、確信度が表示されるか。
3番目が省かれた明文化は、責任だけを現場に移す形になります。この形は「ガバナンスを整備した」という記録を作りますが、実際のリスクは減りません。
型4 ― 監査と利用ログを整備しない、または形骸化させる
ログを取得していても、見なければ意味がありません。形骸化の形を挙げます。
- 取得しているが見ていない ― 月次の確認項目に入っていない。
- 見る項目が多すぎる ― 20項目のダッシュボードは見られなくなります。
- 集計されていない ― 生のログだけがあり、傾向が分からない。
- 品質の指標が入っていない ― 稼働状況と費用だけで、人による修正の割合が含まれていない。
- 権限の棚卸しがない ― 付与された権限の一覧が更新されていない。
対処は表の第16章に示したとおり、月次で見る項目を3つに絞ることです。費用、利用者数、修正率。加えて年1回の棚卸し(サービス・自作ツール・権限)。
次の2つが確認できない場合、統制は実質的に機能していません。(1) 使用中のAIサービスの一覧が、直近1年以内に更新されている。(2) 退職・異動時の権限整理が既存の手続きに組み込まれている。とくに2番目は、既存の入退社手続きに1項目追加するだけで実装できます。実装されていない場合、退職者のアカウントが有効なまま残っている可能性があります。
型5 ― 高リスク用途の判定を曖昧にする
すべての利用に同じ管理を適用すると負荷が過大になるため、リスクに応じた分類が必要です(表の第16章)。この判定基準が曖昧だと、次のことが起きます。
- 判定が個別の交渉になり、時間がかかる
- 推進の圧力が強い案件が低リスクに分類される
- 現場が自分で判定できず、申請が増えるか、申請されなくなる
対処は、判定基準を具体的な5項目で示すことです。次のいずれかに該当すれば高リスクとする形が実務的です。
- 個人情報または取引先の機密情報を扱う
- AIの出力が、人に対する判断(採用・評価・与信・給付)に使われる
- 出力が社外に出る(顧客への回答、公開物)
- 人の承認なしに操作が実行される(送信・更新・削除)
- 止まると業務が止まる
4番目が、エージェント型の利用に対応します。自律的に操作を実行する仕組みは、それだけで高リスクに分類するのが安全側の設計です(第21章)。
朝凪精機のAI利用規程は、二年目の四月に作られた24ページのもので、全員が「読みました」にチェック済みでした。二月下旬に推進室が21人に聞き取ると、区分の判断が人ごとに分かれていました。経理課長は取引先名の入った表が社内限りか禁止か分からず、AIに入れないことにし、営業部の若手は先方の担当者名が入った商談メモを社内チャットで要約していました。規程は機密かどうかを「利用者が適切に判断する」とするだけで、迷った場合の連絡先が書かれていませんでした。慎重な人は利用を控え、そうでない人は境界に近い利用を行っていました。チャットの入力欄の上に連絡先を1行出し、問い合わせを月末にまとめて区分の例に追記する運用にすると、商談メモは禁止の例に「名前を除けば社内限り」と添えて入り、判断の幅が縮まりました。
この場面は網羅物語之巻 第13章「規程は作った」に出てきます。
実効性を測る7つの問い
整備の形ではなく機能しているかを確認する問いです。すべて外形的に確認できます。
- 過去1年で、申請または登録は何件あったか
- 承認済みサービスの一覧は、いつ更新されたか
- 現場の担当者は、扱うデータの区分を答えられるか
- 正式審査の所要期間は明示されているか
- 判断者が確認に必要な情報(出典・根拠)を受け取る設計になっているか
- 月次で見る項目に、品質の指標(修正率)が含まれているか
- 退職・異動時の権限整理は既存手続きに組み込まれているか
7問のうち3問目が最も端的な指標です。現場が区分を答えられない規程は、存在しても機能していません。