Every AI vendor selling into healthcare claims to be HIPAA compliant. Most of them are describing something far narrower than what your risk and compliance team needs to verify. If your organization is scaling AI-powered healthcare operations, the evaluation process starts before you read any vendor's compliance page. Signing a business associate agreement (BAA) makes a vendor a business associate under HIPAA. It doesn't make their product HIPAA compliant in any operationally meaningful sense. The distinction matters because your organization, as a covered entity, carries the liability when a vendor's implementation fails to meet the Privacy Rule or Security Rule requirements, regardless of what the BAA says.
What a real evaluation requires is understanding how each vendor handles protected health information (PHI) across the full deployment stack. HIPAA compliance isn't a checkbox — it's a technical and contractual posture you have to verify. Not just whether they'll sign paperwork.
HIPAA compliance isn't a certification. The health insurance portability and accountability act doesn't issue compliance certificates, and neither does HHS. When a vendor describes their product as HIPAA-compliant AI, they're making a self-assessed claim about their practices, not an independently verified status. What the claim typically covers: they'll sign a BAA, they store data on encrypted infrastructure, and they've conducted some form of risk assessment. None of that is sufficient to determine whether their deployment is appropriate for handling your PHI.
Covered entities — health systems, hospitals, group practices, and insurers — are required to enter into a BAA with any vendor that creates, receives, maintains, or transmits PHI on their behalf. That vendor becomes a business associate and takes on specific obligations under the law. But the BAA only governs the contractual relationship. The underlying technical and administrative safeguards required by the Security Rule are the covered entity's responsibility to verify: independently, through technical review, not vendor assurance.
HHS enforces HIPAA through the Office for Civil Rights. Fines reach $50,000 per violation per category, up to $1.9 million annually for repeated violations of the same type. When a vendor's infrastructure exposes PHI, the covered entity is accountable.
The business associate agreement establishes that a vendor accepts their obligations under HIPAA and takes on liability for breaches caused by their own failure to comply. What it doesn't do is tell you anything about how PHI actually flows through their system.
Before you accept a BAA, read it. Most are vendor-drafted and favor the vendor. Three areas require specific attention. First, breach notification timelines: HIPAA requires covered entities to notify HHS within 60 days of discovering a data breach affecting 500 or more individuals, and your BAA should require vendors to notify you significantly faster; 24 to 72 hours is a reasonable commercial standard. Second, subcontractor coverage: AI vendors almost always use cloud infrastructure providers and third-party APIs as subcontractors. If the BAA doesn't require them to impose equivalent obligations on those subcontractors, your PHI may flow to infrastructure that isn't covered by the agreement. Third, termination provisions: the BAA should give you the right to end the relationship and require the vendor to return or destroy all PHI if they can't remediate a compliance failure.
The subcontractor question is particularly acute for AI vendors. OpenAI, Anthropic, Google, and most large model providers route inference through cloud infrastructure, typically AWS, Microsoft Azure, or Google Cloud, and often through additional subprocessors for logging, monitoring, or fine-tuning. A HIPAA-compliant deployment requires that every link in that chain has documented BAA coverage, not just the primary vendor relationship.
The highest-risk area in most healthcare AI deployments isn't data storage — it's inference. When a clinician submits a patient note to an AI system for summarization, triage, or coding, that text typically contains PHI. The question you need answered is: what happens to that content after the API call completes?
Consumer-grade AI products are categorically not appropriate for PHI, and the gap between a consumer product and a genuinely HIPAA-compliant AI tool is wider than most procurement teams realize. ChatGPT's standard interface, under OpenAI's standard consumer terms, explicitly excludes HIPAA coverage. OpenAI does offer enterprise agreements and API access with BAA coverage for healthcare use cases, but these require specific contracts separate from the default ChatGPT product that most employees are already using. The same distinction applies to Gemini: Google's consumer product is not HIPAA eligible, while certain Google Cloud healthcare APIs include BAA coverage under separate agreements.
Claude, Anthropic's AI, offers HIPAA-eligible deployment under enterprise agreements with BAA coverage. Anthropic's Claude enterprise agreement includes specific healthcare data handling commitments that differ meaningfully from the default API terms. As with OpenAI's API, this requires a dedicated contract; it's not automatic. In every case, the critical question is model training data practices. Many generative AI vendors reserve the right to use your inputs to improve their AI models. For any deployment involving PHI, you need explicit contractual language prohibiting training on your data, with no carveouts.
Vendors serving healthcare should be able to tell you, in writing and without delay: whether PHI is retained after inference, for how long, under what conditions, and whether it is used for any purpose beyond serving your request. If getting a straight answer requires multiple escalations, that's a signal about their operational readiness for healthcare.
The HIPAA Security Rule requires covered entities and their business associates to implement technical safeguards protecting electronic PHI. For AI vendors, the baseline technical posture includes the following requirements, each of which should be confirmed through documentation, not assurance. Understanding why health systems are adopting AI at all — and what administrative burden AI automation is meant to solve — makes it easier to calibrate where the risk exposure is highest.
Data encryption at rest should use AES-256 or equivalent. Data encryption in transit should use TLS 1.2 or higher. These are table-stakes requirements. Any healthcare AI vendor that can't confirm both specifications in writing during the sales process is not operationally ready for clinical or administrative deployment.
Access controls are where meaningful differentiation appears. Role-based access control (RBAC) at the application layer should allow your administrators to define which users can access which PHI, mapped to your existing identity systems with single sign-on and multi-factor authentication support. Privileged access to the underlying infrastructure — databases, model weights, storage — should be logged, time-limited, and reviewable.
Audit logs and audit trails are required under the Security Rule and in many cases by your EHR's own compliance requirements. Every access to PHI should be logged: who accessed it, when, from where, and what action was taken. Those logs should be tamper-evident and retained for at least six years per HIPAA's documentation requirements. Audit controls at the application level should be separately exportable: you need records you can pull into your own security operations environment, not just a vendor's assurance that they keep records internally.
Risk assessments are a HIPAA legal requirement, not a sales tool. Any business associate should have a documented HIPAA risk assessment that explicitly covers their AI systems, and they should be willing to share the scope and findings with your security team. A vendor that can't produce this documentation hasn't completed one. Or completed one, and the results weren't favorable.
The PHI exposure profile changes significantly depending on the use case, and each one demands a different set of technical controls. Artificial intelligence applied to clinical workflows creates data handling obligations that consumer and general-purpose enterprise tools were never designed to meet.
An AI scribe that processes ambient listening audio from a patient-clinician encounter captures PHI continuously and in real time. The clinical notes and progress notes these systems generate flow directly into EHR records. Before deploying an AI scribe, confirm that audio is processed in-region and not routed internationally, that intermediate transcription steps are covered by the BAA (not just the final note output), and that neither audio nor derived text is retained beyond what's required to generate the clinical documentation. AI scribes represent one of the highest-value use cases in healthcare operations: they demonstrably reduce documentation burden for clinicians and improve time with patients. They also represent one of the broadest PHI exposure surfaces. The compliance architecture has to match the ambition.
Ambient listening tools that produce discharge summaries or support clinical documentation workflows outside of direct encounter recording have a narrower exposure profile, but require the same BAA coverage of every processing step. A coding assistant that takes completed discharge summaries and applies ICD codes is working on finished documents: lower risk than a live scribe, but PHI nonetheless. The same evaluation logic applies to AI automation in revenue cycle management, where claim data carries equivalent sensitivity.
Dictation tools with HIPAA-compliant configurations have existed for years. The evaluation challenge for newer AI models entering these same workflows is that their compliance frameworks are newer and the operational track record is shorter. That's not a reason to avoid them (the productivity gains for clinicians are real), but it is a reason to conduct more detailed technical due diligence, not less.
EHR integration is where most clinical AI deployments encounter their hardest compliance questions. Your EHR vendor has its own BAA requirements, and any AI system connecting to your EHR via API needs to be explicitly covered by those terms. HL7 and FHIR API connections that expose patient data to external systems require the same BAA scrutiny as any other PHI transfer. Confirm that the AI vendor's access scope is limited to the minimum PHI necessary for the intended use, and get that limitation in writing as part of the technical architecture review, not just the contract.
Selecting HIPAA-compliant AI tools for healthcare operations requires more than evaluating the feature set. A vendor claiming to offer HIPAA-compliant AI should be able to answer the following questions immediately and in writing: What BAA terms do you offer, and do they extend to your subcontractors? Does your infrastructure meet HIPAA-eligible standards on AWS, Azure, or an equivalent certified environment? What is your breach notification timeline to us? Do you use customer PHI for model training in any form? Can you provide documentation of your most recent risk assessment? Who is your designated HIPAA privacy officer and what is their response timeline for compliance inquiries?
Add a data privacy review to your standard vendor evaluation process that goes beyond the security questionnaire. Your legal team should review the BAA before procurement signs anything. Your security team should verify encryption standards, access controls, and audit log architecture through technical review: inspection of actual configurations, not vendor-supplied summaries. And your procurement team should know that an enterprise agreement with BAA coverage and a standard account using the same vendor's product are not the same thing.
Invisible is HIPAA, SOC 2, and GDPR certified, and we've deployed AI across healthcare operations at organizations like Headway, where AI-powered claims automation delivered 8x faster processing, with the compliance architecture built in from day one, not retrofitted after deployment.
The vendors that are operationally ready for healthcare will answer your evaluation questions immediately and in writing. The ones that aren't will tell you it's complicated and schedule a call to explain why their product is a special case. Once you've selected a vendor that clears your compliance bar, the 90-day guide to implementing AI in healthcare operations covers what structured deployment looks like from that point forward.
Invisible deploys production AI for health systems — including the HIPAA-compliant architecture and human oversight your operations require. See how we support healthcare operations or get started.
A business associate agreement is a contract required under HIPAA between a covered entity and any vendor that creates, receives, maintains, or transmits protected health information on their behalf. For AI vendors, the BAA establishes defined compliance obligations, but it doesn't verify their actual technical controls. You still need to audit security architecture, subcontractor coverage, and data handling practices independently.
ChatGPT's standard consumer product is not appropriate for PHI. OpenAI offers enterprise agreements and API access with BAA coverage for healthcare use cases, but these require dedicated contracts separate from the default ChatGPT interface. If your organization's clinicians or administrators are using ChatGPT via personal or standard organizational accounts to handle patient data, that use is not covered by any BAA and creates direct HIPAA exposure.
PHI at rest should be encrypted using AES-256 or equivalent. PHI in transit should be protected with TLS 1.2 or higher. These are baseline requirements — a vendor that can't confirm both specifications in writing during the sales process isn't operationally ready for healthcare deployment. Ask for encryption standards at each layer: database storage, backups, and any interim processing steps in the inference pipeline.
Yes, but the compliance requirements are specific. The vendor must have a BAA in place that covers all processing steps, including intermediate audio transcription, not just the final clinical note output. Audio must be processed in-region, PHI must not be retained beyond the time required to generate documentation, and the system must not use clinical data for model training without explicit contractual prohibition. Verify the full data flow, not just the finished note.
A risk assessment for an AI deployment should identify all PHI flowing through the system, evaluate the likelihood and impact of potential threats, assess existing controls, and document a remediation plan for any gaps. For AI-specific deployments, the assessment should explicitly address model training data practices, API logging, subcontractor data handling, and the technical controls at each inference step. Ask vendors for their risk assessment documentation and confirm your specific deployment was included in scope.
The Privacy Rule governs who can access PHI and for what purposes: it's the foundation for what your BAA commits a vendor to. The Security Rule requires specific administrative, physical, and technical safeguards for electronic PHI, including access controls, audit controls, data integrity protections, and transmission security. For AI vendors, the Security Rule is the more operationally demanding of the two and requires verification through technical review, not contractual commitment alone.
Request a complete list of all subprocessors that may handle PHI as part of the vendor's service, including cloud infrastructure providers like AWS, analytics tools, and any third-party APIs in the processing chain. Confirm the vendor has BAAs in place with each subcontractor and ask them to certify this in writing as part of your procurement process. A vendor that cannot identify their subcontractor chain hasn't mapped their own PHI exposure and is not ready for healthcare deployment.
