Why do signed BAAs not fully solve HIPAA risk when organisations use Gemini?

A BAA governs how Google processes data after receipt, but it does not prevent PHI from being sent to the model in the first place. Users can paste notes into chat, agents can retrieve sensitive Drive content, and summaries can expose patient data. Organisations still need policy, access controls, audit logging, and DLP to reduce exposure before data leaves their environment.

Why This Matters for Security Teams

A signed BAA is necessary for regulated use, but it is not a control boundary by itself. It says how a vendor may handle data after receipt; it does not stop staff from entering PHI into prompts, nor does it prevent connected workspace tools from surfacing records that were never intended for model use. For Gemini deployments, the real risk often starts at the point of user action and privilege, not at the cloud contract.

That is why HIPAA risk here is operational as much as legal. Security teams need to treat the model interface, connected data sources, and export paths as sensitive processing stages. The relevant posture maps well to NIST Cybersecurity Framework 2.0, especially around governance, access control, and data protection. The common mistake is assuming procurement work is the same thing as risk reduction. In practice, many security teams encounter PHI exposure only after users have already copied it into an AI workflow or an agent has already summarised a restricted file.

How It Works in Practice

To understand why the BAA does not fully solve the problem, separate the AI service into three layers: input, processing, and output. The BAA governs processing obligations between the customer and Google, but the customer still controls who can send data, what sources the model can reach, and where the results can be shared. If those upstream controls are weak, the BAA only limits downstream handling of data that should never have entered the workflow.

In practice, organisations need a control stack around Gemini that includes:

• Clear acceptable-use rules that prohibit paste-in of PHI unless the workflow is explicitly approved.
• Role-based access controls on connected content repositories so only authorised users and agents can retrieve sensitive records.
• Data loss prevention and content inspection to flag identifiers, notes, and attachments before submission.
• Audit logging for prompts, file access, and generated outputs so security and compliance teams can reconstruct exposure paths.
• Retention and sharing controls that prevent summaries from being copied into less protected systems without review.

HIPAA-aligned governance also depends on administrative safeguards, not just technical ones. NIST SP 800-53 Rev 5 Security and Privacy Controls provides useful control language for access enforcement, auditing, and media protection, and it is more actionable for implementation than a contract alone. For AI-specific use cases, teams should also decide whether the model is permitted to process de-identified data, minimum necessary excerpts, or only synthetic test content. Those distinctions matter because a BAA does not reclassify the data a user chooses to send.

These controls tend to break down when Gemini is connected to broad document repositories with permissive sharing, because the model can inherit the organisation’s worst access sprawl faster than policy reviews can catch it.

Common Variations and Edge Cases

Tighter AI controls often increase friction for clinicians, analysts, and support teams, requiring organisations to balance speed against privacy and compliance. That tradeoff becomes sharper in environments that rely on shared workspaces, federated file stores, or heavy agent automation. There is no universal standard for how much PHI a generative AI workflow may process by default, so current guidance suggests using the minimum necessary principle and enforcing it technically, not just procedurally.

Edge cases matter. If Gemini is used only for non-clinical drafting with fully redacted inputs, the BAA risk profile is materially lower than in workflows that summarise chart notes or triage messages from a live patient portal. If an AI agent can retrieve files from Drive or shared drives, the question shifts from “Is the vendor covered?” to “Did the organisation prevent overbroad retrieval and downstream disclosure?” That is where identity governance intersects with HIPAA risk: excessive permissions, shared accounts, and weak review of delegated access can turn a compliant vendor relationship into an exposure event. For that reason, teams should also align policy with the actual data paths, not the intended ones, and revisit controls whenever access scopes or integrations change.

Related resources from NHI Mgmt Group

• Why does shift-left security not fully solve AI agent risk?
• When should organisations use self-signed TLS client authentication instead of CA-signed mTLS?
• Should organisations rely on passwordless authentication to solve access risk?
• Should organisations use business impact to prioritise identity risk?