AI Governance for Health Plans: Rules of the Road

A health plan commits the budget, announces the timeline, and wants to start building. Stopping now for an honest look at governance and how change is handled feels like a delay. Worse, it might surface the one answer nobody wants to bring back to leadership after the announcement: "we're not ready yet." But the question of readiness sits above any single use case. It asks whether the organization, not just the frontline team, is set up to operate AI.

Ideally, that readiness work starts before anything gets built and then runs alongside the first use case. In practice it rarely starts at all. That isn’t because plans think infrastructure doesn’t matter. It’s because the first AI initiative rarely looks like an infrastructure decision when it shows up. It looks like one expensive, well-defined problem in one department, like a pended-claims backlog that a bot could clear by matching claims against NPPES and TIN data and, when it’s confident enough, creating a new provider record on its own. A project that small doesn’t seem to need organization-wide data governance or a formal policy, and once it works, a second and third use case tend to follow the same path without anyone stopping to ask. Nobody sets out to skip governance. They set out to clear a backlog, and governance never comes up. There’s no point relitigating how plans got here, but once the gaps are visible, the fourth or fifth use case shouldn’t take the same path.

The Gaps That Keep Showing Up

When a plan finally steps back and looks across its AI use cases, the same gaps tend to surface. Each one is manageable on its own, but left unaddressed, they compound with every new use case.

• Governance. No documented policy on which categories of decision an AI system may resolve on its own and which require human review. Plans that get this right sort every use case into what must stay human, what suits AI, and what the existing platform already handles. They also ask whether the workflow should be redesigned rather than just automated. Then they write that down as approved policy instead of leaving each project team to reinvent it.
• Ownership. No single accountable executive or committee for AI use cases across the plan. A decision like letting that bot create provider records on its own has no one positioned to catch it before it compounds.
• Documentation. Institutional knowledge lives in people's heads instead of in written procedures anyone could hand to a build team.
• Provenance. Reviewers can’t see what an AI recommendation is based on, such as the source records, rules, or policy language behind it. So they either accept it on faith or redo the work to check it.
• Feedback loops. Frontline staff and downstream teams have no structured way to flag a wrong AI recommendation, so the same failure repeats quietly until someone happens to escalate it informally. The opposite signal matters too: when reviewers almost never override the system, it may mean they’ve stopped checking.
• Model performance monitoring. No ongoing validation to catch silent model drift. Data distributions shift, edge cases emerge, and performance degrades over time, so the model validated at deployment isn't necessarily the model running six months later. Without scheduled monitoring, revalidation triggers, and alerts when accuracy drops below threshold, degradation compounds until someone notices the failure rate has climbed.

Rules of the Road: What AI Governance Has to Cover

Governance isn't a compliance binder and it isn’t a playbook borrowed from another plan. It’s your plan’s own set of standing answers that keep every new AI use case from re-arguing the same questions. At a minimum, it covers ten areas.

• Use-case intake and risk tiering: A single front door for every proposed AI use case, with each one rated by risk (member impact, financial exposure, regulatory exposure) so oversight matches the stakes.
• Decision rights and human-in-the-loop rules: Which decisions AI can make, recommend, or never touch, and who must review before action. This covers adverse determinations, denials, and anything affecting member access to care.
• Data standards and source lineage: What data AI may use, its approved sources, minimum quality thresholds, PHI/privacy and minimum-necessary controls, and what AI may write back to systems of record.
• Provenance and audit trail: Every AI-touched record and output carries its origin (system, model and version, prompt or rules in effect, confidence score, timestamp) and a reversible link back to source. Logs let any AI action be reconstructed for auditors, regulators, or a provider dispute.
• Downstream propagation and rollback: AI-originated data is tracked as it flows into directories, claims, credentialing, and regulatory reporting, so errors can be found and unwound in bulk, not record by record.
• Regulatory and accreditation alignment: Mapping each use case to CMS, state, NCQA/URAC, HIPAA, and directory-accuracy requirements, with compliance sign-off before go-live.
• Vendor and third-party oversight: Contract terms for model transparency (training data sources, versioning), audit rights, and accountability when a vendor’s AI touches your members, providers, or data.
• Validation and operational sign-off: Testing against real payer workflows, plus a downstream-impact review by operational and systems owners before launch.
• Ongoing monitoring and performance thresholds: Accuracy, drift, bias, and exception-rate tracking, with defined triggers for retraining, pausing, or shutting off a use case.
• Accountability, escalation, and workforce use: A named owner for each use case, an incident response and escalation path, and rules and training for staff use of AI outputs.

Change Management Belongs to the Whole Organization

Getting one operations team to trust and adopt a specific tool is a team-level job. Organizational readiness sits a layer above it, and it is where most plans underinvest. It starts with leadership agreeing on what AI is and isn’t for at this plan. From there, it takes concrete work:

• A readiness baseline before each use case: Documented, standardized current-state workflows, so you know what AI is changing and who is affected. Automating a process nobody has written down means automating the variation.
• Cross-departmental coordination: With the provider-record bot, Provider Relations, Network Operations, Credentialing, and Claims all had a stake and all needed a seat in the same conversation, before build, not after launch.
• Role and workflow redesign: Staff move from doing the work to reviewing exceptions, validating AI output, and correcting what it gets wrong. Those are different jobs, and they need updated job descriptions, productivity targets, and QA standards.
• Capacity and sequencing: Teams need room to learn and to run parallel processes during the transition. Stacking several AI rollouts on the same team at once is a common cause of failure.
• Training that scales: A role-based program that goes beyond the pilot team, covering how the tool works, when to override it, and how to escalate problems.
• Change champions and feedback loops: Respected frontline staff in each department who surface issues early, plus a clear channel for reporting AI errors that gets a visible response.
• A communication cadence: Regular updates on what is live, what is coming, what is changing for each team, and what results the AI is delivering, so the rest of the plan hears it from leadership and not from rumor.
• Reinforcement after go-live: Adoption tracking, workaround detection, and a defined owner for sustaining the change once the project team moves on.

Measure More Than Speed

Turnaround time and volume are the easiest numbers to put on a dashboard and the least sufficient ones to govern by. They're the same metrics that made the provider-record bot look like a success while its errors piled up downstream. Start with the value case. Before a use case launches, define what it’s supposed to improve and measure it against a pre-AI baseline. If the plan doesn't define value, every vendor will define it for you. "We freed up staff" isn't a result unless that capacity went somewhere measurable. Then track downstream effects on purpose: appeals and complaint trends, data-quality drift, override and escalation rates, and whether provisional or exception cases actually get resolved within their intended window instead of just getting created.

The Audit Is the Fast Path, Not the Delay

Most plans don’t skip this diagnosis on purpose. The pressure to show progress is real, the vendor demos are persuasive, and the gaps described above are hard to see from the inside. So the diagnosis happens later, after a failed or stalled deployment, when it costs more and the next attempt starts with more skepticism built in. Smaller and mid-sized plans feel this most. AI lets an organization make mistakes faster than any manual process ever could, and a smaller plan has less room to absorb the cleanup. Governance is what lets a plan move fast without betting the organization on each use case. An organizational readiness assessment is cheap next to a deployment that has to be relaunched, this time in front of a workforce that already watched the first attempt struggle.

i2 Health builds the data, governance, and ownership layer into the deployment plan alongside the workflow itself, so the health plan is ready to run what gets built. Results, not roadmaps.

Not sure whether your data, governance, and ownership can support the next use case? Start with an AI readiness assessment.

Frequently Asked Questions

Q: We already have an AI committee. Isn't that governance?

Not by itself. A committee is the body that applies governance, not governance itself. Governance is the set of guidelines the committee decides by, and the standing answers those guidelines produce: which decision categories each tier of AI may handle, who owns every system that can act on its own, what metric triggers a model audit, and who has the authority to pull a model. If the committee is making judgment calls one use case at a time without those guidelines, it’s a forum, not governance. A useful test: ask who owns the last bot your team launched, and what accuracy threshold would get it switched off. If nobody can answer both, start there.

Q: Do we need clean data before we start an AI pilot?

Usually not. Waiting for perfect data can stall a pilot indefinitely, and payer data is rarely perfect. What you need is to know where your data is unreliable for the specific decision the pilot touches: which fields different teams populate differently, which legacy feeds drop values, and who owns fixing them. A pilot built on a known data gap, with a human review step covering it, is safer than one that assumes the data is fine. The provider-record bot described above is the counterexample: it created new records with no human review, so a data gap became a compounding problem. Lineage and provenance tagging can run alongside the first use case instead of ahead of it, so you can always trace what the AI touched and unwind it if needed.

Q: Who should own AI governance at a health plan: IT, compliance, or operations?

One accountable executive, with all three at the table. IT owns the platform and the model monitoring. Compliance owns audit trails and regulatory exposure. Operations owns the workflow, its downstream consequences, and the monitoring of downstream impact. That’s why governance housed entirely in IT tends to miss what matters most: errors usually surface in network operations and claims, not in the model’s own metrics. Where the owner sits matters less than having one, with the authority to pause a system that's drifting.

Q: How does AI governance connect to CMS-0057-F prior authorization requirements?

Closely, if any part of your prior authorization workflow is automated. CMS-0057-F requires impacted payers (Medicare Advantage, Medicaid and CHIP, and exchange plans) to meet 72-hour and 7-day decision timeframes, give a specific reason for every denied medical prior authorization, publicly report metrics annually, and have a Prior Authorization API in place beginning January 1, 2027. Automation that touches those decisions needs the audit trail described above: which decisions a system may make on its own, which route to a clinician, and a traceable record of both. Without that, an automated workflow becomes the hardest thing to explain when the metrics are public.