NAIC AI Model Bulletin vs CMS Prior Authorization Rules for Medicare Advantage Plans

Two regimes with different sources of authority

The NAIC AI Model Bulletin was adopted by NAIC members on December 4, 2023. It is not a model law or regulation. It is a guiding document meant to foster uniformity among state insurance regulators about what they expect of carriers that deploy AI. It binds an insurer only in a state whose insurance department has issued its own bulletin. Implementation lists show state bulletins in jurisdictions such as Alaska, Connecticut, Illinois, Maryland, Massachusetts, and Vermont, with adoption dates running from February 1, 2024 to February 5, 2025. California (Bulletin 2022-5) and Colorado (3 CCR 702-10) have their own instruments, so form and wording vary by state.

The bulletin reminds carriers that decisions affecting consumers that are made or supported by advanced analytical and computational technologies, including AI, must comply with all applicable insurance laws, including unfair trade practices laws. It is addressed to insurers holding certificates of authority in the state and expects a written AIS Program, commensurate with an assessment of risk, that governs the development or acquisition and the use of AI Systems by or on behalf of the insurer. The program should be designed to mitigate the risk of Adverse Consumer Outcomes.

CMS requirements work differently. When a coordinated care plan uses prior authorization for basic or supplemental benefits, the MA organization must comply with the prior authorization provisions of 42 CFR Part 422. Those provisions reach all policies and procedures used in prior authorization. They are program requirements, and CMS enforces them with tools ranging from warning letters and corrective action plans to sanctions and civil money penalties under subpart O. A CRS report notes that CMS's final rule on MA prior authorization also discusses the limits of using AI in prior authorizations and other coverage decisions.

Side-by-side comparison as of October 2026

The table separates what each regime states from how an insurer operationalizes it. The CMS column covers the prior authorization requirements that apply to MA organizations whether or not AI is involved.

• Legal authority: NAIC: model bulletin, effective only through state-issued bulletins or regulations. CMS: 42 CFR Part 422 and the 2024 interoperability and prior authorization final rule, in force for MA organizations.
• Who is covered: NAIC: insurers holding certificates of authority in an adopting state, for AI Systems used by or on behalf of the insurer. CMS: MA organizations, for prior authorization policies and procedures of coordinated care plans.
• Core obligation: NAIC: a written AIS Program scaled to risk, aimed at mitigating Adverse Consumer Outcomes. CMS: compliant prior authorization processes, including internal coverage criteria based on current evidence where Medicare criteria are not fully established.
• Dated requirements: NAIC: state adoption dates vary. CMS: denial reasons must be communicated beginning January 1, 2026 (excluding Part D drug requests), and a Prior Authorization API must be in place beginning January 1, 2027.
• Enforcer and mechanism: NAIC: state insurance departments through investigation and examination. CMS: compliance actions from warning letters to civil money penalties.
• Evidence expectation: NAIC: information and documentation a department may request about AI System use. CMS: demonstrable compliance of prior authorization processes and required outputs such as denial reasons and API availability.

Where the regimes overlap and where they diverge

The overlap is accountability. Both place responsibility on the insurer or MA organization, including for AI used on its behalf. A single utilization management workflow that uses a vendor model can therefore sit under a state AIS Program expectation and under CMS prior authorization requirements at once. Assigning one owner to reconcile the two avoids duplicated or conflicting evidence.

The divergence is in structure. The NAIC bulletin is AI-specific and program-oriented: it asks how the insurer governs AI Systems across their lifecycle and what it can show an examiner. The CMS rules are process-oriented and not limited to AI: they define how prior authorization must operate and what outputs members and providers must receive. An insurer could have a well-documented AIS Program and still miss a CMS output requirement, or meet the CMS outputs and lack AI governance documentation a state department would request.

Enforcement also differs. State departments examine the insurer under state authority and the version of the bulletin that state issued. CMS acts under federal program authority. Applicability must be mapped by state for the NAIC side, and by plan and benefit for the CMS side. Whether AI is actually used in a given MA prior authorization step is a fact each insurer has to establish internally, since prevalence across plans is unclear.

What runtime controls can support and what stays organizational

Policy enforcement in the AI execution path operates on individual interactions and tool calls. It can allow, redact, block, or escalate a request for human approval, and it can record what was enforced and why. That produces evidence at the level of a single interaction. This is useful for an AIS Program, because it shows how a control behaved at runtime rather than only how it was described in a policy document.

Most of what a state examiner or CMS reviewer would look for lives outside any single interaction. The written AIS Program, inventories of AI Systems, data lineage, vendor due diligence, and third-party contracts are organizational artifacts. An earlier draft of the NAIC bulletin anticipated examination requests along these lines, including contract terms on cooperation with regulators. On the CMS side, publishing internal coverage criteria, writing denial-reason content, and building and maintaining the Prior Authorization API are process and engineering responsibilities that do not run through an AI policy layer.

Human review is a workflow control. Runtime escalation can route a case to a reviewer and record the approval, but the reviewer role, qualifications, and decision standards are set by the organization. Per-interaction evidence can supplement these artifacts. It does not replace them, and it should not be presented as satisfying a CMS requirement.

A practical sequence for compliance teams

Treat the two regimes as separate mapping exercises that converge on one workflow inventory.

• Build a state applicability table: List each licensed state, whether it issued the bulletin or an equivalent, and in what form.
• Inventory AI in utilization management: Identify which prior authorization steps use algorithms or AI, directly or through vendors.
• Map CMS obligations to those steps: Work from the text of 42 CFR Part 422, covering all prior authorization policies, not only AI.
• Track dated CMS items separately: Manage denial-reason communication and the 2027 Prior Authorization API as their own workstreams.
• Assign evidence owners: Name who retains governance documents, vendor contracts, diligence records, and compliance records.
• Classify each control: Mark whether it is enforced in the execution path, a human review step, or an organizational process.

Where runtime policy enforcement fits

Trussed enforces policy in the execution path across models, agents, tools, and MCP servers. Policies are enforced at runtime, not reviewed after the fact, with outcomes of allow, redact, block, rate limit, or escalate for human approval. Enforcement generates audit-ready evidence on individual interactions and tool calls, mapped to NAIC among other frameworks, which a regulated enterprise can use to support the control and examination-readiness elements of an AIS Program. It can be self-managed in the customer cloud, with configurable retention and data residency.

The scope is bounded. Trussed does not replace the written AIS Program, vendor due diligence, or clinical and coverage processes, and this page does not claim that it satisfies CMS prior authorization requirements. Transaction-level governance, model provenance, and end-to-end tracing of agentic workflows are not part of what it provides today.