組織が責任あるAI利用に関するポリシーを公開し、それに行動が従うと想定するだけでは不十分だ。開発者は納期のプレッシャーの下で働き、不明確な問題に直面している。そのため、公式の経路が遅かったり、エンジニアリング業務の詳細から切り離されているように見えたりすると、未承認のツールに頼ることがある。そこで、Stack Overflow Blogに掲載された記事は、中心的な考えとして、「隠れたAI」を抑えるには、学習ポータルに別の文書を追加するのではなく、ワークフローを設計することから始めるべきだと述べている。
この記事は、AI導入と開発者の信頼に関するStack Overflowの結果に基づいている。回答者の84%がAIツールを利用している、または利用を計画していると答えた一方、これらのツールの正確性を信頼していない開発者の数は、信頼している開発者の数を上回った。ほぼ正しいように見えた後、追加の修正が必要になる出力は、主な不満の原因の一つだった。
未承認の利用はワークフローの不備を示すシグナル
記事は、管理者が未承認の利用を、すべて要件を満たしたコンプライアンス違反として扱うべきではないと提案している。エンジニアが機密性の高い情報を一般向けモデルにコピーしたり、許可されていないコーディングアシスタントをインストールしたりする場合、それは承認済みの経路がタスクの完了に必要なデータ、コンテキスト、統合、または権限を提供していないことの兆候かもしれない。
実務的な対応は、診断的な質問から始まる。開発者を外部ツールへ向かわせているタスクは何か。承認済みの代替手段を妨げている摩擦は何か。全面的な禁止で阻止しようとするのではなく、承認済みのプラットフォームと利用を記録する監視ゲートを通じて実験を可能にできないか。この観点では、非公式な利用は、従業員に実験を隠すよう強いる自動的な理由ではなく、組織がシステムを改善する助けとなる証拠になる。
ポリシーをエンジニアリング・インターフェースへ変える
優れたポリシーは目的を定めるが、優れた運用はそれを、開発者が日常業務中に判断できる形へ変換する。記事は、NISTのAIリスク管理フレームワークの機能である、ガバナンス、特定、測定、管理に言及している。実務上、ルールは、ユースケースの分類方法、許可されるモデルとデータソース、結果のテスト方法、承認に責任を持つ部門、開発記録に保存すべき証拠を明確にすべきだ。
ポリシーが直接答えるべき質問には、次のようなものがある。各ツールに入力できるデータは何か。ツールがアクセスを許可されるリポジトリまたはシステムはどれか。生成コードに必要なレビューの水準はどの程度か。人間の意思決定者による介入が必要になるのはいつか。有害、安全でない、または信頼できない出力を開発者はどのように報告するのか。実験が本番システムへ移行するのはいつか。記事は、セキュリティとプライバシーが開発者が技術を拒む主な理由の一つだと述べている。そのため、明確なルールは不確実性を減らし、導入を支える要因になる。
業務が行われる場所に統制を置く
トレーニングポータルに保存されたポリシーは、統合開発環境に組み込まれたアシスタントと競うのが難しい。そのため記事は、リポジトリ、プルリクエスト、ビルドパイプライン、アクセスシステム、デプロイワークフローに統制を置くことを提案している。例として、承認済みモデルの設定をバージョン管理システムに保存すること、役割に応じてアクセスを制限すること、シークレットを検出するためにプロンプトと出力を検査すること、リスクの高いユースケースでログを保持すること、生成された変更をマージする前にテストを強制することが挙げられる。
また、「AIの出力をレビューする」という表現は、機能チェック、コンテキストへの適合性の確認、依存関係のレビュー、必要に応じた複数人によるレビューなど、再現可能な手順へ変換すべきだ。すべての利用に一律の承認レベルが適しているわけではない。コードを説明するツールと、本番システムへの書き込み権限を持つエージェントでは、リスクが異なる。記事は、生成AIアプリケーションに関するOWASPのリストから、プロンプトインジェクション、機密情報の漏えい、サプライチェーンの脆弱性、出力の不適切な処理、過剰な権限などのリスクを挙げている。
説明責任、トレーニング、測定
利用ごとに明確な人間の所有者を任命すべきであり、その人物は求められる結果を理解し、プロセスを停止または変更する権限を持つべきだ。提案されている分担によれば、製品リーダーはビジネス上の判断を担い、エンジニアリングリーダーは実装の品質を担い、セキュリティとプライバシーの専門家は適切な統制を定める。一方、開発者は提出するコードに責任を持ち、レビュアーは承認の判断を担い、運用担当者は監視とインシデント対応を担う。
記事はまた、一般的な啓発セッションではなく、開発者が実際に行う判断に結び付いたトレーニングを呼びかけている。内容には、承認済みツール、許可されるデータ、失敗パターン、レビュー要件、エスカレーション経路、組織の環境からの例を含めるべきだ。トレーニングは、リポジトリの指示、レビューチェックリスト、テストセット、承認済みのプロンプトパターン、文書化された例など、ワークフロー内で利用できる要素を生み出すべきである。証明書は出席を証明するが、行動に影響を与えるのはこれらの要素である。
成功の測定は、ライセンス数、プロンプト数、アクティブユーザー数だけに限定すべきではない。記事は、ツール導入前後のワークフローを比較し、サイクルタイム、本番に到達する欠陥、ロールバック、セキュリティスキャンの結果、レビュー負荷、ドキュメントの品質、インシデント、開発者満足度、出力の修正に費やした時間などの指標を用いることを提案している。この点は特に注目に値する。2024年のDORAの結果は、導入率の高さをドキュメントとコードの品質向上、レビュー速度の向上と結び付けた一方、ソフトウェアデリバリーのパフォーマンスに潜在的な悪影響も確認した。また、Stack Overflowの調査は、エージェントによって個人の生産性が向上する可能性がある一方、チームの協働では同様の向上がないことを示した。
certi.newsによる編集部の読み解き
この記事が提案する実際の変化は、新しいポリシーの文言ではなく、責任を文書のレベルからツールとプロセスのレベルへ移すことにある。安全な経路が利用可能になるのは、承認済みツール、有用なコンテキスト、明確な境界、迅速なエスカレーション、データの機密性、自律性の程度、影響の可逆性に応じた統制を提供するときだ。
これは人間の判断をなくすための処方箋ではない。判断を開発サイクルの目に見える一部にする試みである。提案の有効性は、各組織がユースケースを特定し、実際の結果を測定できる能力に左右される。また、記事に示された数値は複数の研究と調査の結果を要約したものであり、それだけで、すべての開発環境が同じ結果を得ることを証明するものではない。