規制業界におけるカスタムLMの検証とリリース

リリースサイクルからの覚書 — 第IV部

法務顧問がエンジニアリングレビューに姿を現します。彼女の質問はひとつです。「明日、EU AI法第17条の消去権リクエストが届き、特定の患者についてモデルが学習したあらゆる事実を削除せよと求められたら、私たちは実際に削除したことを証明できますか?」

ほとんどのチームが正直に返せる答えはこうです。「モデルをファインチューニングして忘却させることはできます。学習ランも提示できます。しかし、その情報が構造的に消えていることは証明できません。敵対的なプロンプト次第で再浮上する可能性があるからです。」

これはコンプライアンスの答えではありません。手続き上の肩すくめで終わる、非回答です。

本投稿が扱うのは、カスタムLLMにとって本物のコンプライアンスの答えがどのような形をしているか、という点です。4つの規制フレームワーク(EU AI法、GDPR第17条、HIPAA、NIST AI RMF)を、顧客リリース向けに当社が出荷する4段階パイプライン(登録 → ゲート → ロール → 観察)にマッピングします。すべての規制当局の要請を貫く根本的な緊張は、オープンウェイトとクローズドAPIの対立です。Gemma 4ファインチューンについて証明できることと、不透明なベンダーAPIの背後で提供されるリリースについて証明できることは別物です。当社が用いるレシートフォーマットは、その違いを一行ずつ明示的に述べます。その正直さこそが、レシートを監査人にとって有用なものにします。

4つの規制当局と、それぞれが実際に求めていること

コンプライアンスの議論は「文書化しました」で済まされがちです。その枠組みは監査人には通用しません。監査人が求めるのは、あなたのインフラを信頼しなくても検証できる証拠です。以下の4つのフレームワークは、同じ根本的な要請を異なる語彙で表現しています。

これらのフレームワークを興味深いものにしているのは、制裁金の数字ではありません。制裁金の数字は、これらを荷重を担う存在にしているだけです。興味深いのは検証プリミティブ、つまり各フレームワークが実際にアーティファクトに対して求める形です。4つのうち3つは異なる語彙で暗号学級の証明を要求します。4つ目(NIST AI RMF)は任意ですが、企業調達では事実上必須となっています。これらはすべて同じ形に収束します。あなたのログを信頼しなくても監査人が検証できるアーティファクトです。

分岐点:オープンウェイト対クローズドAPI

ステージ単位のマッピングに入る前に、本投稿全体で最も重要な留保事項を述べます。

オープンウェイトのモデルバッキングについて — Gemma、Qwen、Llama、Mistral、GPT-OSSなど、重みがアドレス可能で編集可能なものすべて — Divinciのリリース決定は、重み証明(decision timeにアクティブな重みが、マニフェストが登録した重みと厳密に一致することの暗号学的証明)を含むvindexレシートを発行します。これがGDPR第17条の検証可能な消去を可能にする仕組みです。重み空間から特定のエンティティ-関係を取り除くDELETEパッチを適用し、レシートにbefore/afterハッシュを埋め込み、監査人は公開vindexに対して検証を再実行することで削除が実際に行われたことを確認できます。

クローズドAPIのモデルバッキングについて — OpenAI、Anthropic、Googleなど不透明なAPI経由のもの — 同じレシートが決定チェーン(どのマニフェスト、どのゲート結果、どのモニター読み取り、どのユーザーがどのアクションをトリガーしたか)をカバーしますが、重みの出所を主張することはできません。プロバイダーが重みを公開していないからです。レシートはこれをweight_attestation: nullフィールドと、その理由を説明するnoteで明示的に示します。これはコンプライアンス姿勢の格下げではなく、検証可能なものの限界を正直に書き留めたものです。レシートを読む監査人は、どの種類の証明が行われていて、どれが行われていないかを正確に理解します。

この分岐は、以下のすべての規制当局の要請を貫いています。フレームワークが重みレベルで何かを要求するときはいつでも、オープンウェイト経路はそれを満たすことができ、クローズドAPI経路はできません。当社は提供できない証明を匂わせるのではなく、レシートでそう述べます。

各フレームワークが4つのパイプラインステージにどうマッピングされるか

パイプラインには4つのステージがあります。各規制当局の要請は、そのうち1つ以上にマッピングされます。以下のマトリクスが実際のマップです。

2つの◐セルがGDPR第17条/オープンウェイト専用エントリです。これらはクローズドAPI経路が完全には満たせない要請です。それ以外はどちらのバッキングにも該当します。

本投稿の残りでは、各ステージの貢献を順に取り上げます。

ステージ① — 登録

登録ステージは、SHA-256でアドレス付けされたイミュータブルなJSONマニフェストを生成します。規制対象リリースの場合、マニフェストは附属書IV^[1]が求めるすべてを1つのアーティファクトに収めます。

• モデルアーティファクト(HFリポジトリ + コミットSHA、またはvindexパッチ参照)
• プロンプトテンプレート(すべての変数、すべてのシステムメッセージをバージョン管理)
• ルーティングルール(どのトラフィッククラスがどのリリースに着地するか)
• ゲートしきい値の計算に使用されたデータセットバージョン(学習データのハッシュによる要約)
• 直前リリースのSHA(監査チェーンが途切れないように)
• 開示範囲 — HIPAAデプロイメントの場合、モデルが受領を許可されているPHIカテゴリー

マニフェストが文書そのものです。監査人は散文を読むのではなく、マニフェストハッシュを読み、バンドルを検証します。半年後に書かれた散文要約は不要です。

オープンウェイトの利点。 モデルアーティファクトがオープンウェイトモデルを参照する場合、マニフェストにはvindex_sha256(モデルの公開vindexの暗号学的フィンガープリント)も埋め込まれます。このフィンガープリントによって、第三者は当社のデプロイメントインフラを信頼することなく、アクティブな重みを検証できます。

クローズドAPIの留保。 モデルアーティファクトがクローズドAPIモデルを参照する場合、マニフェストのvindex_sha256フィールドはnull、weight_attestation_classはdecision_chain_onlyとなります。これを読む監査人は、何が主張されていて何がそうでないかを正確に把握します。

ステージ② — ゲート

ゲートステージはEU AI法の「人間による監督措置」^[1]を運用化する場所です。EU AI法を読んで「人間の承認ワークフローが必要だ」と結論する規制担当者は要点を外しています。難しい問いは、人間が何に対して承認するのかです。ゲートステージはその問いに、人間アンカー付き採点者^[3]に対するスライス単位のスピアマンρで答えます。あなたの規制姿勢で重要なスライス(小児腫瘍、IPライセンシング、ベルギーフランス語)はそれぞれ独自のしきい値を持ちます。オーバーライド経路には、監査証跡に残る文書化された根拠が必要です。

HIPAA対象のデプロイメントでは、「最小必要限度」開示ルールもここに存在します。ゲートのスコア付きQAスイートには、PHI過剰露出の負例テスト — 何も求められていないのに個人識別子を含む回答 — が含まれます。過剰露出スライスで後退するリリースは、他のスライスのパフォーマンスにかかわらず、ゲートで失格となります。

NIST AI RMFについては、ゲートステージが「測定」機能をカバーします。システムが設定された許容範囲内で動作していることをスライス単位の数値証拠で示します。

ステージ③ — ロール

EU AI法の市販後監視^[1]は、運用者がAIシステムの実環境でのパフォーマンスを継続的に(打ち上げ前だけでなく)観察していることを示すよう求めます。5% → 25% → 100%のカナリアと品質モニターチェックポイントの組み合わせは、これを満たす最も自然な方法です。各チェックポイントでの滞留時間と、滞留中のモニター読み取りこそが監査人が確認したいものです。

HIPAAについては、カナリアステージはリクエスト単位の監査ログがエンドツーエンドで実行される場所でもあります。各チェックポイントは署名済みリクエスト-レスポンスレシートのサンプルを生成します。いずれかでPHI処理の設定誤りがあれば、100%のトラフィックではなく5%のトラフィックで表面化します。

ステージ④ — 観察

このステージこそがコンプライアンスのストーリーを成立させます。観察ステージは、アクティブなリリースに対して継続的にトレースリプレイを実行し、ゲートと同じ人間アンカー付き判定者で採点し、しきい値を破ると自動ロールバックをトリガーする品質モニターを備えます。

すべてのリリース決定 — 登録、ゲート通過、ゲート失敗、ゲートオーバーライド、チェックポイント昇格、チェックポイント保留、自動ロールバック、手動ロールバック、そしてあらゆるGDPR第17条DELETEパッチの適用 — がvindexレシートを発行します。この顧客の前のレシート、およびこのリリースの前のレシートとハッシュ連結されます。

以下は、GDPR第17条DELETEパッチに対する実際のレシートの姿です。コンプライアンスページに文書化されているフォーマットからそのまま引用しています。

{
  "name": "gdpr-art17-patient-12348-removal",
  "version": 1,
  "base_model": "google/gemma-4-E2B-it",
  "manifest_sha256": "9abaeaf6c91f8b...",
  "previous_manifest_sha256": "8f72b1de4a93c5...",
  "created_at": "2026-05-29T03:17:42Z",
  "user_id": "compliance-officer-7c4e1a",
  "operation": {
    "op": "delete",
    "entity": "patient-record-12348",
    "relation": "diagnosis-association",
    "target": "weight-feature-11179-layer-27",
    "weight": -1.0
  },
  "verification": {
    "before_feature_11179_score": 17.34,
    "before_feature_11179_rank": 1,
    "after_feature_11179_score": null,
    "after_feature_11179_rank": "ABSENT_FROM_TOP_25",
    "perplexity_delta_wikitext103": "+0.02%",
    "vindex_sha256_before": "abc12...",
    "vindex_sha256_after":  "def34..."
  },
  "weight_attestation_class": "full",
  "chain_signature": "sha256(manifest || prev_manifest || user_id || created_at || prev_chain_signature)"
}

このアーティファクトは検証可能です。監査人は当社のログを信頼する必要がありません。vindex_sha256_afterを取り、対応する公開vindexをhuggingface.co/Divinci-AIから取得し、レイヤー27の特徴量11179が上位25から構造的に欠落していることを確認します。chain_signatureを取り、前のレシートに対して検証します。チェーン全体が顧客の設定するスケジュールで外部にアンカーされます。

クローズドAPIモデルに対する同じ操作。 上記のレシートフィールドは3点で変わります。operation.targetはprovider_api_endpointになり、verificationは決定チェーン証拠のみをカバーする別のスキーマになり、weight_attestation_classはdecision_chain_onlyになります。クローズドAPIモデルプロバイダーは重みを公開していないため、レシートはそう述べます。重みレベルの証明を望む監査人は、当社ではなくプロバイダーにエスカレーションすべきだと知ることになります。

これが2026年に他社が出荷していない差別化要因です。評価CI陣営(Braintrust、Humanloop、Patronus)はトラフィックに座らず、決定レシートを発行しません。サービングカナリア陣営(SageMaker Deployment Guardrails^[2]、KServe、Vertex、BentoCloud、Seldon)はインフラメトリックログを発行しますが、ハッシュ連結されたコンプライアンスレシートではありません。可観測性陣営(Arize、Phoenix、Confident、Deepchecks)は出力を監視しますが、強制はしません。

監査人は実際に何を検証するのか?

有用な演習として、実際の監査人が問う質問と、それに答えるアーティファクトを順に追ってみましょう。

監査人がする必要がないこと: 当社のDatadogを信頼する。CloudWatchを信頼する。スクリーンショットを信頼する。エクスポートを信頼する。レシートフォーマットの要点は、監査人が独立して検証できる点にあります。

これでは解決しないこと

正直な制約を3つ挙げます。

GDPR第17条領域でのクローズドAPI後退は、プラットフォーム層では解決できません。 クローズドAPIモデルの背後で医療アシスタントを提供していて、患者が第17条を行使した場合、プラットフォームは患者の記録が検索ストア、プロンプトテンプレート、ルーティングルールから削除されたことを証明できますが、基盤モデルの重みが患者のデータを忘却したことは証明できません。オープンウェイトのバッキング、もしくはベンダーによる重みレベル消去のコミットメントが必要です。当社はそれをレシートで明示します。

文書化は必要条件ですが、十分条件ではありません。 モデルがしきい値を満たしたことを証明するレシートは、そのしきい値が正しいしきい値だったことを証明しません。スコア付きQAスイートが、あなたのサービス内の患者にとって実際に重要なスライスをカバーしていなければ、いくらレシートを連結してもそれは直りません。規制当局はこれを次第に理解しつつあります。評価が間違った評価であった場合、「私たちは評価を通過しました」はもはや十分なコンプライアンスの答えではありません。

vindexフォーマットは単一ベンダー仕様です。 当社はこれを採用しています。今日、重みレベル証明に利用可能な最も具体的な暗号学的プリミティブだからです。業界が別のフォーマット — ハッシュ付きモデルカード、NIST公開アーティファクトスキーマなど — に収束するなら、レシートフォーマットはそれに合わせて進化させるべきです。荷重を担うのは実体(ハッシュ連結、外部検証可能、重み証明対応)であって、特定のスキーマ名ではありません。規制と標準の地形が成熟するにつれ、これは変化することを予期しています。

FAQ

AIシステムにおけるGDPR第17条の検証可能な消去とは何ですか?

検証可能な消去とは、第三者があなたのログを信頼することなくデータが削除されたことを検証できることを意味します。モデルをファインチューニングして特定の情報を「忘却」させることは、この基準を満たしません。情報は敵対的プロンプト下で再浮上する可能性があり、監査人が確認できる暗号学的プリミティブが存在しないためです。before/afterのvindexハッシュを公開した重みレベルのDELETEパッチならこの基準を満たします。監査人が公開アーティファクトに対して検証を再実行できるからです。

なぜクローズドAPIモデルは同じ方法でGDPR第17条を満たせないのですか?

プロバイダーが重みを公開していないからです。重みにアクセスできなければ、APIを利用する顧客を含むいかなる第三者も、重みレベルの消去を発行または検証することはできません。レシートの決定チェーン部分(どのプロンプトテンプレートが使われたか、データはどの検索ストアから来たか、どのルーティングルールが有効だったか)は依然として検証可能ですが、重みレベルの主張は不可能です。これは重みが非公開のときに何が検証可能かの限界であり、コンプライアンスフレームワークの限界ではありません。

EU AI法附属書IVは平易な言葉で言うと何を要求しますか?

附属書IVは、システムの論理、学習データの要約、意図された用途、人間による監督措置、市販後監視をカバーする技術文書を要求します。ほとんどのチームが陥る罠は、これらを5つの別個の文書として扱うことです。ステージ1のリリースマニフェストは最初の3つの要請を1つのハッシュとして担います。ゲートステージは4つ目をカバーします。ロールと観察のステージは5つ目をカバーします。1つのパイプライン、4つの要請が通常運用の副産物として満たされます。

HIPAA対象デプロイメントのロールバックはどれくらい速くあるべきですか?

HIPAAはロールバック時間を規定していませんが、侵害対応に関するHHSのガイダンスは封じ込めまでの時間を荷重を担う指標として扱います。秒オーダーでのロールバック(マニフェスト駆動のフリップでイン-フライトをドレイン — 当社の数字は約12秒)は、アラーム伝播に依存する典型的なインフラメトリックブルーグリーンよりも構造的に高速です。公開ポストモーテムと比較してみましょう。Cloudflareの2022年6月のインシデント^[4]では、エンジニア同士が互いのリバートに踏み込んだため、リバートまでに44分を要しました。

NIST AI RMFはリリースパイプラインにどうマッピングされますか?

NIST AI RMFの4つの中核機能 — ガバナンス、マッピング、測定、管理 — は単一ステージではなくリリースライフサイクル全体に及びます。ガバナンスは文書化されたリリースポリシーとゲートオーバーライドの根拠ワークフロー(登録 + ゲートステージ)です。マッピングはスライス単位のスコア付きQAスイート(ゲート)です。測定はスライス単位のスピアマンしきい値と継続品質モニター(ゲート + 観察)です。管理はロールバック経路とレシートチェーン(観察)です。パイプラインが完全なレシートセットを発行するとき、4つすべてがカバーされます。

References

1. EU AI Act. artificialintelligenceact.eu. Annex IV defines the technical documentation requirements for high-risk AI systems: system logic, training data summary, human oversight measures, post-market monitoring. Penalties up to 7% of global turnover for non-compliance.
2. AWS SageMaker Deployment Guardrails. Use canary traffic shifting + Auto-Rollback Configuration. Default TerminationWaitInSeconds 600, max MaximumExecutionTimeoutInSeconds 1800. Cited as the industry-standard infra-metric canary that the Stage 4 quality monitor is contrasted against.
3. Calibrated LLM-as-judge agreement. Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (NeurIPS 2023). >80% overall GPT-4-vs-human agreement, with per-category variance from coding (86%) down to writing (36–44%). Anchor for the per-slice Spearman calibration that drives the Gate stage.
4. Cloudflare June 2022 outage. Cloudflare outage on June 21, 2022. 44 minutes from "we know what to revert" to revert complete because engineers walked over each other's reverts. Anchor for the "manifest-driven rollback can't have that failure mode" claim.
5. NIST AI Risk Management Framework. NIST AI RMF. Voluntary framework — Govern, Map, Measure, Manage — that has become the de facto enterprise procurement baseline for AI governance. Voluntary but enforced in practice through customer due-diligence questionnaires.
6. HIPAA Privacy Rule. HHS Office for Civil Rights. Minimum-necessary disclosure, access audit, and breach response timing requirements applicable to any AI system that touches PHI. Civil monetary penalties up to $1.9M per violation-type per year per CMP inflation adjustment, 2025.
7. GDPR Article 17 (Right to Erasure). gdpr-info.eu/art-17-gdpr. The data subject's right to obtain erasure of personal data, and the controller's obligation to demonstrate compliance under Article 5(2) accountability. Penalties up to €20M or 4% of annual global turnover.
8. Internal — vindex receipt format. The receipt JSON in this post is adapted from the format documented on the compliance page and demonstrated in the "Deleting Paris from a Language Model" post. The hash chain is SHA-256 over manifest || prev_manifest || user_id || created_at || prev_chain_signature. Externally anchorable on a customer-configured schedule.

本シリーズの次回: インスタントロールバック付きの自動LLM CI/CDパイプライン。 本投稿は監査人が求めるものを示しました。次回は、レシートが数週間ではなく数秒で監査人の机に届くことを可能にする運用パターン — 4段階パイプラインの下にある自動化、特にロールバックが自律的に発火したときに何が変わるかに焦点を当てた話 — を示します。