AI Governance Without the Theater. Implementing ANSI/HSI 2800:2025

Most health systems already have AI policies. Too many still don’t have control. In one 2026 survey, 75% said they were using AI, but only 18% had mature governance, while 42% had neither a clear plan nor a formal group. My takeaway is simple: if I can’t tie AI to named owners, approval gates, monitoring limits, and incident steps, then governance is just paperwork.

Here’s the short version of what this article says you need to do:

• Assign one owner to every AI system
• Keep a current inventory of all AI tools, including vendor products
• Score risk before go-live across clinical, security, privacy, bias, resilience, and compliance
• Set approval paths by risk tier
• Watch systems after launch for drift, unsafe output, outages, and data issues
• Use AI-specific incident playbooks for model failure, leaks, prompt injection, and vendor events
• Track a small set of metrics that leaders can review

A few numbers make the problem hard to ignore:

• 295 public health-AI incidents were reported from 2012 to 2025
• More than 90% of health systems now use third-party AI
• Less than 25% have managing third-party AI risk with compliance review
• 52% have AI tools handling PHI without confirmed BAA coverage
• Only 30% keep an enterprise-wide AI inventory, even though 70% have AI governance committees

What I like here is the shift from policy talk to day-to-day control. The article boils ANSI/HSI 2800:2025 down to a working system: inventory, risk scoring, approval, vendor review, monitoring, incident response, and board metrics.

If I had to sum it up in one line, it would be this: fewer policy binders, more evidence, decisions, and escalation.

AI Governance for Healthcare: Risk Assessment, Testing & Monitoring

sbb-itb-535baee

Map ANSI/HSI 2800:2025 to control families

ANSI/HSI 2800:2025 works best when you turn it into clear control families with a named owner, a repeatable procedure, an evidence set, and a review cadence. If any of those pieces are missing, the program may look fine on paper but fall apart in an audit.

The core families here are governance and accountability, intake and risk classification, policy and documentation, data governance, lifecycle management, third-party oversight, monitoring and reporting, and incident response. Each one should be tied to day-to-day work, not left sitting in a policy binder.

Governance, accountability, and decision rights

Governance starts with decision rights. In plain English, people need to know who can approve what, who can say no, and who owns the risk when something goes sideways.

That means board or executive oversight, a named executive sponsor, and a cross-functional AI governance committee with seats for clinical, security, privacy, compliance, legal, data, procurement, and operations.

The committee should set approval thresholds by risk tier instead of reviewing every single tool. Low-risk internal tools can move through a lighter approval path. Patient-facing or diagnostic tools need committee review, validation evidence, and legal/privacy signoff. High-risk uses - anything that influences diagnosis, treatment, or automated decisions - should move up to executive leadership or a formal risk committee, with documented risk acceptance that states who signed it, when it expires, and what triggers a mandatory review.

This is not busywork. A 2025 study found that 97% of organizations experiencing AI-related security incidents lacked proper AI access controls^[2]. That points, at least in part, to a governance problem. When ownership is fuzzy, risk is fuzzy too.

Policy, data, and lifecycle controls

For an auditable AI governance program, the minimum policy set includes seven elements:

• an AI use policy
• intake and approval criteria
• data provenance and permitted-use rules
• documentation
• validation
• change control
• retirement rules

Each policy needs to tie directly to a workflow and a team. If it doesn't, it won't hold up under pressure.

These rules apply to internally developed AI and to AI built into third-party tools. That distinction matters a lot in healthcare. More than 90% of health systems now deploy third-party AI^[1], so most AI risk comes in through procurement rather than development. A vendor's clinical documentation assistant still carries the same data governance duties as an internally built model.

For every AI use case, the required artifacts should include a use-case intake form, a risk assessment record, an inventory entry, an approval log, test evidence, and an owner assignment. No system should move forward without a gate, an evidence package, and a named approver.

Data governance needs extra focus here. Teams need to know where training, fine-tuning, and inference data came from, whether that data is allowed for the intended use, and whether it includes protected health information. AI outputs can drift or become unsafe when upstream data pipelines change or when patient populations shift. Without documented provenance, that drift can slip by until it causes harm.

Comparison table: ANSI/HSI 2800:2025 mapped to adjacent frameworks

ANSI/HSI 2800:2025 does not stand alone. In healthcare, mapping it to nearby frameworks helps create one review path for clinical, privacy, and security risk. That means less duplicate work and one shared evidence set for security, compliance, and AI governance.

The practical way to read this map is simple: NIST AI RMF gives you the risk-management vocabulary, ANSI/HSI 2800:2025 turns that vocabulary into healthcare-focused governance controls, and HITRUST lines those controls up with health-sector security and compliance practices.

Organizations that map across all three can cut duplicate work and show compliance to different audiences - regulators, auditors, and health system leadership - using one evidence set.

Use that map to support one evidence package across governance, security, privacy, and compliance. These control families only work when they are built into intake, approval, and oversight workflows.

Build the workflows that make governance work

Controls matter only when they lead to repeatable work. These three workflows turn governance into something people can actually run day to day.

AI inventory and classification workflow

Start with a full, current inventory of every AI system in use. That includes vendor tools and in-house builds, as well as clinical and administrative systems.

The key move is simple: trigger inventory at procurement, not after go-live. If a new contract, integration, or configuration change involves AI, it should create an intake record right away. That record should capture the owner, use case, autonomy level, data types, PHI exposure, minimum-necessary justification, hosting, vendor dependencies, integrations, regulatory scope, and risk tier. Those fields then drive the approval tier, control owner, and monitoring cadence.

Ownership should follow the field type:

• IT or digital health teams own technical fields
• Security and privacy own PHI classification
• Clinical owners - typically the CMIO or a service-line lead - confirm use case, autonomy level, and patient impact for care-related systems
• Business operations leaders own administrative tools like revenue cycle automation or patient scheduling chatbots

Track four metrics: total systems in production, percent of complete records, risk-tier distribution, and inventory lag for new systems. Without those numbers, you don’t have a baseline. And you can’t show whether the program is doing its job.

Less than 25% of healthcare organizations have formal AI vendor approval processes that include compliance review, and 52% have AI tools processing PHI without confirmed BAA coverage.^[3]

That’s where inventory comes in. If a system isn’t in the record, it can’t be assessed, monitored, or governed. Treat the inventory as the intake queue for risk scoring and approval.

AI risk assessment and approval workflow

Once a system is inventoried, it should move straight into scoring before approval. This workflow covers six domains: clinical safety, cybersecurity, privacy, bias and equity, operational resilience, and compliance impact. Score each domain on one scale, then use the total to set the tier and approval path. Each domain score should tie to a required control or sign-off.

A radiology triage AI, for example, would likely score high on clinical safety. If demographic performance data are incomplete, it would also score high on bias risk. That combination puts it in the high-risk tier.

The evidence package should include:

• Intake form
• Domain-by-domain assessment templates
• Risk scoring record
• Corrective action plan with named owners and due dates
• Risk register entry linking the system to its residual risk, controls, and monitoring plan

Don’t allow production access until that package is complete.

Approval gates should match the tier. High-risk systems go to the AI governance committee and executive review. Moderate-risk systems need security and privacy sign-off. Low-risk systems can move through a lighter path, but the review still needs to be documented. If there’s an exception - say, a high-risk system moves forward with incomplete evidence because of an urgent clinical need - it should go to a named executive body that accepts residual risk in writing.

Accountability routing and third-party oversight workflow

Findings need to go to the person who can fix them. Clinical safety concerns should go to the CMIO and the right service-line leadership. Cybersecurity findings belong with the CISO or security operations. Privacy issues go to the privacy officer. Compliance gaps go to legal and compliance. Procurement-related work - contract changes, vendor obligations, subprocessor arrangements - should go to vendor management or supply chain.

Less than 20% of healthcare organizations have ongoing vendor monitoring programs, and 47% have never reviewed vendor subprocessors.^[3]

That makes third-party oversight a big deal. External AI tools need contract terms and steady vendor review. Contracts should spell out permitted data handling, model-change notification duties, and evidence-sharing requirements, including validation studies and performance data across relevant demographic groups. Vendor management should also include periodic reassessment when model updates, configuration changes, or contract renewals occur.

Censinet RiskOps and Censinet AI bring routing, evidence capture, remediation tracking, and owner assignment into one place across both health system-owned and vendor AI assets. Assessment findings and remediation tasks are automatically sent to designated stakeholders - including AI governance committee members - based on preconfigured rules. The AI risk dashboard pulls together real-time data across all systems, giving security, compliance, and clinical leadership one view of outstanding assessments, open exceptions, and remediation status. Use the platform to route findings, track remediation, and keep final decisions with risk owners. That routing then feeds monitoring and incident response.

Run continuous monitoring and AI incident response

Once a system is approved, the hard part isn't over. It's just entering a new phase.

Governance doesn't stop at go-live. ANSI/HSI 2800:2025 calls for continuous monitoring and incident response, which matters a lot in healthcare, where a model can look fine at launch and then drift over time.

Monitoring, telemetry, and thresholds

You need to track more than uptime. Watch for performance drift, data drift, latency, anomalous outputs, security events, fairness, user feedback, override rates, and retraining triggers.

The FDA has flagged data drift and model drift as serious enough to "undermine" device performance after deployment.^[7]

A risk-based review cadence helps keep this practical instead of chaotic:

• Daily: IT and clinical support monitor uptime, latency, security alerts, and critical output anomalies. This is day-to-day operations, not committee work.
• Weekly: System owners - the AI product owner, CMIO delegate, and data science lead - review override rates, user feedback, and near-miss safety events.
• Monthly: The AI governance committee reviews performance drift, data drift, fairness metrics, retraining events, and aggregated incident data. Decisions and action items should tie back to the risk register.
• Quarterly: The board or executive team reviews incident counts, severity, inventory changes, fairness and safety trends, and remediation progress.

Just as important, thresholds and escalation rules need to be written down. They can't live as loose tribal knowledge.

Say you have a cancer detection model. A sensitivity drop of more than 3% might trigger an immediate RCA. A lower-risk tool may allow more room before action kicks in. Either way, every threshold should spell out:

• who gets notified
• what action is required
• how fast it needs to happen

Without that, a dashboard is just a pretty screen.

When a threshold is crossed, monitoring shifts into incident response.

AI-specific incident response in healthcare

AI incidents need their own playbooks. Most health systems already know how to respond to ransomware. Silent model degradation is a different beast.

Unsafe model behavior can affect clinical decisions, PHI handling, and reporting duties. Common incident types include unsafe outputs, data leakage, prompt injection, adversarial manipulation, model failure or degradation, vendor-side outages or degradations, and unauthorized model changes. Prompt injection, including indirect prompt injection through EHR content or external data, can force unsafe outputs.^[4][5][6][8]

The response should start with detection and triage. Alerts, clinician reports, or vendor notices can all trigger review. From there, classify the incident and assign an initial severity level.

Next comes containment. That may mean disabling the affected AI feature, switching to a manual fallback, or limiting access to compromised components. If one feature breaks, turn off that feature, not the whole platform.

Rollback plans should be documented and tested ahead of time. Communication also needs to move fast - through the EHR, team huddles, or email - so staff know what changed and whether recent AI-supported decisions need review. At the same time, preserve logs, inputs, outputs, configuration states, and telemetry for forensic work and possible regulator review.

Root cause analysis should bring in IT, data science, clinical leadership, compliance, and the vendor. After that, teams should put CAPA in place and update guardrails. The last step is checking whether the event triggers HIPAA breach notification, FDA reporting for regulated products, or other reporting duties.

The gap between symbolic oversight and day-to-day control shows up fast in the monitoring design.

Comparison table: symbolic monitoring versus ANSI/HSI 2800:2025-aligned monitoring

Those operational signals feed the rollout plan and metrics in the next section.

Implementation roadmap, metrics, and conclusion

With the controls in place, the next move is a 90-day rollout.

A 90-day rollout plan for healthcare organizations

A practical 90-day rollout works best in three 30-day phases. Each phase should have specific, lightweight deliverables that fit healthcare delivery organizations and their vendors.

Days 1–30 focus on the charter and inventory. This is the base for the governance and accountability control family. Approve a short 2–3 page governance charter that sets scope, decision rights, and how AI governance ties into your current cyber risk program. The charter should state plainly that the goal is to implement ANSI/HSI 2800:2025 as part of cyber risk management - not to produce governance documents that sit on a shelf. Set up an AI oversight committee, or expand an current risk or technology committee, with a clinical safety lead, cybersecurity lead, privacy/compliance, supply chain/vendor management, and IT operations. Then define your AI inventory data model and begin filling it in. Vendor lists and EHR integration data can help you find the first group of AI systems fast.^[10]

Days 31–60 shift to the risk gate and vendor oversight control families. Use the standard risk questionnaire to assign each system a tier and approval path. Set approval criteria for high-risk AI. For example, no unresolved critical security findings, along with required clinical validation and bias testing. Put third-party oversight requirements in place for vendors, including security questionnaires, a shared-responsibility matrix, incident notification SLAs, and performance monitoring expectations. Start by finishing assessments for your top 10–20 highest-impact systems. Update procurement and onboarding checklists so every new AI solution goes through the process before go-live.^[9]

Days 61–90 connect monitoring and incident response. Feed AI events into SIEM, APM, and EHR logs. Set thresholds for material deviations and route alerts to both IT/security and clinical safety leads when those thresholds are crossed. Build AI-specific incident response playbooks for incorrect clinical recommendations, data leaks through AI tools, and model drift. Then fold those playbooks into your broader incident response plan. Report AI risk posture, incidents, and remediation progress through board-level dashboards.

Start with the highest-risk AI use cases first.

Track progress through:

• Coverage
• Timeliness
• Remediation closure

Metrics that show governance is working

One metric deserves close attention: unapproved AI uses discovered.

Research shows that 70% of healthcare organizations have AI governance committees, but only 30% keep an enterprise-wide AI inventory.^[10] That gap is exactly where shadow AI tends to show up. Finding it doesn't mean the program is broken. It means the program is starting to do its job.

These metrics show whether governance is changing day-to-day operations.

Conclusion: fewer policies, stronger controls

Start with clear accountability. Build a full AI inventory. Standardize risk assessments and enforce pre-deployment approval gates. Put explicit third-party oversight expectations into vendor contracts. Monitor on a continuous basis with defined thresholds and escalation paths. Then connect all of it to enterprise cyber risk management so AI governance doesn't run as a separate track - it becomes part of how the organization manages risk.

The result is a governance program that produces evidence, decisions, and escalation - not policy theater.

FAQs

Who should own AI governance?

Under ANSI/HSI 2800:2025, AI governance is an enterprise risk that the Board oversees, while the CEO and executive leadership lead execution. A senior executive who reports to the CEO should coordinate the governance model.

Health systems should also assign clear, named accountability for every AI system, including:

• Clinical owners for patient safety
• Technical owners for performance and security
• Business owners for deployment and use cases

How do we risk-tier AI systems?

Use a formal intake to sort each AI use case by inherent risk. Base that rating on factors such as patient safety and clinical impact, PHI and data sensitivity, model purpose, hosting and subcontractors, and business criticality.

Start with four tiers - low, moderate, high, and critical - and use the assigned tier to scale due diligence, validation, approvals, monitoring, and reassessment. Re-tier when workflows, datasets, or vendor models materially change.

What metrics show governance is working?

Governance works when it changes behavior and improves control results, not when it just adds more policies.

Track a small set of day-to-day metrics:

• AI inventory completeness: more than 95%
• Risk assessment coverage: 100%
• Board review completion: for high-risk use cases
• Executive ownership coverage: every use case has a clear owner
• Assessment turnaround time: how long reviews take
• Risk mitigation completion: more than 90%
• Remediation timing: under 7 days for critical findings and 30 days or less on average
• Open high-severity findings: 0
• Validation freshness: less than 12 months old
• Governance-linked KRIs: track risk indicators tied to the program

This keeps the focus on what people are doing and whether controls are holding up under day-to-day use.

Related Blog Posts

• ANSI/HSI 2800:2025 Could Change How Healthcare Governs AI
• Inside the First American National Standard for AI Governance in Healthcare Operations
• What ANSI/HSI 2800:2025 Means for Healthcare Executives and Boards
• From Intent to Execution: The Promise of ANSI/HSI 2800:2025