Gemini Enterprise and HIPAA Compliance
Accepting a Business Associate Agreement is a few clicks in the admin console. Making sure Gemini Enterprise actually satisfies HIPAA takes a little more work than that.
The BAA itself does not make an organisation compliant. Google's own compliance documentation says so directly: there is no HHS-recognised certification for HIPAA, and meeting it is a shared responsibility between Google and the customer.
HIPAA's Security Rule is specific about what has to be in place, requiring three categories of safeguard: administrative, physical, and technical.
Physical safeguards cover the data centre and the hardware inside it, which is Google's responsibility, but they also cover workstation security, which stays with the organisation regardless of platform.
Administrative safeguards, which includes things like a documented risk analysis, workforce training, and a named security official, stay with the organisation too.
Gemini Enterprise's governance controls, covering access, containment, content inspection, and agent tracking, sit almost entirely inside the third category: technical safeguards, set out in 45 CFR 164.312.
This section is made up of five standards:
Access control
Person/entity authentication
Audit controls
Integrity
Transmission security
Gemini Enterprise can help US healthcare organisations meet HIPAA's technical safeguards, covering each of these standards:
Access control
45 CFR 164.312(a)(1) requires covered entities to "implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights."
Gemini Enterprise connectors carry data access controls (ACLs) across from systems like SharePoint, Jira and ServiceNow, so retrieval respects the same permissions a person would have logging in directly.
One exception matters here too. BigQuery does not carry access controls across automatically, so any clinical data held there needs the access control column added manually before this standard is actually satisfied.
Person or entity authentication
45 CFR 164.312(d) requires covered entities to "implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed."
This standard sits with Cloud Identity for organisations already on Google Workspace, and Workforce Identity Federation for those authenticating through an external identity provider such as Entra ID or Okta. Multi-factor authentication belongs here too.
Audit controls
45 CFR 164.312(b) requires covered entities to "implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information."
This splits into two parts:
Access Transparency records what Google's own support staff did inside an organisation's environment.
A separate system, enabled by the customer, records what an organisation's own people did.
Within that separate system, admin actions are logged automatically, changes like updating a connector's permissions or adding a new user role. Logging of everyday data access is not automatic, things like a clinician's query returning a patient record, or an agent retrieving a discharge summary. For a HIPAA audit, that second log of everyday data is often the one that matters most, since it's what shows who actually touched patient data. So, an administrator should switch on Data Access logging in the Gemini Enterprise admin settings rather than assume it came enabled by default.
Integrity
45 CFR 164.312(c)(1) requires covered entities to "implement policies and procedures to protect electronic protected health information from improper alteration or destruction."
This is where content inspection is critical. Model Armor screens for prompt injection and jailbreak attempts that could otherwise manipulate an agent into altering or exposing data it shouldn't touch. Then, Sensitive Data Protection inspects, tokenises, and masks personally identifiable information in prompts and responses in real time.
Transmission security
45 CFR 164.312(e)(1) requires covered entities to "implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network."
Customer-managed encryption keys let an organisation hold its own encryption keys instead of relying on Google's, but only if its Gemini Enterprise data is processed in the US or Europe. This is about where the data itself is handled, not where the organisation is based.
What this does not cover
None of the above touches the administrative side of HIPAA.
A documented risk analysis, a named security official, and workforce training all remain the organisation's responsibility no matter which platform sits underneath them. Breach notification sits under a separate HIPAA rule entirely, and depends on an organisation's own incident response process rather than anything a platform configures.
Gemini Enterprise can support the technical side of HIPAA compliance. It cannot substitute for the governance work that HIPAA also requires around it.
Put simply, a signed Business Associate Agreement and a well-built platform only satisfy HIPAA's technical safeguards if someone actually configures and checks each piece behind them. Access controls, audit logging, encryption keys, and region settings all have to be set up correctly, not just switched on by default. This is a separate and high-stakes job that can be scrutinised under audit.
Cobry can help configure Gemini Enterprise properly from day one, and keep it that way as Google's covered-services list and regional settings change. Get in touch to talk through deploying Gemini Enterprise for HIPAA-regulated organisations.
