INSIGHT

社内のAI利用台帳を作る——用途・情報・責任者を更新できる記録へ

ACTION|次の確認へ AI / リスクと対策

サービス名の一覧を、仕事と情報の変化を追える記録にするには何が必要か。

各部門へAIツールの利用状況を聞くと、二十以上の製品名が集まった。ところが、「誰が」「どの仕事に」「何の情報を使い」「いまも動かしているか」は一覧から読めない。同じ製品を営業は提案の下書き、人事は規程検索に使っている。製品名が一行では、変更時に影響を受ける仕事を探せない。

台帳は保有ツールを数える表ではない。利用開始、変更、終了の判断を関係者へ渡す業務記録として作る。

更新できる台帳は、製品の名簿ではなく、AIを使う仕事と責任者の現在地を示す。

一行の単位を「製品」から「利用場面」へ変える

同じ製品でも、用途、情報、利用者、影響が違えば行を分ける。「文章作成」のような広い用途ではなく、「営業担当が公開情報から顧客提案の初稿を作り、責任者が確認して提出する」と、入力から確定までが読める単位にする。

各行には、少なくとも次を置く。

  • 利用目的と、AIが担う操作
  • 利用部門、業務責任者、日常の利用者
  • 検討中、試行中、限定利用、本番、停止中、終了の状態
  • 出力を確認する人と、最終判断・実行をする人
  • 開始日、次の見直し日、終了を判断する人

製品を替えずに用途だけ広がることもある。部門内の下書きが顧客提出へ変わる、公開資料だけだった入力に顧客情報が加わる、といった変化を行の更新として残す。製品名だけの台帳では見逃しやすい変化である。

情報と接続先は、流れが分かる粒度で書く

台帳へ個人情報や契約本文を転記する必要はない。どんな種類の情報を、どこから受け取り、どこへ出し、誰が確定するかが分かるようにする。

入力・参照・出力を分け、公開情報、社内限定、顧客情報、個人情報など自社の区分を付ける。正本やデータの所有者、利用を認めた規程・契約へのリンクも置く。AIがファイル共有、顧客管理、メール、会計などへ接続する場合は、読み取りだけか、作成・送信・更新までできるかを記録する。

接続先は技術図の代わりではない。障害や誤操作があったとき、どの仕事と情報を確認するかを探す索引である。詳細な設定は各システムの管理記録へつなぎ、台帳自体へ秘密情報や認証情報を置かない。

更新のきっかけを台帳の外から集める

台帳の担当者が、すべての現場変更を見つけるのは難しい。新規利用申請、契約更新、利用者や権限の変更、外部接続の追加、参照資料の変更、事故や訂正、サービス終了を更新のきっかけにする。

きっかけごとに通知する人を決める。利用部門は用途と利用者、情報の所有者は資料と入力条件、ITは接続・権限・設定、購買は契約・更新・終了、業務責任者は本番化と停止を知らせる。台帳担当は通知を受け、変更後も同じ範囲で使えるかを確認者へ返す。

NISTのAI Risk Management Framework 1.0 は、GOVERN 1.6で組織のリスク優先度に応じたAIシステムの把握、GOVERN 1.7で安全な終了、GOVERN 2で役割や経営層の責任などを扱う2023年の任意フレームワークである。法令や認証基準ではなく、台帳を作れば統制や安全が保証されるという資料でもない。この記事の項目と通知経路は、自社の仕事へ当てはめた編集上の提案である。

定期確認だけに頼らず、用途・情報・接続・契約が変わった瞬間を台帳更新へつなぐ。

更新されない行を照合で見つける

半年に一度「変更はありますか」と聞くだけでは、担当交代した利用や、現場だけで終わった試行が残る。承認済みの契約一覧、経費、アカウント管理、接続設定など、会社がすでに持つ記録と台帳を照合する。ここで探すのは個人の未申告を責める材料ではなく、所有者のない利用と、終了処理が必要な利用である。

照合で見つかった差は、三つに分ける。実際は継続しているのに台帳が古い。台帳にはあるが利用を終えている。製品は同じでも用途や情報が変わっている。担当者へ事実を確認し、状態、責任者、次の判断日を直す。利用者がいなくても、契約、保存データ、接続、成果物が残る場合は、終了作業を完了するまで行を閉じない。

台帳会議では三つの判断だけを行う

台帳を報告資料で終わらせないため、関係者は各行について「続ける」「条件を変える」「終了する」を決める。続ける場合は現行の用途・情報・責任者を確認する。変える場合は、何が広がるかと、追加確認の担当を置く。終了する場合は、契約、アカウント、接続、保存データ、代替手段、利用者への周知を閉じる。

利用終了の行も、ただ削除するのではなく、終了日と対応結果を履歴として残す。後から問い合わせを受けたとき、当時どのサービスと情報を使っていたかを追うためである。履歴自体の保存期間と閲覧者は、会社の記録管理に合わせて決める。

最初の合意は、次のようにできる。

「顧客情報を扱う利用、外部へ送信・更新する利用、本番で複数部門が使う利用から登録する。用途変更は利用部門、接続・権限変更はIT、契約変更は購買が台帳担当へ知らせる。所有者、情報区分、確認者のいずれかが不明な行は利用拡大を保留する。終了は接続解除とデータの扱いを確認して閉じる」

台帳の完成度ではなく、各行について続ける・変える・終了する判断を更新できることを運用の基準にする。

利用台帳を、継続・変更・終了を判断できる記録として更新する

AI利用台帳は、製品名を集めただけでは更新に耐えない。利用場面を単位にし、情報、接続、責任者、状態を結ぶ。変更のきっかけを複数部門から受け取り、既存記録との照合で古い行を見つける。会議で継続・変更・終了を選べる台帳になれば、問題時の影響確認にも次の投資判断にも使える。

参考資料