LLM Governance in Fraud, Waste, and Abuse Reviews: An Implementation Guide

Why FWA reviews need interaction-level control

Special investigation units and payment integrity teams work with identifiable beneficiary and provider data. Where HIPAA applies, an LLM input drawn from that data should be treated as ePHI under the Security Rule, which requires regulated entities to protect the confidentiality, integrity, and availability of the ePHI they create, receive, maintain, or transmit.

The difficulty is that LLM use is rarely one event. A single investigator request can retrieve claims, summarize a medical record, call a tool, and draft a narrative. Policies written as documents and reviewed after the fact cannot show what the model was permitted to access or do in any one of those steps. The practical unit of governance is therefore the individual interaction and tool call, each with its own policy decision and its own record.

This guide separates two jobs that are often blurred. Policy design decides what should happen. Runtime enforcement makes it happen before the call executes and leaves evidence that it did.

Classify tasks by PHI exposure and decision influence

Start with an inventory of LLM-assisted tasks, then classify each on two axes: does it touch PHI, and can its output influence a consequential action such as a payment hold, provider referral, or recoupment. This classification is an internal exercise. No regulation hands you the categories, so document your reasoning and the roles that own it, consistent with NIST AI RMF Govern 1.1, which covers legal and regulatory requirements being understood, managed, and documented.

A workable starting point is below. Adjust it to your own data flows.

• Claims and record summarization: High PHI exposure, moderate influence. Needs task-scoped data access, redaction of fields the summary does not need, and a full interaction record.
• Lead triage and scoring: Moderate PHI exposure, high influence on which providers get attention. Needs reviewer visibility into the inputs used and human review above a defined risk threshold.
• Investigative narrative drafting: High PHI exposure and output that may enter referral files. Needs human approval before the draft is finalized or shared.
• Any tool call that changes state: Holds, referrals, or recoupment actions. Should never be available to a summarization or drafting function. Requires escalation for human approval.

Write runtime policy rules for each decision outcome

A runtime policy states, for each task class, the conditions under which an interaction is allowed, modified, stopped, or sent to a person. Bind access to the minimum scope the task requires and apply separation of duties, so a drafting function cannot assume privileges that bypass other controls. NIST's guidance on agent identity also notes that authority should attenuate as it is delegated, so a downstream tool never holds more authority than the initiating user or agent. Define risk thresholds that trigger human review, and route escalations to a named authority rather than a general queue.

• Allow: The request matches a permitted task, the data requested is within the task's scope, and no threshold is reached. Record the decision and the scope applied.
• Redact: The request is permitted but includes PHI the task does not need. Remove or mask those fields before the model sees them and record what was removed.
• Block: The request exceeds scope, targets a prohibited data class, or attempts an action the task may not take. Stop it and record the reason.
• Rate limit: Volume or pattern is unusual for the user or task, such as bulk retrieval of records. Throttle and record the trigger.
• Escalate for human approval: The action could influence a consequential outcome or crosses a risk threshold. Hold execution until a designated reviewer approves or rejects, and record who decided and when.

Define the evidence record before you need it

Auditors and regulators will ask what a specific interaction did, not whether a policy existed. Define the evidence record per interaction and per tool call, and make the enforcement decision the source of that record rather than reconstructing it later.

A reasonable minimum includes the requesting user and role, the task class, the policy version applied, the data that was accessible, the decision taken (allow, redact, block, rate limit, escalate), what was redacted or blocked, the tool called, the approver and approval time for escalated actions, and a timestamp. These fields are your own design choice. Define them against the audit controls standard at 45 CFR 164.312(b) and confirm the current regulatory text before finalizing the mapping.

Set retention and review deliberately. NIST AI RMF Govern 1.5 calls for ongoing monitoring and periodic review with defined roles and frequency, which sampling alone does not satisfy if you cannot retrieve the underlying interactions. Map the same record to the other frameworks your program answers to, including NAIC expectations for insurers and the NIST AI RMF, and present the mapping as risk-management alignment, not as certification. As of October 2026, the January 2025 HHS proposal to strengthen the Security Rule is a proposed rule, so do not treat its provisions as operative.

Where runtime enforcement platforms fit

Trussed enforces policy in the execution path across models, agents, tools, and MCP servers, applying allow, redact, block, rate limit, and escalate-for-human-approval decisions to individual interactions and tool calls. Enforcement is at runtime, not reviewed after the fact, and the same enforcement generates continuous audit-ready evidence mapped to HIPAA, NAIC, NYDFS, the EU AI Act, and NIST. It can be self-managed in the customer cloud, with configurable retention and data residency.

Trussed runs in production with healthcare organizations and has customers across insurance, pharma, healthcare, and education. Approved operating figures include 18+ months of continuous production in a regulated enterprise, 99.95% uptime on live production traffic, 100+ models under one policy plane, and 30+ GB of audit evidence generated per day.

Trussed operates at the level of interactions and tool calls. It does not provide transaction-level governance across tasks or model lineage, so your task classification and approver roles remain your own program decisions. The evaluation questions above apply to any approach you consider.