Is NotebookLM HIPAA Compliant? Check the Service and Agreement

The standard NotebookLM service is outside Google’s HIPAA business associate agreement, according to its Workspace Privacy Hub↗ (opens in a new tab), which calls the product Gemini Notebook. Google Cloud separately lists Gemini Notebook Enterprise among its HIPAA-supported services↗ (opens in a new tab), so coverage depends on the exact service and agreement. Do not upload protected health information (PHI), such as identifiable patient records, based on the NotebookLM name alone.

Tools like fenbs can keep the non-sensitive review decision visible to your team and its assistants. That record should explain the approved boundary without holding patient information, clinical examples, or confidential contract material.

Which NotebookLM service are you using?

Start with the product your administrator actually deployed. A Google account managed by your employer does not, by itself, establish that you are using the separate Cloud Enterprise service. Similar names and familiar screens make this an easy distinction to miss.

Google’s Enterprise overview↗ (opens in a new tab) describes a separate Google Cloud environment governed by the applicable Cloud agreement. Ask your administrator to identify the service, project, and approved access route. A colleague saying “we have the enterprise version” is a starting point for checking, not the evidence itself.

What must a HIPAA agreement actually cover?

A business associate agreement, or BAA, sets contractual responsibilities for handling PHI on behalf of a HIPAA-regulated organization. The HHS cloud guidance↗ (opens in a new tab) says a covered entity or business associate can use a cloud provider for electronic PHI when an appropriate BAA is in place and the other applicable HIPAA requirements are met.

Ask the person responsible for contracts to confirm which legal entity accepted the agreement and which services it covers. Then identify everything the proposed workflow touches: the original document, the notebook copy, the prompt, generated material, and any place someone exports the result. Treat each destination as a separate review question.

A service appearing on a supported list does not establish that your organization has accepted the right agreement or approved your particular use. Keep those findings separate so a reviewer can see exactly which requirement remains unresolved.

Why don’t privacy and encryption settle the question?

A promise about model training answers a different question from whether a service is covered by your BAA. A private notebook also needs review even when you intend to be its only reader. Neither fact changes which agreement applies to the service.

HHS explains that a cloud provider maintaining electronic PHI can still be a business associate even when it cannot decrypt the information. Encryption therefore does not remove the need to address the business associate relationship. The same HHS guidance calls for the organization’s own risk analysis and risk management.

Translate broad assurances into specific review questions. Who can access the uploaded material? Where can generated content be copied? How will the team respond if someone uses the wrong account? The answers need to fit the actual workflow rather than a general impression that Google is secure.

What should your organization approve before an upload?

Give your privacy, security, and clinical leaders a concrete proposal. “Use AI to summarize records” leaves too much undefined. A useful proposal identifies the purpose, the exact service, permitted information, intended users, and the destination of each output.

• Contract scope: confirmation that the applicable agreement covers the proposed service and use.
• Information boundary: which material may enter, who checks it, and what must remain in existing approved systems.
• Access and handling: the approved account, sharing rules, retention arrangements, and export destinations.
• Review responsibility: who checks summaries against their sources and handles a suspected disclosure or incorrect output.
• Approval limits: the specific workflow allowed, unresolved questions, and events that require another review.

Consider a hypothetical clinic testing summaries of public patient-education leaflets. That proposal is narrower than summarizing individual visits. Approving the public-material experiment should not silently approve the patient-record workflow later.

Can you use public or de-identified material?

Public research papers and approved educational materials can provide a useful starting point without uploading patient records. Confirm permission to use the sources and your organization’s rules before testing. Keep notes and prompts free of patient details too; an ordinary research question can become sensitive when you add a real clinical example.

Removing names does not establish HIPAA de-identification. HHS describes two methods↗ (opens in a new tab): Expert Determination and Safe Harbor, each with requirements. Have the responsible team assess the material before it reaches a service outside the approved PHI environment. Do not upload identifiable records to an unapproved tool and ask that tool to anonymize them.

If you are choosing a research workflow for approved material, see NotebookLM alternatives and Claude Projects versus NotebookLM. Those comparisons address how you work with sources; each service still needs its own review for sensitive information.

What belongs in the review record?

Save the decision in words the next colleague can apply. For example: “Public educational sources only; patient information is excluded; any proposed expansion returns to the privacy reviewer.” Record who approved that boundary, the public documentation consulted, and what remains open.

Keep signed agreements and sensitive assessments in their approved organizational system. In the shared work record, use a non-sensitive task such as “Confirm approved service route.” Avoid patient names, medical record numbers, screenshots, incident details, and links whose addresses reveal patient information. fenbs Decisions and rules can hold the approved boundary for assistants to read.

How to do this with fenbs

1. Create a free account, then add a project for the non-sensitive tool review.
2. Add tasks for confirming service scope, agreement coverage, and organizational approval. Describe the checks without copying patient information or confidential documents.
3. Record the boundary a person approved in Decisions and rules. Leave unanswered approval questions open; an assistant cannot decide or sign off.
4. Connect a supported assistant through Integrations, and ask it to read the rules before helping with review tasks. Save remaining checks in Where we left off.

fenbs is not the right fit for storing clinical records or confidential compliance evidence. Use it only for a non-sensitive work record your organization permits; it does not make another tool HIPAA compliant.

When should the decision be checked again?

Review the decision before changing the service, account, information type, sharing arrangement, or output destination. A new feature can introduce a new data path even when the notebook looks familiar. Check the current vendor documentation rather than treating this article as permanent authorization.

Keep the earlier approval and record the replacement when a person changes the boundary. The AI governance hub covers related questions about keeping human review connected to AI work.