AI governance covering the whole surface: what you built, what arrived embedded in a vendor platform, and what a delegated entity is running on your behalf while you remain accountable for the outcome.
Payer AI governance programmes usually start with the models the plan is building. Those are the smallest part of the exposure and the easiest to control. The larger part sits inside core administration platforms, utilization management tools, payment integrity vendors and care management partners, where the plan is answerable for the result and frequently cannot inspect how it was produced.
If AI influences whether a member gets care or a provider gets paid, the plan owns that outcome regardless of whose model produced it.
A plan can govern its own development rigorously and still carry most of its exposure elsewhere. A payment integrity vendor scores claims using a model nobody at the plan has seen. A utilization management platform ships predictive features that were enabled by default. A delegated entity applies its own criteria automation to cases the plan remains answerable for. In each case the member and the regulator see the plan.
That is different from most enterprise AI governance, which assumes the organization controls the model. Here the governing question is frequently not how was this model built, but what did we ask, what were we told, what can we verify and what did we agree to accept.
Vendor AI arrived without a decision
Features enabled in a platform upgrade, scores appearing in a workflow, a capability included in a renewal. Nobody approved it because nobody was asked.
Delegated entities run their own AI
Utilization management, claims and care management delegated to partners who deploy their own models. Delegation transfers the work and not the accountability.
Governance that only slows the plan down
A review process with no timeline and no conditional path teaches teams to route around it, which produces exactly the ungoverned adoption it was created to prevent.
Everything treated as one risk category
An AI that drafts an internal summary and an AI that influences a coverage outcome cannot share an approval path.
Pilots accumulate without a portfolio view
Collectively they produce duplicate capabilities, several vendors solving the same problem, inconsistent controls and rising cost without enterprise value.
Population effects nobody is measuring
Models operating across member populations can perform differently across groups. Where that affects access or payment, it is an obligation rather than an analytics curiosity.
No answer for the regulator or the board
Asked what AI the plan uses, where, under what oversight and with what safeguards, most organizations cannot produce a current answer from a system rather than from a working group.
Inventory before roadmap, and the inventory is mostly other people models.
The first deliverable is an honest account of every AI capability influencing a plan decision, including the ones already running. In every assessment we have done, the plan finds capabilities it did not know were active, usually inside a purchased platform. That inventory is uncomfortable, it is more useful than a strategy document, and it changes the roadmap that follows.
A governance framework succeeds when teams choose it because it is quicker than avoiding it.
That requires a published decision timeline, a conditional approval path and proportionate review, so a low-risk internal tool is not held behind the process designed for a model that touches a coverage outcome.
Step 1
Inventory everything, including vendor-embedded and delegated AI. What is running, where, produced by whom, influencing what decision.
Step 2
Classify by consequence, not by technology. What the output affects determines the tier, whether it is a rule engine or a large model.
Step 3
Establish the accountability position for AI you did not build: what you will require, what you will verify and what you will accept.
Step 4
Define the boundaries that never move. The decisions that stay human regardless of accuracy, agreed with clinical, legal and compliance leadership.
Step 5
Design the review path per tier, with a published decision timeline and a conditional yes, so the process is faster than routing around it.
Step 6
Set the readiness gates. Data, monitoring, ownership, escalation and evidence requirements a use case must meet before deployment rather than a maturity score.
Step 7
Prioritize the portfolio against value, risk, readiness and regulatory exposure, and produce an explicit stop list alongside the roadmap.
A stop list is as valuable as a roadmap and considerably rarer.
Naming what the plan will not do with AI, and why, protects the programme in two directions. It gives teams a clear boundary rather than a case-by-case negotiation, and it gives leadership something defensible to point at when asked why a particular capability was declined.
The failure mode for governance work is a framework document that is accurate, comprehensive and unused. Everything below is designed to produce something a plan operates weekly rather than something it reviews annually.
See the Surface
Full AI Inventory
Built, bought, embedded and delegated capabilities catalogued with owner, purpose, the decision they influence, the populations affected and current oversight.
Vendor AI Assessment
What each vendor uses, on what data, with what validation and monitoring, what they will disclose, and what the plan is contractually able to require or verify.
Delegated Entity Oversight
What AI delegated partners deploy on the plan behalf, what the delegation agreement permits, and what oversight the plan can actually exercise rather than assume.
Risk Tiering
Classification by what the output affects, from internal productivity through to anything influencing access to care or payment, with proportionate requirements per tier.
Decide and Prioritize
Portfolio Prioritization
Use cases scored on value, feasibility, readiness, risk and regulatory exposure, producing a sequenced roadmap and an explicit list of what is not being pursued.
Readiness Gates
The data, monitoring, ownership, escalation and evidence conditions a use case must satisfy before deployment.
Boundary Definition
The decisions that remain human regardless of model performance, agreed with clinical, legal and compliance leadership.
Review Path Design
Proportionate review per tier with a published decision timeline and a conditional approval route.
Operate and Evidence
Operating Model
Who decides, who monitors, who can pause a capability, what escalates to whom, and what the board sees and how often.
Monitoring Standards
What must be monitored per tier, including performance, drift, population effects and override patterns, with thresholds and owners defined before deployment.
Evidence and Artifacts
The register, tier definitions, approvals, validations, monitoring results and decisions, maintained as a current record.
AI Incident Management
What happens when a capability produces harmful output, crosses a boundary, acts on incorrect information, exposes data or behaves differently after a change.
Contract and Procurement Standards
AI disclosure, validation, monitoring and audit provisions built into vendor and delegation agreements.
What CaliberFocus does, and does not do.
We are not your counsel and we do not provide legal opinions on regulatory obligations. We build the inventory, the tiering, the operating model and the evidence trail, working alongside the legal and compliance leadership who own the interpretation. We will also tell you when a governance programme is being built to document a decision that has already been made, because a framework produced to justify a deployment is not governance and it will not read as governance to anyone examining it.
Every candidate leaves prioritization with one of five verdicts. A portfolio where everything is proceed has not been assessed, and the two refusal verdicts are what make the other three credible to a board or a regulator.
| Verdict | What It Means |
|---|---|
| Proceed | Value is clear, readiness gates are met, the risk tier is manageable and an owner is named. |
| Prepare | Worth doing and not yet buildable. The gate that is failing is identified with what would clear it. |
| Pilot | Value is plausible and unproven. A bounded test with defined success criteria and a stop condition. |
| Proceed, Assist Only | The work is worth automating and the decision is not. AI prepares and a qualified person decides. The most common correct answer in payer operations. |
| Hold | Technically feasible and inappropriate now, usually because the regulatory position or the evidence base is moving. |
| Do Not Pursue | The plan will not do this. Recorded with the reasoning, so it is a decision rather than a recurring debate. |
Build the Portfolio in Four Waves
Internal productivity and knowledge first, to establish the process, evaluation, monitoring and value measurement with limited member consequence. Then administrative operations with defined authority and exception handling. Then member and provider interaction, only once grounding, boundaries, escalation and monitoring are proven. Then high-consequence decision support, where AI assembles evidence and prepares qualified reviewers. Decision support is not decision authority.
Technology-based tiering produces the wrong answer twice. A simple rule engine determining benefit application can carry more consequence than a large model summarizing an internal document. The classification that holds up is what the output affects and who it affects.
TIER 1
Internal productivity
An employee own work, with no downstream effect on a member or provider
Named owner, acceptable use, basic monitoring
TIER 2
Administrative
Internal workflow, routing, prioritization, operations and case handling
Owner, performance monitoring, override capture, escalation path
TIER 3
Provider-facing
Payment, contracting, network or provider communications
The above plus abrasion monitoring, appeal route and defined financial limits
TIER 4
Member-facing
Member communications, service and account outcomes
The above plus accuracy validation, boundary enforcement and complaint linkage
TIER 5
Care and coverage influencing
Access to care, coverage outcomes, clinical prioritization
The above plus clinical ownership, population effect monitoring, transparency and formal oversight
Sequence by tier, not by enthusiasm. A plan that proves its governance on administrative work earns the credibility to attempt anything harder. One that starts at the top of the risk range spends the next two years explaining itself.
| Domain | Typical Value | Tier |
|---|---|---|
| Administrative Workflow and Pend Resolution | High volume, articulable rules, no member-facing decision | Lower tier. Best starting point |
| Provider and Member Service Support | Repetitive enquiry volume with definitive answers | Middle. Rises when the employee repeats it to a member |
| Provider Data and Directory Operations | Regulated data quality with cross-workflow benefit | Middle. Directory obligations apply |
| Authorization Administrative Support | Substantial elapsed time, mostly non-clinical | Higher. Adjacent to a clinical determination |
| Clinical Risk and Population Models | Care management targeting and stratification | Highest. Population effects and access implications |
| Anything Influencing Coverage or Medical Necessity | Not a candidate for automated determination | Highest, and the determination itself is out of scope |
Determinations stay human
Coverage, medical necessity and appeal outcomes are decided by authorized people. This is a boundary rather than a threshold.
Confidence does not create authority
How certain a system is and whether it may decide are separate questions, and the second is settled first.
Adverse actions are never automated
Anything reducing access, denying payment or disadvantaging a member or provider requires a person acting under their own authority.
Delegation does not transfer accountability
A delegated entity may run the model. The plan answers for the outcome, and the oversight has to be real rather than contractual language nobody exercises.
What Every Capability Must Never Do
Make unauthorized coverage determinations, make clinical judgements outside qualified review, interpret contracts as binding positions, bypass required human review, hide uncertainty, access data outside the user entitlement, or continue operating after a defined stop condition.
For AI the plan builds, governance is technical. For AI the plan buys or delegates, governance is contractual and procedural, and it is decided at procurement and renewal rather than at deployment. That timing is the point most plans miss.
Disclosure
What AI is used, where in the workflow, on what data, and notification when a new capability is introduced rather than discovery after the fact.
Validation evidence
How the model was validated, on which population, with what results, and whether it was validated on a population resembling yours.
Monitoring commitment
What the vendor monitors, at what frequency, what triggers notification, and what they report to you without being asked.
Population performance
Subgroup performance where the capability affects access or payment, since the plan carries that obligation regardless of who built the model.
Audit and inspection
What the plan may examine, request or independently test, agreed before signature because it is unobtainable afterwards.
Change notification
Notice before a model, threshold or behaviour changes, since a silent update can alter outcomes the plan is answerable for.
Data provenance and permitted use
What data may be used for model development, by whom, and whether member data may leave the plan environment or contribute to a vendor model.
No client data training third-party models
Enforced contractually and technically, with hosting and residency defined rather than assumed from a marketing statement.
Model and configuration versioning
For internal models, what produced a given output and when. For vendor models, what version was in force and when it changed.
Retirement as a normal outcome
Capabilities that no longer perform, no longer earn their oversight cost, or no longer suit the risk position are switched off. A register that only grows is not governed.
AI in payer operations, particularly anything touching utilization management or coverage, is under sustained regulatory and legislative attention. The realistic planning assumption is that the plan will at some point be asked to describe its AI use, its oversight and its safeguards, within a timeframe that does not permit assembling the answer.
The artifacts to hold current
- An AI register covering built, bought, embedded and delegated capabilities, with owner, tier, purpose and the decision each influences
- Tier definitions and the requirements attached to each, approved by the accountable body
- Approval records, validation evidence and monitoring results per capability, current rather than point-in-time
- The stop list, with reasoning
Security and PHI
- Encryption, access control and least privilege across model development, inference and monitoring environments
- PHI minimization in training data, prompts, inference logs and monitoring stores
- Vendor hosting, residency and subprocessor position documented per capability rather than at platform level
Oversight and accountability
- A named accountable executive for AI, and a named owner per capability distinct from the platform owner
- Clinical ownership for any capability influencing care access, with a defined route to pause it
- Compliance visibility by design, including delegated entity AI
- A defined cadence and content for what reaches the board
Operational control
- The ability to pause, restrict or disable any capability, including vendor-embedded ones, without disabling the platform
- Monitoring thresholds and escalation owners set before deployment
- Incident definition and response for AI specifically, since an AI failure often presents as a pattern rather than an outage
Run the exercise before somebody else does.
Ask your organization to produce, within five working days, a complete list of AI capabilities influencing a plan decision, who owns each, what oversight applies, and the evidence supporting the highest-risk one. Most plans cannot. Finding that out internally, on your own timetable, with the ability to correct it, is an entirely different position from finding it out in response to an enquiry with a statutory response period attached.
Governance programmes report policies published and committees established. Neither tells you whether the plan knows what AI it is running or whether teams are using the process rather than avoiding it.
| Category | What We Measure | Why It Matters |
|---|---|---|
| Inventory Coverage | Share of AI capabilities in the register, including vendor-embedded and delegated | You cannot govern what you have not found, and most of it is not yours |
| Decision Speed | Time from submission to a decision, and the share receiving a conditional yes | Governance faster than the workaround is governance that gets used |
| Refusals | Capabilities placed on hold or declined, with reasoning recorded | A portfolio with no refusals has not been assessed |
| Vendor Position | Agreements carrying AI disclosure, validation, monitoring and audit provisions | The only real control over a model you cannot inspect |
| Monitoring in Force | Higher-tier capabilities with active monitoring, thresholds and named owners | The gap between approved and monitored is where exposure sits |
| Evidence Readiness | Time to produce the register and the supporting evidence for a named capability | The measure that matters on the day it is requested |
The inventory will find AI nobody approved.
Most often inside a purchased platform, and occasionally at a delegated entity. That is uncomfortable and it is the point. It also means the first phase produces findings rather than a roadmap, and the roadmap that follows is different from the one leadership expected. Agree in advance that surfacing the current state counts as progress.
Try to list every AI capability influencing a plan decision today, including your vendors and your delegates.
Bring us your vendor list for core administration, utilization management, payment integrity and care management, along with your delegation agreements and any AI policy you have, including the answer that none exists. We will build the inventory across built, bought, embedded and delegated capabilities, tier each one by what it affects, assess what your contracts let you require, verify or disable, and design a review path with a published decision timeline. The inventory alone typically changes the roadmap, and it is the first thing you will need if anyone asks.
One conversation with people who will tell you the inventory is the deliverable, and a written assessment you can use with or without us.
- AI Agents and Workflow Automation
- Prior Authorization Automation
- Generative AI and Enterprise Copilots
- Voice and Conversational AI
Security & Compliance
