AIアプリを安全にデプロイするには、公開前に6点を確認します。必要なデータしか読めないこと、利用者全員にロールが割り当てられていること、監査ログが有効であること、実データに近い形のデータでステージング検証済みであること、ワンクリックで前バージョンに戻せること、そして責任者が名前で決まっていること。ひとつでも欠ければ、それはアプリの公開ではなく、誰も見ていないリスクの公開です。
危険なアプリを、わざと公開する人はいません。
デモでは動いた、月曜までに必要だと言われた、そして6つの確認事項がプラットフォームではなく誰かの頭の中にあった。だから起きるのです。
安全なデプロイのための6項目チェックリスト
最初の実ユーザーがログインする前に確認してください。各項目はAgentUIでの実装方法にリンクしています。
機能の範囲より先に、データの範囲を決める
アプリが到達してよいのは、必要なテーブルと列だけです。つなぐのが早いからといって、データウェアハウス全体を開けてはいけません。
仕組みを見る利用者全員にロールを割り当てる
「全員が全部見られる」も一つの判断であり、たいていは誤った判断です。ロールは最初の苦情の後ではなく、公開前に決めてください。
仕組みを見る監査ログを最初に有効にする
水曜に有効化したログから、先週火曜の出来事は再構成できません。実データが入る前にオンにしてください。
仕組みを見る実データに近い形でステージング検証する
サンプルデータは例外を隠します。空の列、重複ID、2019年の行。自社データに似たデータでリハーサルしてください。
仕組みを見るロールバックをプロジェクトではなく1クリックにする
バージョン履歴があれば、まずい変更は事故ではなく手間で済みます。必要になる前に、戻せることを確認してください。
仕組みを見る責任者を名前で決める
持ち主のいないアプリは、全員の問題になるその瞬間まで、誰の問題でもありません。リンクを共有する前に名前を書き留めてください。
仕組みを見る急いで公開した場合と、安全にデプロイした場合
同じアプリの6週間後です。違いを生むのは、初日に何を設定したかだけです。
| 重要になる場面 | 急いで公開 | 安全にデプロイ |
|---|---|---|
| 見てはいけない給与情報を誰かが見る | 数週間後に偶然発覚 | ロールで遮断され、そもそも表示されない |
| レポートの数字がおかしい | 誰が変えたのか誰にも分からない | 監査ログが担当者と時刻を示す |
| 更新でメイン画面が壊れる | プレッシャーの中で作り直し | 昨日のバージョンに戻すだけ |
| コンプライアンスからデータの扱いを問われる | 慌てて経緯を再構成 | ログとアクセス権限表をエクスポート |
| 作った本人が退職する | ツールは静かに朽ちていく | 責任者が明示され、履歴も残っている |
AIアプリの安全なデプロイ：よくある質問
セキュリティ専門チームがなくても、AIアプリを安全にデプロイできますか
6項目のチェックリストを実行すれば可能です。データ範囲の限定、ロールの割り当て、監査ログの有効化、ステージングでの検証、ロールバックの確認、責任者の指名。どれも専門家を必要としません。必要なのは、これらの統制をサービス案件ではなく設定として提供するプラットフォームです。
いちばん多い失敗は何ですか
業務に必要な範囲を超えたデータアクセスを与えてしまうことです。ビューを絞るより、データベース全体をつなぐほうが早かったからです。後から起きるアクセス問題は、ほぼすべてこの最初の近道に由来します。
社内ツールにステージング環境は必要ですか
必要です。しかも使うこと自体に費用はかかりません。サンプルデータでは、実データにある空の列や重複IDは表面化しません。実データに近い形での検証こそ、それらがまだ安上がりなうちに見つかる場所です。
AIが作ったアプリは、手書きのコードより安全性が低いのですか
本質的にはそうではありません。リスクはAIが書いたことではなく、開発者なら習慣として踏んでいたデプロイ手順を、AI製アプリでは飛ばしがちなことです。必要な統制は同じで、違うのは誰かがそれを実行するかどうかだけです。
ここでいう「ロールバック」とは何を指しますか
公開したバージョンはすべて保持されるため、前のバージョンに戻すのは作り直しではなく1クリックです。金曜のまずい変更が、事故ではなく手間で済むようになります。
社内AIアプリの責任者は誰にすべきですか
作った人ではなく、使っているチームの中の特定の担当者です。責任者がいるとは、壊れたときに気づく人がいて、その人に変更する権限があるということです。リンクを配る前に名前を書き留めてください。