HIPAA AI Compliance: The Complete 2026 Guide for Mid-Market Healthcare

The architecture question is the question The healthcare CIO who is asked, in the spring of 2026, whether her organization can adopt artificial intelligence is being asked a question her board has already decided the answer to. The board has read the same trade publications, sat through the same vendor pitches, and approved the same five-year strategic plan that every other mid-market hospital system, behavioral health network, multi-site clinic group, and regulated digital-health platform has approved. Adoption is no longer the decision. The decision is whether the adoption is going to be defensible in the audit that will follow it by twelve to thirty-six months. That defensibility is almost never decided by the model. The conversation the CIO is about to have with her vendors and her clinical leadership will, by default, center on whether OpenAI or Anthropic or AWS Bedrock or Azure AI Foundry has the right Business Associate Agreement, the right data-residency commitment, the right zero-data-retention language. Those are real questions and the answers matter. But the question the Office for Civil Rights auditor is going to ask in 2027 or 2028 is not what model was selected. The question is how the protected health information moved through the system: who initiated the prompt, what context was assembled into it, what got logged at the orchestration layer, what got written back to the electronic health record, which downstream service the agent called on the clinician's behalf, and whether every link in that chain was covered by a contractual instrument that the regulator can read. The architecture is the question because the architecture is where the audit lives. A model is a six-month decision. The architecture is the next five years of audit posture, vendor renewal economics, regulatory drift, acquisition diligence, and incident response. A mid-market healthcare buyer who picks an architecture well in 2026 can swap models in 2027, absorb new HIPAA enforcement guidance in 2028, and survive a private-equity-backed roll-up in 2029 without rebuilding. A buyer who picks a model first and lets the architecture form around it will, in the conservative case, rebuild twice in five years; in the less conservative case, will rebuild once and explain the original posture to a regulator in between. We have read more than seventy HIPAA assessment reports across mid-market healthcare in the past twenty-four months. The pattern across those assessments is consistent enough to publish. The organizations that get cited are not the organizations that picked the wrong model. They are the organizations that picked a model with a clean Business Associate Agreement and then deployed it inside an architecture the BAA did not actually cover. A BAA on a model endpoint does not retroactively cover the Slack channel where a nurse pastes a discharge summary into a prompt window. A BAA on a model does not cover the audit-log retention on the orchestration layer that an engineering team assembled in two weeks against a deadline. A BAA on a model does not cover the retrieval-augmented generation pipeline whose vector database pulls full three-year patient histories into every prompt because nobody mapped retrieval against the minimum-necessary standard at design time. This guide is a complete reference for getting the architecture right the first time, and for sequencing the BAA chain, the agent governance, the workforce supervision protocol, the vendor selection, and the audit posture in the order that the regulator will eventually ask about them. It is opinionated where the field is settled and explicit about where it is not. It is intentionally long because the alternative is to fragment the topic across a dozen short pieces, which is how organizations end up with twelve good answers and no defensible program. Where the topic warrants going deeper than a pillar should, the relevant Securem field guides and AI Watch briefings are linked in context; the HIPAA AI architecture reference implementation is the natural companion to this document and is referenced throughout. Two framing constraints before the reader continues. First, this guide addresses HIPAA-covered entities and their business associates operating in the United States. The questions overlap with state privacy law, with the Federal Trade Commission's health-breach jurisdiction, with the Substance Abuse and Mental Health Services Administration's 42 CFR Part 2 rules, and with state-level artificial-intelligence statutes; those are addressed in adjacent Securem field guides where they intersect with the HIPAA decision. Second, the guide is written for mid-market organizations: roughly fifty to two thousand employees, with internal security and compliance functions but without the regulatory affairs department a national hospital system can field. The architecture choices and BAA-chain economics that are defensible at that scale are different from the choices a five-hospital integrated delivery network or a Fortune 500 payer is making, and that difference is acknowledged where it changes the recommendation. Chapter one: the seven HIPAA controls AI tools must satisfy The HIPAA Security Rule lives in 45 CFR Part 164, with the administrative safeguards in §164.308, the physical safeguards in §164.310, and the technical safeguards in §164.312. The Privacy Rule occupies the adjacent sections, and the Breach Notification Rule sits in §164.400 and following. Most of the rule does not change in an AI context. Workforce training is workforce training, contingency planning is contingency planning, and physical safeguards on a data center are the same whether the data center hosts an electronic health record or an inference endpoint. But seven specific controls take on substantially new meaning the moment a workflow that touches PHI is mediated by a model, an agent, or a retrieval pipeline. These are the seven controls where the audit findings concentrate, and they are listed here in the order an auditor typically encounters them. One. Audit logging at the prompt level (§164.312(b)). The Security Rule requires an audit trail of access to protected health information. In a traditional EHR the audit trail is a database query log keyed to the user, the patient record, and the timestamp. In an AI workflow the equivalent is the prompt-and-completion log: the exact text of what was sent to the model, the exact text of what came back, the identity of the user on whose behalf the call was made, the identity of the service that made the call, and the timing of every step. Most AI deployments we audit log the API call but not the prompt content. That is an audit-trail gap. The control is not satisfied by an observability platform that records latency and error rates; it is satisfied by an artifact retention regime that can produce, on regulator demand, the exact text of every PHI-containing prompt sent to any model in the prior six years. The retention obligation is six years from the date of creation or the date last in effect under §164.530(j), and it applies to the prompt content because the prompt is the access event. Two. The minimum necessary standard (§164.502(b)). The Privacy Rule limits PHI use to the minimum necessary for the stated purpose. In a retrieval-augmented generation architecture, that obligation lives in the retrieval step, not the model step. The retriever must filter context to the minimum required to answer the prompt and must do so in a way that can be reconstructed after the fact. We have read assessment reports where the retrieval pipeline injected three years of progress notes into a prompt asking the model to draft a single discharge summary. The model gave a perfectly reasonable answer. The architecture violated minimum-necessary on every single call, and the audit log recorded the violation in full color. The minimum-necessary failure mode is the most common substantive citation we see in mid-market AI assessments. Three. Access controls (§164.312(a)(1)). The model itself sees what the application sends it. The controls that matter are upstream: which clinicians can initiate which prompts; which prompt categories require additional authorization; whether the orchestration layer enforces role-based access on the underlying data sources or whether it acts as a service principal with read access to the entire chart. The audit question is not whether the model has a Business Associate Agreement; it is whether the access decision at the orchestration layer mirrors the access decision the EHR would have enforced if a clinician had queried it directly. Four. Transmission security (§164.312(e)). PHI must be encrypted in transit. The model API itself is rarely the failure point, every major frontier model provider serves over TLS, often with additional certificate pinning available, but the integration boundary between the orchestration layer and the source-of-truth data store frequently is. We see orchestration services making plaintext SQL queries against EHR reporting databases over internal networks that the engineering team assumed were trusted. Transmission security fails on the boundary, not on the model call. Five. Integrity controls (§164.312(c)(1)). PHI must not be altered or destroyed in unauthorized ways. AI introduces a specific and underappreciated risk on this control: model output that updates a record. When a clinical-documentation workflow writes a draft progress note back to the EHR, the integrity control requires that the audit trail distinguish a clinician-authored note from a model-authored draft, and that any clinician sign-off on a model-authored draft be recorded as an attestation rather than as authorship. Auditors look for this distinction explicitly. Most deployments do not have it because the engineering team thought of the write-back as a productivity feature rather than as an integrity event. Six. Person or entity authentication (§164.312(d)). The clinician's identity must be tied to the prompt, the completion, and any downstream action the AI takes on their behalf. Single sign-on from the EHR to the AI tool is necessary. Single sign-on that loses the user identity at the orchestration boundary, because the orchestration layer makes its own service-account calls into downstream systems, is the most common implementation mistake the field exhibits. The audit log shows "ai-orchestration-service" instead of "Dr. Singh," and the chain of custody between the clinician and the action breaks at exactly the point the regulator wants to see it intact. Seven. Business associate management (§164.308(b)). Every entity in the chain that creates, receives, maintains, or transmits PHI on behalf of the covered entity must be under a Business Associate Agreement, and where that business associate engages a subcontractor, the subcontractor must be under a parallel agreement. The model vendor's BAA is one link. The orchestration vendor is a separate link. The vector database vendor is a separate link. The observability vendor is a separate link if and only if it ingests prompt or completion content. The evaluation vendor that scores outputs is a separate link. The audit asks for the chain, not the model. The full procurement mechanics of constructing that chain are covered in the vendor BAA chain procurement field guide; the chapter that follows summarizes the points the architecture decision turns on. The seven controls above are not exhaustive, HIPAA has more to say about disaster recovery, contingency planning, workforce training, sanction policies, and physical safeguards, but they are the seven where the architecture decision either satisfies the control or quietly violates it. Every control on this list is a question that a vendor's Business Associate Agreement does not, on its own, answer. Every control is a question the architecture either gets right or gets wrong at the moment of design. Chapter two: the four-architecture decision tree There are exactly four architecture shapes a mid-market healthcare organization can choose for AI workflows that touch PHI. We have not seen a fifth shape that holds up under audit. The choice is not driven by the model selection; it is driven by where PHI is allowed to live, where it is allowed to traverse, and what the regulator-facing log of those movements is required to look like. Architecture A: hosted SaaS with a full Business Associate Agreement. A vendor offers a healthcare-specific application, ambient clinical documentation, prior authorization automation, patient messaging triage, and signs a comprehensive BAA covering the application, the underlying model, the orchestration, the storage, and the observability. PHI flows from the EHR into the vendor's environment and back. The covered entity inherits a HIPAA-defensible posture from the vendor. This architecture works when the vendor genuinely controls every layer of the stack, when the BAA actually covers what the vendor's marketing implies it covers, and when the use case is sufficiently constrained that the vendor's controls map cleanly to the covered entity's risk analysis. It does not work when the vendor relies on subprocessors whose BAAs were never executed, or when the application's roadmap drifts beyond the original scope without a BAA amendment. The buyer's diligence question is not "do you have a BAA" but "show us your subprocessor list with the BAA execution dates." Architecture B: cloud-native build on a hyperscaler with HIPAA-eligible services. The covered entity builds the AI workflow inside its own AWS, Azure, or Google Cloud tenant using services on the hyperscaler's HIPAA-eligible list, with the hyperscaler's BAA in place. Examples include AWS Bedrock with Knowledge Bases inside a HIPAA-eligible account, Azure AI Foundry with Azure OpenAI in a HIPAA-eligible subscription, or Google Vertex AI under the Google Cloud BAA. The PHI never leaves the hyperscaler's HIPAA boundary, the covered entity controls the application layer, and the BAA chain collapses to the covered entity, the hyperscaler, and any narrowly scoped subprocessors the covered entity introduces. This is the most common defensible architecture for a mid-market organization that has internal engineering capacity. The AWS Bedrock healthcare BAA Knowledge Bases briefing and the Azure AI Foundry agents audit-log healthcare briefing walk through the specific configurations that hold up under audit. Architecture C: on-premises or virtual-private-cloud deployment. The covered entity deploys an open-weight or licensed-weight model inside its own data center or a dedicated single-tenant cloud environment. PHI never leaves the covered entity's HIPAA boundary at all; there is no vendor BAA on the model because there is no model vendor on the request path. This architecture is the right answer for behavioral health organizations governed by 42 CFR Part 2, for substance-use treatment networks where the consent posture cannot tolerate any external processing, and for organizations whose risk analysis concludes that the additional control surface justifies the additional operating cost. It is the wrong answer for organizations that lack the in-house machine-learning operations capability to maintain it. The on-device AI HIPAA regulated-professionals briefing addresses the narrower case of inference on a clinician's device. Architecture D: hybrid where PHI never leaves the covered entity's boundary while orchestration and non-PHI inference happen outside. The covered entity tokenizes or redacts PHI before any external model call, performs the inference against a hyperscaler or frontier model, and reconstitutes PHI inside the boundary on the way back. The architecture works when the redaction is reliable enough to be defensible under audit, which in practice means a deterministic redaction pipeline with an audit log of every redaction decision and a human-reviewable sampling regime to catch failures. It is the right answer for organizations that want the capabilities of frontier-model intelligence without the BAA-chain complexity of having those models process PHI directly. It is the wrong answer when the use case requires PHI in the prompt to produce a useful answer, because the redacted prompt will degrade the model's response below clinical utility. The decision tree across these four architectures is driven by three questions, asked in order. First, does the use case require PHI in the prompt to be useful? If no, Architecture D is the default. Second, does the organization have the in-house engineering capacity to operate a hyperscaler-native build with proper logging, access control, and BAA chain hygiene? If yes, Architecture B is the default. Third, does the organization's regulatory posture, including 42 CFR Part 2 obligations, state-level mental-health confidentiality statutes, or sensitive specialty-care lines, require that PHI never leave the boundary at all? If yes, Architecture C is the default. If none of the above hold and there is a vendor with a defensible BAA chain offering the use case as a hosted application, Architecture A is the default. The decision tree is not a one-time exercise. A mid-market healthcare organization with a meaningful AI footprint in 2026 will typically operate in two or three of these architectures simultaneously, with different use cases mapped to different shapes. The governance task is not to pick one architecture for the organization; it is to maintain a current inventory of which use cases sit in which architecture, and to ensure that the BAA chain, audit log, and access control posture for each is internally consistent. The HIPAA AI architecture reference implementation provides the full configuration detail for each of the four shapes. Chapter three: the vendor BAA chain A Business Associate Agreement covers what the agreement covers. The phrase is repetitive because the misunderstanding is repetitive. A BAA executed with a model vendor covers the model endpoint, the data the model vendor processes on the covered entity's behalf, the model vendor's logging and retention practices, and the model vendor's obligation to notify in the event of a security incident. It does not cover the orchestration layer that sits between the application and the model. It does not cover the vector database that the orchestration layer queries. It does not cover the observability stack that ingests the prompts. It does not cover the evaluation service that scores the outputs. It does not cover the workflow automation platform that triggers the agent on a schedule. Each of those is a separate business associate engaged by the covered entity, or a separate subcontractor engaged by one of the covered entity's business associates, and each requires its own contractual instrument. The chain is the unit of compliance. A mid-market healthcare buyer building a clinical documentation workflow in 2026 will typically have between four and nine business-associate relationships on the request path: the application vendor, the model vendor, the orchestration vendor, the vector database vendor, the embeddings vendor (sometimes the same as the model vendor, sometimes not), the observability vendor, the identity-provider vendor, the prompt-evaluation vendor, and the workflow automation vendor. Every one of those entities either holds PHI for an instant, processes PHI in service of the workflow, or has access to a log that contains PHI. Every one of those entities requires a BAA, or a subprocessor designation under another business associate's BAA, or a documented assertion from the procurement-of-record entity that the vendor in question does not in fact touch PHI. The chain construction is mechanical and is best executed in the procurement cycle rather than retroactively. The vendor BAA chain procurement field guide walks through the procurement-side mechanics. The summary points for the architecture decision are these. First, the orchestration layer is the most commonly missed link. A buyer that has executed a model BAA and an observability BAA will frequently have overlooked the orchestration vendor because the orchestration vendor presents as developer tooling rather than as a PHI processor. The orchestration vendor BAA gap procurement briefing addresses this directly. Second, observability vendors fall into two buckets, those that genuinely do not see prompt content because the buyer has configured the integration to scrub it, and those that ingest the full prompt as a default. The audit question is which bucket the integration is actually in, not which bucket the vendor's marketing implies. Third, distilled or fine-tuned variants of frontier models introduce a procurement question that the standard BAA template does not address; the distilled models BAA procurement question briefing covers this. The chain has to survive a renewal cycle. A BAA executed in 2026 against a vendor's 2026 architecture will, by 2028, often be misaligned with what the vendor is actually doing, because the vendor has added a subprocessor, changed a data-residency posture, or introduced an agent capability that the original BAA did not contemplate. The covered entity's procurement function has to treat BAA review as an annual exercise tied to vendor renewal, not as a one-time signature at onboarding. The agent licensing meter shift SaaS renewal audit briefing addresses the parallel commercial-terms drift that is now standard in vertical SaaS renewals. A practical artifact the audit will ask for is the BAA coverage matrix. The matrix lists every component on the request path for every active AI workflow, the business-associate relationship covering that component, the execution date of that relationship, the next review date, and the named subprocessors covered under that relationship. A mid-market healthcare organization with three to five active AI workflows in production will have a matrix of roughly thirty rows. The matrix is the artifact the OCR auditor will ask for. The absence of the matrix is itself a finding, because §164.308(a)(1)(ii)(A) requires a risk analysis and §164.308(b) requires the business-associate documentation, and the matrix is the artifact that proves both have been performed. Chapter four: agent governance for healthcare AI The architecture and BAA chain questions are sufficient for AI workflows that take a prompt, return a completion, and stop there. They are not sufficient for agentic workflows, which is to say workflows in which the model is permitted to take actions on the covered entity's systems on a clinician's behalf. The agent-governance question is the question that 2026 forces onto the agenda and that 2027 will make non-optional, because the frontier of healthcare AI adoption is moving rapidly from generation to action: an agent that drafts a prior authorization is replaced by an agent that submits it; an agent that summarizes a chart is replaced by an agent that updates the problem list; an agent that schedules a follow-up is replaced by an agent that reschedules across the calendar, the patient portal, and the referral system simultaneously. The governance frame is what we call trust architecture, and it is covered in depth in Trust architecture for regulated AI. The frame has five elements, and a healthcare AI deployment that is missing any of them is governance-incomplete by audit standards. One. Per-agent identity. Every agent that takes action on behalf of a clinician must have its own identity in the identity provider, distinct from the clinician's identity and distinct from other agents. The identity is what the audit log records as the actor. The reason matters: when an agent action is reviewed three years later in litigation discovery or in a regulator's investigation, the question is which agent took the action, with what permissions, on which clinician's authority. A shared service account fails this question. The agent infrastructure 12 pieces regulated buyers field guide catalogs the identity-layer requirements in full. Two. Scoped permissions. Every agent identity has an explicit, enumerable set of permissions in every downstream system it touches. The scope is defined at the action level, "write a draft progress note in the EHR", not at the role level, "clinical staff." Permission scoping at the role level inherits the problem the agent was supposed to solve: the agent has the union of all clinical-staff permissions and can therefore take any action any clinical staff member can take. Scoping at the action level limits the agent's blast radius to what it was actually deployed to do. The agent blast radius Terraform data-loss briefing is the cautionary case from outside healthcare and the lessons translate directly. Three. The validator gate. Every action the agent proposes to take is evaluated by a separate component, the validator, sometimes called the judge, that decides whether the action falls within the agent's scope, whether the action is well-formed, and whether the action triggers any escalation criteria. The validator is architecturally separate from the model that proposes the action, because a model evaluating its own action is not a control. The agent control layer judge validator architecture briefing is the reference for the validator pattern. In a healthcare context the validator is also the layer where minimum-necessary, consent, and authorization checks are enforced, because those checks are policy decisions that cannot be delegated to the model that is taking the action. Four. An audit log per action. Every action an agent takes is logged with the agent's identity, the clinician's identity that authorized the action, the prompt and reasoning that led to the action, the validator's evaluation, the action taken, the system on which it was taken, and the response. The audit log is the artifact the regulator will demand, the artifact litigation discovery will request, and the artifact the clinical leadership will use to investigate adverse events. The log retention period is six years under the Security Rule's general retention obligation. The code execution AI audit trail regulated buyers briefing addresses the specific case of agents that execute code, which is increasingly common in revenue-cycle and analytics workflows. Five. An escalation surface. Every agent has a clearly defined escalation path: which actions require human review before execution, which actions trigger a notification after execution, and which actions are flat-out prohibited. The escalation surface is the organizational policy made operational. A healthcare AI agent that is permitted to draft documentation but not to submit a claim, permitted to suggest a medication change but not to update the active medication list, and permitted to schedule a follow-up but not to cancel an existing appointment is an agent with a coherent escalation surface. An agent without these constraints is an unbounded actor. The trust-architecture frame applies to agents the covered entity builds, agents the covered entity buys from a vendor, and agents that a clinical workflow vendor has embedded inside a product the covered entity already uses. The third case is the one most mid-market organizations are blindsided by in 2026, because the vendor often deploys the agent capability as a feature release rather than as a procurement event. The shadow agent discovery middleware spread audit briefing and the middleware trap AI vendor procurement audit briefing document the procurement-side discovery problem. The shadow AI exposed instances mid-market briefing is the broader inventory case. The five-element frame is the governance contract. It is the layer above the architecture and the BAA chain, and it is what an OCR auditor in 2027 is going to evaluate as the operational maturity of the program. The five-layer AI compliance stack mid-market regulated field guide places agent governance inside the broader stack of compliance layers a regulated mid-market organization needs. Chapter five: workforce supervision for AI on PHI The architecture, the BAA chain, and the agent governance are vendor-facing and engineering-facing controls. The workforce supervision protocol is the operator-facing control, and it is the one that mid-market healthcare organizations underinvest in most consistently, because the procurement and engineering side is more legible to the CIO than the clinical supervision side. The Security Rule's workforce-related controls live in §164.308(a)(3) (workforce security), §164.308(a)(4) (information access management), and §164.308(a)(5) (security awareness and training). The supervision protocol is the operational answer to those controls in the AI context. The protocol has four moments of supervision. The first moment is at prompt initiation: the clinician or operator who initiates a prompt that will touch PHI has a documented understanding of which categories of prompts are permitted on which patient populations under which clinical circumstances, and has training that is current within the prior twelve months. The second moment is at action authorization: when the agent proposes an action that requires human review, the reviewer has both the clinical authority and the technical understanding to evaluate the proposal, and the review event itself is logged as an attestation rather than as a passive approval. The third moment is at exception handling: when the agent's behavior deviates from expected, a refusal, an unexpected output, a validator gate trip, there is a clear escalation path that does not require the operator to invent the response in the moment. The fourth moment is at retrospective review: every workflow with an AI component has a periodic review cycle, typically quarterly, in which a sample of agent actions is examined for clinical appropriateness, minimum-necessary adherence, and audit-trail integrity. The escalation surface within the protocol is three-tier. Tier one is the operator-side review at the moment of action: an action that falls within the agent's normal operating envelope is approved or declined by the clinician or operator on whose behalf the agent is acting. Tier two is the supervisor-level review for actions that fall outside the normal envelope but inside the policy boundary: an unusual prompt, an unusually large data scope, an action against a sensitive patient category. Tier three is the compliance-level review for actions that touch the policy boundary itself: an action that may implicate consent, an action that may exceed the BAA's scope, an action that has caused or may cause a reportable event. The three-tier surface is the organizational control plane. The agent supervision protocol regulated operators briefing is the operational reference for the protocol. The training side of the supervision protocol is where the mid-market organization most often falls short of the regulator's expectation. Annual HIPAA training that does not address AI workflows specifically is no longer sufficient under the Security Rule's risk-analysis obligation, because the risk the workforce is being asked to manage has changed. The training has to address what PHI is appropriate to put into a prompt, what the audit log captures and what it does not, how the validator gate works and what it means when the gate trips, what the escalation path looks like and when to use which tier, and what the workforce member's personal responsibility is when the agent does something unexpected. The AI governance one-page policy mid-market can defend field guide is the one-page policy artifact a mid-market organization can use as the training centerpiece. A workforce supervision protocol that exists on paper but does not show up in the audit log is not a control. The protocol has to produce artifacts: signed attestations on agent actions that required review, training completion records keyed to current curriculum, exception logs with disposition, quarterly retrospective-review minutes with findings and remediation. The artifacts are what the auditor reads. The protocol is what the artifacts come from. The sabotage risk report HIPAA audit posture briefing addresses the parallel internal-risk case in which workforce supervision is the primary detective control. Chapter six: vendor selection, Anthropic, OpenAI, AWS Bedrock, Azure AI Foundry, DeepSeek Vendor selection is the chapter the CIO wants to read first and that is, by structural necessity, the last substantive chapter. The vendor decision is downstream of the architecture, the BAA chain construction, the agent governance, and the workforce supervision protocol. A vendor that is a strong fit for Architecture B in an organization with mature agent governance may be a weak fit for Architecture A in an organization that is just beginning. The matrix below scores the five most-considered vendors as of publication on the dimensions that drive HIPAA defensibility specifically. It is not a general-purpose vendor evaluation; it is a HIPAA-posture evaluation. Anthropic. Anthropic offers Claude under a Business Associate Agreement available through both its direct API and its presence on AWS Bedrock and Google Vertex AI. The direct-API BAA covers the model endpoint, the input and output content, and Anthropic's logging behavior under the zero-data-retention configuration. The Anthropic Trust Portal publishes the underlying control evidence. The HIPAA defensibility of an Anthropic deployment is strongest in Architecture B inside AWS Bedrock or Vertex AI, where the BAA chain collapses to the covered entity and the hyperscaler, and where the model is one of several services governed by the same hyperscaler BAA. Direct-API deployments are defensible but require the covered entity to construct the BAA chain manually for orchestration, observability, and evaluation. OpenAI. OpenAI offers GPT models under a Business Associate Agreement through its direct API with the zero-data-retention addendum, and through Azure OpenAI inside Azure AI Foundry under the Azure BAA. The OpenAI Trust Center publishes the underlying control evidence and the procurement mechanics for the ZDR addendum are addressed in the OpenAI ZDR addendum procurement mechanics briefing. The HIPAA defensibility is strongest in Architecture B inside Azure, where the chain collapses to the covered entity and Microsoft. Direct-API deployments require the ZDR addendum and the same manual BAA chain construction as the Anthropic direct-API case. AWS Bedrock. AWS Bedrock is the hyperscaler model-hosting service most commonly chosen for Architecture B in mid-market healthcare. The AWS HIPAA-eligible services reference lists the specific services that fall under the AWS BAA; Bedrock, Bedrock Knowledge Bases, and the supporting Lambda, S3, and DynamoDB primitives are all HIPAA-eligible. The defensibility is strongest when the covered entity confines the workflow to HIPAA-eligible services inside a dedicated HIPAA account, and when the Knowledge Base configuration enforces minimum-necessary at the retrieval layer. The AWS Bedrock healthcare BAA Knowledge Bases briefing is the configuration reference. Azure AI Foundry. Azure AI Foundry is the Microsoft equivalent and the natural choice for organizations whose EHR is Microsoft-integrated or whose identity provider is Entra ID. Azure OpenAI, Azure AI Search, and the supporting Azure primitives are HIPAA-eligible under the Microsoft BAA. The defensibility is strongest in deployments that use Azure's managed identity for service-to-service authentication, which preserves the clinician identity through the orchestration layer in a way that satisfies §164.312(d) without custom code. The Azure AI Foundry agents audit-log healthcare briefing addresses the audit-log configuration. DeepSeek. DeepSeek's open-weight models are technically capable and commercially attractive, but the hosted-API version is not under a Business Associate Agreement and the data-residency and processing posture do not satisfy the HIPAA Security Rule's transmission-security and business-associate-management controls. The defensible deployment of DeepSeek for PHI is exclusively Architecture C, in which the open weights are deployed inside the covered entity's own infrastructure with no external API dependency. The mid-market healthcare organization considering DeepSeek for PHI should treat it as an Architecture C decision exclusively, with the operational cost of on-premises or VPC inference fully internalized into the business case. The vendor matrix above is current at publication and is revised quarterly in the Securem AI Watch surface. The matrix is also use-case-conditional: a vendor that is the right answer for ambient clinical documentation may not be the right answer for revenue-cycle automation, because the action surface, the validator requirements, and the integration burden differ. The governed action shift Q2 2026 enterprise procurement briefing addresses the broader procurement shift toward action-capable agents and how the vendor evaluation criteria are migrating with it. The Q1 2026 three structural shifts regulated AI briefing is the prior quarter's reference. The intent engineering regulated mid-market briefing addresses the application-layer design question that sits above the vendor choice. Chapter seven: what the OCR auditor will ask in 2027 The Office for Civil Rights audit program operates in two modes: the random compliance audit, which is on a roughly seven-year cycle for covered entities of mid-market size, and the for-cause investigation, which is triggered by a breach notification, a complaint, or a referral. Both modes will, by 2027, include explicit examination of AI workflows because the OCR enforcement page and the HHS HIPAA Security Rule guidance have both signalled that AI is now within scope of the existing rule rather than a separate regulatory domain. The covered entity should expect the audit posture to be operationalized through the following lines of inquiry. The auditor will ask for the inventory of AI workflows that touch PHI. The expected artifact is a list that names each workflow, identifies the clinical or operational owner, describes the use case in two or three sentences, specifies the architecture (A through D), lists the vendors on the request path, and references the BAA coverage matrix entry for the workflow. A covered entity that cannot produce this list in an audit will be cited under §164.308(a)(1)(ii)(A) for inadequate risk analysis. The auditor will ask for the BAA coverage matrix. The expected artifact is the matrix described in Chapter three. The auditor will sample three to five workflows and trace the chain end-to-end. The auditor will ask whether the subprocessors named in the vendor agreements match the subprocessors actually in use, and will ask for evidence of the periodic review. The auditor will ask for the audit log for a specified workflow over a specified period. The expected artifact is the prompt-and-completion log at the level of detail described in Chapter one, control one. The auditor will sample specific events and ask the covered entity to reconstruct the access decision, the minimum-necessary determination, the clinician identity, and the downstream actions taken. A covered entity that has logging at the API-call level but not at the prompt-content level will be cited. The auditor will ask for the agent governance documentation. The expected artifacts are the per-agent identity register, the scoped-permissions inventory, the validator-gate configuration, the escalation surface policy, and the audit log of actions taken by each agent over the audit period. The auditor will sample agent actions and ask the covered entity to walk through the trust-architecture frame for the action. The auditor will ask for the workforce supervision protocol documentation. The expected artifacts are the training curriculum keyed to AI-specific content, the training completion records, the exception logs with disposition, and the quarterly retrospective review minutes. The auditor will ask for evidence that the protocol has been exercised on a real exception, not merely documented in policy. The auditor will ask for the incident response posture for AI-specific failure modes. The expected artifact is an incident response plan that addresses model failure, validator-gate bypass, prompt-injection events, agent action exceeding scope, and data exposure through the prompt or completion log. The plan must reference §164.404 and the breach notification mechanics where applicable. The trust architecture frontier models instruction failures briefing is the reference for the instruction-failure case. The audit posture is not a separate program. It is the externally legible face of the architecture, BAA chain, agent governance, and workforce supervision protocol that the prior chapters have addressed. A covered entity that has built those layers correctly will produce the audit artifacts as a byproduct of the operating program rather than as a stand-alone preparation exercise. A covered entity that has not built those layers will discover, in the audit, that the artifacts cannot be retroactively constructed. Chapter eight: implementation roadmap The implementation roadmap below sequences the work across the first one hundred and eighty days for a mid-market healthcare organization adopting AI under HIPAA for the first time, or rebuilding an existing footprint that has accumulated technical and procurement debt. The roadmap assumes a starting point of one or two AI workflows in informal use and a desire to reach a defensible posture across the organization within six months. Days one through thirty: inventory and architecture decision. The first thirty days are spent producing the AI workflow inventory described in Chapter seven, mapping each existing workflow to the four-architecture framework in Chapter two, and identifying the use cases the organization expects to add in the following twelve months. The deliverable is the inventory document and the architecture map. The second activity in this phase is the engagement of a vCISO function, whether internal or external, to own the program. The third activity is the initial draft of the one-page AI governance policy that the executive team can ratify within the phase. Days thirty-one through sixty: BAA chain construction and remediation. The second thirty-day window is spent constructing the BAA coverage matrix for every workflow in the inventory, identifying the gaps, and beginning the procurement-side remediation. Some gaps will be closed by executing missing BAAs. Some will be closed by reconfiguring workflows to remove vendors from the request path. Some will require a workflow to be paused pending remediation. The deliverable is the BAA coverage matrix and the gap-remediation plan, with timelines and owners. The diagnostic-grade BAA review is offered as a fixed-scope engagement through the Securem Diagnostic and is the most common entry point for mid-market organizations at this stage. Days sixty-one through ninety: agent governance and audit logging. The third thirty-day window is spent operationalizing the trust-architecture frame from Chapter four. The per-agent identity register is established in the identity provider. The scoped-permissions inventory is constructed and enforced. The validator-gate pattern is deployed for every action-taking agent. The audit logging at the prompt-and-action level is implemented and verified by reconstructing a sample of actions end-to-end. The deliverable is the agent governance documentation and a working audit log that can answer the auditor's questions for the workflows in production. Days ninety-one through one hundred and twenty: workforce supervision protocol. The fourth thirty-day window is spent operationalizing the workforce supervision protocol from Chapter five. The training curriculum is updated to address AI-specific content. The escalation surface is formalized into operating policy. The retrospective review cycle is scheduled and the first review is conducted. The deliverable is the supervision protocol documentation, the training completion records, and the minutes of the first retrospective review. Days one hundred and twenty-one through one hundred and eighty: audit-readiness rehearsal. The final phase is a mock audit conducted against the program. The mock audit follows the seven lines of inquiry in Chapter seven, produces the expected artifacts, and identifies any remaining gaps. The deliverable is the mock-audit report, the gap-closure plan, and an executive briefing to the board on the program's posture. The phase is typically conducted by the vCISO function in conjunction with an external assessor, and the resulting artifact is the document the organization will hand the real auditor when the random compliance audit arrives. The roadmap above is the standard sequence. It compresses or expands based on the starting posture, the size of the AI footprint, the complexity of the EHR integration, and the maturity of the in-house engineering and compliance functions. A mid-market behavioral health network with 42 CFR Part 2 obligations will spend longer in the architecture phase because Architecture C is more likely to be the right answer for material portions of the workflow. A mid-market hospital system that has already standardized on Microsoft will move through Architecture B more quickly. The roadmap is intended as a sequencing reference, not as a literal schedule. Frequently asked questions Is ChatGPT HIPAA-compliant? ChatGPT, as the consumer-facing product at chat.openai.com, is not under a Business Associate Agreement and is not appropriate for PHI under any circumstances. The OpenAI API and the Azure OpenAI service are available under BAAs (the OpenAI API requires the zero-data-retention addendum), and the model itself is capable of HIPAA-defensible deployment when placed inside Architecture A or Architecture B with the full BAA chain constructed correctly. The question is conventionally asked about the model and is correctly answered at the architecture and chain level. Does a vendor BAA cover orchestration? Almost never, unless the orchestration is part of the same vendor's product and explicitly named in the BAA. A model vendor's BAA covers the model. An orchestration vendor (a workflow platform, an agent framework, a developer platform) is a separate business associate engaged by the covered entity and requires its own BAA. The orchestration vendor BAA gap procurement briefing addresses this in procurement detail. What is a vendor BAA chain? The BAA chain is the set of contractual instruments that together cover every entity on the request path of an AI workflow that touches PHI. The chain typically includes the model vendor, the orchestration vendor, the vector database vendor, the observability vendor, the evaluation vendor, and any workflow automation vendor in the path. The chain is the unit of compliance because the audit asks about end-to-end coverage, not about any individual link. The vendor BAA chain procurement field guide is the working reference. How does HIPAA apply to AI agents? HIPAA applies to any agent that creates, receives, maintains, or transmits PHI on behalf of a covered entity or business associate. The agent is governed by the same Security Rule controls as any other system on the request path, with particular emphasis on audit logging, minimum necessary, access controls, integrity controls, and person-or-entity authentication. Agentic workflows additionally require trust-architecture governance, per-agent identity, scoped permissions, validator gate, audit log per action, escalation surface, which is covered in Chapter four and in Trust architecture for regulated AI. Can I use DeepSeek for PHI? Only inside Architecture C, where the open-weight model is deployed inside the covered entity's own infrastructure with no external API dependency. The hosted DeepSeek API is not under a Business Associate Agreement and the data-residency and processing posture do not satisfy the Security Rule's transmission-security and business-associate-management controls. The defensible deployment requires the operational capacity to maintain on-premises or VPC inference, which is a non-trivial commitment for a mid-market organization to make. What is the difference between Architecture B and Architecture C? Architecture B keeps PHI inside a hyperscaler's HIPAA-eligible boundary (AWS, Azure, or Google Cloud) under the hyperscaler's Business Associate Agreement, with the covered entity building the application layer on top. Architecture C keeps PHI inside the covered entity's own infrastructure with no hyperscaler dependency at all, typically using open-weight models. Architecture B is the most common defensible answer for mid-market organizations with internal engineering capacity. Architecture C is the right answer for organizations governed by 42 CFR Part 2 or with risk analyses that conclude external processing is not acceptable for sensitive specialty lines. The full decision tree is in Chapter two. How often does OCR audit AI workflows? The Office for Civil Rights does not maintain a separate AI audit cadence; AI workflows are examined within the existing audit program. The random compliance audit cycle is roughly seven years for mid-market covered entities, and for-cause investigations are triggered by breaches, complaints, or referrals. From 2027 forward, the audit examination is expected to include the seven lines of inquiry described in Chapter seven, with particular focus on the BAA chain and the prompt-level audit log. What is the cost of HIPAA AI compliance? The cost varies with the starting posture and the size of the AI footprint, but the budgetable components are predictable: the vCISO or internal compliance function (typically a fraction of a senior leader's time plus an external advisory engagement), the procurement and legal work for BAA execution and review, the engineering work to instrument prompt-level audit logging and the validator gate, the workforce training program update, and the periodic external assessment. A mid-market organization with three to five AI workflows in production should expect the program cost to fall in the range of two to six percent of the AI workflow's total cost of ownership, with the variance driven by the maturity of the in-house compliance and engineering functions. The Securem Diagnostic is the fixed-price entry point for organizations that want a defined-scope baseline before building the internal capacity. Where to go deeper The Securem field guides and AI Watch briefings below are the supporting cluster for this pillar. Each addresses one slice of the HIPAA AI compliance problem in greater operational depth than the pillar can hold. Architecture and reference implementation. The HIPAA AI architecture reference implementation is the companion deep-dive on the four architectures with configuration detail for each. The AWS Bedrock healthcare BAA Knowledge Bases briefing and the Azure AI Foundry agents audit-log healthcare briefing are the hyperscaler-specific configuration references. The on-device AI HIPAA regulated-professionals briefing addresses the narrower edge-inference case. BAA chain and procurement. The vendor BAA chain procurement field guide is the working reference for chain construction. The orchestration vendor BAA gap procurement briefing, the distilled models BAA procurement question briefing, the middleware trap AI vendor procurement audit briefing, and the OpenAI ZDR addendum procurement mechanics briefing address specific procurement-side failure modes. Agent governance and trust architecture. Trust architecture for regulated AI is the foundational reference for the five-element governance frame. The agent infrastructure 12 pieces regulated buyers field guide catalogs the infrastructure layer. The agent control layer judge validator architecture briefing, the agent blast radius Terraform data-loss briefing, the agent skill marketplace credential exposure briefing, the code execution AI audit trail regulated buyers briefing, and the trust architecture frontier models instruction failures briefing address specific governance failure modes. Workforce supervision and policy. The agent supervision protocol regulated operators briefing is the operational reference for the workforce protocol. The AI governance one-page policy mid-market can defend field guide is the one-page policy artifact. The intent engineering regulated mid-market briefing addresses the application-layer design question. Audit posture and market context. The five-layer AI compliance stack mid-market regulated field guide places HIPAA AI compliance inside the broader regulated-mid-market stack. The sabotage risk report HIPAA audit posture briefing, the shadow AI exposed instances mid-market briefing, and the shadow agent discovery middleware spread audit briefing address the discovery and detective-control side. The Q1 2026 three structural shifts regulated AI briefing, the governed action shift Q2 2026 enterprise procurement briefing, and the agent licensing meter shift SaaS renewal audit briefing are the market-context references for the procurement cycle the buyer is operating inside. Industries and practices. The Healthcare industry surface and the Behavioral health industry surface host the vertical-specific guidance. The vCISO practice and the AI Advisory practice host the engagement models. The Diagnostic is the fixed-scope entry point for mid-market healthcare organizations that want a defined-scope baseline before building the internal program. External references for the regulatory framework: the HHS HIPAA Security Rule guidance, the OCR enforcement page, 45 CFR Part 164, the NIST AI Risk Management Framework, the Anthropic Trust Portal, the OpenAI Trust Center, and the AWS HIPAA-eligible services reference.