HIPAA Compliance Roadmap for AI Teams 2026

Building Privacy-Governed AI Systems in Healthcare

Who This Guide Is For

This guide is designed for:

🏥 Healthcare AI Teams — Building or deploying AI systems that process Protected Health Information
💊 Digital Health Startups — Developing AI-powered clinical, diagnostic, or patient-facing products
💼 SaaS Platforms — Providing AI-powered tools to healthcare organizations as Business Associates
🔬 Research Organizations — Using AI to process patient data for clinical research
🏛️ Health Systems & Payers — Deploying LLMs, automation, or AI decision-support in care workflows
🤝 AI Governance Leaders — Building compliant AI infrastructure in regulated healthcare environments

If your AI system processes, stores, or transmits Protected Health Information (PHI) from US patients, this guide is for you.

A Note on This Guide

This guide is designed for organizations building privacy-governed AI systems that handle Protected Health Information. It provides a comprehensive overview of HIPAA obligations as they apply to AI, explains what governance-ready healthcare AI looks like, and helps you assess where you stand.

What this guide does:

✅ Explains what HIPAA requires for AI systems handling PHI
✅ Helps you understand your obligations as a Covered Entity or Business Associate
✅ Shows you the AI-specific risks HIPAA was not designed for
✅ Provides a framework for privacy-governed healthcare AI governance

What you'll need beyond this guide:

Legal counsel (for definitive HIPAA interpretation specific to your situation)
Technical implementation support (for your specific systems and workflows)
Privacy and security infrastructure for ongoing compliance

Ready to discuss your HIPAA readiness strategy? Schedule a 30-minute HIPAA Readiness Assessment

A Critical Note on AI and HIPAA

HIPAA was enacted in 1996. Large language models, generative AI, and modern ML pipelines did not exist. This creates a significant and underappreciated gap:

HIPAA's rules were designed for structured databases. AI systems break almost every assumption HIPAA was built on.

Specifically:

HIPAA assumes data stays in defined fields. LLMs process free-form text containing PHI.
HIPAA assumes de-identification removes risk. LLMs can reconstruct identity from context.
HIPAA assumes access is controlled. AI APIs send PHI to external third parties by default.
HIPAA assumes audit trails are complete. AI pipelines often have gaps in PHI tracking.

This guide addresses both the traditional HIPAA requirements and the AI-specific gaps that most compliance programs miss.

Who This Guide Is For
What HIPAA Actually Demands
Why This Matters for Your Business
Covered Entities vs. Business Associates: Know Your Role
Protected Health Information: What Counts as PHI in AI Systems
The 18 Safe Harbor Identifiers
The AI Re-Identification Problem
The HIPAA Security Rule for AI Systems
The 5 Essential Things You Must Do
Business Associate Agreements and AI Vendors
The Minimum Necessary Standard
Patient Rights Under HIPAA
Breach Notification Obligations
HIPAA and the HITECH Act
State Law Considerations
Compliance Readiness Assessment
Getting Started
About SpanForge
Resources & Next Steps

Section 1: What HIPAA Actually Demands

The Health Insurance Portability and Accountability Act (HIPAA) was enacted in 1996 and substantially expanded by the HITECH Act in 2009. It establishes national standards for protecting sensitive patient health information.

If you create, receive, maintain, or transmit PHI as a covered entity, business associate, or subcontractor business associate, HIPAA generally applies.

The Three HIPAA Rules

HIPAA compliance for AI systems requires understanding three distinct rules:

Rule	What It Covers	Applies To
Privacy Rule	Who can access PHI and for what purposes	All covered entities and business associates
Security Rule	Technical, physical, and administrative safeguards for electronic PHI (ePHI)	All covered entities and business associates
Breach Notification Rule	What to do when PHI is improperly accessed or disclosed	All covered entities and business associates

The Simple Version

HIPAA requires that organizations handling PHI:

Only use or disclose PHI for permitted purposes
Protect PHI with appropriate administrative, physical, and technical safeguards
Give patients rights over their own health information
Notify patients and authorities when PHI is breached
Ensure vendors who handle PHI on your behalf are contractually bound to the same standards
Can prove all of the above on demand

HIPAA is not asking for perfect security. It is asking for documented, reasonable safeguards appropriate to the risk.

Section 2: Why This Matters for Your Business

The Financial Stakes

HIPAA violations are tiered by culpability, from situations where the organization did not know (and could not have known) of the violation, through to willful neglect that is not corrected. Penalties can stack per violation, per day, making large fines common even for smaller organizations.

Civil monetary penalties are adjusted periodically for inflation and depend on the level of culpability. Organizations should consult current HHS/OCR penalty schedules for the latest figures.

The tiered structure means that a single breach affecting thousands of patients can result in penalties that multiply across affected individuals. Willful neglect that is not corrected carries the highest penalty exposure.

Advocate Aurora Health (2022): $3M+ settlement — pixel tracking tools on patient portals transmitted PHI to third parties without authorization. A direct analogy to AI API integrations.
Banner Health (2016): $1.25M settlement — insufficient access controls and audit logging.
University of Rochester Medical Center (2019): $3M settlement — lack of encryption and device management controls.

The Advocate Aurora case is particularly relevant: embedding a third-party tool that transmitted PHI without a BAA is exactly the pattern that occurs when healthcare organizations integrate AI APIs without proper agreements.

Beyond the Fine

Criminal liability: Knowingly obtaining or disclosing PHI without authorization can result in criminal prosecution (up to 10 years imprisonment for malicious intent)
OCR investigation: Even without a fine, investigations are costly, disruptive, and reputationally damaging
State AG action: Many state attorneys general independently enforce HIPAA
Civil litigation: Patients affected by breaches can bring class action lawsuits under state law
Contract loss: Healthcare organizations increasingly require HIPAA attestation from all AI vendors

Section 3: Covered Entities vs. Business Associates: Know Your Role

HIPAA compliance obligations depend entirely on your role. Getting this wrong is one of the most common failures in healthcare AI.

Covered Entities

Organizations that are directly subject to HIPAA:

Type	Examples
Healthcare providers	Hospitals, clinics, physicians, therapists, pharmacies
Health plans	Insurance companies, HMOs, Medicare, Medicaid
Healthcare clearinghouses	Organizations that process health information between entities

If you are a covered entity, you are directly subject to all HIPAA rules.

Business Associates

Organizations that handle PHI on behalf of a covered entity:

Type	Examples
AI platform vendors	Companies providing AI tools to hospitals or health plans
Cloud providers	AWS, Azure, GCP hosting PHI workloads
Analytics vendors	Companies processing health data for covered entities
EHR integrators	Companies accessing patient records to build AI features

If you are a business associate, you must:

Sign a Business Associate Agreement (BAA) with each covered entity you serve
Implement the same safeguards as a covered entity
Only use PHI for the purposes specified in the BAA
Report breaches to the covered entity

Subcontractors

If your business associates outsource PHI-related work to another vendor, that vendor becomes a subcontractor business associate and must also sign a BAA.

Common AI scenario:

Hospital (Covered Entity)
    → Signs BAA with AI Platform (Business Associate)
        → AI Platform uses OpenAI API for processing (Subcontractor BA)
            → OpenAI must also sign BAA

If any link in this chain is missing a BAA, every organization in the chain is potentially liable.

The Most Common Mistake

Healthcare AI teams frequently assume that because they are a technology company (not a hospital), HIPAA doesn't apply to them. This is wrong. If you receive, process, or store PHI from a covered entity — even indirectly — you are a business associate and HIPAA applies in full.

Section 4: Protected Health Information: What Counts as PHI in AI Systems

PHI is any individually identifiable health information that is created, received, maintained, or transmitted by a covered entity or business associate.

The Three-Part Test for PHI

Information is PHI if it meets all three criteria:

It relates to health — past, present, or future physical or mental health; healthcare provision; or payment for healthcare
It identifies an individual — or there is a reasonable basis to believe it could identify an individual
It is held or transmitted by a covered entity or business associate

Where PHI Appears in AI Systems (Often Unexpectedly)

AI Component	Where PHI Can Appear
LLM inputs	Clinical notes, patient messages, referral letters fed as context
LLM outputs	Generated summaries, discharge letters, treatment recommendations
Training data	Historical EHR data used to fine-tune models
RAG retrieval	Patient records retrieved to answer clinical questions
Embeddings	Vector representations of patient records stored in vector databases
Conversation logs	Chat histories between patients and AI systems
Model weights	Fine-tuned models may have memorized PHI from training data
API request logs	Logging of API calls that included PHI in the request body
Error logs	Stack traces that inadvertently capture PHI values

Electronic PHI (ePHI)

PHI that is stored, processed, or transmitted electronically is called ePHI. The Security Rule applies specifically to ePHI. In practice, almost all AI-related PHI is ePHI.

Section 5: The 18 Safe Harbor Identifiers

The Privacy Rule provides two methods for de-identifying PHI. The most common is Safe Harbor, which requires removing or masking 18 categories of identifiers.

The 18 Safe Harbor Identifiers

#	Identifier	AI-Specific Risk
1	Names	Appears in clinical notes, referral letters, discharge summaries
2	Geographic subdivisions smaller than state	City, zip code, address in patient records
3	All elements of dates (except year) for individuals over 89	Admission dates, birth dates in clinical text
4	Telephone numbers	In patient communications and contact records
5	Fax numbers	In legacy clinical records and referrals
6	Email addresses	In patient portal messages fed to AI
7	Social Security numbers	In billing and eligibility records
8	Medical record numbers	In EHR exports used for training
9	Health plan beneficiary numbers	In insurance and claims data
10	Account numbers	In billing systems integrated with AI
11	Certificate and license numbers	In provider credentialing data
12	Vehicle identifiers and serial numbers	In accident and injury records
13	Device identifiers and serial numbers	In implant records and medical device data
14	Web URLs	In patient portal activity logs
15	IP addresses	In system access logs fed to AI
16	Biometric identifiers	Fingerprints, voice prints in authentication systems
17	Full-face photographs and comparable images	In clinical photography and telehealth
18	Any other unique identifying number, characteristic, or code	Any identifier not listed above

What Safe Harbor De-Identification Does NOT Cover

Safe Harbor removes structured identifiers. It does not address:

Contextual re-identification: A clinical note describing "a 67-year-old male farmer from rural Iowa admitted following a tractor accident in August" may be uniquely identifiable even without any of the 18 identifiers
LLM memorization: Models trained on patient data may reproduce identifying details in outputs even when the training data was de-identified
Combination attacks: Combining de-identified records with external datasets (social media, public records) to re-identify individuals
Rare condition identification: Patients with rare diseases may be uniquely identifiable from their diagnosis alone

Section 6: The AI Re-Identification Problem

This is the most important section for AI teams. Standard HIPAA de-identification approaches were not designed for AI systems.

The Three Re-Identification Risks Unique to AI

Risk 1: LLM Training Data Memorization

Large language models memorize portions of their training data. Research has demonstrated that models can be prompted to reproduce verbatim text from training data — including patient records, clinical notes, and other PHI.

What this means for you:

Fine-tuning a model on patient data creates a model that may reproduce that data in outputs
Even "anonymized" training data may produce identifiable outputs
Model weights may encode information derived from PHI, raising unresolved legal and compliance questions that organizations should monitor as regulatory guidance develops

Risk 2: Contextual Re-Identification in Prose

Clinical text is narrative. It contains combinations of attributes that, while individually non-identifying, together uniquely identify an individual.

Example: "The patient is a 71-year-old retired firefighter from Springfield who was admitted for a liver transplant in March after 14 years on the waiting list" — contains no Safe Harbor identifiers, but is likely uniquely identifying.

Pattern-matching de-identification tools designed for structured data miss this entirely.

Risk 3: Retrieval-Augmented Generation (RAG) Leakage

RAG systems retrieve patient records to provide context for AI responses. If retrieval is not carefully controlled:

A query about one patient may retrieve records about another
Retrieved context containing PHI may appear in model outputs
Retrieved PHI may be logged in API request/response logs

What This Means for Your Compliance Program

Standard Safe Harbor de-identification is necessary but not sufficient for AI systems. You need:

Context-aware PII/PHI detection — not just pattern matching
Output scanning — monitoring AI outputs for PHI that was inadvertently included
Training data governance — policies for what data can be used to train or fine-tune models
RAG access controls — ensuring retrieval is scoped to the minimum necessary records
Model output audit trails — tamper-evident logs of all AI outputs containing potential PHI

Section 7: The HIPAA Security Rule for AI Systems

The Security Rule requires covered entities and business associates to implement administrative, physical, and technical safeguards to protect ePHI.

Administrative Safeguards

These are policies, procedures, and training requirements:

Requirement	What It Means for AI
Security Management Process	Conduct a risk analysis covering all AI systems handling ePHI
Security Officer	Designate someone responsible for AI security compliance
Workforce Training	Train all staff who interact with AI systems on PHI handling
Access Management	Implement role-based access to AI systems handling ePHI
Contingency Plan	Data backup and disaster recovery for AI systems and their data
Evaluation	Periodic review of security measures as AI systems change

Physical Safeguards

Controls for physical access to systems containing ePHI:

Requirement	What It Means for AI
Facility Access Controls	Physical access controls to servers and workstations running AI models
Workstation Security	Policies for workstations used to interact with AI systems containing ePHI
Device and Media Controls	Disposal, backup, and accountability for hardware containing AI model weights or training data with PHI

Technical Safeguards

Technical measures to protect ePHI:

Requirement	What It Means for AI
Access Control	Unique user IDs, emergency access, automatic logoff, encryption
Audit Controls	Hardware, software, and procedural mechanisms to record access to ePHI in AI systems
Integrity Controls	Mechanisms to verify ePHI has not been altered or destroyed improperly
Transmission Security	Encryption of ePHI in transit — including API calls to AI services

The Risk Analysis Requirement

The Security Rule requires a thorough and accurate assessment of potential risks to ePHI. For AI systems, your risk analysis must address:

All AI systems and pipelines that process ePHI
Third-party AI APIs receiving ePHI (each is a separate risk)
Training data containing PHI
Model outputs that may contain PHI
API logs and monitoring systems that capture ePHI
Vector databases storing embeddings of PHI

This risk analysis must be documented, regularly reviewed, and updated when systems change.

Section 8: The 5 Essential Things You Must Do

Building HIPAA-aligned AI systems requires these 5 foundational practices:

Thing 1: Map All PHI Flows Through Your AI Systems

Question: Where does PHI enter, flow through, and exit your AI systems?

Action: Create a complete PHI flow map for every AI system that touches patient data.

Your map should show:

What PHI enters each system (inputs: clinical notes, patient messages, EHR data)
Where it goes (APIs, model inference, vector databases, logs, storage)
Who has access at each stage
Which third-party services receive PHI (and whether BAAs are in place)
How long PHI is retained at each stage
How PHI is deleted when no longer needed

Outcome: Complete documentation of PHI flows — the foundation of your Security Rule compliance and your response to any OCR investigation.

Thing 2: Conduct and Document a Risk Analysis

Question: What are the risks to PHI in your AI systems?

Action: For each AI system touching PHI, document a formal risk analysis.

Risk analysis should cover:

What PHI does this system create, receive, maintain, or transmit?
What are the threats to that PHI? (unauthorized access, breach, loss, improper disclosure)
What is the likelihood of each threat?
What is the impact if the threat occurs?
What safeguards are in place?
What residual risk remains?

Outcome: Documented risk analysis (legally required under the Security Rule; the first thing OCR asks for in an investigation)

Thing 3: Implement Technical Safeguards

Question: Can you prove your AI system protects ePHI with appropriate technical controls?

Safeguards should include:

Safeguard	Implementation
Encryption at rest	All PHI in storage encrypted (AES-256 minimum)
Encryption in transit	All API calls and data transfers use TLS 1.2+
Access controls	Role-based access; unique user IDs; MFA for PHI systems
Audit logging	Tamper-evident logs of all access to ePHI
PHI detection	Automated scanning to detect and redact PHI in AI inputs and outputs
Output monitoring	Monitoring AI outputs for inadvertent PHI disclosure
Retention & deletion	Automated enforcement of data retention schedules

Outcome: Demonstrable technical safeguards (required under the Security Rule)

Thing 4: Execute Business Associate Agreements With All AI Vendors

Question: Do you have valid BAAs with every vendor that handles PHI on your behalf?

Action: Audit every vendor in your AI stack. Identify which ones receive PHI. Execute BAAs before sending any PHI.

Vendors that almost certainly need BAAs in an AI context:

Vendor Type	Examples	BAA Required?
Cloud AI APIs	OpenAI, Anthropic, Google AI	✅ Yes if PHI is sent
Cloud platforms	AWS, Azure, GCP	✅ Yes (most offer BAAs)
Vector databases	Pinecone, Weaviate, Chroma	✅ Yes if storing PHI embeddings
Monitoring platforms	Datadog, Splunk	✅ Yes if logs contain PHI
LLM observability	LangSmith, Weights & Biases	✅ Yes if traces contain PHI

Important: Some AI vendors do not offer BAAs. If a vendor will not sign a BAA, in most cases you should not use that service for PHI processing. Failure to execute a required BAA is a significant HIPAA compliance deficiency and a common basis for enforcement.

Outcome: Complete BAA coverage for all PHI-handling vendors (legally required; failure to execute a required BAA is a significant HIPAA compliance deficiency and a common basis for enforcement)

Thing 5: Build a Breach Detection and Response Capability

Question: If PHI was improperly accessed or disclosed through your AI system, would you know? And could you respond within 60 days?

Breach detection requires:

Monitoring AI inputs and outputs for PHI that shouldn't be there
Alerting on unauthorized access to PHI-containing systems
Logging all AI system access in tamper-evident audit trails
Regular review of access logs for anomalies

Breach response requires:

A documented incident response plan for PHI breaches
Clear escalation path to your Privacy and Security Officers
Templates for patient notification letters
OCR reporting procedures
Documentation of the breach investigation

Outcome: Breach detection and response capability (required under the Breach Notification Rule; inadequate monitoring can significantly impair your ability to detect and respond to reportable breaches)

Section 9: Business Associate Agreements and AI Vendors

BAAs are one of the most commonly mishandled aspects of healthcare AI. Here is what you need to know.

What a BAA Must Cover

Under 45 CFR §164.504(e), a BAA must include:

Permitted uses and disclosures of PHI
Prohibition on uses not permitted by the agreement
Requirement to implement appropriate safeguards
Requirement to report breaches to the covered entity
Requirement to subcontract PHI work only to entities that agree to the same restrictions
Requirement to return or destroy PHI at the end of the relationship
Authorization for the covered entity to terminate the agreement for material breach

BAA Checklist for AI Vendors

Before sending any PHI to an AI vendor:

Does the vendor offer a BAA?
Is the BAA signed and executed (not just available for download)?
Does the BAA cover the specific use case (e.g., using PHI for model inference but not training)?
Does the BAA prohibit the vendor from using PHI to train their own models?
Does the BAA specify data retention and deletion obligations?
Does the BAA require the vendor to report breaches within 60 days?
Are subcontractors covered?

When AI Vendors Refuse to Sign BAAs

Some AI vendors have policies against signing BAAs or charge significant premiums for HIPAA-eligible tiers. Common situations:

Situation	Your Options
Vendor offers no BAA at any price	Cannot send PHI to this vendor
Vendor offers BAA on enterprise tier only	Upgrade to enterprise or find alternative
Vendor BAA prohibits use for training	Acceptable — confirm in writing
Vendor BAA is silent on training	Negotiate explicit prohibition or find alternative
Vendor offers BAA but requires data sharing	Do not sign — this is likely not HIPAA compliant

Section 10: The Minimum Necessary Standard

One of the most practically important HIPAA requirements for AI teams is the minimum necessary standard.

What It Requires

When using or disclosing PHI, covered entities and business associates must make reasonable efforts to limit PHI to the minimum necessary to accomplish the intended purpose.

What This Means for AI Systems

AI Use Case	Minimum Necessary in Practice
Clinical summarization	Send only the relevant clinical notes, not the entire patient record
Diagnosis support	Send only data relevant to the presenting condition
Patient messaging AI	Include only the context needed to answer the specific question
RAG retrieval	Retrieve only records relevant to the query — not all records for that patient
Analytics AI	Use de-identified or aggregated data where the use case permits

Why AI Teams Get This Wrong

AI models generally perform better with more context. There is a natural engineering tendency to provide as much data as possible to improve model performance. HIPAA prohibits this where PHI is involved.

The minimum necessary standard requires you to:

Define what data is actually required for each AI use case
Implement technical controls that enforce those limits
Document your minimum necessary determination for each use case
Regularly review whether more data is being sent than necessary

Section 11: Patient Rights Under HIPAA

Patients have rights over their health information that your AI systems must support.

Key Patient Rights

Right	What It Means for AI	Deadline
Right of Access	Patients can request copies of their PHI — including data processed by AI	30 days (one 30-day extension permitted when allowed and documented)
Right to Amend	Patients can request corrections to inaccurate PHI	60 days
Right to an Accounting of Disclosures	Patients can request a log of non-routine PHI disclosures	60 days for up to 6 years
Right to Restrict Uses	Patients can request restrictions on certain uses of their PHI	Must acknowledge; limited obligation to comply
Right to Confidential Communications	Patients can request PHI be communicated through alternative means	Must accommodate reasonable requests

AI-Specific Challenges

The Accounting of Disclosures Problem: If your AI system sends PHI to external APIs for processing, each such disclosure may need to be logged and available to patients on request. This creates a significant audit trail requirement for AI integrations.

The Amendment Problem: If a patient corrects inaccurate information in their record, your AI systems trained or fine-tuned on that data may continue to reflect the inaccurate information. This creates an obligation to either retrain or document the limitation.

The Access Problem: If a patient requests their data, that request may extend to data processed by AI systems — including conversation logs, AI-generated summaries, and model outputs stored in your systems.

Section 12: Breach Notification Obligations

The HIPAA Breach Notification Rule requires specific actions when PHI is improperly accessed, used, or disclosed.

What Counts as a Breach

A breach is the acquisition, access, use, or disclosure of PHI in a manner not permitted by the Privacy Rule — unless the covered entity or business associate can demonstrate a low probability that PHI has been compromised (the four-factor test).

AI-specific breach scenarios:

Scenario	Breach?	Action Required
LLM outputs PHI about one patient in response to query about another	Yes	Notify affected patients, OCR
PHI sent to AI vendor without BAA	Yes	Notify affected patients, OCR
Training data containing PHI accessed by unauthorized party	Yes	Notify affected patients, OCR
AI system logs containing PHI exposed in a security incident	Yes	Notify affected patients, OCR
PHI included in AI API call to a vendor with a BAA; vendor has a breach	Yes (vendor must notify you)	Notify affected patients, OCR
PHI accidentally included in a test query that was immediately deleted	Possibly — apply four-factor test	Document assessment

The Four-Factor Test for Low Probability

Before concluding that an impermissible disclosure does not constitute a breach, you must assess:

The nature and extent of the PHI involved (type and amount)
Who used or received the PHI (authorized person? malicious actor? AI vendor?)
Whether the PHI was actually acquired or viewed
The extent to which the risk has been mitigated

This assessment must be documented. You cannot conclude "no breach" without a documented four-factor analysis.

Notification Timeline

To affected individuals:

Without unreasonable delay, and no later than 60 days after discovery
Must include: description of breach, PHI involved, steps individuals should take, what you're doing to investigate, contact information

To the Department of Health and Human Services (HHS/OCR):

Small breaches (<500 individuals): Annually, no later than 60 days after end of calendar year
Large breaches (≥500 individuals): Without unreasonable delay, no later than 60 days after discovery

To prominent media (if ≥500 individuals in a state or jurisdiction):

Without unreasonable delay, no later than 60 days after discovery

Section 13: HIPAA and the HITECH Act

The Health Information Technology for Economic and Clinical Health (HITECH) Act, enacted in 2009, significantly strengthened HIPAA in ways directly relevant to AI.

Key HITECH Provisions

Expanded Business Associate Liability: HITECH made business associates directly liable under HIPAA — not just through contractual obligations. AI vendors who are business associates can be investigated and fined directly by OCR, independent of the covered entity.

Enhanced Penalties: HITECH introduced the current tiered penalty structure (Tiers 1–4) with significantly higher maximums than the original HIPAA penalties.

Accounting of Disclosures for EHRs: HITECH requires that when patients request an accounting of disclosures from an EHR, disclosures for treatment, payment, and operations must be included. This creates additional audit trail obligations for AI systems integrated with EHRs.

Breach Notification: HITECH introduced the federal Breach Notification Rule (the 60-day requirement).

Enforcement: HITECH authorized state attorneys general to bring civil actions on behalf of state residents for HIPAA violations — expanding enforcement beyond OCR.

Section 14: State Law Considerations

HIPAA establishes a federal floor. State laws may impose stricter requirements.

When State Law Preempts HIPAA

HIPAA preempts state law unless state law is more protective of patient privacy. Where state law is stricter, organizations must comply with both.

States With Notably Stricter Health Privacy Laws

State	Key Provisions Relevant to AI
California (CMIA, CPRA)	Broader definition of medical information; CPRA adds consumer privacy rights applicable to health data
Washington (My Health MY Data Act)	Broad definition of consumer health data; applies to non-HIPAA entities; consent requirements
Nevada (SB 370)	Health data privacy requirements for consumer-facing health products
New York (SHIELD Act)	Broad data security requirements applicable to health data

For AI teams operating nationally: State health privacy law is a rapidly evolving area. The Washington My Health MY Data Act in particular has broad applicability and extends well beyond HIPAA-covered entities. Legal counsel review of state-specific obligations is strongly recommended.

Section 15: Compliance Readiness Assessment

HIPAA compliance is ongoing, not a one-time event.

Building HIPAA-aligned AI systems is a continuous governance practice.

Pre-Deployment Checklist

All PHI flows through AI systems mapped and documented
Risk analysis completed and documented for all AI systems handling PHI
Business Associate Agreements signed with all PHI-handling vendors
Minimum necessary standard applied and documented for each AI use case
Technical safeguards implemented (encryption, access controls, audit logging)
PHI detection and output monitoring operational
Breach detection and response plan documented and tested
Workforce training completed for staff with PHI access
Privacy and Security Officers designated

Post-Deployment (First 3 Months)

Audit logs reviewed for unauthorized PHI access
AI outputs monitored for inadvertent PHI disclosure
BAA coverage verified as new vendors are added
Minimum necessary determinations reviewed
Breach response procedures tested

Ongoing (Continuous Governance)

Annual risk analysis review (or after significant system changes)
Regular audit log review for access anomalies
Workforce training refreshed annually
BAAs reviewed when vendor terms change
State law developments monitored
OCR guidance on AI and HIPAA monitored

What an OCR Investigator Would Ask

If the Office for Civil Rights investigates, can you answer these?

"Show me your risk analysis for this AI system."
"Show me your Business Associate Agreements with your AI vendors."
"How do you enforce the minimum necessary standard in your AI pipelines?"
"How do you detect PHI in AI outputs?"
"Show me your audit logs for PHI access in this system."
"How do you respond to a patient's right of access request?"
"Show me your breach notification procedures."
"How do you ensure PHI is encrypted in transit when sent to AI APIs?"

If you can answer all 8 with documentation, you are significantly better positioned to demonstrate HIPAA compliance readiness.

SpanForge SDK: Implementing HIPAA Obligations

The SpanForge SDK provides the PHI access controls, audit logging, and de-identification infrastructure that HIPAA requires — with HMAC-signed evidence packages that map directly to the Security Rule safeguards your auditors need to see.

Safeguard-to-SDK Mapping

HIPAA Rule / Section	Requirement	SpanForge Capability	Event Types
§164.312 — PHI Access Controls	PHI access audit trail	`sf-audit`, HMAC audit chains	`llm.audit.`, `llm.trace.`
§164.312 — PHI Audit Controls	Tamper-evident access logs	HMAC audit chains with gap detection	`llm.audit.*`
§164.312(e) — PHI Transmission	No PHI in telemetry	`SFPIIClient` PII redaction pipeline	`llm.redact.*`
§164.308 — Administrative Safeguards	Model governance and oversight	Model Registry, T.R.U.S.T. Scorecard	`model_registry.*`
HIPAA Safe Harbor	De-identify 18 PHI identifiers	`SFPIIClient.safe_harbor_deidentify()`	—
§164.308(a)(6) — Incident Procedures	Detect and respond to PHI incidents	Alert routing (`sf-alert`), breach detection	`llm.guard.*`

Generating Your HIPAA Evidence Package

from spanforge.core.compliance_mapping import ComplianceMappingEngine

engine = ComplianceMappingEngine()
package = engine.generate_evidence_package(
    model_id="your-model-id",
    framework="hipaa",
    from_date="2026-01-01",
    to_date="2026-03-31",
)

print(package.gap_report)     # safeguard-by-safeguard coverage gaps
print(package.attestation)    # HMAC-signed attestation for auditors

Or via CLI:

spanforge compliance generate \
  --model-id your-model-id \
  --framework hipaa \
  --from 2026-01-01 \
  --to 2026-03-31

Key SDK Features for HIPAA Compliance

HIPAA Safe Harbor De-identification — SFPIIClient.safe_harbor_deidentify(text) removes all 18 PHI identifier categories before data leaves your AI pipeline
PHI Audit Trail — Every PHI access generates llm.audit.* events; HMAC chaining makes the log tamper-evident
Zero-Egress PII Redaction — Runs fully locally; no PHI is sent to external services for scanning
Air-Gapped Deployment — Full offline mode with zero egress for environments where PHI cannot leave the network
Encryption at Rest — AES-256-GCM with envelope encryption via cloud KMS; FIPS 140-2 mode available

SDK Reference: Compliance & Tenant Isolation · PII Redaction · Evidence Export

Section 16: Getting Started

Building an operational HIPAA AI governance infrastructure is not a one-time project.

Your specific situation is more complex than this guide can address because:

Your PHI flows are unique. The health data your AI processes and how it moves through your systems is specific to your architecture.
Your vendor landscape is unique. Which AI APIs, cloud platforms, and data services you use determines your BAA obligations.
Your patient population is unique. The sensitivity of the conditions, the state laws that apply, and patient expectations differ by use case.
Your risk profile is unique. Some risks matter more for your clinical context, patient population, and regulatory environment.

What You Need to Build HIPAA-Aligned AI

To move from "I understand HIPAA" to "my AI systems are actually compliant," you need:

Assessment: What are YOUR specific HIPAA obligations for YOUR AI systems?
Custom approach: What does HIPAA-aligned AI look like for YOUR architecture and clinical workflows?
Implementation support: How do you actually build PHI detection, audit trails, and breach detection?
Continuous governance: How do you stay compliant as AI systems evolve and vendors change?

Next Step

Schedule a 30-minute HIPAA Readiness Assessment.

During this call, we'll:

Review your AI systems and PHI flows
Identify gaps in BAA coverage
Assess your current risk analysis and technical safeguards
Create a recommended implementation approach
Discuss implementation timeline and next steps

No pressure. No sales pitch. Just expert guidance on building HIPAA-aligned AI systems.

Section 17: About SpanForge

SpanForge helps organizations build governance-ready AI systems. We provide the governance infrastructure, continuous monitoring, and operational compliance workflows needed to meet HIPAA, GDPR, EU AI Act, and broader regulatory requirements — while maintaining patient trust. From assessment through implementation and beyond, we help you move from compliance concepts to compliance practice.

Section 18: Resources & Next Steps

What's Included in This Guide

What You'll Need Beyond This Guide

Legal counsel: For definitive HIPAA interpretation specific to your organization, use cases, and state
Technical implementation support: For PHI detection, audit trails, BAA workflows, and output monitoring in your specific architecture
Privacy and governance infrastructure: For continuous HIPAA compliance as your AI systems evolve

This Is the Starting Point

This guide is designed to:

Build awareness of HIPAA obligations specific to AI
Show you what's necessary for HIPAA-aligned AI
Help you assess your current state relative to obligations
Demonstrate the scope of work required

It's not designed to be a complete compliance solution. That's where operational AI privacy governance comes in.

Schedule Your Free Assessment

Ready to understand your specific HIPAA obligations?

Schedule a 30-minute HIPAA Readiness Assessment →

We'll help you understand:

Your specific HIPAA obligations
Current compliance readiness across your AI systems
Recommended implementation approach
Implementation timeline and next steps

Contact {#contact}

Schedule Your 30-Minute HIPAA Readiness Assessment

→ sriram@getspanforge.com

We'll help you build HIPAA-aligned AI systems designed to:

Protect patient privacy
Satisfy OCR requirements
Support patient rights
Pass vendor security assessments

Disclaimer

This is an educational guide, not legal advice.

HIPAA compliance depends on:

Whether your organization is a covered entity, business associate, or both
The specific PHI your AI systems process
Your deployment context, use cases, and clinical workflows
Applicable state laws, which may be stricter than HIPAA
OCR guidance and enforcement priorities, which continue to evolve
The terms of your specific Business Associate Agreements

For definitive legal advice, consult with qualified legal counsel specializing in healthcare privacy law and HIPAA compliance.

This guide reflects current understanding as of May 2026. OCR guidance on AI-specific HIPAA obligations continues to develop.

HIPAA Compliance Roadmap for AI Teams 2026 Building Privacy-Governed AI Systems in Healthcare Brought to you by SpanForge May 2026

Ready to move from understanding to implementation?

Schedule an assessment Explore the SDK