§164.312(a) · アクセス制御
- PHI フィールドに対する Ontology のプロパティ単位の権限
- Agent IAM がどのエージェントがどのオブジェクトを読めるかを限定
- 必要最小限を強制 — 制限された読み取りはフェイルクローズ
- 過度に広い PHI アクセスはすべて 403 で拒否
HIPAA への整合
監査証跡を失わずに、エージェントに PHI を扱わせる。
HIPAA は、対象事業者とそのビジネスアソシエイトにおける保護対象保健情報（PHI）を規律します。セキュリティ規則は管理的・物理的・技術的セーフガード — アクセス統制、監査統制、完全性、送信のセキュリティ — を求め、プライバシー規則は利用を必要最小限に限定します。エージェントがカルテを読んだり事前承認の申請を起草したりするとき、それは PHI を扱っています。Cortex はプロパティ単位で必要最小限のアクセスを強制し、PHI に触れたすべての操作を改ざん検知可能な台帳に封印します。
HIPAA セキュリティ規則・プライバシー規則向けに構築 · BAA はご要望に応じて締結
audit/verify
ok: true
verifyChain ▸ 連鎖する SHA-256 · 署名付きレシート
HIPAA とは
HIPAA セキュリティ規則・プライバシー規則 を、平易な言葉で。
HIPAA（Health Insurance Portability and Accountability Act）は、個人を識別できる健康情報を保護します。セキュリティ規則（45 CFR Part 164, Subpart C）は技術的セーフガードを求めます：アクセス制御（§164.312(a)）、監査統制（§164.312(b)）、完全性（§164.312(c)）、送信のセキュリティ（§164.312(e)）です。プライバシー規則はこれに必要最小限基準を加えます — 業務に必要な PHI のみを利用・開示するというものです。AI エージェントにおけるリスクは、過度に広いアクセスと、証明できない証跡です。Cortex はその両方に対処します：Ontology のプロパティ単位の権限が読み取り時に必要最小限を強制し、DLP がツール呼び出しの入出力で PHI を検査し、ハッシュチェーン化された Trust Ledger が、完全性そのものを証明できる監査統制を提供します。
適用対象 ▸ 米国のヘルスケア · 対象事業者およびビジネスアソシエイト
義務要件と Cortex のマッピング
すべての要件が、強制適用され記録されるコントロールになります。
HIPAA の技術的セーフガードと必要最小限基準は、Cortex のデータレイヤー統制にそのまま対応します。PHI への各アクセスはゲートを通り記録されるため、OCR の監査は完全で改ざん検知可能な証跡に行き当たります。
§164.312(b) · 監査統制
- すべての PHI アクセスを Trust Ledger に封印
- verifyChain がアクセスログの未改ざんを証明
- 10 ホップのリネージ：誰が、なぜ、どのポリシーの下でアクセスしたか
- オフラインで検証可能な証跡としての署名済みレシート
§164.312(c) · 完全性
- ハッシュチェーン化された記録が挿入 / 編集 / 削除を検知
- データポイント来歴が事実を出典レコードに固定
- Action Fabric の補償が不適切な書き込みを取り消す
- value_hash が書き込み後に値が改変されていないことを証明
必要最小限
- DLP がすべてのツール呼び出しの入出力で PHI を検査
- 出力ガードレールが生成コンテンツから PHI を秘匿
- Oversight のゲートが高リスクな開示をレビューのために保留
- コスト上限が PHI の一括処理を制限（402）
送信と分離
- 転送時は TLS 1.2+、保存時は AES-256
- あらゆる箇所で (tenantId, id) を鍵としたテナント分離
- ローカルモデルによるエアギャップ導入、外部呼び出しはゼロ
- ビジネスアソシエイト契約はご要望に応じて締結
コントロールのマッピング
条文上の義務から、証明可能な証拠へ。
どの義務も、フェイルクローズのランタイムゲートに帰着します。その判定は改ざん検知可能な台帳に記録され、そのまま検査官に渡せます。これが、このフレームワーク向けに Compliance Pack が出力する対応表です。
| 義務要件 | 強制適用される Cortex コントロール | 台帳のエビデンス |
|---|---|---|
| §164.312(a) — アクセス制御 / 一意の識別 | Ontology の権限 + Agent IAM | 制限された読み取りで 403 |
| §164.312(b) — 監査統制 | Trust Ledger（ハッシュチェーン） | verifyChain ▸ ok:true |
| §164.312(c) — PHI の完全性 | value_hash + record_hash チェーン | hashOk:false が改変を検知 |
| 必要最小限の利用と開示 | DLP + 出力ガードレール | 451 で PHI を秘匿 |
| §164.312(e) — 送信のセキュリティ | 転送時は TLS · 保存時は AES-256 | 暗号化 · テナント分離 |
| PHI に触れたすべての操作に説明責任 | 10 ホップのリネージ + レシート | lineage/:correlationId |
Compliance Packs
ワンクリックのエビデンス出力を、Trust Ledger から直接。
OCR の調査や漏えい時のレビューは、アクセスログと監査ログ次第です。Compliance Pack はセキュリティ規則のセーフガードを対応する Cortex の統制に対応付け、封印済みの PHI アクセス記録をエクスポートします — その完全性は verifyChain で証明でき、可変のログが残す穴をふさぎます。
- HIPAA のコントロール対応表を自動生成 — 手作業の寄せ集めではありません
- 封印された実行記録を verifyChain でオフライン検証
- データポイントのプロベナンス — あらゆる事実が出典までたどれます
- 設計上、誠実 — 証拠は生成されるものであり、主張するものではありません
主張ではなく、証明を
デモで確認できる HIPAA の判定。
スライド上の約束ではありません。このフレームワークのコントロールに対して実際に検証したとき、ランタイムが返す実際のコードとレシートです。
ゲート判定 ▸ HIPAA
過度に広い PHI フィールドの読み取りを拒否強制適用
エージェント出力から PHI を秘匿強制適用
PHI アクセス証跡の完全性を証明証明済み
不適切な書き込みを取り消し証明済み
compliance-pack ▸ trust ledger から生成 · オフライン検証可能
監査への備え方
HIPAA を紙の上から証明可能へ、3ステップで。
- 01
マッピング
HIPAA を選ぶだけです。Cortex は各義務要件を、それを強制するランタイムゲートに対応付けます — 表計算の発掘作業は不要です。
- 02
強制適用
すべてのエージェント実行が同じフェイルクローズのゲートを通過します。拒否されたコントロールは実際のコード(402 / 403 / 409)を返し、黙って通過することはありません。
- 03
証明
Compliance Pack を出力します。対応表に加え、各コントロールが作動したことを示す封印済み台帳レコードが含まれ、オフラインで検証できます。
整合であって、認証取得を主張するものではありません
Cortex は HIPAA のセキュリティ規則およびプライバシー規則に対応して構築され、それらに整合しており、ビジネスアソシエイト契約も締結します。HIPAA に認証制度はなく、遵守は対象事業者またはビジネスアソシエイトである貴社の義務であり、Cortex が強制する統制と証跡がそれを支えます。
マッピングを支えるコントロール
このフレームワークを満たす Cortex の機能。
上記の各義務要件は、ランタイム上の実際の機能によって強制適用されます。このフレームワークを担う機能をご覧ください。
関連フレームワーク
規制対応の残りの領域もマッピング。
同じ強制適用コントロールとワンクリックのエビデンス出力が、監査人が挙げる他のフレームワークにも対応します。
コンプライアンスの位置づけ
監査人がすでに挙げているフレームワークに向けた設計。
封印された台帳、署名付きレシート、リネージグラフは、報告対象となるあらゆる制度の義務要件に対応します — 整合であって、保有していない認証を主張するものではありません。
EU AI ActNIST AI RMFISO 42001SOC 2HIPAAFINRAIRS Circular 230
HIPAA を、負担からボタン1つへ。
Cortex が HIPAA を強制適用コントロールへマッピングし、監査水準の証拠を必要に応じて出力する仕組みをご覧ください。