If AI touches patient care or PHI, I should treat it as a board issue, not just an IT task.
Here’s the short version: many U.S. hospitals already use AI, but many still don’t have clear governance in place. The article’s core message is simple: boards need a clear view of every AI use case, set rules for risk, assign owners, and track vendor AI after launch.
A few numbers make the point fast:
- 65% of hospitals already use AI
- About 50% of nonfederal acute care hospitals are expected to use generative AI in EHRs by the end of 2025
- 63% lack AI governance policies
- 97% of organizations with AI-related security incidents lacked proper access controls
What I’d take away from this:
- Inventory all AI use cases across clinical, admin, and vendor systems
- Classify risk based on patient impact, PHI use, and autonomy
- Set board-approved policy for review, validation, logging, and vendor rules
- Assign named owners who can approve, pause, or stop deployment
- Monitor after launch for drift, errors, safety events, and vendor changes
The article also argues that one-time approval is not enough. AI tools can change after deployment, especially when vendors update models or switch on new features. That means boards need reporting on AI risk the same way they expect reporting on patient safety, privacy, and cyber issues.
In plain terms: if a board can’t see where AI is used, it can’t govern the risk.
Healthcare AI Governance Gap: Key Stats & Board Action Steps
Health Care Corporate Governance: Critical New AI-Related Issues for Health Care Boards
sbb-itb-535baee
The Problem: Most Healthcare Organizations Still Govern AI Like a Narrow IT Project
The main problem isn’t AI adoption by itself. It’s weak governance over where AI is being used and how it shifts over time.
In U.S. hospitals, adoption is moving faster than oversight. About 65% of hospitals already use AI, and about 50% of nonfederal acute care hospitals are expected to use generative AI in their EHRs by the end of 2025. But 63% lack AI governance policies, and 97% of organizations with AI-related security incidents lacked proper access controls.[7][5][6]
###[sic] Untracked AI Use Creates Blind Spots
Teams often start using AI tools without a central review. On top of that, vendors may switch on AI features inside current contracts with little notice. The Office for Civil Rights has directly warned about this pattern, calling out untested plugins, free dictation apps, and consumer chatbots used with PHI as risky.[10]
When these tools handle protected health information without a business associate agreement or an audit trail, the organization loses sight of basic facts. It may not be able to show who accessed the data, what model produced the output, or whether later systems or decisions were touched by it. That’s the heart of the problem: boards can’t govern what they can’t see.
And this visibility gap matters for a simple reason. AI can fail in ways that standard software usually doesn’t.
AI Risks Differ from Standard Software Risks
After validation, standard software is often fairly stable. AI isn’t. Models can drift as patient populations shift. Generative tools can hallucinate. Attackers can also exploit prompt injection or data poisoning.[6][8]
These aren’t abstract risks. They tie straight to HIPAA exposure when PHI moves through model pipelines that no one controls. They also affect quality of care when biased or drifting models shape diagnosis or treatment. And they add cyber risk when AI endpoints open new attack surfaces that no one is watching.[4][6][8] Healthcare already faces the highest breach costs and the slowest containment times. Weak AI governance is likely to make both worse.[6]
So if the risk keeps moving, a one-and-done approval process won’t hold up.
One-Time Approval Is Not Enough
Many organizations still handle AI like a normal software purchase: review it once, approve it, and move on. That falls apart fast.
Vendors update models. Clinical workflows shift. Patient populations change.
The FDA has made this point clearly. AI/ML-based medical devices need a "total product life cycle" approach, including real-world performance monitoring and predetermined change control plans, because AI behavior can change after deployment.[3][8] If a vendor pushes a model update, the health system may not even know the tool’s risk profile has changed.
That means a board relying on one-time approval isn’t governing a living system. It’s governing a snapshot.
The next step is pretty plain: inventory and review can’t stop at procurement. Boards need a process that tracks AI all the time, not just when a contract gets signed.
Solution 1: Build a Board-Mandated AI Inventory and Risk Classification Process
A board-mandated AI inventory is the starting point for healthcare AI governance. If a health system can't see where AI is being used, who owns it, or what it touches, oversight falls apart fast. One healthcare AI governance resource puts it plainly: without an inventory, oversight is structurally impossible.[2]
So the board's first move should be simple: build a complete inventory.
What the AI Inventory Should Include
The inventory should track each AI use case and spell out who is responsible for it. That means recording the business owner, clinical owner, department, workflow, vendor, PHI exposure, data sources, integrations, human review step, patient-safety risk, approval date, validation date, and monitoring owner.
Why does that matter? Because the board needs a clear view of accountability and material exposure, not a vague list of tools.
Missing ownership or validation fields are red flags. They usually mean an AI deployment is live without proper control. For example, if a clinical team is using a generative AI documentation assistant and there is no listed clinical owner or validation status, that risk is already sitting inside a care workflow.
How to Classify AI by Risk and Materiality
Each AI use case should be placed into a risk tier: low, medium, high, or critical. Those tiers should reflect clinical impact, PHI use, autonomy, and patient-facing exposure.
A documentation copilot that drafts notes for physician review may sit in the medium-risk tier if a clinician always checks the output before it enters the medical record. A sepsis prediction model or imaging triage tool is different. Those tools shape clinical judgment, so mistakes can directly affect care decisions. That pushes them into high or critical risk. Vendor-hosted models that process PHI or connect to multiple systems may also move up the scale because they increase privacy and cyber exposure.[14][15]
Risk tiers should also account for regulatory, reputational, and operational impact.[13][16]
Once the board can see the AI estate and rank its risk, it can decide what level of risk it will accept and who owns each area.
Use Censinet RiskOps™ to Centralize AI Visibility
Spreadsheets might work for a handful of tools. They don't work across an enterprise.
Censinet RiskOps™ gives governance teams and boards one place to view AI-enabled vendors, clinical applications, medical devices, and supply chain dependencies. Ownership, mitigation status, and risk tier appear in one hub instead of being scattered across departments.[16]
The difference is pretty clear:
| Untracked AI Use | Tracked AI Use with Censinet RiskOps™ | Board Oversight Implications |
|---|---|---|
| No named owner; unclear accountability | Business and clinical owners documented per use case | Board can assign and verify accountability |
| PHI exposure unknown | Data sensitivity and PHI involvement recorded | Privacy risk is visible and manageable |
| Risk level undefined | Each use case tiered as low, medium, high, or critical | Board can prioritize oversight resources appropriately |
| Approval status informal or missing | Approval and validation status tracked with dates | Auditable record supports compliance review |
| No monitoring after deployment | Mitigation status and monitoring obligations tracked | Board receives current risk posture, not a stale snapshot |
| Shadow AI deployments go undetected | Enterprise-wide visibility surfaces undocumented tools | Reduces blind spots before a safety or privacy event occurs |
Censinet AI™ routes findings to governance stakeholders for review and approval. A single dashboard keeps policies, risks, and tasks current.
That visibility gives the board something it rarely gets from scattered tracking methods: a live view of AI risk, ownership, and control.
Solution 2: Set Board-Level AI Risk Appetite, Accountability, and Policy Controls
Once the AI inventory is done, the board's next job is control. That means setting risk appetite, naming who decides what, and requiring guardrails before AI gets anywhere near patient care or sensitive data.
Define Risk Appetite for Clinical, Operational, and Administrative AI
Risk appetite should change by domain. A board should accept far less risk for clinical AI - like diagnostic support, imaging triage, or ambient documentation - than for administrative AI such as scheduling, prior authorization, or revenue cycle workflows.
Put the rules in writing. Set clear thresholds for:
- human review
- explainability for clinicians and auditors
- error rates that are not acceptable
Those thresholds should live in policy, not in vague internal guidance.[20]
Assign Clear Ownership Across the Board and Executive Team
A Censinet benchmarking study found that 70% of healthcare organizations have AI governance committees, yet only 30% maintain an enterprise-wide AI inventory.[18] That gap says a lot. A committee on paper doesn't mean the work is being done.
AI oversight should sit with the full board or a designated committee, with named executive owners for clinical safety, privacy, cybersecurity, compliance, and vendor management.[1][17] And this part matters: one specific person must have the authority to approve, pause, or stop an AI deployment. It can't stop at "someone raised a concern."
Set Controls Matched to Clinical, Privacy, and Cyber Risk
The Joint Commission recommends that healthcare organizations implement risk-based governance structures that oversee AI used in direct or indirect patient care, support services, and care-relevant operations, and ensure the hospital's governing body is regularly updated on AI use, outcomes, and potential adverse events.[20]
Boards should require documented approved use cases and minimum-necessary PHI rules.[19] They should also require BAAs, audit logging, AI-specific incident response, bias testing tied to Section 1557 nondiscrimination obligations, and annual minimum-necessary reviews for AI outputs that contain PHI.[12][11][9]
Once those controls are set, the board needs to check vendors and watch how AI behaves after launch.
Solution 3: Strengthen Third-Party AI Due Diligence and Continuous Monitoring
Most healthcare AI comes in through vendors. Sometimes it's built into clinical systems. Other times it's a standalone tool. Either way, managing third-party AI risk belongs in board governance, not just the procurement process.
Expand Vendor Due Diligence to Cover AI-Specific Risk
Standard software vendor reviews weren't built for AI. They often miss the questions that matter most.
Take ambient documentation tools. They can stream encounter audio to vendor systems, which creates PHI exposure and consent risk that routine security reviews may not catch.[27][28]
That means boards need AI-specific questions asked before any contract gets approved. Before go-live, vendors should document:
- model transparency
- PHI handling
- data flows
- upstream vendors and subprocessors
- update controls
- defenses against prompt injection, data extraction, and adversarial manipulation[12]
This due diligence needs to be written down and reviewed. It can't just be assumed.
Monitor for Drift, Safety Events, and Vendor Changes After Deployment
Approval isn't the finish line. The board also needs a steady monitoring cadence tied to vendor behavior, not just internal audits.
After deployment, monitoring should track output patterns, edit rates, subgroup performance, and adverse events. Revalidation should kick in when vendors make updates or when workflows change.[21][23][25][26]
In practice, that means:
- daily output checks
- weekly edit-rate and subgroup reviews
- monthly adverse-event trend review[23][24]
Boards should also require vendors to disclose model updates, data source changes, and integration modifications in advance.[21][22][26]
The table below shows how boards can structure oversight across the full AI vendor lifecycle:
| Area | Pre-deployment Checks | Post-deployment Monitoring | Board Reporting |
|---|---|---|---|
| Clinical performance | Validation evidence and bias testing | Daily output checks, weekly edit-rate and subgroup reviews, monthly adverse event log review | Trend summaries and escalation thresholds |
| Cybersecurity | Access controls and AI-specific threat assessment | Security anomaly detection and access log review | Incident alerts and periodic posture updates |
| Privacy / PHI | BAA review and data routing documentation | PHI access audits and consent checks | Breach notifications and compliance issues |
| Vendor changes | Model version and training data disclosure at onboarding | Advance notice of updates and revalidation triggers | Change log review and material change escalation |
| Mitigation status | Documented remediation plan for pre-deployment findings | Open finding tracking and remediation deadlines | Aging findings and closure confirmation |
Use Censinet to Put AI Third-Party Risk Management Into Practice
Putting this kind of oversight in place at scale is hard. That's where purpose-built support can help.
Censinet RiskOps™ centralizes AI policies, risks, and tasks. Censinet AI™ speeds due diligence and summarizes evidence from submission to decision. Censinet Connect™ extends vendor risk assessments and benchmarking across the network.
Conclusion: What Boards and Healthcare Executives Should Do Now
AI governance is now a board-level duty in healthcare. If AI tools shape clinical decisions, touch protected health information, add to the cybersecurity attack surface, and move through third-party vendors, the board is on the hook for what happens next. When governance is weak, the fallout is serious: patient harm, privacy violations, regulatory penalties, and lost trust. These are not just IT issues. They're leadership issues.
The path forward is simple. Boards need visibility, controls, and ongoing monitoring. Start by building an AI inventory, classifying each use case by risk, and putting controls in place that fit the level of impact.
Those controls fall apart if no one clearly owns them. Assign accountability clearly. A cross-functional executive AI governance committee should own the inventory, enforce policy, and report to the board on a set cadence [29]. Each AI domain also needs a named leader who is responsible for outcomes, not just general awareness.
That governance has to reach every third-party AI tool too. Tighten vendor due diligence with AI-specific checks for transparency, PHI handling, validation, security, and change management. After a vendor gets approved, monitoring can't be a one-time task. It needs to become a standing process, with set review cadences and escalation thresholds tied to the board's stated risk appetite.
This only works if teams have one place to manage it all. Censinet RiskOps™ brings together AI policies, risk classifications, vendor profiles, and monitoring data in a single governance hub. That way, boards get consistent, actionable reporting instead of scattered updates. Censinet AI™ helps speed up vendor due diligence, and Censinet Connect™ extends risk visibility across the vendor network. The mandate is clear: boards need to act before an AI incident makes the call for them.
FAQs
When does AI become a board issue?
AI turns into a board issue the moment it touches clinical care, privacy, data security, or vendor risk. Once that happens, it stops being just an IT matter. A failure can lead to patient harm, regulatory violations, and financial or reputational liability.
Boards should treat AI as a core enterprise risk. That means formal, documented oversight and clear escalation triggers for problems like model drift, bias, or safety events.
What should an AI inventory include?
An effective healthcare AI inventory should be a living record of every AI system in use, not just a spreadsheet that sits untouched.
At a minimum, it should track:
- the use case
- the system owner
- the data types involved
- the patient impact
But that’s only the starting point. A useful inventory should also include the model type, risk tier, model version, training data provenance, embedded workflows, validation status, approval records, and escalation paths.
That way, each system is clearly owned, tracked, and easy to review.
How often should boards review AI risk?
Boards need to review AI risk on a regular basis, not just when a system gets approved. Once a model is live, it can drift, degrade, or behave in ways no one expected at the start. That’s why one-time review isn’t enough.
Right now, only 14% of boards discuss AI at every meeting. That gap matters. Good oversight calls for a formal, steady process that keeps AI on the agenda instead of treating it like a one-off topic.
AI risk should also be written into committee charters, with a clear scope and clear triggers for when issues must be reported. In practice, that means committees should keep a close eye on things like bias, safety, and model drift, then bring those updates to the full board on a regular basis.
