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.
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.
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.
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.
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.
Step 8
Validate before production against realistic payer scenarios: normal cases, exceptions, ambiguous inputs, boundary cases, adversarial inputs, system failures, outdated information and conflicting sources.
Step 9
Build the operating model: who decides, who monitors, who can pause, and what reaches the board and how often.
Step 10
Produce the artifacts you would need if asked tomorrow, and keep them current as a system rather than as a periodic exercise.
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 task below is offered by portals everywhere. What varies is whether it completes without staff involvement, and that depends on your systems rather than on the interface.
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.
Prioritize the work AI can remove, not the decisions it can replace.
Finding information, collecting documents, matching records, summarizing history, checking completeness, preparing cases, tracking timelines. That is where the safe value is, and it is most of the cost.
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.
Off switch
The ability to disable an AI capability without abandoning the platform it is embedded in.
Exit
How you disable the capability, retrieve required records, remove your data and move provider without losing operational continuity or audit history.
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
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
- A usable non-digital path that is not a deliberately degraded channel, so a portal-first strategy does not become an access barrier for the people who need access most
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
readiness
- 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
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.
And a first roadmap that works usually has three lists rather than one: scale, where value is proven and controls are sufficient; fix before scaling, where the data, content, review or vendor controls are not ready; and do not delegate, where AI may assist the work but the authority stays with a qualified person. That distinction is what leadership can actually fund.
| 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.
We will build the inventory across built, bought, embedded and delegated capabilities, tier them by what they affect, assess what your contracts actually permit you to require, and design a review path that teams will use because it is faster than avoiding it. The inventory alone typically changes the roadmap, and it is the artifact you will need first if anyone asks.
Bring us a specialty or clinical setting where clinicians are spending too much time creating notes. We will assess where ambient documentation fits, what must remain clinician controlled, how it should integrate with your EHR, and how to measure whether it is actually reducing burden.
One conversation with people who have run these deployments, and a written readiness view you can use with or without us.
- AI Agents and Workflow Automation
- Voice and Conversational AI
- Document AI and Intelligent Processing
- Generative AI and Enterprise Copilots
- AI Strategy and Governance
- HCC and Risk Adjustment Analytics
Security & Compliance
