AIエージェントは現在、永続的です。彼らは会話、決定、個人情報、規制コンテンツ、手順状態を日々、ツール、テナントを跨いで記憶しています。データを規制する既存のすべての規制レジーム — GDPR Article 17, HIPAA, PIPL, PIPEDA, EU AI Act — は、その記憶に適用されます。当人が、規制機関、または内部ポリシーが「私についてエージェントが覚えていることを消去してください」と要求したとき、「試みました」という答えはできないのです。
この投稿では、データベースの DELETE が消去ではない理由、暗号論的消去 とは何か、SAIHM が AI メモリに対してそれを実装する方法、規制機関が SAIHMs からの協力なしにパブリック ブロック エクスプローラーで単一の消去を検証する方法について説明します。また、既存の AI クライアントに貼り付けて今日忘れを実行し、監査レシートを取得するための 3 つのプロンプトもあります。
1. DELETE は消去ではない理由
規制当局が「データが完全に消去されたことを証明してください」と問いただす場合、通常、「DELETE を実行しました」というだけでは受け入れられません。
関係データベースにおける DELETE 文は、特定の 1 つの処理を行うだけです。つまり、ライブテーブル内の行を削除されたものとしてマークすることです。しかし、現代の運用環境では、行が保存されていたすべての場所からバイトを実際に消去することはありません。バイトは以下の場所に残ります。
-
書き先ログ — 行の以前の完全な値が、WAL セグメントが古くなって削除されるまでそこに残ります。時には数週間になることもあります。
-
時点バックアップ — 日次、週次、月次のスナップショットが、標準的なバックアップ ポリシーにより数年間行を保持する可能性があります。
-
読み取りレプリカ — 遅延コピーで、時には地理的に分散されており、時には別のチームによって運用されています。
-
スナップショット ボリューム — クラウド プロバイダーのブロック レベルのスナップショットで、災害復旧のために保持されることがよくあります。
-
ベクトル埋め込み — AI ワークフローでは、行の内容を別のベクトル ストアに埋め込みます。その埋め込みは派生的な個人データであり、独自の忘却問題です。
-
ダウンストリーム シンク — 行がストリーミングされたすべての場所: 分析倉庫、検索インデックス、ログ集約器、不正検出パイプライン、AI エージェントの独自のメモリなど。
これらの場所は、それぞれが独立した消去問題です。「すべての場所から消去する」というエンジニアリング チケットは、ダウンストリーム システムが増えるたびに成長します。従来の答えは、血統を追跡し、すべてのシンクを計器化し、最終的一貫性を証明するために数四半期にわたるプロジェクトです。一方、規制当局は待っており、時計は動いています。
AI メモリ レイヤーは、この問題を悪化させます。AI エージェントは、元のデータから派生した事実を独自のメモリ ストアに書き込みます。そのメモリは、元のデータとは異なるアクセス ポストュアで、規制対象コンテンツの独自のコピーになります。ソースに対する標準的な DELETE は、エージェントのメモリに対して何もしません。
2. 暗号論的消去とは実際に何であるか
キーを破棄せよ、バイトを破棄するのではない.
暗号論的消去 — 時々、crypto-shredding と呼ばれる — 問題を反転させる。バイトのすべてのコピーを削除しようとするのではなく、バイトをキーで暗号化し、そのキーを1つの取り消し可能な場所に保持し、「忘れる」というときにキーを破棄する。
暗号文は、どこに複製されたかに関係なく — バックアップ、スナップショット、分散ストレージネットワーク、アーカイブ階層 — 残ることができる。キーがなければ、すべてのコピーは数学的にランダムなバイトになる。回復できるものは何もない。データは 重要な意味で 消去されたということになる: 誰も、どこでも、いつまでもアクセスできなくなっている。
このパターンは、規格で認識されている。NIST SP 800-88r1 (「メディアの消去のためのガイドライン」) では、暗号化キーを破棄することを暗号化メディアの消去技術として明示的に扱っている。いくつかの国が規制機関は、GDPR 第17条の個人データの消去について、(a) 暗号化が強力だった、(b) キーがそのデータに一意に結び付けられていた、(c) 消去が監査可能だった場合に、同様の立場を取っている。
これら3つの条件は、SAIHM が設計によって厳格に強制するものである。
3. SAIHMがAIメモリの暗号消去を実装する方法
セルごとのキー。実際の破壊。パブリックチェーン上のタンパー証跡レシート.
SAIHMの各セルは、書き込み時にセルごとのデータ暗号化キー (DEK) で暗号化されます。DEKは、ユーザーのウォレットを根とするキーキャストグラフから、ポスト量子対応のHKDFチェーンを使用して導出されます。DEKは、プレーンテキストではAIクライアントから出ないため、クライアント（ウォレットを保持している）のみがそれを再導出できます。
暗号化されたテキストは、パブリックストレージネットワーク（Filecoin / IPFS）に分割されます。SAIHMプロトコルは、セルを指す暗号化されたメタデータエンベロープのみを保持します。ストレージオペレーターはセルを読み取ることができません。SAIHMプロトコルオペレーターはセルを読み取ることができません。ウォレットを保持しているAIエージェントのみがセルを読み取ることができます。
忘却パイプライン
SAIHMにセルを忘れることを要求すると、4つの処理が順序に従って実行されます。
-
DEK破壊。セルのデータ暗号化キーがクライアントのキーストアで破壊されます。SAIHMのプロトコルは、明示的なGDPR第17条理由コードを使用してこの破壊を識別します。
-
トゥームストーン。将来のリコールクエリがセルを返すことができないように、SAIHMプロトコルにトゥームストーンレコードが書き込まれます。
-
CIDブラックリスト。セルのストレージコンテンツ識別子がブラックリストされ、キャッシュまたはダウンストリームリゾルバがそれを提供することを拒否します。
-
オンチェーンアンカー。削除のタンパー証跡レシート（セルID、タイムスタンプ、GDPR第17条理由コード）がパブリックチェーンに書き込まれます。そのレシートは、規制当局が確認する監査アーティファクトです。
このシーケンスの後、ストレージネットワーク上の暗号化されたバイトはまだ存在しますが、誰でもによって永久に復号化不可能になります。セルは暗号的な意味で消去され、パブリックに検証可能なレシートが生成されます。
セルごとのDEKが重要な理由
すべてのセルを保護する単一のマスターキーを持つと、「1つのセルを破壊する」ことは、新しいマスターキーで他のすべてのセルを再暗号化することを必要とし、巨大で遅く、エラーが発生しやすい操作になります。SAIHMは、各セルに独自のDEKを割り当てて、忘却を1つの原子的なキー破壊として実行します。1つのセルを削除すると、残りのメモリには影響しません。
4. 規制機関がSAIHMの消去を検証する方法
SAIHMの協力なしで。パブリックブロックエクスプローラー上で。約1分で.
検証アーティファクトは、オンチェーンレシートです。規制機関（または自社のコンプライアンスチーム、または独立した監査人）は、消去されたとされるセルIDを取り、mainnet.cotiscan.io のCOTI V2メインネットのパブリックブロックエクスプローラーを開き、SAIHM監査コントラクトを照会します。レシートには、以下の3つの事実が含まれています。
-
セルIDは消去ログに存在する。
-
消去のタイムスタンプ。
-
消去に付随するGDPR第17条の理由コード。
検証者は、SAIHMのサーバーにアクセスする必要はありません。SAIHMは、レシートを後から変更することはできません。ブロックチェーンは、すべてのユーザーに対して不変です。検証方法は、データ主体、管理者、規制機関、独立した監査人にとって同じです。
これがGDPR第17条の下で重要な対比です。規制機関が「DELETE row 4928 OK」のスクリーンショットを受け取った場合、規制機関はオペレーターの言葉をすべて信じる必要があります。つまり、DELETEが実行された、バックアップが古くなった、レプリカがまだ行を保持していない、ということを信じる必要があります。一方、規制機関が消去イベントのオンチェーントランザクションハッシュを受け取った場合、誰かの言葉も信じる必要はありません。レシートは自分で検証されます。
5. 今日の SAIHM を実行するための 3 つのプロンプト
これらのプロンプトを、既存の AI クライアントにペーストしてください。SAIHM プロトコルは、Claude Code、Claude Desktop、Cursor、Continue、ChatGPT（MCP ブリッジ経由）および他の Model Context Protocol クライアントでも同じです。
プロンプト 1: 1 つのセルの忘却と証明
SAIHM を使用して、{sensitive-topic} というタグ付けされたセルを忘却してください。
証明してください、それが消滅していることと、オン チェーン レシートの URL を提供してください。
AI エージェントは、消去トランザクションへの直接リンクを返します。
プロンプト 2: スコープに一致するすべてのセルの忘却と確認
SAIHM を使用して、{personal-data-of-subject-X} というタグ付けされたすべてのセルを忘却してください。
オン チェーンで各消去を確認し、審査サマリーを提供してください。
データ サブジェクトの消去要求が複数のセルに適用される場合に便利です。各セルには DEK の破棄とオン チェーン レシートがあり、サマリーにはそれらをリストします。
プロンプト 3: 期間内のアウディト トレイルのエクスポート
SAIHM を使用して、{project-name} のアウディト トレイルを 90 日間の期間でエクスポートしてください。
書き込み、回顧、共有、忘却を含め、コンプライアンス レビュー用の形式でエクスポートしてください。
エクスポートは、AI エージェントのウォレット ID で署名されており、オン チェーン トランザクション ハッシュを含みます。審査員に渡してくださいまたは、規制回答に添付してください。
この投稿は元々 dev.to で公開されていました。
6. これができること
SAIHM は、シンプルさと同義です。ここでは、次のようなものを操作または予算から外すことができます。
-
消去追跡製品。 それぞれの生産ライン追跡、個別の同意管理ボルトオン、個別の「忘れ去る権利」ワークフロー製品は不要です。 SAIHM では、忘れ去ることを最初のクラスオペレーションとして実行します。
-
バックアップウィンドウ消去タイムライン。 「データは、90日間バックアップが古くなった後、完全に消去されます。」ということはありません。DEK は忘れ去る時点で破棄され、バックアップは即座に読み取れなくなります。
-
ベンダートラストの仮定。 「信頼してください、データは削除されました。」ということはありません。オンチェーンの受領証明書は証拠であり、SAIHM またはストレージオペレータの信頼が必要ありません。
-
マルチシステムの調整。 「倉庫、検索インデックス、ログアグリゲーター、埋め込みストアからも削除する必要があります。」ということはありません。セルは 1 つのプロトコル内に存在し、忘れ去ることは 1 つのプロトコル内で行われます。
-
規制者の間のやり取り。 アウディットエクスポートにはオンチェーンの受領証明書が含まれます。検証は 1 つのクリックで行うことができます。パブリックブロックエクスプローラーで。会話は終わります。
7. SAIHMに参加し、独自のAIメモリで忘却を実行する
現在のAIメモリ層が「これが消去されたことを証明する」という質問に検証可能なレシートで答えることができない場合、それは潜在的なコンプライアンスのギャップです。SAIHMは、最初の日からこれを解決します。
-
SAIHMに参加することです。/joinで参加できます。登録は数クリックで完了します。PAYGと有料プランが利用可能です。詳細は/pricingを参照してください。
-
AIクライアントをSAIHMエンドポイントに接続することです。1つのブロックの設定で、quickstart pageからコピー&ペーストできます。
-
忘却を実行することです。テストセルを保存し、上記のプロンプト1で消去します。ブロックエクスプローラーのリンクを開きます。レシートは、ポットが沸騰する前にすでに表示されます。
コンプライアンスを担当するCISOやリードが、10の要件全ての概要を望む場合は、AIメモリには標準が必要です。SAIHMはすでにそれを満たしています。も参照してください。こちらは、より詳細なボード/RFP向けの記事です。
独立性に関する通知。SAIHMは、Apache-2.0プロトコルであり、独立して作成されています。OpenAI、Anthropic、Google、Perplexity、またはその他のAIクライアントベンダーとは関連ありません。この記事では、実装されたSAIHM消去プロトコルについて説明しますが、特定の規制体制に関する法的なアドバイスは含みません。組織は、消去手順を自らの管理者と規制当局と対照して検証する必要があります。価格とプランの詳細は/pricingに記載されています。
元の記事は、SAIHMブログに2026-05-21に掲載されました。SAIHMは、Sovereign AI Horizontal Memoryプロトコルです。Apache 2.0、オープン仕様はsaihm.coti.globalでご覧いただけます。