AI Governance in healthcare: Compliance and security

Healthcare organizations adopted AI faster than they built the governance to account for it. Eighty-eight percent of health systems already use AI internally, while only 18% have both a mature AI governance structure and a fully formed AI strategy.

The Healthcare Financial Management Association reported both figures in Health System Readiness for AI, from a May 2025 survey of more than 230 health system executives.

AI rarely arrives through procurement, which is how it outruns the inventory. A Microsoft 365 Copilot license gets added to an existing agreement, an ambient documentation feature ships inside the electronic health record (EHR), or a clinician uses a personal device.

Wolters Kluwer's December 2025 Shadow AI Report surveyed 518 hospital providers and administrators and found that 57% had encountered or used an unauthorized AI tool.

Not knowing what an AI tool can reach becomes an accountability problem the moment a board member or auditor asks which tools touch protected health information (PHI), who owns each one, and what proves the controls work.

What is AI governance in healthcare?

AI governance in healthcare is the discipline of knowing where AI systems touch PHI, who is accountable for each use case, and whether the controls around that access can be proven to work. Organizations underestimate the third element because they treat a written policy as proof, when it only describes intent.

A board committee or external auditor is testing whether the organization can say, on the spot, what a specific AI tool reaches and who owns it. Most healthcare organizations can't, because Copilot pilots, embedded vendor AI, and conversational tools reach PHI-adjacent systems before security finishes cataloging them.

The consequences show up in the breach data. The Netwrix 2026 Data and Identity Security Report recorded a 43% breach rate over the last 12 months in organizations where AI significantly increased the identity footprint, against 11% where AI had not meaningfully changed it.

The survey behind that report also found that only 21% of organizations have complete visibility, monitoring, and controls over what sensitive data AI tools, models, or copilots use.

Why healthcare carries a different level of AI risk

The generic case for AI governance rests on reputational and operational risk. In healthcare, the exposure is regulated, the data is unusually valuable, and liability stays with the provider, not whoever built the model. Healthcare cybersecurity already carries that asymmetry.

A stolen medical record never expires

Most regulated data has a shelf life, which caps what a breach of it is worth. A stolen payment card gets canceled and reissued within days. A medical record carries diagnoses, insurance details, demographics, and a Social Security number, none of which can be reissued, so it stays exploitable for years after the breach that produced it.

Healthcare therefore can't rely on the containment other sectors get for free. An AI tool that reaches PHI creates exposure with no expiry date, which raises the cost of a mistake in access design rather than just the odds of one.

The provider carries the liability even when a vendor causes the breach

Healthcare organizations subject to HIPAA, which the rule calls covered entities, stay legally responsible for PHI no matter whose model processes it. That's what separates AI procurement here from AI procurement in an unregulated sector, where a vendor contract can shift risk. The HIPAA compliance rules governing every other system apply to AI unchanged.

The Department of Health and Human Services (HHS) Office for Civil Rights (OCR) treats a third-party AI chatbot handling PHI on a patient portal as a business associate, the same status it applies to cloud providers. Business associates carry direct obligations of their own, and that doesn't reduce the provider's. OCR has settled with providers over vendor failures before, including the North Memorial settlement tied to a missing Business Associate Agreement (BAA).

One review process can't cover both kinds of AI a hospital runs

Most sectors deploy one class of AI and govern it one way. A hospital runs two at once, and they fail differently enough that a single review process will miss one.

A diagnostic tool fails by reaching a patient with a wrong or biased recommendation, which is a patient-safety question for clinical leadership and, often, an FDA one. A productivity assistant fails by surfacing PHI to someone who should never have seen it, which is an access-control question for security. Running both through the same committee means administrative tools get clinical-style scrutiny they don't need while nobody asks what they can actually reach.

A healthcare breach costs more than a breach anywhere else

Healthcare has held the highest average data breach cost of any sector for more than a decade, reaching $6.64 million in 2026 (down from $7.42 million in 2025) according to IBM's Cost of a Data Breach Report. No other industry has stayed at the top that long.

That figure is what makes AI access design a board-level question rather than an IT one. It sets the price of getting it wrong, and it's usually the number a board remembers from a briefing.

The difference between clinical AI and administrative AI in healthcare

Governance splits along the line between AI that informs care and AI that handles the work around it. Each side has different owners, different regulators, and different questions to answer.

Clinical AI validation is a serious discipline with its own regulatory apparatus, and not one a data-visibility platform should claim to solve. Administrative AI belongs to security, IT, and privacy, and it's where the access questions a board asks actually land.

How US regulators are responding to AI in healthcare

Federal rulemaking, accreditation, and state legislation are all moving, and none of it requires waiting for a final rule before acting. Regulators are treating AI as an extension of existing obligations, so new requirements land on HIPAA machinery health systems already run.

The HIPAA Security Rule update names AI directly

HHS issued a notice of proposed rulemaking (NPRM) on the HIPAA Security Rule that explicitly addresses artificial intelligence. Its proposed risk analysis standard for electronic protected health information (ePHI) names AI tools directly. It requires "repeated consideration of, among other things, the type and amount of ePHI accessed by artificial intelligence tools, to whom the data is disclosed, and to whom the output is provided."

The rule remains proposed, and OCR continues to enforce the current Security Rule. Covered entities running HIPAA risk analyses today should already document how AI tools interact with ePHI.

The Joint Commission now certifies AI governance

The Joint Commission launched its Responsible Use of AI in Healthcare certification on June 1, 2026, the first credentialing program built around how health systems govern AI rather than around the AI products themselves.

It awards the certification at the organization or system level, and its standards cover governance, data management, risk and bias reduction, monitoring and validation, and transparency and training.

Certification is voluntary, though accredited organizations should expect the underlying expectations to surface in survey conversations.

State AI laws are layering on top of HIPAA

State legislation adds obligations rather than replacing federal ones, so health systems operating across state lines inherit requirements that vary by where care is delivered.

The Texas Responsible Artificial Intelligence Governance Act has required patient disclosure when providers use AI in care since January 1, 2026, and California's AB 3030 requires disclaimers on generative AI communications about a patient's clinical information.

Federal preemption looks unlikely to relieve that burden. The Senate voted 99 to 1 in July 2025 to strip a ten-year moratorium on state AI regulation from the budget reconciliation bill, leaving multi-state operators with compounding, jurisdiction-specific obligations.

FDA and EU AI Act obligations stay clinical in scope

FDA oversight of AI-enabled medical devices and the EU AI Act's high-risk rules both impose real requirements, and both attach mainly to AI that informs diagnosis or treatment. A team scoping administrative AI should still confirm which category each tool falls into, since ambient documentation and triage tools sit closer to the clinical line than their vendors sometimes suggest.

Why Microsoft 365 Copilot deserves its own governance conversation

Copilot is the one administrative AI tool most health systems deploy tenant-wide, and it needs separate treatment because it changes nothing about permissions while changing everything about who notices them.

Microsoft's documentation states that Copilot "only surfaces organizational data to which individual users have at least view permissions." Every governance question therefore lands on what those permissions already allow, and that produces three problems a policy document can't reach:

• Effort collapses, so dormant access gets used: Someone who could already open a file in SharePoint or search a mailbox can now ask Copilot to summarize it, surface it in a different conversation, or pull it into a draft. The permission was always there. What drops is the work required to exercise it, from a deliberate search to one sentence of natural language
• Old oversharing becomes current exposure: Broad sharing links, stale permissions, and group memberships nobody has reviewed since a reorganization sit harmlessly until something starts reading across them at speed. Licensing Copilot in a healthcare tenant is that moment, which is why Copilot data security starts with a permissions audit.
• Surfacing PHI to the wrong clinician breaches HIPAA: When that overshared content is PHI, showing it to users who don't need it violates HIPAA's minimum necessary standard at 45 CFR 164.502(b). Sensitivity-label encryption materially changes exposure, because Copilot needs extract rights to summarize content.

Health systems that have done this work report permission remediation running into the millions of individual sharing corrections before a tenant-wide rollout, which makes readiness a project rather than a checkbox.

How to build a healthcare AI governance program

Each of these decisions belongs to a leader who makes it and then delegates the work, and they need to happen in order. Name an owner before the inventory exists, and that person has nothing to manage yet.

Name a single accountable owner

"The AI governance committee will handle it," with no named individual behind it, is how these programs stall. Whether that person sits in security, compliance, or IT matters less than the fact that one person is answerable, the same way a HIPAA privacy officer is answerable for privacy. Joint Commission guidance expects a named owner leading AI implementation across the lifecycle.

Base the inventory on what each tool can actually reach

Catalog every AI system touching clinical, administrative, or embedded workflows, and map each one to the PHI or PHI-adjacent data it can reach. Route each entry to the owner who can judge how it fails, sending diagnostic tools to clinical review and productivity tools to security.

Most inventories start from nothing, because the discovery itself is usually informal. A December 2025 survey of 51 healthcare organizations by Censinet and the CHIME Foundation found that 51% relied on either informal ad hoc discovery or vendor release notes to learn what AI they were running. Shadow AI security risks accumulate for as long as that discovery stays informal.

Confirm vendor and BAA coverage matches how the AI is actually used

Every AI vendor that creates, receives, maintains, or transmits PHI needs a BAA that addresses how the vendor's AI processes, stores, and retains PHI. A boilerplate BAA signed before AI entered the product leaves a real accountability gap even though the agreement is still in force, so vendor product updates should trigger the review rather than renewal dates.

Review the covered service, data use, retention, subcontractor, and security terms specifically. Check the standard service agreement alongside the BAA, since a signed BAA doesn't override separate terms granting the vendor broad rights to use customer data. Coverage also varies by product line. OpenAI offers BAAs for eligible ChatGPT Enterprise deployments using a Regulated Workspace, while ChatGPT Business remains ineligible.

Set data and identity controls against what the inventory found

Access restrictions and monitoring need to address the exposure the inventory actually surfaced. Least-privilege language written before anyone knew which systems AI could reach won't survive an auditor's follow-up question. An identity and access management risk assessment scoped to the inventoried systems produces that specificity.

The resulting control should be concrete, not a policy statement. If the inventory shows Copilot can reach a file share holding patient census spreadsheets, the control is a permission remediation on that share, with a date and an owner.

Put a monitoring and escalation path in place

A program needs a way to detect AI-driven PHI exposure as it happens, and a named person to escalate to when detection fires. Detection means watching the repositories AI tools read from, which is ordinary file access monitoring pointed at a new consumer. Without the escalation half, the first sign of a problem is an incident report where a governance review should have been.

Using NIST AI RMF and HIPAA as your operating model

NIST AI RMF provides the structure for a healthcare AI governance program, and HIPAA provides the legal specifics; together, they remove the need for a bespoke framework.

NIST's four functions map cleanly onto a governance program. Govern is the named accountable owner, Map is the inventory, Measure is the evaluation of each use case's actual risks, and Manage is the ongoing controls and monitoring. The cycle runs continuously, not as a one-time configuration.

The inventory expectation is explicit, as Subcategory GOVERN 1.6 calls for mechanisms to inventory AI systems, and the NPRM's proposed technology asset inventory would make the same expectation regulatory.

HIPAA's Privacy and Security Rules then supply the legal obligations underneath that structure wherever PHI is involved. Together, they produce a broad-legible narrative, and neither framework requires formal certification.

The evidence that proves PHI access is actually controlled

Auditors and board committees ask for artifacts, and retrieval is where most programs fail: they do the work, then scatter the proof across six systems and four people's inboxes. Each artifact has to exist before the question arrives.

A current AI system inventory with a named owner

Every cataloged system, each tied to a named individual, not a department, who can answer when an auditor asks who approved a given Copilot expansion. The entry should also record what PHI the system can reach, so the inventory and the data-flow map stay reconcilable rather than drifting into two separate documents

A data-flow map showing where PHI enters an AI tool

Every place PHI enters an AI tool, a prompt, a file, an embedding or an output, located by sensitive data discovery tools along each path. The proposed HIPAA Security Rule would require an ePHI network map updated at least annually, so this artifact is heading toward a regulatory requirement rather than a good practice.

Vendor and BAA documentation specific to each AI tool

Documentation tied to the particular AI capability each vendor provides, not a general BAA folder, matched against the coverage confirmed during program setup. A folder like that doesn't answer the question a reviewer is actually asking.

Access and permission reports showing who can reach PHI-adjacent systems

A point-in-time answer to what an AI tool can see through, meaning the identities and groups holding access to the underlying repositories, not the tool's own configuration screen. Copilot's settings describe what it will do with permissions it already has, so a report drawn only from the tool understates reach. A reviewer is asking about effective permissions, including access inherited through nested groups.

A change log showing when that access shifted

The drift in access over the months since the last snapshot, wider or tighter than before, something a single access report can't show on its own. That trend is what an auditor actually asks to see.

Governance-review records showing the program is actually running

Minutes, sign-offs, or review notes demonstrating a real cadence. The Health Sector Coordinating Council's May 2026 AI cyber governance framework recommends structured board AI risk reports at least quarterly.

An organization that can hand over every one of those on request has a program. One that needs a week to assemble them has a policy.

How Netwrix supports the evidence layer

Netwrix supplies the data-visibility and audit-evidence layer underneath a program the healthcare organization builds and owns, answering which repositories hold PHI, who can reach them, and what changed. Information governance in healthcare depends on those answers being retrievable.

Sensitive-data visibility

Netwrix 1Secure identifies PHI-containing repositories that Copilot and other AI tools can reach and assesses Copilot readiness before rollout, not after. Netwrix Access Analyzer adds automated PHI discovery and pre-built HIPAA compliance mapping across file servers, SharePoint, and hybrid environments, with detection patterns covering ICD-10 codes, medical record numbers, and prescription drug names.

Identity and access context

Netwrix Access Analyzer reports effective permissions on PHI-adjacent data, including the excessive and inherited access that broad groups pick up without anyone noticing. Netwrix 1Secure and Netwrix Auditor report Active Directory and Microsoft Entra ID activity and permission changes over time.

King's College Hospital used Netwrix Auditor to tighten control over the privileges reaching patient data, with full visibility across a 10,000-user network supporting its National Health Service compliance reporting.

Audit evidence

Netwrix Auditor records access and permission changes, capturing who accessed what, when, and what changed, with before-and-after values. Its Long-Term Archive holds older evidence, which is what keeps a change log usable across an audit cycle rather than only since the last retention window closed.

Netwrix 1Secure covers the AI side of the same question. It reports on Microsoft 365 Copilot interactions and tracks which sensitive data Copilot accessed and surfaced, which is the artifact that answers what a tool actually reached rather than what it was permitted to reach.

Where Netwrix stops

Netwrix doesn't provide healthcare AI governance as a category and doesn't guarantee HIPAA compliance. It doesn't govern or apply policy to Copilot or any other AI tool, and it doesn't validate clinical models or detect clinical bias. Its role is the evidence layer beneath a governance program the organization owns.

See what your AI tools can actually reach before an auditor asks

Most healthcare organizations can't yet answer what Copilot and the other administrative AI tools reach, and the reason is rarely a missing policy. Nobody has mapped it.

That mapping is where the program starts, because it tells the accountable owner which repositories matter and turns a list of required artifacts into reports someone can actually run. Teams evaluating an evidence layer should test whether it can map PHI exposure, calculate effective access, preserve permission-change history, and produce those records on demand.

Request a demo to see which PHI-adjacent repositories your AI tools can reach, who holds permission to that data, and how that access has changed over time.