HIPAA-Compliant AI for Healthcare SMBs: What You Actually Need to Know
Most AI vendors claim HIPAA readiness. Very few can back it up with signed BAAs, documented access controls, and audit trails that survive OCR scrutiny. This guide walks through what the law actually requires and how to build AI systems that meet it.
- HIPAA applies to any AI system that touches, stores, transmits, or processes protected health information, regardless of whether it was built for healthcare.
- OCR fines for HIPAA violations range from $100 to $50,000 per violation per record, and willful neglect cases have resulted in multi-million dollar settlements.
- A Business Associate Agreement must be signed before any PHI reaches a vendor's system, including AI tools, not after deployment.
- SOC 2 Type II certification does not equal HIPAA compliance. They measure different things and one cannot substitute for the other.
- Public LLM APIs from OpenAI, Anthropic, and Google do not offer BAAs on standard plans, which means sending PHI through them is a direct HIPAA violation.
- Private LLM deployment on infrastructure you control, or with vendors offering signed BAAs and HIPAA-aligned data handling, is the only architecturally sound path for healthcare SMBs.
What HIPAA Actually Says About AI
HIPAA does not have a dedicated section on artificial intelligence. It was written in 1996, updated in 2013 under the Omnibus Rule, and the statute itself doesn't mention machine learning models or large language models anywhere. That gap is exactly what makes it dangerous for healthcare SMBs trying to adopt AI today. The rules still apply, and OCR has been consistent in applying them to any technology that processes protected health information.
The definition of PHI under HIPAA is broad. It covers any individually identifiable health information that is created, received, maintained, or transmitted by a covered entity or business associate. That includes names, dates of service, diagnosis codes, billing records, appointment notes, prescription histories, and even partial identifiers that could reasonably be used to identify a patient. If your AI system touches any of that data, even to summarize a note, route a call, or generate a billing code, it's operating in regulated territory.
The Security Rule requires covered entities to implement administrative, physical, and technical safeguards to protect electronic PHI. The Privacy Rule governs who can access PHI and under what circumstances. The Breach Notification Rule sets timelines and procedures when something goes wrong. All three apply to AI systems the same way they apply to EHR software or a fax machine sitting in your front office.
Where it gets interesting is the business associate framework. HIPAA defines a business associate as any entity that creates, receives, maintains, or transmits PHI on behalf of a covered entity. An AI vendor whose model processes your patient intake forms is a business associate by definition. That means a signed Business Associate Agreement must be in place before any PHI flows through their system, not after you've been using it for three months and someone asks about compliance.
OCR has made clear through enforcement actions that ignorance of a vendor's status as a business associate is not a defense. Fines run from $100 to $50,000 per violation per affected record, with annual caps that can still reach $1.9 million per violation category. A single unsecured AI tool processing intake forms for a practice seeing 200 patients a week can generate a compliance exposure that no small practice can absorb.
The practical upshot is this: HIPAA doesn't care what category of technology you're using. It cares whether PHI is protected. Before you connect any AI tool to patient data, scheduling systems, billing software, or clinical notes, you need to understand which HIPAA rules apply and verify that your vendor can actually meet them.
HIPAA-Ready vs. HIPAA-Compliant: A Critical Difference
We see this constantly in vendor sales decks: a company describes their platform as 'HIPAA-ready' or 'designed with HIPAA in mind.' These phrases mean almost nothing. They signal awareness of HIPAA's existence, not the ability to actually support your compliance obligations.
HIPAA compliance is not a certification. There is no government body that certifies a vendor as HIPAA-compliant the way PCI DSS has its certification hierarchy. Compliance is a continuous organizational responsibility, and it lives with the covered entity, meaning you, the practice owner or office manager. What a vendor can do is contractually commit to specific behaviors that support your compliance program. That commitment lives in the BAA, and the BAA is only as strong as what's actually written in it.
A HIPAA-ready vendor typically means they have a template BAA available, some documentation about their security practices, and probably encryption in transit. It does not mean they've mapped their data flows to the HIPAA Security Rule's 54 implementation specifications. It does not mean they can tell you exactly where your patient data sits at rest, who has access to it, how long it's retained, or what happens to it when you terminate your contract.
SOC 2 Type II is a useful signal but a common source of confusion here. SOC 2 Type II means an auditor has reviewed a company's security controls over a period of time and found them operating effectively. That's meaningful. But SOC 2 Type II audits are scoped to the Trust Service Criteria chosen by the vendor, which typically include security, availability, and confidentiality. Those criteria do not map one-to-one to HIPAA's requirements. A company can earn a clean SOC 2 Type II report and still lack HIPAA-specific controls like PHI access logging, workforce training documentation, or a compliant breach notification process. One does not substitute for the other.
The question to ask every vendor is not 'are you HIPAA compliant?' That question produces a yes answer from almost everyone. The questions that actually surface meaningful information are: Will you sign our BAA before we share any patient data? Can you provide your data flow diagram showing exactly where PHI is processed and stored? What is your breach notification timeline? How do you handle subcontractors who touch our data, and are they also covered by BAA obligations?
A mid-sized physical therapy group we worked with had been using an AI scheduling assistant for eight months before they realized the vendor had never signed a BAA. The vendor had SOC 2 Type II. The sales team had verbally confirmed HIPAA support. The contract had a privacy policy that mentioned HIPAA. But no BAA existed, which meant eight months of patient scheduling data had flowed through a system with no contractual HIPAA protections. Remediating that situation required a risk assessment, gap analysis, and a notification review. It was expensive and entirely avoidable.
When a vendor can't clearly answer the BAA question or delays getting you a signed agreement, that tells you something important about how seriously they treat compliance obligations. Move on.
Why Public LLM APIs Typically Fail HIPAA
The most common AI mistake we see healthcare SMBs make is routing patient data through public LLM APIs without understanding the compliance implications. This includes OpenAI's API, Anthropic's Claude API, Google's Gemini API, and similar services accessed via standard developer accounts. The capability of these models is real. The compliance problem is also real, and the two facts exist simultaneously.
The core issue is the BAA. On standard plans and API tiers, none of the major LLM providers offer a Business Associate Agreement. OpenAI has stated in its documentation that its standard API terms do not support HIPAA compliance and that users should not send PHI through the standard API. Without a signed BAA, any PHI you send through these endpoints is a potential HIPAA violation, regardless of whether the data is encrypted in transit.
Some providers do offer HIPAA-eligible configurations, but they require enterprise contracts, specific architectural constraints, and sometimes dedicated infrastructure. OpenAI offers a path to a BAA through certain enterprise agreements. Microsoft Azure OpenAI Service can be configured in a HIPAA-eligible environment. Google Cloud's Vertex AI platform has HIPAA-eligible services. But these are not the default configurations most developers or office managers are using when they start experimenting with AI tools. They require negotiated contracts, additional costs, and implementation work that goes well beyond signing up for an API key.
Beyond the BAA issue, public LLM APIs present other HIPAA concerns. Most providers use prompts and completions for model improvement unless you explicitly opt out, which means patient data you send through the API could potentially be used to train future model versions. Even with opt-out, you're relying on contractual assurances rather than technical controls that prevent training data ingestion. The HIPAA Security Rule prefers technical safeguards over administrative ones precisely because technical controls are harder to accidentally circumvent.
There's also the matter of data residency. Public LLM APIs typically don't guarantee that your data stays within a specific geographic boundary or on dedicated infrastructure. For practices subject to state-level health privacy laws that go beyond HIPAA, like California's CMIA or New York's SHIELD Act, this creates additional exposure.
We've seen small practices build what they thought were clever internal tools: a staff member would paste clinical notes into a ChatGPT prompt to generate a patient summary, or a front desk coordinator would use a public AI chatbot to draft appointment reminder messages that included patient names and appointment types. Both scenarios involve PHI being transmitted to a third-party system with no BAA in place. Both are violations. Both could result in OCR fines. The people doing this weren't being reckless. They were solving real problems with tools that were readily available. The compliance infrastructure just wasn't there.
The responsible path with any public LLM API is to treat it as off-limits for PHI until you have a signed BAA in place, have reviewed the specific HIPAA-eligible configuration requirements, and have verified that the architectural constraints you're operating under actually satisfy your Security Rule obligations. That bar is higher than most SMBs realize.
Vendor Due Diligence: What to Demand Before You Sign
Evaluating an AI vendor for healthcare use requires a different process than buying accounting software or a marketing platform. The stakes are higher, the regulatory requirements are specific, and the vendor market is full of companies that understand the opportunity in healthcare without fully understanding the obligations.
Start with the BAA before anything else. Not late in the sales process, not after a pilot, before any PHI touches their system. A vendor who pushes back on this, delays, or asks you to start with a proof of concept using 'de-identified' data you've prepared yourself is signaling that BAA execution is not a routine part of their process. That's a red flag. Mature healthcare-focused vendors have standard BAAs ready and will execute them early in the conversation.
Once you have a draft BAA, read it carefully. The BAA must specify what the vendor is permitted to do with your PHI, what security safeguards they maintain, their breach notification obligations to you (HIPAA requires notification within 60 days of discovery), and what happens to your data when the agreement ends. Vague language in any of these areas should trigger specific questions, and if the answers aren't satisfactory, the language should be changed before signing.
After the BAA, request their security documentation. Ask for their most recent SOC 2 Type II report, their penetration testing summary, their vulnerability management policy, and their workforce training documentation. A vendor who can't produce these documents, or who offers only marketing summaries instead of actual audit reports, hasn't been through the scrutiny that healthcare data handling requires.
Ask specifically about subprocessors. In the AI context, an LLM vendor may use cloud infrastructure providers, monitoring tools, or third-party APIs that also touch your data. Every subprocessor who handles PHI is also a business associate under HIPAA, and your vendor's BAA should extend to their subprocessors. Ask for the list and verify that each one is covered.
For AI systems specifically, ask how the model handles PHI in prompts and completions. Is patient data used for model training? If so, is there an opt-out mechanism and is it contractually binding? Is inference happening on dedicated infrastructure or shared compute? Where is the model running, and where is the output stored? For systems that involve persistent memory or context windows, how long is conversation data retained and who has access to it?
Ask about their incident response process. When they discover a potential breach affecting your patients, what happens and in what sequence? HIPAA requires that covered entities notify affected individuals within 60 days of discovery, notify HHS, and in cases affecting more than 500 residents of a state, notify prominent media outlets. Your vendor needs to notify you quickly enough that you can meet those deadlines. If their breach notification timeline is vague, that's a problem you'll discover at the worst possible time.
One dental group we worked with had gone through a thorough RFP process for an AI patient communication tool, collected SOC 2 reports, reviewed the BAA, and felt confident in their selection. What they hadn't asked was whether the vendor's AI was calling out to a third-party LLM API to generate responses. It was, and that API provider had no BAA in place. The primary vendor's SOC 2 covered their own infrastructure, but the AI inference was happening outside their controlled environment. Subprocessor review caught this in our audit. They renegotiated the contract to require that inference happen within the vendor's BAA-covered environment. The lesson is that vendor due diligence in the AI context has to go deeper than the primary vendor relationship.
Private LLM Deployment Architecture for Healthcare SMBs
Private LLM deployment means running an AI model in an environment you control or that is contractually dedicated to your organization, rather than sending data to a shared public API. For healthcare SMBs, this is the architecture that most reliably satisfies HIPAA's technical safeguard requirements while still delivering the productivity benefits that make AI worth deploying.
The spectrum of private deployment has several points. At the more accessible end, you have managed private deployments through HIPAA-eligible cloud services. Microsoft Azure and Amazon Web Services both have HIPAA-eligible service configurations, and both offer ways to run LLM inference within those configurations. Azure OpenAI Service in a properly configured Azure Government or commercial HIPAA-aligned environment, with a signed BAA with Microsoft (which Microsoft does offer), is a defensible architecture. The same is true for AWS Bedrock in a HIPAA-eligible configuration with a signed AWS BAA.
These managed approaches work well for SMBs that don't have the engineering staff to maintain their own AI infrastructure. The key is that you're not sharing compute or data pipelines with other organizations, the inference happens within your cloud environment, and the provider has contractually committed to HIPAA-compliant data handling through the BAA.
Further along the spectrum, you have self-hosted open-source models. Options like Meta's Llama series, Mistral, and Phi run on your own servers or on cloud virtual machines you provision and manage. The model weights live in your environment. Patient data never leaves your infrastructure. This approach gives you the strongest technical control and the clearest compliance story. It also requires more engineering effort and ongoing maintenance.
For most healthcare SMBs, the right answer sits somewhere between these poles. A practice with 3 to 15 physicians doesn't have an internal ML engineering team, but they can work with a qualified implementation partner who sets up a HIPAA-eligible cloud deployment, connects it to their EHR through compliant APIs, and documents the architecture for their compliance program.
The EHR integration layer deserves special attention. Systems like Epic, Athenahealth, and DrChrono expose patient data through APIs, and those APIs have their own security requirements. Any AI system pulling data from your EHR needs to authenticate properly, request only the minimum necessary data for its function, log all access, and handle the data according to HIPAA's minimum necessary standard. Building this integration without logging PHI access is one of the most common technical gaps we see in healthcare AI deployments.
Audit logging is a non-negotiable component of the architecture. HIPAA requires covered entities to implement hardware, software, or procedural mechanisms that record and examine activity in information systems that contain or use electronic PHI. Your AI system needs to log who or what system accessed what patient data, when, and for what stated purpose. These logs need to be stored securely, retained appropriately, and reviewed regularly. If your AI vendor can't tell you what access logging looks like in their system, the architecture isn't ready for production use with PHI.
For practices that use AI-powered voice agents or conversational interfaces, telephone communications carry additional considerations. If your AI voice agent is integrated with a system like Twilio, the audio data handling must meet HIPAA requirements, and Twilio does offer a HIPAA-eligible configuration with a BAA. The recorded audio of patient calls, the transcription of those calls, and any clinical information derived from them all constitute PHI once they're tied to an identifiable patient. The architecture has to account for all of those data states.
Incident Response and Audit Requirements Under HIPAA
Having a compliant AI system at launch doesn't mean you're compliant six months later. HIPAA requires ongoing operations, not a one-time setup. For AI systems specifically, the incident response and audit requirements deserve detailed attention because the failure modes are different from traditional software.
HIPAA's Security Rule requires covered entities to implement policies and procedures to address security incidents. A security incident is defined broadly as the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an information system. Under that definition, a wide range of AI-related events qualify: a model generating output that includes PHI it shouldn't have accessed, an API key being exposed in a code repository, a prompt injection attack that causes an AI system to disclose patient records to an unauthorized user, or a vendor's infrastructure breach that exposes your data.
Your incident response plan needs to account for AI-specific scenarios that traditional IR plans don't cover. What happens if your AI scheduling system starts logging conversations to a location that isn't covered by your BAA? What if a model update changes how the system handles patient data in ways that break your compliance configuration? What if a staff member figures out they can extract PHI from an AI system by asking it the right questions? These aren't hypothetical edge cases. They're events we've seen happen in real healthcare SMB deployments.
The breach notification timeline is strict. When a breach of unsecured PHI occurs, covered entities must notify affected individuals within 60 days of discovering the breach, not 60 days after they finish investigating it. You must notify HHS. If the breach affects 500 or more patients in a single state, you must notify prominent media outlets in that state. The distinction between a security incident and a reportable breach, and the timeline for making that determination, needs to be clearly defined in your incident response policy before an incident happens.
On the audit side, HIPAA requires regular review of information system activity, including audit logs, access reports, and security incident tracking. For AI systems, this means reviewing who accessed the AI, what queries were made, what data was returned, and whether any anomalous patterns are visible. Most healthcare SMBs don't have dedicated security staff, which means this review needs to be built into someone's regular responsibilities with clear documentation that it's happening.
HHS OCR has ramped up its audit activity, including a random audit program that can target covered entities with no prior complaints or violations. In an OCR audit, investigators will ask to see your risk analysis, your risk management plan, your workforce training records, your BAA inventory, and your audit log review history. For AI systems, they'll want to know how you evaluated each tool before deployment, what safeguards are in place, and how you've documented ongoing compliance.
A family medicine practice we worked with received an OCR inquiry following a patient complaint that had nothing to do with AI. During the review, OCR asked about all systems processing PHI. The practice had recently deployed an AI medical scribing tool. They had a BAA. They had documentation of the vendor evaluation. What they didn't have was evidence of regular audit log review or a documented risk assessment specific to the AI deployment. The resolution required producing those materials retroactively, which was harder and more expensive than building them into the deployment process from the start.
Build your audit review into your deployment plan. Set a calendar schedule for reviewing access logs. Document your risk assessments. Keep your BAA inventory current. These aren't bureaucratic exercises. They're the evidence trail that protects your practice if OCR ever knocks.
Common Compliance Mistakes SMBs Make When Adopting AI
The mistakes we see most often aren't caused by negligence. They're caused by moving fast in a market that's producing new AI tools every week, combined with compliance frameworks that were written before these tools existed. Here are the patterns we encounter regularly, and what to do instead.
The most common mistake is deploying AI tools before completing the BAA process. This happens more often in smaller practices where the office manager or a tech-savvy physician starts a trial of an AI tool without looping in whoever handles compliance. By the time the compliance officer or outside counsel reviews the situation, PHI has already been processed by a system with no contractual protections. The fix is making BAA execution a hard gate: no PHI-touching system goes live until the BAA is signed, reviewed, and stored in your agreement inventory.
The second most common mistake is treating vendor-provided documentation as a substitute for internal risk assessment. A vendor's SOC 2 report and their BAA are inputs to your risk assessment. They are not the assessment itself. HIPAA requires covered entities to conduct their own risk analysis that identifies the potential risks and vulnerabilities to ePHI in their specific environment. If you're deploying an AI medical scribing tool, your risk assessment needs to evaluate that specific tool in your specific workflow, not just trust that the vendor has done their homework.
Third: using public AI tools for internal workflows without thinking about data classification. Staff use of tools like ChatGPT, Gemini, or Claude for drafting messages, summarizing notes, or answering clinical questions can expose PHI without anyone intending it. A front desk employee who pastes a patient's name and appointment history into a public AI chatbot to draft a follow-up message has transmitted PHI to a system with no BAA. Workforce training on what constitutes PHI and which tools are cleared for use needs to be explicit, documented, and regularly refreshed.
Fourth: over-relying on encryption as a compliance answer. Encryption is important and HIPAA does require it as an addressable implementation specification under the Security Rule. But encryption does not satisfy HIPAA compliance on its own. A perfectly encrypted transmission of PHI to a vendor with no BAA is still a violation. Covered entities sometimes hear that their AI vendor uses AES-256 encryption and conclude the compliance box is checked. Encryption addresses one aspect of one rule. The full compliance picture involves access controls, audit logging, workforce training, BAAs, breach notification procedures, and documented risk management.
Fifth: not updating the risk assessment when AI systems are modified or updated. A model your vendor updates can behave differently with patient data than the version you evaluated. Integration changes, new feature rollouts, and vendor infrastructure migrations can all affect your compliance posture. Your risk management program needs to include a trigger for re-evaluation when significant changes happen to any system that processes PHI.
Sixth: not having a clear data deletion process at contract termination. When you stop using an AI vendor, what happens to the patient data their system has processed? HIPAA requires business associates to return or destroy PHI when the relationship ends. Your BAA should specify how this happens, in what timeframe, and how you'll receive verification. We've seen practices change vendors and simply stop using the old tool without ever requesting data deletion. That means patient data sits in a former vendor's system indefinitely with no ongoing contractual protections.
All of these mistakes are fixable. Most of them are preventable with a structured pre-deployment review process, a current BAA inventory, and workforce training that's specific enough to cover the tools people actually use. The practices that navigate AI adoption well are the ones that treat compliance as a design requirement, not an afterthought.
What we see in real deployments
After eight months of using an AI scheduling assistant, the practice discovered the vendor had never signed a BAA despite having SOC 2 Type II and verbal HIPAA support claims. Remediation required a full risk assessment, gap analysis, and notification review. The situation was entirely avoidable with a pre-deployment BAA requirement.
A thorough vendor review uncovered that the dental group's selected AI patient communication tool was routing inference through a third-party LLM API with no BAA in place. The primary vendor had SOC 2 coverage, but the AI inference happened outside their compliant environment. Contract renegotiation required inference to occur within the vendor's BAA-covered infrastructure before launch.
An OCR inquiry triggered by an unrelated patient complaint uncovered that the practice had deployed an AI medical scribing tool with a valid BAA but no documented risk assessment or audit log review schedule. Producing those materials retroactively was costly and time-consuming, reinforcing the value of building compliance documentation into the deployment process from the start.
Frequently asked questions
Does HIPAA apply to AI tools used in a medical practice?
Yes. HIPAA applies to any system that creates, receives, maintains, or transmits protected health information on behalf of a covered entity. If an AI tool processes patient names, appointment data, clinical notes, or billing information, it falls under HIPAA's requirements. The technology category doesn't create an exemption.
Can I use ChatGPT or Claude in my medical practice?
Not with patient data on standard plans. OpenAI and Anthropic do not offer Business Associate Agreements on their standard API or consumer plans, which means sending PHI through those services is a HIPAA violation. Some enterprise configurations of these platforms can be made HIPAA-eligible with a signed BAA and appropriate architectural constraints, but that requires a negotiated enterprise contract, not a standard account.
What is a Business Associate Agreement and why does it matter for AI?
A BAA is a contract between a covered entity and any vendor that handles PHI on its behalf. It specifies the permitted uses of the data, the security safeguards the vendor will maintain, breach notification obligations, and data handling at contract termination. For AI tools, the BAA must be signed before any PHI enters the vendor's system. Without it, even a secure and well-intentioned tool creates HIPAA exposure.
Is SOC 2 Type II enough to confirm HIPAA compliance for an AI vendor?
No. SOC 2 Type II is a meaningful security credential, but it audits against the vendor's chosen Trust Service Criteria, which don't fully map to HIPAA's requirements. A vendor can hold a clean SOC 2 Type II report and still lack HIPAA-specific controls like PHI access logging, breach notification procedures, or minimum necessary access policies. Always require both a SOC 2 report and a signed, detailed BAA.
What are the fines for HIPAA violations involving AI tools?
OCR fines for HIPAA violations range from $100 to $50,000 per violation per affected record, with annual caps per violation category that can still reach $1.9 million. Willful neglect cases have produced multi-million dollar settlements. A single AI tool processing intake forms for a busy practice can generate substantial compliance exposure if PHI is being handled without a BAA.
What is a private LLM deployment and does my practice need one?
A private LLM deployment means running an AI model in an environment your organization controls or that is contractually dedicated to you, rather than using a shared public API. It's the architecturally cleanest way to satisfy HIPAA's technical safeguard requirements. Not every practice needs a fully self-hosted model. Many SMBs can use HIPAA-eligible cloud configurations through Microsoft Azure or AWS, with a signed BAA, to achieve the same goal with less infrastructure overhead.
What should I look for in a BAA for an AI vendor?
A compliant BAA should specify what the vendor is permitted to do with your PHI, what security safeguards they maintain, their breach notification timeline to you, how subprocessors are covered, and what happens to your data when the contract ends. Vague or missing language in any of these areas should be addressed before signing. The BAA is the legal foundation for your compliance posture with that vendor.
How do I conduct a HIPAA risk assessment for an AI tool?
Start by mapping every data flow: what PHI the tool accesses, how it's transmitted, where it's stored, who has access, and what happens to it after processing. Identify potential threats and vulnerabilities at each point in that flow. Evaluate your existing controls against those risks and document gaps. The assessment should be specific to the tool and your workflow, not generic. Update it whenever the tool changes significantly or your workflow changes.
Build AI Systems Your Patients and Auditors Can Trust
We design and deploy HIPAA-compliant AI for healthcare SMBs, from BAA review to private LLM architecture to ongoing audit support. Talk to us before you deploy, not after an OCR inquiry.