If I lead a healthcare organization, this standard changes one thing right away: AI is no longer just an IT issue. It is a board and CEO issue.
ANSI/HSI 2800:2025, approved on December 17, 2025, sets one U.S. framework for healthcare AI governance across procurement, internal development, deployment, and monitoring. It applies to clinical and administrative use cases, including tools from vendors and AI built into current workflows.
Here’s the short version of what I’d take from it:
- Boards are expected to oversee AI risk.
- CEOs and senior leaders are expected to own execution.
- Clinical, compliance, IT, privacy, and risk teams need defined roles.
- Vendors and supply chain AI need the same scrutiny as in-house tools.
- Reporting has to include AI-specific signals like drift, bias, safety events, and privacy issues.
- Records matter: charters, risk logs, approval logs, audit trails, and escalation paths should be in place.
- The first 90 days should focus on ownership, inventory, board reporting, and incident paths.
In other words: if AI affects patient care, staff workflows, revenue, privacy, or trust, I can’t govern it with scattered processes and vague ownership.
A few points stand out from the article:
- The standard is described as the first American National Standard for healthcare AI governance.
- It places board responsibility at the top, with CEO-led execution below it.
- It pushes leaders to look past privacy-only reviews and track things like model drift, biased outputs, and vendor control gaps.
- It also treats third-party and fourth-party AI risk as part of normal governance, not as a side issue.
AI Is Already in Your Organization - Is Your Board Ready?
Quick comparison
| Area | Before ANSI/HSI 2800:2025 | After ANSI/HSI 2800:2025 |
|---|---|---|
| Oversight | AI often sits in IT or innovation | AI sits in board governance |
| Ownership | Split across teams | CEO and senior leaders own execution |
| Vendor review | Often inconsistent | Standardized due diligence and monitoring |
| Risk tracking | Privacy-heavy, often ad hoc | Bias, drift, safety, privacy, and consent tracked |
| Reporting | Limited AI detail | Board dashboards with AI-specific metrics |
| Incident response | Informal paths | Defined escalation and review paths |
What I like about this piece is its main point: leaders do not need to be AI engineers to govern AI well. They do need clear ownership, board visibility, and proof that controls are in place.
That is the lens I’d use for the rest of the article.
The governance problems boards and executives can no longer ignore
These risks hit three areas boards can't brush aside: ownership, vendor oversight, and reporting.
"AI is now touching decisions that shape safety, quality, access, trust, liability, and financial performance of healthcare organizations." [2]
That’s the heart of the problem. The standard is aimed at those breakdowns.
Fragmented accountability across IT, compliance, clinical, and operations teams
The first problem is structural. Most health systems still handle AI like an IT project. That means procurement, monitoring, and escalation end up split across separate silos. Clinical leaders often aren’t brought in until after something has already gone wrong.
When an AI tool leads to an unexpected outcome, no one person clearly owns the issue. That kind of blurred responsibility is a board-level problem, not just a workflow headache. Don Taylor, Chairman of the HSI Foundation Standards Board, puts it plainly:
"Boards and CEOs don't need to be technologists to lead AI…they need a governance system that makes AI accountability real." [2]
Limited visibility into third-party and supply chain AI risk
The second problem sits in the supply chain. Many AI-enabled tools come through vendors, including EHR platforms, revenue cycle tools, imaging software, and predictive analytics products. In many cases, organizations may not fully see or track the embedded AI inside those products.
Governance across the healthcare ecosystem is often uneven and, in many settings, optional [2]. So a health system might hold itself to strict internal rules but still have no clear way to check whether vendors meet that same standard.
Then there’s fourth-party exposure: AI inside the tools used by your vendors’ vendors. That adds one more blind spot. If a vendor’s model drifts or starts producing biased outputs, the health system still needs a way to spot it, escalate it, and respond.
Board reporting that misses AI-specific risk signals
The third problem is reporting. Even routine cyber and compliance reports often leave out AI-specific warning signs, such as model drift, black-box behavior, and gaps in vendor governance.
Without those signals, boards can’t carry out meaningful fiduciary oversight. They’re approving strategy and signing off on risk posture without a clear view into a material source of operational, financial, compliance, and reputational exposure. ANSI/HSI 2800:2025 treats that gap as a governance issue, not just a technical one.
sbb-itb-535baee
What ANSI/HSI 2800:2025 Changes in Board Oversight and Executive Responsibility

Healthcare AI Governance Before vs. After ANSI/HSI 2800:2025
ANSI/HSI 2800:2025 moves AI oversight out of a narrow IT lane and into enterprise governance. The standard's abstract says it in plain terms:
"This standard will be the responsibility of the Board of Directors, with execution by the CEO and executive leadership." [1]
That changes two things right away: what boards need to review and what executives need to document.
Board Accountability and Executive Ownership Under the Standard
Under the standard, boards oversee and the CEO with senior leaders carry out the work. Clinical and compliance leaders also need a seat at the table during implementation. As Hamed Abbaszadegan, MD, MBA, Physician Executive at Stanson Health, explains:
"Physicians have always been taught to trust, yet verify, and AI will never be full proof. Having physicians involved in the oversight process will be critical to ensuring safety for our patients." [2]
That point matters. Clinical leaders need to check safety, equity, and usability, while also guarding against too much reliance on opaque outputs.[2] Their role connects straight back to board oversight. In practice, boards need proof that AI tools are working as governed, not just that they were switched on and put into use.
A practical step is to update committee charters so AI governance sits with enterprise risk or governance committees, not just IT subcommittees.
Governance Records Leaders Should Expect to Review
Defensible governance depends on records that can hold up under audit and regulatory review. Leaders should expect to keep documentation such as:
- Committee charters that clearly assign AI oversight duties
- Formal escalation paths for AI performance issues, safety concerns, or drift
- Decision logs showing who approved each deployment and why
- Risk registers covering bias, safety, drift, transparency, privacy, and consent concerns
- Monitoring reports and audit trails for continuous oversight
Those records become the backbone of board reporting and vendor oversight.
Before and After: How Governance Changes Under the Standard
| Governance Area | Pre-ANSI/HSI 2800:2025 | Post-ANSI/HSI 2800:2025 |
|---|---|---|
| Board Accountability | AI viewed as a technical/IT project; limited oversight | AI treated as a core enterprise risk; formal Board oversight required |
| Executive Roles | Fragmented ownership across IT or innovation departments | CEO and executive leadership held accountable for execution and compliance |
| Risk Documentation | Ad hoc risk assessments; focus on data privacy only | Risk registers covering bias, drift, and clinical safety |
| Escalation Paths | Informal or non-existent pathways for AI failures | Defined escalation pathways across clinical and operational use cases |
| Monitoring | Periodic or reactive reviews of AI performance | Continuous monitoring and audit trails across the full lifecycle |
| Vendor Oversight | Ad hoc vendor questionnaires | Standardized due diligence, contract controls, and monitoring evidence |
Next, these governance requirements need to show up in board metrics, vendor decisions, and compliance reporting.
How to Put the Standard to Work in Reporting, Vendor Oversight, and Compliance
The next step is turning governance into board reporting, vendor controls, and compliance workflows.
Board-Level AI Risk Metrics and Reporting Structure
Board reporting should turn AI risk into a standing dashboard with a set schedule and clear escalation triggers.
Use the risk register and monitoring reports to build a standing board dashboard.
| Governance Domain | Board-Level Metric / Reporting Item | Reporting Cadence | Escalation Trigger |
|---|---|---|---|
| Clinical Safety & Quality | AI-related near misses or safety incidents | Quarterly | Any incident resulting in patient harm or major drift in diagnostic accuracy |
| Third-Party Risk | % of AI vendors with documented conformance to ANSI/HSI 2800:2025 | Bi-annually | Discovery of unapproved AI tools in clinical workflows |
| Operational Performance | Revenue cycle accuracy and financial variance linked to AI | Quarterly | Major deviation from baseline financial or operational KPIs |
| Patient Notice and Consent | Patient consent compliance metrics | Annually | Regulatory inquiry or breach of patient privacy/data usage terms |
| Clinician Workload | Clinician burnout scores related to AI tools | Annually | High rates of over-reliance or workflow disruption reported by staff |
Use these metrics across procurement, deployment, and monitoring.
That matters because the same governance controls shouldn't stop once a tool goes live. They should carry straight into procurement and renewal decisions too.
Applying the Standard to Third-Party and Supply Chain Decisions
Require vendors to show documented conformance to ANSI/HSI 2800:2025 or similar audit evidence, with contract terms that cover transparency, bias review, monitoring, and escalation.[2]
During procurement, evaluate AI-enabled tools for transparency, bias controls, monitoring, and response duties if performance changes. In plain terms, if a vendor can't explain how the tool is watched, tested, and handled when results shift, that's a red flag.
Tie procurement criteria straight to the records leaders are already keeping, including:
- risk registers
- decision logs
- monitoring reports
From there, map AI controls into existing cyber, privacy, and enterprise risk programs.
Aligning the Standard with Existing Cyber, Privacy, and Compliance Programs
The standard complements HIPAA, NIST CSF, and ERM. Use it to cover AI-specific governance gaps those programs do not address on their own.
In practice, cybersecurity teams can extend vendor risk assessments to include AI-specific controls such as drift monitoring and transparency requirements. Privacy teams can map patient consent workflows to transparency expectations. Patient safety and quality committees can review AI monitoring results alongside adverse event reporting. ERM teams can treat AI risk with the same rigor applied to financial or clinical quality risk and route it through the existing board-level reporting structure.
Actions Healthcare Leaders Can Take Now and Key Takeaways
A 90-day governance action plan
Turn the standard into action with a short, board-ready plan.
Within 90 days, name an executive owner, inventory all AI tools, set a board reporting cadence, and define approval and escalation paths across the full AI lifecycle. The first priorities are ownership, visibility, and escalation. Those are the same failure points this standard is meant to address.
Once ownership and inventory are in place, set the approval workflow for new AI deployments and the incident escalation path for when something goes wrong. Then review your highest-risk vendor relationships against the standard’s expectations and flag any gaps. If an AI tool affects patient-facing decisions or communications, review consent and disclosure practices too. By day 90, bring the board its first AI risk dashboard.
How Censinet supports execution at scale

Censinet RiskOps™ puts the records, workflows, and reporting this standard calls for in one place.
These governance tasks need a single system for assessments, routing, and reporting. The table below maps Censinet’s core capabilities to the governance needs ANSI/HSI 2800:2025 creates:
| ANSI/HSI 2800:2025 Governance Need | Censinet Capability | What It Does |
|---|---|---|
| Centralized governance records | Censinet RiskOps™ | Centralizes risk assessments, policies, and tasks |
| Vendor and supply chain oversight | Censinet Connect™ | Supports vendor collaboration and third-party risk assessments |
| Faster AI-related assessments | Censinet AI™ | Speeds questionnaires, summarizes evidence, and drafts risk reports |
| Accountability and routing | Human-in-the-loop orchestration | Routes findings to the right reviewers for approval |
| Board-level reporting | AI risk dashboard | Centralizes AI-related policies, risks, and tasks for executive and board visibility |
Key points for executives and boards
For boards, this is about operational control, not technical detail.
ANSI/HSI 2800:2025 reframes AI as a board-level governance issue, not a technical project. Boards should require explicit accountability, board reporting, vendor visibility, and continuous monitoring.
FAQs
Who should own AI governance in a healthcare organization?
Under ANSI/HSI 2800:2025, the Board of Directors holds primary responsibility for AI governance. The CEO and executive leadership, meanwhile, are accountable for execution and day-to-day oversight.
To make that work in practice, organizations should back it up with a multidisciplinary AI governance committee that includes clinical, security, privacy, legal, and procurement teams. The Board should stay focused on fiduciary oversight and strategic alignment. Management should own AI authorization, performance monitoring, and decommissioning.
How does ANSI/HSI 2800:2025 change vendor AI oversight?
ANSI/HSI 2800:2025 says healthcare organizations can’t just take a vendor’s word for it. They need to use one clear, defensible governance model across the full AI lifecycle.
That applies from selection and validation to monitoring and change control.
Boards and executive teams also need to hold vendors to the same bar for safety, transparency, and bias mitigation. For AI-driven clinical and operational tools, that means asking for proof, not promises, including evidence of validation, monitoring, and strong change control.
What should boards see in an AI risk dashboard?
Boards should get an auditable, data-based dashboard that shows the organization’s AI landscape in plain terms. Not loose narratives. Not vague updates. A board needs a clear view it can check, track, and question.
At a minimum, that dashboard should show:
- AI systems in use, grouped by risk level
- High-risk use cases waiting for review, plus validation status for high-impact tools
- Unresolved control gaps, failed validation checks, open vendor or contract issues, and AI incidents, near-misses, or bias findings