What is the HIPAA Security Rule?

The HIPAA Security Rule establishes national standards to protect the confidentiality, integrity, and availability of electronic protected health information (ePHI) through administrative, physical, and technical safeguards.

What is considered a HIPAA violation in cybersecurity?

A HIPAA violation occurs when PHI or ePHI is impermissibly used or disclosed or insufficiently safeguarded. Common causes include weak access controls, missing risk analyses, unencrypted devices, improper workforce training, and delayed breach reporting.

What are administrative, physical, and technical safeguards?

Administrative safeguards are policies, procedures, and training. Physical safeguards protect facilities and devices. Technical safeguards include access controls, audit logging, transmission security, and encryption.

Is a HIPAA risk assessment required annually?

HIPAA requires a regular and thorough risk analysis but does not mandate a specific frequency. Many organizations perform it annually and whenever significant changes occur, such as new systems, vendors, or workflows.

What should a HIPAA risk assessment include?

It should identify where ePHI resides, evaluate threats and vulnerabilities, assess likelihood and impact, review current controls, document risk levels, and define prioritized remediation steps and timelines.

What is the role of encryption in HIPAA compliance?

Encryption is an addressable implementation specification. If reasonable and appropriate, it should be implemented for data at rest and in transit. If not implemented, the decision must be documented and an equivalent alternative safeguard applied.

What is a Business Associate under HIPAA?

A Business Associate is any person or organization, other than a workforce member of a covered entity, that creates, receives, maintains, or transmits PHI on behalf of a covered entity. Examples include cloud providers, IT support, billing services, and certain consultants. A Business Associate Agreement (BAA) is required before PHI access.

Do business associates need to be HIPAA compliant?

Yes. Business associates must implement appropriate safeguards for PHI, comply with applicable HIPAA requirements, enter into a BAA, report incidents and breaches, and ensure their subcontractors that handle PHI also comply.

What happens if a business associate causes a breach?

Both the covered entity and the business associate have obligations. The business associate must investigate, mitigate, and notify the covered entity. Breach notifications to individuals, HHS, and in some cases the media may be required based on the incident size and circumstances.

How do I secure remote access to ePHI?

Use VPN or zero-trust access, require multi-factor authentication, enforce least-privilege access, encrypt devices, manage endpoints and patches, disable local data storage when possible, and monitor logs for suspicious activity.

Can employees use personal devices under HIPAA?

Yes, if governed by a BYOD policy that enforces device encryption, screen locks, remote wipe, mobile device management, separation of work data, and prohibits storing ePHI in unsecured apps or locations.

What is considered a HIPAA data breach?

A breach is an impermissible use or disclosure of unsecured PHI that compromises its security or privacy, such as ransomware, lost or stolen devices, misdirected emails, or unauthorized access, unless a documented risk assessment shows a low probability of compromise.

How soon must a HIPAA breach be reported?

Affected individuals must be notified without unreasonable delay and no later than 60 days after discovery. Reporting to HHS depends on the number of affected individuals; large breaches (500 or more) require more immediate reporting and, in some cases, media notice.

What are the penalties for HIPAA violations?

HIPAA penalties vary by tier based on level of culpability, with per-violation amounts and annual caps per violation type. Enforcement may include corrective action plans, settlement amounts, and monitoring. Actual amounts depend on the facts and current HHS guidance.

Can my practice be audited for HIPAA compliance?

Yes. HHS’s Office for Civil Rights conducts audits and investigations, particularly after breaches or complaints. Maintaining documentation, training records, and current risk analyses helps demonstrate compliance readiness.

What documentation is required to prove HIPAA compliance?

Keep current risk analyses, remediation plans, security and privacy policies, workforce training logs, incident response procedures, business associate agreements, access audit logs, and evidence of ongoing monitoring and evaluations.

What Does HIPAA Compliant AI Look Like for Health Tech?

Jun 4

Written By L Trotter II

HIPAA Compliant AI for health tech companies doesn't require a new framework or certification. It requires the same HIPAA Security Rule controls — risk analysis, access controls, Business Associate Agreements, encryption, and audit logs — applied to every are where AI touches Protected Health Information. The HIPAA Security Rule is technology-neutral by design, which means it covers AI the same way it covers databases and cloud systems. The one area where AI requires additional governance is model drift monitoring. Compliance is proven through documentation and evidence, not a certification.

A CIO at a health tech company reached out recently.

His product uses AI.

A health system just sent him a security questionnaire.

The AI section alone had 15 questions.

He assumed he needed a new compliance framework.

A new audit.

Or a new certification process specifically for AI.

He didn't.

HIPAA Compliant AI isn't a new standard.

It's the same standard applied to new technology.

(We didn't change HIPAA for applications, IoT, or blockchain)

The questions buyers ask aren't new.

They trace back to the same controls that have been in the HIPAA Security Rule since 2003.

The technology changed.

The requirements didn't.

The Misconception Costing Health Tech CIOs Deals

Everyone is treating AI Compliance like a new category.

New frameworks are being sold.

New certifications are being marketed.

New audits are being positioned as the answer.

Here's what's actually true:

OCR has not published AI-specific HIPAA guidance.

The HIPAA Security Rule is the framework...and it was written to be technology-neutral by design.

That means it applies to databases, cloud systems, mobile apps, and AI models the same way.

What changed when your product added AI features?

The number of places where PHI can enter, live, and exit your system expanded.

HIPAA Compliance didn't.

👉 If you're fielding security questionnaires about your AI product right now, the Security Review Playbook breaks down the 5 things health system buyers score in every vendor review. Request it here.

The Five Controls That Make AI HIPAA Compliant

These are some of the controls that have always been required under the HIPAA Security Rule.

Applied to AI, here's what each one actually means:

1. Risk Analysis

Does your AI product introduce new PHI exposure points?

Where does PHI enter the model?

Where does it live?

Where does it exit?

A risk analysis that doesn't include your AI features isn't a complete risk analysis.

If your last risk assessment was completed before you added AI, it's already outdated.

2. Access Controls

Who has access to model endpoints?

Who can query the model?

Who has access to training data?

Who has access to outputs?

Role-based access controls apply to AI the same way they apply to any system that touches PHI.

(According to IBM's 2025 Cost of a Data Breach Report, 97% of organizations that experienced an AI-related breach lacked proper AI access controls.)

If your engineers have unrestricted access to model endpoints in production, that's a gap.

3. Business Associate Agreements

Your AI hosting provider touches PHI.

Your model provider may touch PHI.

Every third-party integration that feeds data into or receives data from your AI system touches PHI.

Every one of them needs a BAA.

This is a commonly missed control in AI risk analysis.

Because CIOs overlook mapping all AI dependencies to the HIPAA BAA requirement.

4. Encryption

PHI in transit to and from the model needs to be encrypted.

PHI at rest...

PHI in training data...

PHI in logs...

And PHI in outputs needs to be encrypted.

The question health system buyers ask: "Is PHI in the LLM encrypted?"

The correct answer isn't yes or no.

It's a documented explanation of where PHI lives in your AI architecture and how encryption is handled in each layer.

5. Audit Logs

Can your system produce logs of who accessed what, when?

Can you show what was attempted, not just what succeeded?

Health system security teams want evidence.

👉 The Health Tech AI Readiness Self-Assessment maps your AI governance against all five of these controls. Know your gaps before your buyer finds them.

Most AI Vendors Overlook The Privacy Rule

The HIPAA Security Rule governs how you protect PHI with technical controls.

The Privacy Rule governs how you use it.

Both apply to your AI product.

Here are two Privacy Rule requirements health tech CIOs need to address specifically for AI:

Minimum Necessary Standard

Your AI system should only access and process the PHI required for the specific task it's performing.

If your model can access a patient's full record but only needs a diagnosis code...that's a minimum necessary violation waiting to happen.

According to IBM's 2025 Cost of a Data Breach Report, shadow AI (employees using unsanctioned AI tools without approval), was a factor in 20% of all breaches.

Every one of those incidents could be a minimum necessary violation.

Employees accessing PHI through tools that haven't been vetted, approved, or restricted to what's actually needed.

Health system buyers will ask: how does your AI limit PHI access to what's actually needed?

If the answer is "it has access to everything," that's a gap.

Consent

Certain uses of PHI by AI require patient authorization beyond standard treatment, payment, and operations purposes.

If your AI product uses PHI for model training, research, or any purpose outside the health system's stated operations...you need to be transparent with the health system.

This is the question health system legal teams are asking more frequently as AI adoption expands.

The short version: the Privacy Rule requires health systems to know what your AI does with PHI, not just that you protect it.

The One Thing That Is Different About AI

HIPAA Compliance for AI is mostly the same as HIPAA Compliance for any other technology.

But there is one area where AI requires additional thinking beyond standard controls.

Model drift.

A database doesn't change its behavior over time.

An AI model can.

Accuracy degrades.

Outputs shift.

Behavior drifts from baseline.

In a clinical context, model drift is a patient safety problem.

Traditional HIPAA controls don't fully address this.

Monitoring model performance over time...tracking when outputs change, who's responsible for catching it, and how fast it gets corrected...is the one area where AI-specific governance adds value on top of standard HIPAA controls.

If your AI product touches clinical workflows and you don't have a model drift monitoring process, that's the gap most likely to surface in today's security review.

What Health System Buyers Are Asking

These are the questions that surface in vendor evaluations I respond to weekly:

This is not theoretical.

→ Do you have a BAA with your AI hosting provider?

→ Can the solution produce audit logs?

→ Have you identified and measured AI risks?

→ Has your staff completed responsible AI training?

→ How do you monitor for model drift?

The first four are standard HIPAA Security Rule questions applied to AI.

The fifth is the AI-specific addition.

If you can answer all five with documented evidence, you're ahead of most health tech vendors in the market.

What This Means for Your Next Security Review

If your HIPAA Compliance program is solid, you're closer to HIPAA Compliant AI than you think.

The gap is almost always documentation.

Your existing HIPAA controls already cover most of this.

The work is applying them to every AI feature and documenting it.

Audit your current HIPAA controls against every AI feature in your product.

Map your BAAs to every AI third-party you use.

Confirm your audit logs cover AI inputs and outputs.

Document your model drift monitoring process.

Then answer the five questions above with evidence.

👉 If you want to know exactly where your AI governance stands before your next security review, take the Health Tech AI Readiness Self-Assessment.

FAQ

Q: What does HIPAA Compliant AI look like for health tech companies?

HIPAA Compliant AI means applying the existing HIPAA Security Rule controls — risk analysis, access controls, Business Associate Agreements, encryption, and audit logs — to every area where AI touches Protected Health Information. There is no AI-specific HIPAA certification. Compliance is demonstrated through documentation and evidence.

Q: Do you need a BAA for AI tools that touch PHI?

Yes. Any AI hosting provider, model provider, or third-party integration that processes, stores, or transmits Protected Health Information requires a signed Business Associate Agreement. Mapping every AI dependency to the BAA requirement is one of the most commonly missed steps in AI compliance.

Q: Can data in LLMs be encrypted under HIPAA?

Yes, and HIPAA requires it. PHI must be encrypted in transit to and from the model, and at rest in training data, logs, and outputs.

Q: What is the difference between HIPAA Compliance for AI and other technology?

HIPAA Compliance for AI uses the same Security Rule and Privacy Rule controls as any other technology. The one meaningful difference is model drift — because AI model behavior can change over time, monitoring model performance is an AI-specific governance requirement that traditional HIPAA controls don't fully address.

L Trotter II

As Founder and CEO of Inherent Security, Larry Trotter II is responsible for defining the mission and vision of the company, ensuring execution aligns with the business purpose. Larry has transformed Inherent Security from a consultancy to a cybersecurity company through partnerships and expert acquisitions. Today the company leverages its healthcare and government expertise to accelerate compliance operation for clients.

Larry has provided services for 12 years across the private industry developing security strategies and managing security operations for Fortune 500 companies and healthcare organizations. He is influential business leader who can demonstrate the value proposition of security and its direct link to customers.

Larry graduated from Old Dominion University with a bachelor’s degree in Business Administration with a focus on IT and Networking. Larry has accumulated certifications such as the CISM, ISO27001 Lead Implementer, GCIA and others. He serves on the Board of Directors for the MIT Enterprise Forum DC and Baltimore.

https://www.inherentsecurity.com