AI Agents in Prior Authorization: Governance Under WISeR and CMS-0057-F

Prior authorization is where AI agents are moving fastest in health plans, and where the regulatory attention is sharpest. Two developments set the terms. CMS's WISeR model is testing AI and machine learning in traditional Medicare prior authorization, and the CMS-0057-F interoperability rule sets turnaround clocks and denial-explanation requirements that any agent in the workflow has to support. If your plan is putting an agent anywhere near an approval or denial, these rules define what you have to be able to prove.

This post is for healthtech and payer teams building or buying utilization-management agents. It covers where agents sit in the prior auth workflow, how to evaluate their adherence to clinical criteria, how to capture evidence that a clinician reviewed the decision, and how to produce the reason trail and turnaround reporting the rules expect.

WISeR and CMS-0057-F in brief

WISeR is a CMS test model, not a nationwide mandate. It runs from January 1, 2026 through December 31, 2031 in six states, and it tests the use of AI and machine learning in prior authorization within traditional (Original) Medicare. A key design point: clinician review is required before a request can be denied. The model is meant to study whether enhanced technology can reduce spending on low-value services without compromising access to care.

WISeR drew a congressional challenge. In July 2026, the Senate voted 46-50 against a resolution to disapprove the model, so the rollback failed and WISeR stands.

CMS-0057-F, the interoperability and prior authorization final rule, sets the operational baseline that applies more broadly. Impacted payers must decide urgent requests within 72 hours and standard requests within 7 calendar days, and must give specific reasons when they deny. The rule's API requirements are due mainly on January 1, 2027.

Together, these set three things any agent in the workflow has to support: a turnaround clock, an explainability bar for denials, and a human-review expectation. The rest of this post maps agent governance to those three demands.

Where agents sit in the prior auth workflow

A prior authorization agent typically triages incoming requests, matches submitted documentation against the applicable clinical criteria, surfaces cases that look like clear approvals, and flags the rest for clinician review. Some draft the rationale that supports a decision.

The line that governance has to preserve and prove is simple: the agent recommends, and a clinician decides. WISeR requires clinician review before a denial, and CMS-0057-F requires a specific reason behind one. Both depend on that division holding and on being able to show that it held.

Map each agent touchpoint to where evidence has to be captured. Intake and criteria matching produce the inputs and the policy the agent applied. The recommendation step produces what the agent proposed and why. The clinician review step produces the human decision and how it compared to the recommendation. Denial drafting produces the explanation that will reach the requesting provider. Each of those is a point where a trace should record what happened.

Evals for clinical-criteria adherence and consistency

An agent matching documentation against clinical criteria needs its accuracy tracked, not assumed. The way to do that is with binary, specific evals tied to the criteria the agent is applying. The question each eval answers is concrete: did this recommendation follow the stated clinical policy for this service, given the documentation provided? A pass/fail answer with an explanation is auditable. A 1-to-10 quality score is not, and it pushes the judgment onto a human who has to decide what number requires attention.

Consistency matters as much as accuracy here. The same case should not get different recommendations across runs. A consistency check that replays representative cases and flags divergence catches the kind of non-determinism that erodes trust in an automated decision. A generic "was this a good recommendation?" eval produces noisy, inconsistent signal. An eval anchored to a named clinical criterion, with the retrieved policy and documentation in its context, produces signal a reviewer can defend.

Proving human clinical review happened

WISeR requires clinician involvement in denials. The governance artifact that satisfies that requirement is a record that review actually occurred, captured at the time it happened rather than asserted afterward.

That record should show who reviewed the case, when, what the agent recommended, and what the clinician decided. Capturing it in the trace makes the review reconstructable on audit: a reviewer can pull the exact case, see the agent's recommendation alongside the clinician's final decision, and confirm that a human made the call. The comparison between recommendation and decision is also useful signal in its own right, because a pattern of clinicians overturning the agent points to a criteria-matching problem worth investigating.

Reason trails for specific denial explanations

CMS-0057-F's specific-denial-reason requirement needs a traceable path from the clinical criteria to the recommendation to the final decision. A denial notice that says "does not meet medical necessity" without a trail behind it will not hold up.

The reason trail records which criteria applied to the request, what documentation was weighed against them, where the documentation fell short, and the explanation that supports the denial notice. When that path is captured in the trace, the specific reason that reaches the provider is grounded in the agent's actual context rather than reconstructed later. This is the explainability the rule expects, produced as a byproduct of how the agent is instrumented rather than as a separate compliance exercise.

Monitoring turnaround and drift before the 2027 API deadline

The 72-hour and 7-day thresholds are measurable, so measure them. Tracking decision turnaround against those limits tells you whether the agent-assisted workflow is meeting the clock and where it is slowing down.

Watch for drift as well. Recommendation patterns and eval failure rates change over time as case mix shifts, criteria get updated, or an underlying model changes. A rising rate of criteria-adherence failures, or a shift in the approval-to-flag ratio, is worth investigating before it shows up in a complaint or an audit. Continuous monitoring and a maintained agent inventory give you that early signal across every agent touching the workflow.

The API requirements land mainly on January 1, 2027. The runway before then is the time to get the evaluation and evidence layer in place, so that when the interoperability requirements take effect, the governance underneath the agent is already producing the records you need.

Where Arthur fits

Arthur is the evaluation, monitoring, and evidence layer for agents in the prior auth workflow. The agent recommends and a clinician decides. Arthur tracks clinical-criteria adherence through binary, specific evals, captures the record that human review happened, and produces the reason trail and turnaround monitoring that WISeR and CMS-0057-F make necessary. It does not adjudicate claims, replace clinician review, or guarantee compliance on its own. It gives payer and healthtech teams the evidence to show that the agent behaved as intended and that a clinician stood behind every denial.

To see how Arthur evaluates and monitors agents in regulated workflows, book a demo.

‍