AI, but with a seatbelt on. See the AI Exposure Check

← All insights

Healthcare AI · 8-minute read

Doctors using AI: is patient data protected?

AI can make a physician’s day easier. It can draft a note, summarize a document, organize a task list, or help explain a complex topic. But once patient information enters a prompt, upload, connected inbox, or browser extension, the question is no longer only whether the tool is useful. It is whether the data path is understood and controlled.

A doctor may use AI for work and personal administration in the same day. The boundary can become blurry: drafting a patient message, cleaning up a referral note, summarizing a lab narrative, planning a schedule, or asking an assistant to turn an appointment transcript into a checklist. It is easy to assume that an individual account or a familiar consumer tool is separate from clinical work. The information being entered—not the intent—creates the risk.

This does not mean every use of AI with a healthcare context is automatically improper, and it does not mean an AI tool is automatically unsafe. The operational problem is that a practice cannot know patient information is protected merely because a tool has a privacy setting or someone uses it carefully. The practice needs to understand what data enters the tool, who can access it, how the provider handles it, what agreements apply, and what other systems the tool can reach.

When a prompt becomes a patient-data pathway

Patient information can reach AI in more ways than a pasted medical record. It can appear in a prompt, an uploaded PDF, a screenshot, a copied calendar entry, an email thread, a dictated transcript, a connected drive, or an integration that pulls data automatically. A tool may also retain chat history, offer shared workspaces, allow administrators to review activity, or connect to other applications through a broad permission.

That means a seemingly harmless request such as “summarize this patient follow-up” needs a different review than “help me write a generic office announcement.” The first may create a pathway for protected health information. The second can often be handled with no patient information at all. Separating those two use cases is a practical first control.

The key question is not whether people in the practice are trying to do the right thing. It is whether the practice can see every place where patient information could be entered, transmitted, stored, or acted on by an AI-enabled service.

What HIPAA changes

For HIPAA-covered entities and business associates, HHS explains that when a cloud service provider creates, receives, maintains, or transmits electronic protected health information on the organization’s behalf, that provider is a business associate. HHS says the parties must have a HIPAA-compliant business associate agreement and otherwise comply with the HIPAA Rules. [1]

That is why a personal AI account should not be treated as a shortcut around a practice’s normal review. Before patient information is sent to an AI provider, the practice should confirm that the intended service, account type, configuration, and contractual arrangement actually support the proposed use. A logo, a generic privacy statement, or a claim that data is encrypted does not by itself answer those questions.

HHS also describes a risk-based, scalable Security Rule that requires appropriate administrative, physical, and technical safeguards. Its guidance specifically addresses risk analysis, access control, audit controls, authentication, transmission security, and periodic review. [2] An AI workflow should be included in that same security conversation rather than treated as an exception because it is new or convenient.

Five controls to review before clinical AI use expands

1. Separate permitted work from patient-data work

Make it obvious which AI tasks may use only generic, non-patient information and which tasks require an approved clinical workflow. A short rule can prevent a common mistake: a staff member starts with a harmless draft and gradually adds names, dates, screenshots, or account details to make the answer more useful.

2. Approve the provider, account, and configuration together

Do not approve a product name in the abstract. Review the exact version, account plan, workspace controls, connected apps, retention choices, administrative controls, and contractual terms the practice will use. A business offering may have different privacy, access, and agreement options than an employee’s personal account.

3. Limit what the AI can reach

Use the narrowest practical permissions. A tool that assists with a single workflow should not quietly receive broad access to mailboxes, all shared files, every calendar, or an entire electronic record environment. Remove test connections when a trial is over and name an owner for every active integration.

4. Keep a record of access and use

Someone should be able to answer: Which staff accounts can use each approved tool? What systems can it access? What data categories may be used? Who approved it? HHS identifies audit controls and review of access activity as important Security Rule considerations. [2] A small inventory is more useful than an unwritten assumption that everyone knows the policy.

5. Give staff an easy safe alternative

People use personal tools when the approved route is slow, unclear, or unavailable. Offer a simple answer for common needs—drafting non-clinical text, summarizing approved materials, or escalating a new use case for review. Training should include examples of information that may not be entered into an unapproved AI tool.

Questions for every AI tool that may touch patient information

Before a practice allows patient-related information into an AI workflow, leadership should be able to answer the following questions:

  • What exact information will the tool receive, create, store, or transmit?
  • Is the intended organization and service arrangement appropriate for that information, including any required agreement?
  • Can the tool connect to email, files, calendars, the EHR, or another system—and are those permissions necessary?
  • Which people can use the tool, view its history, administer the workspace, or change its settings?
  • What logging, retention, deletion, and incident-response controls apply?
  • Who reviews the tool again when its features, integrations, or clinical use changes?

If those answers are not clear, the right move is not necessarily to ban AI. It is to pause the patient-data use case until the practice can define a safe path.

A practical next step for a medical practice

Start with the tools already in use. Ask physicians, staff, contractors, and vendors what AI assistants, transcription tools, note helpers, browser extensions, and automations they use. Then trace the highest-risk workflows first: anything involving patient messages, clinical notes, documents, voice recordings, scheduling details, or connected applications.

For each one, decide whether to approve it with clear limits, move it to a better-controlled workflow, reduce its access, or stop using it with patient information. Bring your privacy, compliance, and legal advisers into the decision where appropriate. The goal is not perfect certainty. It is a documented, defensible understanding of where patient data can move and who is responsible for protecting it.

Need a clearer AI inventory?

Find the tools and access paths that deserve a closer look.

Book an AI Exposure Reality Check

Sources

  1. HHS: Guidance on HIPAA and Cloud Computing
  2. HHS: Summary of the HIPAA Security Rule