Get a BAA before any data flows.
No exceptions. No just for testing. No we will sign it later. If a vendor will not sign a BAA up front, they are not a candidate for any workflow that touches PHI.
Primer
What HIPAA actually requires of your AI tools.
Your compliance officer asked: is this HIPAA compliant? Most vendors will tell you yes. Here is what they should mean by that, what to verify, and what to walk away from.
The hook
Where this shows up.
HIPAA compliance is not a checkbox. It is a set of administrative, physical, and technical safeguards that work together to protect patient information. When a vendor claims their AI tool is HIPAA compliant, they are claiming compliance with a specific subset of those rules.
The technical safeguards are the ones you can verify. Here are the six that matter for AI tools, translated out of regulatory language and into questions you can ask in a vendor call.
The misconception
That HIPAA compliance is a binary status the vendor either has or does not.
What most people believe
HIPAA compliance is not certified. There is no government issued HIPAA stamp. A vendor saying we are HIPAA compliant is making a claim about their internal controls and their willingness to sign a Business Associate Agreement.
The verification is on you. Read the BAA. Read the data flow diagram. Test the technical safeguards. The penalty for trusting a vendor who exaggerates is a breach you have to report.
The better model
Six technical safeguards. Verify each one.
What actually works
HIPAA's Security Rule defines six required technical safeguards for any system that creates, receives, maintains, or transmits ePHI. AI tools are no exception. Here is what each one means and what to verify.
- 01
Access control.
Only authorized people can access the data. Verify: role based access, unique user IDs (no shared logins), automatic logoff, emergency access procedures.
- 02
Audit controls.
Every access to PHI is logged. Verify: who accessed what, when, from where. Logs are immutable. Retention meets your state requirements (often six years).
- 03
Integrity controls.
Data cannot be silently altered or destroyed. Verify: change tracking, checksums on stored data, backup procedures that include integrity verification.
- 04
Person and entity authentication.
The system knows who is logging in. Verify: multi factor authentication required, password complexity rules, account lockout after failed attempts.
- 05
Transmission security.
Data is encrypted in transit. Verify: TLS 1.2 or higher for all connections, including internal service to service traffic. No unencrypted endpoints.
- 06
Encryption at rest.
Data is encrypted on disk. Verify: encryption applies to the database, the backups, the logs, and any cached data. AES 256 minimum. Keys held separately.
Three decisions
Make these calls differently this week.
Read the data flow diagram. If they cannot show you one, walk away.
Where does the data go? Who has access at each hop? Is it encrypted at every point? A vendor who cannot draw the diagram does not understand their own system, which means you cannot verify it is safe.
Verify encryption end to end.
Not just the customer portal. Verify the database, the backups, the logs, the admin tools, the model training pipeline. PHI in any of these places needs the same protection.
How ByteWorthy uses this
What this looks like in our work.
We do this audit on day one of every healthcare engagement. It is part of the 01 architecture stage in our folder system. The output is a written compliance map that lives in the project folder forever, so the next contractor or auditor can see exactly what was verified and when.
When we deploy local AI for healthcare practices, we cover all six safeguards by default because the data never leaves your network. When we deploy cloud AI, we negotiate the BAA and document the data flow before any PHI is involved.
Keep reading