A new participant has quietly joined the clinical care team. It doesn’t carry a badge. It doesn’t attend committee meetings. It never complains about the EHR. But it reads patient charts. All of them.

Artificial intelligence (AI) is entering healthcare organizations faster than most governance frameworks can handle. What began with narrow machine learning models supporting radiology, risk scoring, or predictive analytics has rapidly transformed into large language models (LLMs) embedded directly within clinical and operational workflows.

Today, these systems summarize patient records, generate clinical documentation, triage patient messages, assist with clinical decision-making, and automate tasks that consume large portions of the clinician and administrative workday.

For health systems and medical facilities, the benefits of leveraging AI engines are significant. AI can reduce documentation burden, streamline prior authorization workflows, provide links to recommended guidelines, and help clinicians navigate increasingly complex patient records and payor requirements.

AI engines excel at most paperwork tasks, and healthcare has a lot of paperwork. But every system that can read the chart eventually learns something important: charts are full of Protected Health Information (PHI). PHI is not just data. It is a detailed narrative of someone’s life told through diagnoses, medications, lab values, and moments when things went wrong.  Restricting the exposure of PHI is critical not just from legal compliance and HIPAA penalties but because it safeguards patients’ privacy and prevents serious harm, such as stigma, discrimination, identity theft, or financial loss from disclosure of sensitive medical details. Safeguarding patient data builds and maintains trust in the healthcare system, encouraging patients to seek care and share health issues with providers, leading to better diagnoses, treatment outcomes, and overall quality of care.

For Chief Medical Information Officers, Chief Information Officers, and Chief Privacy Officers the question is no longer whether AI can safely operate inside private HIPAA healthcare environments. The question has transformed to one of deeper interest:

Where does the data go after the AI accesses it?

Healthcare’s Expanding AI Use

Healthcare organizations are adopting AI solutions rapidly. Health systems are integrating AI across their enterprises, including:

  • Clinical documentation and ambient scribing
  • Revenue cycle and Preauthorization workflows
  • Patient message handling and call center automation
  • Population health analytics and clinical quality measures
  • Care coordination and discharge planning

These systems were initially designed to assist clinicians and administrators with narrow tasks. Language models are evolving into something more capable, where they now operate within what is called agentic architecture.

This is a technical way of saying that the AI doesn’t just answer questions anymore; it takes action. Agentic AI systems can retrieve information, query databases, call external tools, trigger workflows, and exchange structured data with other software systems as part of completing tasks, all from a single prompt.

Standards such as the Model Context Protocol (MCP) and similar tool-calling frameworks are emerging to make these integrations easier. With these frameworks, a language model can connect to external systems as easily as plugging a device into a wall outlet.

Plug in a Payor API. Plug in a scheduling system. Plug in a clinical database.

The system becomes increasingly more capable and helpful as it is connected to other external systems. In complex systems, connections are where interesting things happen.

What AI Systems Can Access

When an AI system integrates with an electronic health record (EHR) or electronic medical record (EMR), the scope of information it can access depends entirely on the integration architecture.

In some deployments, models operate on curated summaries or structured queries generated by the application layer. In others, the integration allows the AI to access broader portions of the patient record. That information may include:

  • Diagnoses and problem lists
  • Medication histories
  • Laboratory results and vital signs
  • Imaging reports
  • Clinical notes and encounter documentation
  • Social and behavioral health information

This is the same information clinicians rely on when delivering care. The difference is that the AI can read thousands of charts without fatigue and capture items not easily available to an end user in the medical record.

The Limits of Infrastructure-Level Compliance

Healthcare organizations are deploying AI systems inside HIPAA-compliant cloud environments such as Microsoft Azure or Amazon Web Services, under a Business Associate Agreement (BAA). Hosting AI Engines in private HIPAA-compliant cloud environments with established BAAs are necessary safeguards. They protect how PHI is stored and processed within the infrastructure hosting the system, although infrastructure compliance does not address how modern AI systems behave.

A BAA governs how a cloud provider handles protected health information within its services. It does not automatically govern how data flows when an AI system begins interacting with external APIs, third-party services, or specialized software tools.

AI systems interact with many tools, and system connections will expand exponentially as Agentic AI use expands. As AI systems become more connected, the model itself becomes a bridge between systems. They retrieve information from one environment, perform reasoning, and then pass context into another system as part of completing a task.

When this works as designed, there is not much of interest, but occasionally the bridge leads somewhere unexpected.

Agentic AI and the Data Flow Problem

Agent-based AI systems excel at multi-step workflows. They retrieve information, call external services, chain actions together, and pass structured data between systems. Numerous Healthcare workflows benefit from this ability.

Architecture diagram of a HIPAA-compliant private cloud EHR with an embedded LLM/AI engine that accesses patient data and integrates via agentic AI APIs with scheduling, lab, pre-authorization, health information exchange, research and clinical guidelines, and future healthcare systems.

Figure 1: Healthcare’s Artificial Intelligence Ecosystem

Consider an AI assistant supporting prior authorization.

The system retrieves diagnosis codes, medication history, and encounter details from the EHR, constructing an authorization request. That request is then transmitted to a payer’s API.

Efficient. Helpful. Exactly what everyone wanted. But inside that request may be more patient context than anyone realized.

Many external services log activity and requests and maintain them for debugging and analytics purposes. This means fragments of patient records may now be stored outside the health system’s controlled HIPAA environment.

Nothing malicious occurred. No one bypassed security controls. The machine simply moved information from one system to another while completing its task. And it did so very efficiently.

Reducing Exposure Through De‑Identification

One effective architectural strategy for reducing risk is to limit the amount of identifiable patient information that reaches the AI model. A properly designed de‑identification layer can remove or mask the identifiers defined under HIPAA’s Safe Harbor standard before information is provided to the LLM. Names, addresses, phone numbers, geographic identifiers, and medical record numbers can be replaced with pseudonymous tokens.

Clinically meaningful context is not removed. Laboratory values, vital signs, diagnoses, medications, and encounter histories remain intact.

Dates can be consistently shifted within a session so that the sequence of clinical events remains accurate without exposing real calendar dates. Many of these deidentification strategies already exist for constructing test sets and training machine learning models.

From the model’s perspective, nothing important is missing. Behind the scenes, a secure session-scoped mapping service maintains the relationship between tokens and the underlying patient identifiers. When clinicians act on the AI’s recommendations, the application layer resolves those tokens back to the appropriate patient record within the authorized clinical system.

Once the session ends, the mapping can be destroyed. The AI retains the medical logic, but it cannot determine the patient’s identity. Which is usually the safest arrangement for everyone involved.

The Governance Imperative

Implementing de-identification technical solutions for AI access is a safeguard; technology alone does not solve the whole problem. AI Governance is critical as AI solutions are deployed across clinical and operational workflows. Healthcare leaders evaluating AI systems should understand several key questions before deployment:

  • What patient information is provided to the LLM or AI engine?
  • What external tools, APIs, or services can the system access?
  • Where is patient information logged, stored, or transmitted during those interactions?

The technology to manage these risks exists. The challenge now is ensuring governance evolves as quickly as the AI Engines accessing the charts to verify that the technology properly protects PHI. Because once a system learns how to navigate the chart, it eventually learns how to navigate everything connected to it.


Guest Byline:

Dennis P. Sweeney, MBA — Co-Founder, Vertebrai Solutions Inc. & Principal, Tellogic Inc. Consulting

Mr. Sweeney is Co-founder of Vertebrai Solutions Inc, which released the Vertebrai AI Clinical Assistant at HIMSS26. He is also a Consulting Principal with Tellogic Inc, as a trusted advisor, supporting healthcare organizations for over 30 plus years, leading the IT & Data/Information strategies, establishment Clinical Integration & Accountable Care Organization programs, leading cross functional teams, providing program management, technical assessments, business transformation, organizational redesign, software product development, change management, and system implementations.

Subscribe to Our Newsletter

We keep your data private and share your data only with third parties that make this service possible. See our Privacy Policy for more information.