Do AI models in prior auth handle PHI?

Yes. The clinical input the model receives is PHI under HIPAA. The model handling and the audit record both have to comply with HIPAA's privacy and security rules. The model vendor (OpenAI, Anthropic, AWS Bedrock, etc.) must have a BAA in place with the deploying covered entity or business associate.

Does California SB-1120 require a clinician to review every AI decision?

The law requires that adverse determinations be reviewed by a licensed physician with appropriate clinical specialty before the decision is final. Affirmative authorizations that the AI recommends do not require the same physician review threshold but still require the AI to be based on the patient's individual clinical context.

How does Colorado SB 26-189 change things for HIPAA-covered entities?

Before the amendment, HIPAA covered entities had a broad exemption from the Colorado AI Act. SB 26-189 narrowed the exemption: consequential decisions in healthcare are now in scope of the Colorado AI Act for covered entities, with the effective date January 1, 2027.

What does CMS expect in the audit trail for MA prior-auth?

CMS expects that the coverage criteria the plan applied, including any AI-generated or AI-influenced criteria, be available on request. The per-decision audit trail has to show that the AI's contribution did not violate Medicare's coverage rules and that the criteria are not more restrictive than the underlying Medicare benefit.

Can the gateway audit record substitute for the application's medical-record entry?

No. The audit record is regulatory evidence about the AI decision. The medical-record entry is the clinical record of the prior-auth determination. The two have to exist independently and reference each other through the beneficiary and request identi

AI Security for Prior Authorization: HIPAA, State Laws, and the Identity-Bound Decision Record

Prior authorization is the highest-volume AI use case inside payer organizations and a growing one on the provider side. The application of language models and rules engines to coverage determinations has moved from pilot programs to production decision flows at most large national payers and increasingly at integrated delivery networks. The regulatory environment has tracked the operational expansion: HIPAA's existing rules apply to the PHI in every prior-auth request and response; California, Texas, and Colorado have all passed utilization-review laws that constrain how AI can be used in coverage decisions; and CMS has signaled increasing scrutiny of denial patterns from Medicare Advantage plans that are at least partially AI-assisted.

I want to walk through the identity, classification, and audit requirements specific to prior authorization, the failure modes recent enforcement actions have surfaced, the architectural pattern that produces a decision record a regulator can actually examine, and where the gateway-layer controls live in the stack.

What the AI is actually doing in prior auth

The AI involvement in a prior-authorization workflow typically falls into three categories. Document understanding: a model reads the clinical chart excerpt, the imaging report, and the requesting provider's notes and produces a structured representation of the clinical scenario. Coverage classification: a model or rules engine matches the structured representation against the plan's medical policy and produces a coverage decision recommendation. Notification drafting: a model drafts the determination letter to the requesting provider and the member, with citation to the policy clauses and the supporting clinical evidence.

The first category handles PHI directly. The second category handles PHI plus the plan's medical policy, which is internal but not PHI. The third category produces output that becomes part of the medical record and the plan's official correspondence.

Each category triggers different controls. Document understanding's principal concerns are PHI minimization, accurate extraction, and the audit trail for which model saw which data. Coverage classification's principal concerns are the deterministic policy linkage, the avoidance of model drift in coverage decisions, and human reviewer involvement at the regulatory threshold. Notification drafting's concerns are accuracy of citation, member-readable language, and the ability to reconstruct what the member was actually told.

The state utilization-review laws

California SB-1120 took effect January 1, 2025. The bill requires that AI used in utilization-review decisions be based on a patient's medical or other clinical history, that the AI not deny, delay, or modify care based solely on group datasets, that decisions be reviewed by a licensed physician with the appropriate clinical specialty, and that the AI be subject to disclosure on request to the patient.

Texas SB-815 took effect September 1, 2023 and was strengthened in subsequent sessions. The Texas framework requires that AI used by utilization-review agents in adverse determinations be developed and used in accordance with generally accepted standards of care, that the AI be subject to ongoing performance monitoring, and that adverse determinations involving AI be reviewable by a clinician.

Colorado SB 26-189 signed by Governor Polis on May 14, 2026 amended the Colorado AI Act with healthcare-specific provisions. The HIPAA covered-entity exemption from the broader Colorado AI Act no longer carries over for consequential decisions in healthcare. The amendment is effective January 1, 2027 with a 60-day attorney-general cure period.

The common requirement across the three laws is that the AI's decision-making must be reconstructable. Regulators and patients have a right to know what the AI saw, what the AI recommended, what the human reviewer did with the recommendation, and what the patient was told.

CMS and Medicare Advantage scrutiny

CMS issued a memo in February 2024 reminding Medicare Advantage organizations that algorithms and AI tools used in coverage determinations must comply with the Medicare laws and not be more restrictive than the Medicare program. Subsequent guidance has specified that internal coverage criteria used in MA prior-auth, including AI-generated criteria, must be made available on request.

The practical implication for plans is that the audit trail for an AI-influenced decision has to include the policy clauses the AI applied, the clinical evidence the AI cited, and the human reviewer's confirmation or modification. A regulator asking why a specific MA beneficiary was denied a service has to be able to trace the decision from the original request through to the final notification, with the AI's contribution at each step explicitly identified.

Documented failure modes

Recent enforcement actions and litigation have surfaced specific failure modes that are gateway-controllable. The Cigna v. Class Action case alleged that an algorithm-driven review denied claims in bulk without individual clinician review. The Humana algorithm litigation alleged that algorithm-driven denials of post-acute care for Medicare Advantage members operated below the threshold of meaningful clinician oversight. The state attorney-general inquiries into multiple payer programs in 2025-2026 focused on whether the AI's decisions could be reconstructed at the per-member level.

The common gap was the audit record. When the regulator asked which decisions were AI-influenced and on what basis, the payer's audit log produced a yes-or-no field for AI involvement but no per-decision reconstruction. The decision record was not designed to be regulator-evidentiary.

What the regulator's questions actually look like

The pattern of regulator questions in healthcare AI inquiries has stabilized. The questions a payer or provider should expect: which beneficiaries were the subject of AI-influenced decisions in the inquiry window; what specific clinical information did the AI receive for each beneficiary; what coverage policy did the AI cite; what was the AI's recommendation; what human reviewer saw the AI's recommendation; what did the human reviewer decide; what was the beneficiary told; was the beneficiary told in writing that AI was involved in the determination.

An application-controlled audit log usually answers two or three of those questions. The rest require the underlying records to have been captured at the AI request layer with identity context, classification, and policy versioning attached.

The identity-bound audit record

The audit record that answers all of the regulator's questions has a specific structure. Each AI request through the production system produces a per-decision record that includes: the beneficiary ID (treated as PHI), the requesting provider ID, the principal identity of the human or system that triggered the AI call, the model and version invoked, the input data class (chart excerpt, imaging report, claim form), the coverage policy ID and version, the AI's structured recommendation, and the linkage to the human-reviewer disposition record.

The record is committed at the AI request boundary, outside the application that consumed the response. The application cannot mutate or suppress the record. The record's policy ID dereferences to the policy document version in effect at the moment of decision, retained for the duration of the audit period.

The pattern is the same one the EU AI Act Article 19 logging requirements describe in different vocabulary. The healthcare application of the pattern is a fully developed version of what the AI Act requires for high-risk systems generally.

DeepInspect

This is the gap DeepInspect closes for payer and provider organizations running AI in prior authorization. DeepInspect sits at the AI request boundary as an external enforcement layer, enforces identity-bound policy on every request and response, and writes a per-decision audit record outside the calling application. The record carries the beneficiary identifier (handled as PHI with appropriate retention and access controls), the requesting principal, the policy ID applied, and the model recommendation, with linkage to the downstream human-review record the application maintains separately.

The architecture is stateless and HIPAA-compatible: PHI in transit is handled under the BAA scope, the audit records are retained on the deployer's infrastructure with the deployer's retention controls, and the per-decision record commits before the response returns to the application that drives the workflow. Coverage-policy versions are pinned in the record, which means a regulator's replay question months after the decision dereferences to the policy in effect at the moment.

For payer and provider security and compliance teams that are scoping the audit-trail requirement under California SB-1120, Texas SB-815, the new Colorado SB 26-189 framework, and CMS Medicare Advantage scrutiny, the gateway is the architectural piece that produces regulator-evidentiary records. Book a demo today.