社員の生成AI利用申請を整える手順と確認項目の決め方

生成AIの利用申請は、サービス名を届け出るだけでは不十分です。同じサービスでも、公開情報の要約と顧客情報を含む文書の処理では確認点が異なります。仕事の目的、入力する情報、出力を使う先を組み合わせて、利用できる範囲を決めます。

申請の対象を用途で定義する

「文章作成に使いたい」では、どこまで認められたか分かりません。「公開済み資料を基に、社内で確認する説明文の下書きを作る」のように対象を記載します。出力をそのまま外部へ送るのか、確認者が修正して使うのかも分けます。

利用者が試す前に確認すべき情報は、社内の入口にまとめます。利用可能なサービス、避ける情報、問い合わせ先、申請が必要となる変更を示します。日常的な利用をすべて個別審査にするより、共通条件で使える範囲を定める方法も検討できます。

入力しない情報も具体的に書くと誤解が減ります。「秘密情報は入れない」だけでなく、自社で迷いやすい顧客名、契約内容、未公開資料などの扱いを確認します。名称を伏せても他の項目から特定できる場合があるため、単純な置換だけで判断しません。

業務の妥当性は仕事を理解する人、サービスや情報の扱いはその条件を確認できる人が判断します。全用途に同じ承認経路を課す必要はありません。小さな会社では役割を兼ねることもあるため、誰がどの論点を確認したかを残します。

判断欄は「承認・否認」だけでなく、利用条件と保留理由を書ける形にします。条件付きで認めるなら、入力を公開情報へ限定する、外部送信前の確認を設ける、接続機能を使わないなど、守れる手順に変換します。

情報の扱いや契約条件を確認できない場合は、実データを投入せず、仮の資料で使い勝手だけを確かめる方法があります。試行を認めたことと、顧客情報の利用を認めたことを同じ意味にしないようにします。

想定例として「社外向けメールの下書き」を申請する場合、入力資料は公開済みサービス説明、宛先情報は入力しない、出力は送信担当が事実確認して修正する、と記載できます。下書きに含まれた約束や納期を誰が確認するかも決めます。

記入内容が曖昧なら、単に「詳しく書いてください」と返さず、「入力に顧客から受け取った文章が含まれるか」「出力を誰が確認するか」を質問します。申請者が技術用語を知らなくても、実際の作業を説明すれば回答できる書式にします。

利用目的が変わる、入力する情報が増える、外部サービスへの接続を加える、出力を自動送信する、といった変更は再確認の対象として決めておきます。サービスの条件が変わった場合も、既存の許可がそのまま適用できるかを確認します。

異動や退職、試行終了時には、アカウント、共有設定、保存データの扱いを整理します。申請台帳には担当者と見直し予定を残し、誰も使っていない契約や、管理者が不明な利用状態を放置しないようにします。

利用条件から外れた入力が判明したときは、追加利用を止め、扱った情報と共有範囲を確認して、社内の対応窓口へつなぎます。利用者が報告をためらわないよう、窓口と初動を事前に示すことも運用の一部です。

料金だけでは判断できません。仕事の情報を扱うか、社内で定めた対象に当たるかで確認します。

承認は用途と利用条件の確認です。個々の回答の正しさを保証するものではないため、用途に応じた確認を続けます。

申請手順自体が複雑で使われない場合は、よくある用途を記入例として示します。情報の区分が分からない申請者向けに相談できる経路も残しておきます。