パイロットはうまく機能した。それは最初から問題ではなかった。デモは成功し、精度は十分に説明可能で、ユーザーからの評判も良かった。それなのに5か月間キューの中で待たされ続け、いつの間にか誰も話題にしなくなった。誰かが止めたわけではない。ただ期限切れになったのだ。これを2度目撃したことがあるなら、おそらく組織が壊れていると結論づけているだろう。だが私はもっと物足りない説明を主張したい。そのパイロットは、誰もブロッカーとして待っていなかった問いに答えるようスコープされていたのだ。

デモが答えるのは「このモデルはこれができるか」という問いだ。組織はその点について不安を抱いたことは一度もない。組織が分かっていないのは、モデルが誤った場合に誰が責任を負うのか、データがどこへ行くのか、更新時に何が起きるのか、誰がサインするのかということだ。これらの問いにはそれぞれ担当者がいて、その担当者にはそれぞれのキューがある。そして誰一人としてあなたのパイロットが来ることを予期していなかった。

調達は悪者ではない

エンジニアリング側の解釈では、調達は一種の税金だ。リスクを嫌う人々が明白な価値の実現を遅らせている、というわけだ。この解釈は心地よいがほとんど間違っており、それを持ち続けるのは高くつく。なぜなら、自分が不当だと決めつけたプロセスの周りを設計することはできないからだ。

調達とは、会社がこの案件と3年間付き合っていけるかを問う機能だ。調達が発する一つひとつの問いは、過去のインシデントをコード化したものであり、たいていはあなたが入社する前に起きたものだ。買収されて価格を3倍にしたベンダー。何を保持しているかの棚卸しがなかったせいで被害範囲を特定できなかったデータ漏洩ツール。たった2人しか使っていない製品の契約が自動更新されてしまったケース。これらはフォームを審査する人にとって仮定の話ではない。フォームが存在する理由そのものだ。

この摩擦は実在するものであり、その一部は本当に無駄でもある。しかし、進みの遅いゲートに対する正しい対応は、良い答えを用意して早めに入ることであり、そのゲートが存在しないことを願うことではない。

実際に物事を止める4つのゲート

セキュリティレビュー

アンケートが本当に問うているのはベンダーのTLS設定ではない。そのツールが何に到達できるのか、誤動作したときに何が起きるのかを確認しようとしているのだ。AIツールはここで構造的な理由から評価が悪くなりがちだ。役に立つためには広い読み取りアクセスを要求するからだ。「テナント内のすべてのドキュメントを読み込んで質問に答えられるようにする」というのは正当な製品要件であると同時に、本当に警戒すべきアクセス要求でもある。この2つは同時に真だ。

このゲートを通過するパイロットとは、権限モデルを一文で説明できるものだ。デフォルトで読み取り専用とし、書き込みアクセスは別途明示的な同意を必要とするステップにする方が、両方をひとつのスコープでまとめるよりも、監査ログがどれほど優秀であっても本質的にレビューが容易になる。ツールが自らの被害範囲を説明できなければ、セキュリティチームはそれを、6週間かけて、文書のやり取りを通じて、じわじわと見つけ出すことになる。

データ処理契約

実のところ、多くのAIパイロットはここで死ぬ。そして死因はただ一つの問いだ。「我々のデータはあなたのモデルの学習に使われるのか」。

答えが一段落かかるようなら、実質的にそれは「イエス」であり、法務はそう読み取る。DPAには再委託先の名前、日数単位で示された保持期間、解約時の削除条件が必要であり、学習に関する問いには一つの条項で答えなければならない。曖昧な言い回しを一つ加えるたびにレビューサイクルが1つ追加され、そのレビューサイクルはそれぞれ2週間かかる。読んでいる担当者には他に40件の案件があるからだ。

さらに問題を悪化させるのは、AIベンダーがDPAの想定するペースよりも頻繁に再委託先を変更することだ。モデルプロバイダーの切り替えは契約の修正条項を要する。そしてその修正条項を誰も計画に入れていない。

AI特有のオーバーレイ

この1年ほどの間に新しく登場し、まだ運用が一貫していないのが、リスク分類、人間による監督の説明、自社の義務を理解している証拠を求める社内のAIレビューだ。これが存在する組織では、担当者にまだ余裕がある分、しばしば最も速いゲートになる。まだ存在しない組織では、それでも同じ問いがその場しのぎで、気づいた誰かによって、最悪のタイミングで投げかけられることになる。8月2日の透明性義務が発効するにつれ、このゲートはより多くの場所で正式化されていくはずだ。そしてそれは改善だと考えてよい。定義されたキュー付きのゲートは、運営委員会で唐突に持ち出される未定義の異議よりもましだからだ。

予算の所有権

最も静かな殺し屋だ。パイロットは誰かの裁量予算か無料枠で動く。しかし本番運用には、明確な費目、コストセンター、そして次のサイクルでそれを守り抜く担当者が必要になる。パイロットのスポンサーが予算保有者ではなく熱意あるエンジニアだった場合、結果がどうであれパイロットから本番への道筋は存在しない。そしてこれは、注意して見ればたいてい初日から見えている。

なぜパイロットそのものが罠を仕掛けているのか

パイロットは始めやすいように設計されており、それを始めやすくしている要素こそが、それを終わらせられなくしている要素でもある。合成データや無害化されたデータを使えば、DPAの問いは決して生じない。サンドボックステナントを使えば、アクセスモデルは決してレビューされない。無料枠を使えば、予算の担当者は不要になる。熱意あるチームであれば、責任の所在を問われることもない。

これらの選択はどれも、ゲートを通過するのではなく先送りしているにすぎない。そしてパイロットが成功すると、4つのゲートが一斉にやってくる。しかもそれは、誰もが難しい部分は終わったと信じ、残る作業は事務手続きだけだと思っている瞬間にだ。組織は本番運用に向けて1ミリも前進しておらず、その上いま失望まで抱えることになる。

パイロットをゲートに合わせてスコープする

解決策はパイロットにガバナンスを増やすことではない。成功すればデプロイを阻む問いに答えられるようなパイロットを選ぶことだ。

  • 実データを実テナント上で、可能な限り小さいスコープで使う。1つの部署、本番データ、実際の権限モデル。3人のユーザーで実データを使うパイロットは、300人で合成データを使うパイロットよりも多くのゲートを通過する。約束ではなく答えを生み出すからだ。
  • DPAは12週目ではなく1週目にレビューさせる。デモの前に法務へ送る。学習に関する条項が問題なら、四半期分ではなく1通のメールの代償でその結果を知ることができる。
  • 始める前に予算の担当者を指名する。誰もその費目を持つ気がないなら、パイロットをリサーチとして実施し、そうはっきり口にする。それは正当なことだ。正当でないのは、それを本番への道筋だと呼ぶことだ。
  • アンケートが届く前にセキュリティの回答を書いておく。権限モデル、データフロー、再委託先、保持期間、削除。1ページで十分だ。6週間の遅延の大半はやり取りの往復であり、往復は作業ではなくレイテンシだ。
  • ゲートは開発と並行して進める。これらはキュー律速であって工数律速ではない。法務がDPAを読むのに、あなたのコードが存在している必要はどこにもない。

これによりパイロットの開始は遅くなるが、完了する見込みは劇的に高まる。このトレードオフは、一度パイロットを失って初めて明白になる。反論も正当だ。探索的な作業にゲートを前倒しで課すと、探索そのものを殺してしまうし、安く早く死ぬ実験であるべきパイロットも中にはある。それでいい。ただ、自分がどちらの種類を実施しているのかは正直であるべきだ。私がここで述べている失敗は、悪い実験ではないからだ。それは誰もがデプロイ計画だと誤解した、良い実験なのだ。

結論

AIパイロットが精度のせいで死ぬことはめったにない。デモが誰もブロッカーとして待っていなかった問いに答え、セキュリティレビュー、DPA、AIオーバーレイ、予算の所有権が最後まで手つかずのまま放置され、そして一斉にやってくるから死ぬのだ。調達は妨害ではない。組織がこの案件と3年間付き合っていけるかを問うているのであり、その問いはあなたがスケジュールしていようがいまいがやってくる。パイロットは、成功がゲートの通過を意味するようにスコープしよう。出荷にこぎつけるチームとは、より優れたモデルを持つチームではない。1週目から12週間の時計を動かし始めたチームだ。

次に読む

この話のインフラ版、つまりプラットフォーム移行がなぜ同じキューで止まるのかについては、ercan.cloudのフィールドノートを参照してほしい。ハブはercanermis.comだ。