HIPAA Compliance AI: What a BAA Does Not Cover

Key takeaways

• A business associate agreement allocates liability for patient data. It says nothing about whether a model is accurate, fair or clinically safe, which is where most of the risk actually sits.
• HIPAA declined to regulate artificial intelligence. The January 2025 Security Rule proposal raised AI only as a request for information and proposed no AI-specific safeguards.
• Section 1557 is the rule that binds clinical AI in the United States today. Its patient care decision support tool duties have been enforceable since 1 May 2025.
• HTI-1 forces certified health IT to expose 31 source attributes for predictive decision support, which doubles as a due diligence checklist for any AI supplier.
• A working HIPAA compliance AI program answers HIPAA, Section 1557, HTI-1, the FDA and, for transatlantic operators, the EU AI Act from a single control set.

What HIPAA actually covers when AI touches PHI

Almost every article about HIPAA compliance AI starts in the same place: pick a vendor that signs a business associate agreement, check the encryption, confirm the tool does not train on your prompts. That advice is correct and it is also the smallest part of the problem. HIPAA has two operative halves. The Privacy Rule governs how protected health information may be used and disclosed. The Security Rule governs the administrative, physical and technical safeguards applied to that information in electronic form. An AI vendor that receives, stores or processes protected health information on behalf of a covered entity is a business associate, and both rules reach it through contract. What HIPAA does not do is regulate the model. It has nothing to say about training data provenance, subgroup accuracy, calibration drift, or whether a recommendation is clinically appropriate. Those questions belong to other regimes, and they are the questions that decide whether an AI deployment harms a patient. Two boundary cases matter more than teams expect. The first is de-identification. Data stripped under the Safe Harbor method or certified through Expert Determination falls outside HIPAA, which is why so many health AI projects run on de-identified corpora. Large models complicate that comfort, because memorisation and linkage across rich clinical text can move a dataset back toward identifiability in ways the original determination never contemplated. If your de-identification certificate predates the model, it does not cover the model. The second is the perimeter itself. HIPAA applies based on who holds the data, not on how sensitive it is. A consumer symptom checker, a wellness app or a direct-to-patient chatbot that never contracts with a covered entity typically sits outside HIPAA entirely and lands instead under the FTC Act and the Health Breach Notification Rule. Health data does not carry HIPAA with it. The relationship does. That distinction is the same one that governs every other privacy assessment your organisation runs, and it is worth reading alongside the difference between a privacy impact assessment, a DPIA and a FRIA, because health AI programs usually need more than one of them.

The BAA is necessary and not sufficient

A business associate agreement does three useful things. It binds the vendor to the Privacy and Security Rules, it defines permitted uses of protected health information, and it obliges the vendor to report breaches. Skipping it is indefensible. Where a vendor mishandles protected health information and no agreement is in place, the Office for Civil Rights treats the missing contract as its own violation on top of whatever else went wrong. The enforcement record supports taking that seriously. On 23 April 2026 OCR announced settlements with four entities over ransomware-related breaches, totalling 1,165,000 dollars and covering more than 427,000 individuals, with each organisation accepting a two-year corrective action plan under OCR monitoring. Vendor oversight sits underneath a growing share of those penalties, and third-party involvement in healthcare breaches doubled from 15 percent to 30 percent year over year in 2025. So sign the agreement. Then notice what it did not buy you. A signed BAA does not tell you which model version is in production. It does not record what the model was trained on, or whether the training population resembles your patient population. It does not measure performance across age, sex, language or payer mix. It does not detect that a supplier silently swapped its underlying foundation model in a quarterly release. It does not produce a single artefact you could hand an auditor who asks why a specific patient received a specific recommendation. Those gaps are governance work, not procurement work. They live in the same place as the rest of your compliance and governance operating model: an inventory, an owner, a risk rating, a test result, a monitoring cadence and a decision record. The contract allocates blame after a failure. Governance is what makes the failure less likely and provable either way.

Where HIPAA stops: the 2025 Security Rule proposal punted on AI

Anyone waiting for HIPAA itself to answer the AI question should read what happened in the most recent rulemaking. On 27 December 2024 the Department of Health and Human Services announced a Notice of Proposed Rulemaking to modernise the Security Rule, published in the Federal Register on 6 January 2025. It is the first substantial update to the Security Rule in roughly two decades. The proposal is ambitious on cybersecurity fundamentals: asset inventories, network mapping, mandatory multi-factor authentication, encryption expectations, and the removal of much of the flexibility that let organisations treat safeguards as optional. On artificial intelligence, it did almost nothing. AI appears in a request for information, grouped with quantum computing and virtual and augmented reality, asking the public how the Security Rule should handle electronic protected health information used in emerging technologies. OCR had the opening to set ground rules for AI and machine learning and chose to gather comment instead. The comment period closed on 7 March 2025 with nearly 5,000 submissions, and a final rule is still pending. The practical reading is straightforward. When the final rule lands it will raise your security floor, which helps. It will not tell you how to validate a model, how to test for disparate performance, or what evidence to retain about an algorithmic recommendation. Treating HIPAA as the whole of your AI obligation is a misreading of a statute that was written for records, not for inference. The full picture sits across several regimes at once, which is why the global map of AI laws matters even to a purely domestic US provider.

Section 1557: the rule that actually governs your clinical AI

Here is the rule that almost no HIPAA compliance AI guide mentions, and it is already in force. Section 1557 of the Affordable Care Act prohibits discrimination on the basis of race, colour, national origin, sex, age and disability in health programs and activities receiving federal financial assistance. HHS issued a final rule on 6 May 2024, effective 5 July 2024, that extends those principles explicitly to what it calls patient care decision support tools. The definition is deliberately broad. It covers automated and non-automated tools, mechanisms, methods and technology used to support clinical decision making, which sweeps in clinical algorithms, risk scores, triage logic and machine learning models alike. Covered entities were given 300 days from the effective date to comply with the decision support provisions, which put the deadline at 1 May 2025. The duty has two parts. First, make reasonable efforts to identify decision support tools in use that employ race, colour, national origin, sex, age or disability as an input variable. Second, make reasonable efforts to mitigate the risk of discrimination arising from those tools. Both obligations are continuing. This is not an attestation you sign once and file. Read those two verbs against the vendor-selection advice that dominates the search results. No amount of encryption identifies an input variable. No business associate agreement mitigates a disparity. The rule reaches the model, and the covered entity, not the vendor, owns the duty.

What reasonable efforts look like in evidence

Regulators do not accept intent. They accept records. For each clinical decision support tool, a defensible file contains an inventory entry naming the tool, its version and its clinical purpose; a documented review of input variables flagging any protected characteristic or close proxy such as ZIP code, language preference or insurance status; performance results broken out by the subgroups the rule names; a written mitigation decision with its rationale, including the decision to accept a residual risk; a monitoring cadence with defined thresholds; and a named accountable owner. That evidence set also answers most of what any AI auditor will request, and it pairs naturally with a clear position on where a clinician sits in the loop. If a tool is advisory, the difference between human-in-the-loop and human-on-the-loop oversight is exactly what determines whether a mitigation is real or nominal.

HTI-1 and the transparency layer inside your EHR

While OCR was declining to regulate models, the health IT certification programme was doing it anyway. The HTI-1 final rule from the Assistant Secretary for Technology Policy, formerly ONC, created a Decision Support Interventions certification criterion that carries the first transparency requirements of their kind for predictive algorithms embedded in certified health IT. Certified systems must surface structured source attributes to the clinical user: 13 attributes for evidence-based decision support, and 31 for predictive decision support. Those 31 attributes are the interesting part. They describe the intervention’s purpose and intended use, the development process, the data used to train and validate the underlying model, how performance was measured, how fairness was assessed, and how the intervention is maintained over time. The stated goal is to let an organisation judge whether a predictive intervention is fair, appropriate, valid, effective and safe, a test the programme abbreviates as FAVES. Two consequences follow for anyone running a HIPAA compliance AI program. First, if your predictive tool ships inside certified health IT, this documentation already exists and you are entitled to it. Many compliance teams have never asked for it. Second, and more useful, the 31 attributes are a ready-made supplier questionnaire for AI that is not certified at all. A vendor that cannot describe its training population, its validation method or its fairness assessment is telling you something, and the federal government has already decided those questions are answerable. Use them when you are deciding whether an AI capability belongs in your governed platform or in the loose stack of tools around it.

FDA, and the line between a feature and a device

Some clinical AI is a regulated medical device, and the boundary is thinner than most buyers assume. The FDA had authorised more than 1,350 AI-enabled devices by early 2026, roughly double the 2022 count. Software that analyses an image, computes a risk score for a named condition or drives a diagnostic conclusion frequently qualifies. Software that summarises a note, drafts a letter or routes a message usually does not. The dividing question is whether the output is intended to diagnose, treat, mitigate or prevent disease, and whether the clinician can independently review the basis for the recommendation. Machine learning strains device regulation in one specific way: cleared devices are supposed to stay as cleared, and models want to change. The FDA’s answer is the Predetermined Change Control Plan, which lets a manufacturer pre-authorise a defined envelope of future model modifications inside the cleared intended use. Adoption is still thin, with roughly 10 percent of 2025 AI clearances including an authorised plan. For a deployer this produces a concrete control. Ask every clinical AI supplier whether the model is under a change control plan, how you will be notified of a model update, and what happens to your validation evidence when the model changes underneath it. A silent retrain can move a product outside its cleared intended use and outside your own testing at the same time. That is a measurement and monitoring problem, and it maps directly onto the Measure and Manage functions of the NIST AI Risk Management Framework.

If you also operate in Europe: the EU AI Act layer

Plenty of organisations touching US protected health information are not US organisations. European health-tech vendors, contract research organisations, device manufacturers and hospital groups with US research partnerships carry HIPAA duties by contract and EU duties by law. For them, HIPAA compliance AI work is only the first floor of the stack. AI that is a medical device, or that is a safety component of one, is automatically high-risk under the EU AI Act. In practice MDR class IIa, IIb and III devices and IVDR class A to D devices normally fall into the high-risk category. MDR Class I devices that need no notified body review are not high-risk on that route, though they can still be caught if they perform an Annex III listed function. Annex III adds two healthcare-adjacent uses that are high-risk without being devices at all: emergency call triage and the triage of patients in emergency care, and risk assessment and pricing for life and health insurance. Payers and triage platforms often assume the Act is a device problem. It is not. Timing changed in 2026. Following the Digital Omnibus adopted in June 2026, standalone Annex III high-risk obligations apply from 2 December 2027, while AI that sits inside an MDR or IVDR regulated device has until 2 August 2028. As of March 2026, AI-enabled medical devices continue to be certified exclusively under MDR and IVDR, and the Act’s high-risk obligations are not yet applicable to them. That gap is planning time, not relief. French organisations have a useful head start. The joint guide published by the Haute Autorité de Santé and the CNIL in March 2026 covers medical device qualification, the Act’s high-risk requirements for health systems, patient data protection and clinical validation in one document, and it is freely available from the CNIL. The German, Italian, Spanish and Portuguese equivalents are thinner, which makes the underlying EU AI Act operator obligations the safer reference point.

Building a HIPAA compliance AI program on one control set

Four regimes, four vocabularies, one set of underlying questions. What is this system, who owns it, what could it get wrong, how would you know, and can you prove it. Building four parallel compliance programs is how healthcare organisations burn a year and still fail an audit. Start with an inventory. Every AI system that touches patients or protected health information gets a record, including the ones nobody registered. Ambient scribes bought by a single department, a summarisation feature switched on inside an existing vendor platform and clinicians pasting notes into a consumer chatbot are all in scope, and all three are common. The shadow AI problem is more acute in healthcare than anywhere else because the clinical benefit is immediate and the procurement path is slow. Then classify each system against four binary questions. Does it process protected health information? Does it influence a care decision? Does it live inside certified health IT? Is it, or is it inside, a regulated device? The answers determine which obligations attach.

Use a management system to hold it together rather than a spreadsheet. ISO/IEC 42001 supplies the certifiable structure: policy, roles, risk treatment, internal audit, management review. The NIST AI Risk Management Framework supplies the working loop of Govern, Map, Measure and Manage. Neither is a US healthcare regulation, and that is precisely why they work as the connective layer: they are the place where a single piece of evidence can be produced once and cited against several obligations. This is the same argument that underpins any serious AI governance framework, applied to a sector where the consequences arrive faster.

FAQ

Can you use AI with HIPAA compliance? Yes. HIPAA does not prohibit artificial intelligence, and nothing in the Privacy or Security Rules bars a covered entity from processing protected health information with a model. What HIPAA requires is that the vendor be brought in as a business associate under a written agreement, that the safeguards apply to the electronic protected health information involved, and that the use is permitted under the Privacy Rule. A HIPAA compliance AI review should therefore start with the clinical purpose rather than the vendor, because the harder question is whether the other applicable rules, particularly Section 1557, are satisfied for that specific use. Is ChatGPT HIPAA compliant for healthcare use? The consumer version is not. A model is never compliant on its own; a deployment is. Compliance depends on whether the provider will sign a business associate agreement, whether prompts and outputs are excluded from training, what the retention policy is, and whether the configuration supports access control and audit logging. Enterprise and API tiers from the major providers can support a compliant deployment. Free consumer interfaces generally cannot, which is why clinicians pasting notes into a public chatbot is one of the most common breaches in healthcare today. Does a signed BAA make an AI tool HIPAA compliant? No. A business associate agreement is a contractual allocation of duties over data. It does not evaluate the model, does not verify accuracy across patient subgroups, and does not create any record of why a particular recommendation was made. Regulators have never treated a signed contract as evidence that safeguards were implemented, and Section 1557 duties attach to the covered entity regardless of what the vendor agreed to. What was the Section 1557 deadline for AI decision support tools? The final rule was issued on 6 May 2024 and took effect on 5 July 2024. Covered entities had 300 days from the effective date to comply with the patient care decision support tool provisions, which set the deadline at 1 May 2025. Those obligations are now live and ongoing, so an organisation that has never inventoried its clinical algorithms for protected-characteristic inputs is already behind. Does HIPAA apply if my AI only uses de-identified data? Properly de-identified data falls outside HIPAA, whether through Safe Harbor or Expert Determination. The caution is that de-identification is a property of a dataset at a point in time, not a permanent status. Rich clinical text, combinations of quasi-identifiers and model memorisation can all push re-identification risk back up. If a determination was made before the data entered a model pipeline, have it reassessed against the actual pipeline rather than assuming it carries forward. Who is liable when an AI vendor causes a PHI breach? Both parties can be. Business associates are directly liable under HIPAA for their own violations, and covered entities remain accountable for vendor selection and oversight. Where no agreement was in place, the covered entity faces a separate finding for that gap alone. Beyond HIPAA, liability for a harmful clinical recommendation is governed by malpractice and product liability law, where the treating organisation is rarely absent from the claim. Your incident reporting process should assume shared exposure. Do European healthcare organisations serving US patients need both HIPAA and the EU AI Act? Usually yes, and they answer to different authorities for each. HIPAA reaches a European vendor through its business associate agreement with a US covered entity. The EU AI Act, GDPR and MDR or IVDR reach the same organisation through EU law. The obligations overlap heavily on risk management, logging, documentation and human oversight, so the efficient path is one control set mapped to both, not two programs run in parallel.

Conclusion

The search results for HIPAA compliance AI describe a procurement decision. The actual obligation is an operating model. HIPAA governs the data. Section 1557 governs the decision, and has done since May 2025. HTI-1 governs the disclosure. The FDA governs the device. For organisations working on both sides of the Atlantic, the EU AI Act governs the system. No single one of them is the answer, and none of them will be satisfied by a signed agreement and an encryption claim. What ties them together is unglamorous and entirely achievable: know every AI system you run, classify it honestly, test it against the characteristics the law names, write down what you decided and why, and monitor it after go-live. That is AI governance, and in healthcare it is the difference between a defensible program and a good intention.