1. Quick Reference
| Item | Detail |
|---|---|
| NPRM Published | January 6, 2025 (90 FR 898) |
| Comment Period Closed | March 7, 2025 |
| Projected Finalization | July 2027 (HHS Unified Agenda) |
| Scope | Covered entities and business associates that use AI systems to create, receive, maintain, or transmit electronic protected health information (ePHI) |
| Key New Requirements | Technology asset inventory (including AI), mandatory risk analysis updates for AI, BAA provisions for AI vendors, patient right to explanation of AI-assisted decisions, de-identification standards for AI training data, patch management within 15 days (critical), MFA everywhere |
| Enforcement | HHS Office for Civil Rights (OCR). Existing HIPAA penalty tiers: $141 -- $2,134,831 per violation category per calendar year (2025 adjusted amounts) |
| SWT3 Procedures Mapped | 12 procedures across 10 namespaces |
2. Proposed Changes Affecting AI
The proposed Security Rule update is the most significant revision to HIPAA security requirements since the original rule took effect in 2005. While the NPRM does not create a standalone "AI regulation," it introduces several provisions that directly affect how covered entities and business associates deploy AI systems that interact with ePHI.
AI Technology Asset Inventory
The proposed rule requires covered entities to maintain a comprehensive technology asset inventory that includes all systems creating, receiving, maintaining, or transmitting ePHI. AI systems -- including machine learning models, inference pipelines, and automated decision tools -- fall within this scope when they process ePHI. The inventory must be updated at least annually or when material changes occur, and must document each asset's function, data flows, and network location.
AI in Risk Analysis
The NPRM proposes to remove the "addressable" versus "required" distinction from implementation specifications, making all specifications required. Risk analysis must now cover all technology assets, including AI systems. This means covered entities must evaluate AI-specific risks: model inference errors affecting patient data, adversarial attacks on AI pipelines, data poisoning of training sets, and unauthorized access through AI system interfaces. Risk analysis must be documented, reviewed, and updated at least annually.
BAA Requirements for AI Vendors
Business associate agreements must address AI-specific data handling. When a business associate uses AI systems that process ePHI on behalf of a covered entity, the BAA must specify how the AI system handles data, what safeguards protect ePHI during model training and inference, and how the business associate will respond to AI-related security incidents. The proposed rule strengthens the requirement that covered entities verify their business associates' compliance, including AI-specific controls.
Patient Rights to Explanation
The proposed rule strengthens individual access rights in ways that affect AI systems. When AI contributes to decisions about patient care, treatment recommendations, or coverage determinations involving ePHI, patients may request an explanation of how their information was used. This intersects with the proposed right to receive an accounting of disclosures in a more granular format, including disclosures to and by AI systems.
De-identification Standards for AI Training
The proposed rule reinforces requirements around de-identification when ePHI is used for AI model training. Safe Harbor and Expert Determination methods under 45 CFR 164.514(b) apply to AI training datasets. The NPRM signals that OCR will scrutinize re-identification risks specific to AI, including the ability of large language models to memorize and reproduce training data containing patient information. Organizations using ePHI-derived data for AI training must document their de-identification methodology and validate that re-identification risk meets the regulatory threshold.
Additional Provisions Relevant to AI
- Patch management (15-day critical): AI system dependencies, libraries, and model serving infrastructure must be patched within 15 days for critical vulnerabilities and within 30 days for high-severity findings. This applies to AI frameworks, inference servers, and supporting infrastructure.
- MFA everywhere: All access to ePHI-processing systems, including AI inference endpoints and model management interfaces, requires multi-factor authentication. No exceptions.
- Encryption in transit and at rest: No longer addressable -- encryption is required for all ePHI, including data in AI training pipelines, model weights trained on ePHI, and inference inputs and outputs.
- 72-hour incident notification: AI-related security incidents (model compromise, training data exfiltration, adversarial manipulation) must be reported within 72 hours to HHS and affected individuals.
- Annual compliance audits: Internal audits must cover AI systems within scope, verifying that security controls are implemented and functioning.
3. Procedure Mapping Table
Each proposed HIPAA Security Rule requirement maps to an SWT3 procedure that produces a cryptographic witness anchor as auditable evidence. These anchors are immutable, timestamped, and independently verifiable.
| Proposed Requirement | SWT3 Procedure | What It Records | Evidence Produced |
|---|---|---|---|
| AI technology asset inventory | AI-INF.1 | AI system inventory and infrastructure documentation | Anchor with asset identifier, system function, data flow classification, update timestamp |
| AI risk analysis | AI-SEC.1 | Security risk analysis covering AI-specific threat vectors | Anchor with risk category, threat type, mitigation status, assessment date |
| De-identification for AI training | AI-DATA.1 | Data quality and provenance for training datasets | Anchor with de-identification method, re-identification risk score, data source, validation date |
| Access control for AI systems | AI-ACC.1 | Access control enforcement on AI endpoints and model interfaces | Anchor with access type, authentication method, authorization scope, endpoint identifier |
| Audit trail for AI operations | AI-AUDIT.1 | Immutable record of AI system operations involving ePHI | Anchor with operation type, model version, input hash, output hash, operator identity |
| BAA compliance for AI vendors | AI-GOV.1 | Governance policy covering AI vendor oversight and BAA provisions | Anchor with vendor identifier, BAA status, AI-specific safeguards, review date |
| Patient notice of AI use | AI-TRANS.1 | Transparency disclosure when AI processes patient ePHI | Anchor with disclosure type, decision context, notification method, recipient category |
| Clinical oversight of AI decisions | AI-HITL.1 | Human oversight when AI contributes to clinical or coverage decisions | Anchor with reviewer role, review type, override authority, clinical context |
| AI component inventory (SBOM) | AI-SBOM.1 | Software bill of materials for AI system dependencies | Anchor with component count, vulnerability status, dependency tree hash, scan date |
| Authentication for AI endpoints | AI-ID.1 | Identity and authentication for AI system access | Anchor with authentication method, MFA status, agent identity, session context |
| AI system lifecycle evaluation | AI-LCM.1 | Lifecycle management from deployment through retirement | Anchor with lifecycle stage, evaluation criteria, approval status, evaluator identity |
| Authorization for ePHI in AI training | AI-CONSENT.1 | Authorization and consent for using patient data in AI training | Anchor with consent type, legal basis, data scope, opt-out availability |
4. Detailed Procedure Cards
Security Risk Analysis for AI Systems
Proposed requirement: Risk analysis must cover all technology assets, including AI systems that process ePHI. The removal of "addressable" specifications means AI-specific risk analysis is no longer optional.
What the proposed rule expects: Covered entities must identify and evaluate risks specific to AI systems, including model inference errors, adversarial attacks, data poisoning, unauthorized access through AI interfaces, and training data leakage. Risk analysis documentation must be reviewed and updated at least annually or when AI systems change materially.
How SWT3 records it: witnessSecurityEvent() creates an anchor for each AI-specific risk assessment activity. The anchor records the risk category, threat type, mitigation status, and assessment date. Over time, the anchor chain documents a continuous risk analysis program covering AI systems.
Query AI-SEC.1 anchors by date range to verify continuous risk analysis coverage. Look for AI-specific risk categories (model_inference, adversarial_attack, data_poisoning, training_leakage). Gaps longer than 12 months between assessments indicate the AI risk analysis program may not meet the proposed annual review requirement. Cross-reference with AI-INF.1 to verify that all inventoried AI assets have corresponding risk assessments.
De-identification and Data Provenance for AI Training
Proposed requirement: De-identification standards under 45 CFR 164.514(b) apply to AI training datasets derived from ePHI. OCR has signaled heightened scrutiny of re-identification risks specific to AI, including LLM memorization of training data.
What the proposed rule expects: Organizations using ePHI-derived data for AI model training must document the de-identification methodology (Safe Harbor or Expert Determination), validate that re-identification risk meets the regulatory threshold, and maintain provenance records from source ePHI through de-identified training dataset. Expert Determination must be performed by a qualified statistical expert whose analysis is documented and reproducible.
How SWT3 records it: witnessDataQuality() records the de-identification method, re-identification risk score, data source, and validation date for each training dataset. The anchor chain documents that de-identification was performed and validated before training data was used.
Check AI-DATA.1 anchors for de-identification method (safe_harbor or expert_determination) and re-identification risk score. For Expert Determination, verify that the expert's qualifications and methodology are documented. Cross-reference with AI-CONSENT.1 to confirm that appropriate authorization existed before ePHI was processed into training data. LLM-based systems warrant additional scrutiny -- verify that memorization testing was performed.
Access Control for AI Systems Processing ePHI
Proposed requirement: Access controls must cover all systems processing ePHI, including AI inference endpoints, model management interfaces, and training data repositories. MFA is required everywhere -- no exceptions.
What the proposed rule expects: Role-based access control for AI system interfaces. API endpoints serving AI inference on ePHI must enforce authentication and authorization. Model management operations (training, fine-tuning, deployment, retirement) must be restricted to authorized personnel. Access logs must capture who accessed what AI system and when.
How SWT3 records it: wrapAccess() creates an anchor for each access event on AI system endpoints. The anchor records the access type, authentication method, authorization scope, and endpoint identifier. Continuous access witnessing produces an evidence chain showing that access controls were enforced throughout the reporting period.
Query AI-ACC.1 anchors for authentication_method. Under the proposed rule, every access event must show MFA. Any anchor with single-factor authentication on an ePHI-processing AI endpoint is a finding. Cross-reference with AI-ID.1 to verify that agent and service account identities are properly authenticated. Check for access events outside of expected hours or from unexpected network locations.
Audit Trail for AI Operations
Proposed requirement: Maintain audit controls that record and examine activity in information systems containing or using ePHI. AI system operations -- inference requests, model updates, training runs, data access -- must be captured in audit logs that are tamper-resistant and retained for at least six years.
What the proposed rule expects: Every AI operation involving ePHI must have a corresponding audit record that includes operator identity, operation type, timestamp, model version, and outcome. Audit logs must be protected from modification and available for examination by OCR during compliance reviews. The proposed rule eliminates the addressable specification for audit controls, making comprehensive logging mandatory.
How SWT3 records it: witnessAudit() creates an immutable anchor for each auditable AI operation. The anchor captures operation type, model version, input hash, and output hash. Because SWT3 Witness Anchors are cryptographically signed and timestamped, they provide tamper-evident audit records that satisfy the proposed rule's integrity requirements.
AI-AUDIT.1 is the foundational evidence procedure for HIPAA AI compliance. Query anchors by date range to verify continuous audit coverage. Any gaps during periods when AI systems were processing ePHI are significant findings. Verify that model_version is recorded -- this is critical for incident response and for tracing which model version processed a specific patient's data. The six-year retention requirement means anchor storage must be planned accordingly.
BAA Compliance and AI Vendor Governance
Proposed requirement: Business associate agreements must address AI-specific data handling. Covered entities must verify that business associates using AI to process ePHI have appropriate safeguards in place.
What the proposed rule expects: BAAs must specify how AI systems handle ePHI, what safeguards protect data during training and inference, incident response procedures for AI-related breaches, and how the business associate will demonstrate compliance. Covered entities must verify BAA compliance -- not just collect signed agreements. The proposed rule also requires that BAAs address subcontractor AI use (downstream business associates).
How SWT3 records it: witnessGovernance() anchors the BAA status, AI-specific safeguards, vendor identifier, and review date. Separate anchors cover initial BAA execution, annual reviews, and material changes. The anchor chain provides a verifiable record that the covered entity maintained active oversight of AI vendor compliance throughout the reporting period.
Query AI-GOV.1 anchors for each AI vendor relationship. Verify that BAA status is current (not expired), that AI-specific safeguards are documented, and that annual reviews occurred. For downstream business associates (subcontractors), verify that the primary BA's governance program covers their AI subcontractors. A covered entity using an AI vendor without a BAA that addresses AI-specific provisions is a high-priority finding under the proposed rule.
5. SDK Integration
The SWT3 Python SDK provides named witness methods for each procedure. Below are examples for common HIPAA AI compliance scenarios.
AI Asset Inventory Witness
w = Witness(
tenant_id="YOUR_TENANT",
api_key="YOUR_KEY",
endpoint="https://sovereign.tenova.io/api/v1/witness"
)
# Record AI system in technology asset inventory
w.witness_infrastructure(
factor_a="radiology-ai-v3.2",
factor_b="inference-endpoint",
factor_c="processes-ephi"
)
De-identification Validation Witness
w.witness_data_quality(
factor_a="safe_harbor",
factor_b="0.003", # re-identification risk score
factor_c="training-dataset-2026-q3"
)
BAA Compliance Witness
w.witness_governance(
factor_a="vendor-ai-diagnostics-inc",
factor_b="baa-annual-review",
factor_c="ai-safeguards-verified"
)
Audit Trail Witness
w.witness_audit_integrity(
factor_a="inference-request",
factor_b="radiology-ai-v3.2",
factor_c="output-hash-abc123"
)
Full SDK documentation: sovereign.tenova.io/docs
Create a free account: sovereign.tenova.io/signup
6. References
- HIPAA Security Rule NPRM -- 90 FR 898 (January 6, 2025)
- HHS HIPAA Security Rule -- Office for Civil Rights
- 45 CFR Part 164, Subpart C -- Security Standards for the Protection of ePHI
- 45 CFR 164.514(b) -- De-identification of Protected Health Information
- Health Insurance AI Crosswalk (SWT3 Protocol)
- ISO 42001 AI Management System Crosswalk (SWT3 Protocol)
- Cryptographic AI Evidence Quickstart (SWT3 Protocol)