大規模言語モデル（LLM）に依存するシステムが実データを扱ったり、影響力のある意思決定を行ったりし始めると、「たいてい動く」という表現はもはや受け入れられる基準ではない。Stack Overflow Blogの記事は、LLMシステム成熟度モデルの第4段階において、相互に関連する4つの実践、すなわち多層のセーフガード、システムの各境界での個人データの制御、改ざん不能な監査台帳、明確な範囲に制限されたメモリによって、安全性とガバナンスをアーキテクチャ自体に組み込むことを提案している。
単一の保護ポイントではなく多層のセーフガード
記事は、モデル出力に対して単一のフィルターだけに依存することを批判し、各セーフガードを独立してテストおよび順序付けできる小さなソフトウェア契約にすることを提案している。リクエストは、入力とプロンプトインジェクションの試み、グラウンディングの制約と出力形式、ポリシー違反や個人データに関する結果のサニタイズ、業務ルールの検証を調べる層を通過する。さらに、正しそうだが誤っているケースには二次判定を用い、最後に信頼度を評価して、意思決定を実行するのか、または人間にエスカレーションする必要があるのかを決定する。
基本原則は「停止側にフェイルする」ことである。セーフガードが故障したり利用できなくなったりした場合、リクエストを自動的に通過させてはならない。また、すべてのブロック処理を運用上のシグナルとして記録すべきである。指標の突然の増加は、攻撃、リリースの劣化、またはデプロイの不具合を意味する可能性があるためだ。記事は、実効性のある制約によって許可されない出力を表現不可能にする必要があり、モデルが回避できるテキスト指示だけに依存してはならないと強調している。
個人データは境界で処理する
システムコンポーネント間のあらゆる移動はセキュリティ境界となる。データの受け入れ、モデルへの送信、ログや意思決定台帳への書き込み、別のサービスへの引き渡しがこれに含まれる。記事は、機密性の中央分類を推奨し、未知のフィールドはデフォルトで個人データとして扱ったうえで、各境界を越える前にデータを削除、秘匿化、または分割することを求めている。
意思決定台帳では、意思決定の根拠を証明するために機密ペイロード全体を保存すべきではない。代替策は、テナントごとに固有の鍵を用いたHMACによるkeyed hashと、編集済みの要約である。記事は、メールアドレスやカード番号のようにランダム性の低いデータに通常のSHA-256を使用すると、逆方向の推測が可能になると指摘している。また、再ハッシュ時に同じ結果が得られるよう、JCS仕様などの正規化された固定的なJSON表現を採用する必要がある。
単にログを保存するのではなく履歴を証明する監査台帳
記事は、デバッグには適しているもののローテーションされたり、構造化されていなかったりする運用ログと、すべての意思決定およびその理由だけを記録する付属の監査台帳を区別している。この台帳には、意思決定の識別子、テナント、権限、モデル・プロンプト・意思決定・信頼度・ルーティング経路の各バージョンに加え、編集済みの要約とハッシュ化された入力が含まれる。
訂正によって以前の記録を変更するのではなく、置き換える記録を指し示す新しいエントリを作成する。改ざんを検出するため、エントリはハッシュチェーンで連結し、番号の連続性と完全性を検証する。しかし、チェーンだけでは末尾の削除や台帳全体の再構築を防げない。そのため記事は、エントリへの署名と、外部ストレージへの定期的なチェックポイントの公開を提案している。また、同時に行われる2つの書き込みによってチェーンに2つの分岐が生じるのを防ぐため、追加処理はロック下で実行しなければならない。
分類されたメモリと、出荷されるものと取得されるものの境界
マルチテナントシステムでは、メモリは単なる機能ではなく、データガバナンスの問題になる。記事は、テナント共有の知識、エージェント領域、一時的なワークフローコンテキスト、監査台帳、意味知識、ユーザー会話など、分離されたカテゴリーを提案している。各カテゴリーにはアクセス範囲、機密性ポリシー、データストア自体で強制されるパーティションキーを設定し、テナント間の読み取りや書き込みを禁止する。また、あるユーザーの会話を他のユーザーの意思決定エージェントから隔離する。
記事はさらに、チームが出荷する初期データと、システムが取得する運用データを区別している。前者には、プロンプト、ルール、テストセット、グラウンディングデータなどが含まれ、バージョン管理され、実行中は変更できないようにする必要がある。一方、後者には、メモリ、ドリフトシグナル、セッションコンテキストなどが含まれ、監査台帳を削除することなく、定められた範囲内でクリーンアップできる。運用データから抽出された新しい挙動は、後続のリリースに統合する前に、レビューとテストを受けるべきである。記事によれば、学習は追跡不能な副作用ではなく、ソフトウェア変更要求に近いものでなければならない。
なぜこれらの実践が重要なのか
この提案の実務的な価値は、単独のツールではなく、独立した層に信頼を分散させる点にある。出力のサニタイズは業務ルールの検証の代わりにはならず、監査台帳は生データの保持を正当化せず、メモリはベクトルデータベースを使用しただけで安全になるわけでもない。なお、工学的な判断が必要な未解決の制約には、各システムに適したデータカテゴリーの決定、保存場所とアクセスのポリシーの調整、人間によるレビューが必要なケースの特定、メモリのクリーンアップによって意思決定に必要な入力が削除されないことの証明がある。