A BAA governs the vendor’s handling of PHI after receipt, but HIPAA compliance also depends on the covered entity’s own controls. Risk analysis, workforce training, access management, and monitoring remain the organisation’s responsibility. If employees can type PHI into unapproved tools or over-share in prompts, the contractual layer has already been bypassed.
Why a BAA Does Not Complete HIPAA Risk Management
A signed BAA is necessary when a vendor may handle PHI, but it is only one layer of the control stack. HIPAA still expects the covered entity to assess how PHI enters AI workflows, who can send it, where it is stored, and whether the tool’s behaviour is observable and restricted. That matters because the weakest point is often not the contract, but the employee prompt, the copied attachment, or the browser plug-in that sends data to an unapproved service. NIST’s NIST Cybersecurity Framework 2.0 is clear that governance, protection, detection, and response all have to work together, not in isolation.
NHIMG research shows how quickly identity exposure becomes an operational problem: when AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and sometimes in as little as 9 minutes, as reported in LLMjacking: How Attackers Hijack AI Using Compromised NHIs by Entro Security. The same lesson applies to PHI in AI use. Contractual terms cannot stop a user from pasting protected data into a service that was never approved, never reviewed, and never bound to the organisation’s control plane. In practice, many security teams discover the gap only after PHI has already been exposed through everyday workflow shortcuts, rather than through intentional misuse.
How HIPAA Controls Have to Extend Beyond the Vendor Contract
The practical answer is to treat the BAA as a vendor requirement, not as a substitute for internal governance. A compliant AI workflow needs a defined intake path for PHI, role-based access, logging, monitoring, and explicit approval of where data may be processed. For AI-specific use cases, current guidance suggests adding prompt controls, data-loss prevention, and clear rules about what may never be entered into public or unmanaged tools. That is why NHI lifecycle discipline matters: Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs helps frame how identities, credentials, and access should be controlled over time, while Top 10 NHI Issues highlights the operational failures that appear when identity and secrets are not governed continuously.
In practice, the control set usually includes:
- Approved tools only, with documented PHI handling rules.
- Least-privilege access and separation of duties for staff who can submit or retrieve PHI.
- Logging of prompts, outputs, and administrative access where permitted by policy.
- Training that tells employees what not to paste, even when the vendor has signed a BAA.
- Monitoring for over-sharing, shadow ai use, and unauthorized data flows.
Where AI systems touch more than one service, the risk can expand quickly. The DeepSeek breach and the Schneider Electric credentials breach show why identity, secrets, and tool access must be managed as part of the security design, not after deployment. These controls tend to break down when staff can move PHI into browser-based AI tools that sit outside enterprise logging and approval, because the data path is invisible before the contract even becomes relevant.
Where the Standard Advice Breaks Down in Real Operations
Tighter control over AI use often increases friction, so organisations have to balance speed against demonstrable PHI protection. That tradeoff is real, especially in clinical, claims, and legal workflows where employees want fast assistance and may bypass approvals if the sanctioned path is too slow. Best practice is evolving, but there is no universal standard for prompt-level HIPAA enforcement yet, so teams should not treat vendor promises as a finished control model.
Operationally, the edge cases are usually the ones that matter most. A BAA may cover a hosted enterprise model, but not the plugin, extension, or sidecar service that copies content elsewhere. A secure platform may be approved, but a user may still upload a document with PHI into a personal account. A governed model may be fine for summaries, but not for free-form analysis that can reproduce sensitive details. The broader lesson is reinforced by the Ultimate Guide to NHIs — Regulatory and Audit Perspectives: auditors will look for evidence of policy, enforcement, and review, not just contracts. NIST’s risk-based approach and the organisation’s own evidence trail both matter. A signed BAA helps, but it does not stop shadow AI, weak training, or uncontrolled data sharing from becoming a HIPAA finding.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 | Governance and oversight are required beyond vendor contracts. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Uncontrolled AI access often starts with weak identity and secret handling. |
| NIST AI RMF | AI RMF addresses organisational risk management for AI use. |
Define AI PHI governance, owners, and review cadence before approving use.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
