AIサービスは、契約と初期設定の後も、利用規約、モデル、料金、業務ルール、職員、連携先が変わります。担当者を置く目的は、AIが「半永久的に続く」と断定することではなく、利用している期間の変更と事故へ対応できる状態を作ることです。
本記事は特定事務所の実話や、複数事務所を観察した結果ではありません。運用責任を決めるための設計例です。
一人の「AI担当」ではなく、判断を分ける
役割名や人数に唯一の正解はありません。少なくとも次の三種類の判断が、誰の責任かを決めます。
業務責任
- AIを使う業務と使わない業務を決める
- 顧客・案件ごとの入力条件を確認する
- 出力を誰がレビューし、顧客へ出すかを決める
- 導入前後の時間、品質、差し戻しを測る
技術責任
- サービス、プラン、契約、設定、連携を管理する
- アカウント、APIキー、権限、ログを管理する
- 変更時の試験と戻し方を用意する
- 障害時にベンダーへ問い合わせる
セキュリティ・コンプライアンス責任
- 個人情報、守秘義務、契約、所属会規程を確認する
- 入力、保存、共有、削除のルールを点検する
- 監査ログと権限変更を確認する
- 事故時の停止、調査、報告判断を統括する
三つを別人へ割り当てる必要はありません。ただし、同じ人が実装と承認を兼ねる場合は、別の人による重要変更の確認など、自己点検だけにしない方法を検討します。
規模ではなく工数とリスクで兼任を決める
旧稿では「5〜10名」「10〜30名」「30名超」といった人数で役割を分けていましたが、その閾値を裏付ける検証記録を確認できなかったため撤回しました。
兼任できるかは次で判断します。
- 対象業務と利用者数
- 利用サービスと連携先の数
- 扱う情報の機微性
- 設定・規約・法令の変更頻度
- ログ点検、教育、問い合わせに必要な時間
- 事故時に止める権限と代替担当者
担当者を任命するだけでなく、月に使える時間、定例作業、判断期限、代理者を明記します。点検周期にも一律の月次・年次を置かず、変更量と事故・逸脱の状況から決めます。
任命時に残す文書
- 対象AIサービス、契約主体、管理者
- 業務ごとの利用可否とレビュー責任者
- 顧客データを入力する条件
- アカウント・権限・APIキーの一覧と失効手順
- モデル・設定変更時のテストとロールバック
- ログの項目、点検者、保存期間、削除条件
- インシデント時の連絡先、停止権限、報告判断者
- 退職・異動・委託終了時の引き継ぎ
文書の長さではなく、現在の担当者以外が手順を実行できるかを確認します。架空アカウントで、停止・権限変更・ログ確認・復旧を試験します。
担当不在を想定したテスト
次は事故実績ではなく、運用テスト用の仮想シナリオです。
- 主担当者が不在でも、AIサービスを停止できるか
- 退職者のアカウントと連携トークンを失効できるか
- 誤った顧客情報を入力した場合に、記録と共有先を特定できるか
- モデルや設定変更後に、重要な出力を再確認できるか
- 契約変更を、利用ルールと職員教育へ反映できるか
テスト結果から担当者、工数、手順を修正します。「役割がある」ことと「実際に動ける」ことを分けて確認します。
関連記事
参考
本記事は一般的な運用設計の情報であり、ShigyoAIの導入実績、運用継続率、規模別の成功条件を示すものではありません。