Most health systems do not have an AI governance problem on paper. They have a control problem in practice.
I’d put the article’s point this way: if a health system cannot show who owns each AI tool, what risk limits exist, what happens when those limits are crossed, and what proof exists today, then it is mostly producing activity, not lowering risk.
Here’s the short version:
- Committees are not controls if they cannot stop or change an AI deployment.
- Policies are not controls if they do not set risk limits, monitoring duties, and enforcement steps.
- Inventories and vendor questionnaires go stale fast when vendors add features, models, or new data flows after approval.
- One-time procurement review is not enough for tools that change over time.
- Split ownership creates gaps when clinical, privacy, security, compliance, and procurement teams each see only part of the risk.
- Real governance needs five things: artifact, control, owner, metric, and evidence.
- The article’s test is simple: if you cannot prove the control works right now, you are likely looking at theater.
A few facts make the gap hard to ignore:
- ECRI named AI the top health technology hazard for 2025.
- More than 50% of healthcare groups have no documented way to detect when vendors add AI to approved products.
- 38% split AI risk across groups without clear escalation paths.
- The article points to target measures like >95% inventory coverage, 100% risk assessment coverage, 0 open high-severity findings, and <7 days to fix critical issues.
The article also makes a plain distinction between two models. One relies on slide decks, approvals, and spreadsheets. The other uses named decision rights, change-triggered reassessment, drift checks, incident paths, and time-stamped proof across the full AI lifecycle.
If I had to reduce the article to one line, it would be this: visible governance is easy to show; measurable control is harder to run.
Healthcare AI Governance - Risks, Compliance, and Frameworks Explained
sbb-itb-535baee
Where health systems confuse motion with control
The pattern is pretty clear: health systems often produce oversight artifacts that look like control, but don't change deployment risk.
Committees, policies, and approvals that do not change risk
Most AI governance setups in U.S. health systems lean on familiar rituals: a steering committee, a written policy, and an approval workflow. Those things create process. They do not create control. In practice, that means no one is actively stopping unsafe clinical use, privacy drift, or security exposure.
Each artifact leaves a specific gap open.
A committee is often set up to review and recommend, not to halt or change deployments. If it has no stop authority, it isn't a control. It's documentation.
Policies usually lay out principles around patient privacy, clinical safety, and transparency. But if they don't include monitoring duties, risk thresholds, and enforcement, they don't change day-to-day behavior.
Approval workflows have the same problem. They close the loop on paper, not in operations. A procurement checkbox that isn't tied to a defined risk threshold, required safeguards, or a documented escalation path is an attestation, not a control.
Inventories and questionnaires that go stale on day one
The second big gap shows up in how health systems track AI tools and vendor risk. A common response to board or regulatory pressure is a one-time AI inventory project. IT or compliance surveys department leaders, builds a list of tools, and saves the results in a spreadsheet. Vendor questionnaires usually follow the same pattern: fill them out at procurement, then archive them.
That approach breaks down because it isn't tied to change triggers.
A hospital might log an ambient documentation tool as AI-enabled transcription. Then, over the next year, the vendor adds automated clinical summarization, diagnostic suggestion features, and an integration with an external large language model. Across revenue cycle tools, patient engagement platforms, and clinical decision support, those kinds of changes almost never trigger a reassessment.
New data flows, model retraining, added modules, and upstream dependencies rarely show up in the original questionnaire. And that's the core issue. The spreadsheet itself isn't the risk. The risk is that clinicians and patients may be relying on a materially different tool than the one that got approved.
As the AMA's monitoring guidance makes clear, meaningful oversight requires routine checks on output quality, algorithm performance, and regular audits - not a one-time review at procurement.[1]
HHS calls for current inventories and risk-based controls.[3]
When inventories go stale, leaders can't answer basic questions like which models are active, what data they use, or how they have changed. At that point, the organization is managing a snapshot, not live AI risk.
Why these gaps persist in U.S. healthcare
These gaps stick around because U.S. healthcare spreads AI risk across teams that rarely share one owner or one live view of the system.
Fragmented ownership is the main driver. Clinical safety teams focus on patient harm but often can't see algorithm design or vendor updates. IT and security tend to treat AI like just another application, instead of a changing decision system. Compliance and privacy teams focus on HIPAA and contract terms, but may not dig into model behavior. So each group assumes someone else is handling the AI risk. The result? No one owns it end to end.
Pressure for visible proof makes it worse. When boards, regulators, and the public want signs that AI is being managed well, the fastest move is to produce artifacts: published AI principles, board slide decks, and AI readiness reports. Boards get artifacts. Operations get no control changes.
Weak operationalization of frameworks leaves many organizations without a usable roadmap. The NIST AI RMF and The Joint Commission's RUAIH guidance are often cited, not implemented.[2]
That's why defensible governance has to assign authority, define escalation, and monitor AI on a continuous basis.
What defensible AI governance requires
Real governance tracks an AI system from intake all the way to retirement.
Lifecycle governance across clinical, privacy, security, and compliance risk
At intake, teams need to review medical device clinical validation, map the protected health information (PHI) the system touches, assess cybersecurity risk, and document who owns that risk. At deployment, the job shifts from paper review to proof. Safeguards need to be in place in the live system, not just listed in a vendor questionnaire.
Vendor changes matter too. If an update adds a new model capability, that should trigger a reassessment. A file update isn't enough. The trigger has to change the review itself.
More than 50% of healthcare organizations have no documented way to detect when vendors add AI into existing, already approved products.[4] That's a major blind spot.
Decision rights, escalation paths, and named accountability
Ownership needs to be named, not implied.
- Security should own inventory and audit trails.
- Privacy and compliance should own HIPAA and BAA coverage for AI-related data use.
- Clinical leadership should own safety validation and human review.
- Legal and procurement should own vendor disclosure.
- Operations should own drift and incident reporting.
Each group also needs documented go/no-go criteria, plus the authority to pause or retire a system when risk crosses a defined threshold.
Right now, 38% of healthcare organizations split AI risk across several groups without clear escalation paths, or they haven't defined ownership at all.[4] You can guess what happens next: during an incident, every team thinks someone else had it covered.
And even when ownership is clear, approval alone doesn't solve the problem.
Continuous monitoring instead of one-time review
Procurement review only shows the starting point. Ongoing oversight needs to include model drift detection, incident and harm reporting, access log review, vendor change notices, and reassessment whenever a workflow or dataset changes.
It also means treating every AI data request as untrusted. Teams should check each request against current policy, data sensitivity, and the system's documented clinical purpose. That keeps AI systems limited to the PHI they actually need for the task.[4]
"Healthcare has built the governance structure for AI, but the operational muscle - inventory, asset management, detection methods, and clear accountability - is not keeping pace with adoption." - Ed Gaudet, CEO, Censinet[4]
These controls produce the evidence that separates theater from real control.
How to tell governance theater from real control
AI Governance Theater vs. Defensible AI Risk Management in Healthcare
The line is pretty clear: if it doesn’t produce evidence, it isn’t control.
A simple test: artifact, control, owner, metric, evidence
Take any governance item in your program - a committee, a policy, an AI inventory, a vendor questionnaire, or an approval workflow - and put it through five basic checks:
- What does this artifact do to cut risk?
- What control does it enforce?
- Who is the named person accountable for that control?
- What metric shows the control is working right now?
- What evidence proves it works?
If you can’t answer all five, you’re probably looking at theater.
A monthly AI committee is a good example. If it reviews slide decks but can’t approve or block deployments, and can’t require risk fixes, it’s just an advisory group. That’s not control. On the other hand, a committee with formal power to approve or reject high-risk AI use cases, require documented risk assessments before go-live, require bias testing and clinical validation, and pause live systems when risk thresholds are crossed is doing something very different. It is enforcing control.
A good way to pressure-test this is to run it across 5–10 AI tools. Patterns will show up fast. Artifacts with no controls, controls with no owners, owners with no metrics - those are the weak spots that need attention first.
Core metrics that show whether oversight is working
Metrics should show whether oversight changes behavior, not whether paperwork exists. Focus on coverage, speed, accountability, and results.
| Metric | Target |
|---|---|
| AI inventory completeness | >95% of known AI systems documented |
| Risk assessment coverage | 100% of inventoried AI with completed assessments |
| High-risk AI under enhanced oversight | 100% |
| Risk mitigation completion | >90% of identified risks with implemented mitigations |
| Highest-risk AI with validation less than 12 months old | 100% |
| Time to remediate critical findings | <7 days on average |
| Open high-severity findings | 0 |
| Average time to close risk findings | ≤30 days |
If your program can’t report most of these today, that points to measurable control gaps.
Governance theater vs. defensible AI risk management: a comparison
This is where the difference shows up in day-to-day work. The issue isn’t activity for activity’s sake. The issue is whether that activity cuts risk.
| Dimension | Governance Theater | Defensible AI Risk Management |
|---|---|---|
| Decision authority | Advisory committees with no blocking power | Named owners with formal go/no-go authority |
| Lifecycle assessment | One-time review at procurement | Intake, deployment, change, and retirement reviews |
| Model inventory quality | Static spreadsheet, updated manually | Continuously maintained, tied to change triggers |
| Third-party oversight | third-party AI risk questionnaire filed and forgotten | Reassessment triggered by material vendor changes |
| Monitoring | Annual or ad hoc review | Defined continuous monitoring per tool and risk level |
| Incident escalation | Informal, no standard path | Documented playbook, tracked to closure |
| Documentation quality | Policies and logs | Time-stamped evidence trail across the AI lifecycle |
| Audit readiness | Can show artifacts | Can show artifacts, controls, owners, metrics, and evidence |
NIST’s four functions - govern, map, measure, and manage - turn AI governance into something you can run, track, and test.[5]
Once this test shows where the gaps are, the next move is to put those controls into one live workflow.
Operationalizing real AI governance with Censinet
Closing the gaps is the hard part. Controls have to stand up to audit, and they have to work at scale without leaning on manual effort. More policy alone won’t fix that. What helps is a single workflow that records intake, review, decisions, and monitoring from start to finish.
Centralize AI risk workflows in Censinet RiskOps™
When security, privacy, clinical, and compliance teams all work from separate files and threads, reviews get messy fast. Censinet RiskOps™ swaps out email, spreadsheets, and siloed reviews for one centralized workflow model. Every AI initiative goes through structured intake, gets routed to the right stakeholders, and creates a connected record of the asset, risks, controls, evidence, and decisions. It ties together the five parts of the model - artifact, control, owner, metric, and evidence test - in one place. That gives teams one clear control point instead of scattered handoffs.
Dashboards give leaders real-time visibility into portfolio status, control coverage, and open findings. AI Telemetry continuously classifies products as AI-enabled, non-AI, or unknown, which helps surface hidden AI exposure as products change and keeps inventories current.[6]
Speed up third-party AI review with Censinet AI™
Third-party AI review is often where governance programs slow down. Censinet AI™ tackles that head-on with AI-assisted questionnaire completion, automatic evidence summarization, and fourth-party exposure capture during intake. It also drafts risk summaries from assessment data. Censinet reports that its Risk Assessor Agent and related automated workflows can deliver up to 66% time reduction on key assessment workflows by using vendor data and network intelligence to spot high-impact exposure early.[7]
Automation moves the review along, but people still make the approval calls. PHI use needs privacy approval. Diagnosis, treatment, or triage use needs clinical approval.
Conclusion: Replace visible activity with measurable control
A governance program works only if it cuts AI-related risk. Real governance means lifecycle controls that stay with an AI system from intake through retirement, named owners who are accountable for specific risks, continuous monitoring, and evidence that can hold up under scrutiny from a regulator, an accrediting body, or a plaintiff's attorney.
FAQs
How can we tell if our AI governance is just theater?
It’s probably theater if your committee can’t formally stop or retire a tool, or if you’re leaning on static, point-in-time reviews for systems that keep changing.
Real governance works day to day. It keeps a current inventory, assigns executive owners, watches for performance drift, and requires local validation - not just meetings, policy docs, or procurement checklists.
Who should own AI risk in a health system?
AI risk needs clear, named accountability. Not vague, shared responsibility.
For each AI tool, health systems should assign a clinical owner who is accountable for patient safety outcomes and a technical owner who is responsible for performance, security, and infrastructure.
That split matters. When ownership is blurry, accountability tends to drift. And when accountability drifts, risks can sit in plain sight because no one has the authority to approve, pause, or retire a model.
What evidence should we collect to prove AI controls work?
Collect audit-ready evidence that shows continuous oversight, not just finished checklists. That means keeping time-stamped records, version histories, incident logs, and validation results based on your local patient population.
You should also keep proof of ongoing monitoring, human oversight, data security, vendor accountability, and formal signed approvals. Include rollback plans and clear retirement triggers for models that stop performing well.
