AI Agent Governance for Medicare Advantage Risk Adjustment

Why Risk Adjustment AI Agents Need Different Governance

AI agents performing HCC coding, chart abstraction, or risk score submission are not equivalent to general-purpose generative AI tools. They read protected clinical data, produce outputs that map directly to reimbursement, and in some deployments can initiate submission actions without a human in the loop. A coding error made by a human coder is reviewed under existing compliance workflows. A coding error made or reinforced by an AI agent across thousands of charts can scale that error before anyone notices it. This is the core reason generic AI compliance checklists are insufficient here: the governance question is not only whether the model output is accurate, but whether the system architecture enforces boundaries on what the agent can access, propose, and submit, and whether that sequence of actions is fully reconstructable after the fact. Health plans remain accountable for coding accuracy and audit defense regardless of whether a human or an AI agent performed the work. Delegating the task does not delegate the regulatory responsibility.

What Runtime Governance Means in This Context

Runtime governance refers to controls enforced while the agent is actually operating, not just policies documented in advance. For a risk adjustment agent, this means the system checks, at the moment of each tool call, whether the agent is permitted to read a specific chart section, whether it is permitted to propose a code for that condition, and whether it is permitted to submit that code to a claims or risk-score system. These are three separate permission boundaries, not one blanket access grant. Static, pre-deployment policy documents describe intent. Runtime enforcement is what actually stops or flags an out-of-policy action before it causes harm. For a workflow tied to CMS reimbursement, the gap between documented policy and enforced behavior is exactly the gap RADV auditors and compliance investigators will probe.

Audit Logging and RADV Defensibility

RADV audits validate that submitted diagnosis codes are supported by medical record documentation. When an AI agent is involved in generating or supporting that code, the audit trail needs to answer more than what was submitted. It needs to show what data the agent referenced, what tool calls it made, what code it proposed, whether that proposal passed or failed a policy check, and who or what approved the final submission. A log that only records the final output does not meet this standard. A log that records the full decision chain does. This distinction matters because during a RADV response, the health plan is the party responsible for producing evidence, and evidence produced after the fact from incomplete logs is far weaker than evidence captured automatically as part of the agent's runtime execution. Retention and retrieval of these logs in a usable format should be planned as part of the initial deployment, not added later.

Implementation Priorities Before Production Deployment

• Map every agent tool call (chart retrieval, code suggestion, submission) to a specific permission scope rather than granting standing access across systems.
• Separate the permission to propose a code from the permission to submit it, preserving a control gate between the two.
• Define and test escalation paths for agent outputs that fall outside approved coding logic, including who reviews them and how that review is documented.
• Coordinate with compliance and coding teams to define what counts as sufficient supporting evidence for an AI-suggested HCC code, since this determines what the log must capture.
• Test enforcement against ambiguous or conflicting documentation cases before production, since these are the scenarios most likely to draw audit scrutiny.
• Confirm that agent identity is distinguishable from human coder identity across all access and submission logs.

Tradeoffs Governance Leaders Should Weigh

Tighter runtime permission scoping reduces the blast radius of an agent error but adds latency and integration work, since each tool call requires an explicit, enforced boundary rather than a single broad credential. Separating propose and submit permissions adds a review step that can slow throughput, which matters in high-volume chart review programs, but removes the risk of an agent-initiated submission bypassing human or policy oversight entirely. Comprehensive decision-chain logging increases storage and engineering overhead compared to logging only final outputs, but it is the difference between being able to reconstruct an agent's reasoning during a RADV request and having to reconstruct it manually, after the fact, under audit pressure. None of these tradeoffs have a universally correct answer. They depend on transaction volume, existing coding review infrastructure, and how much residual human review the plan intends to keep in place as agents take on more of the workflow.