Medical coding departments are moving past the pilot phase. AI agents that suggest ICD-10 codes, flag underdocumented HCCs, and auto-route claims for review are no longer experimental — they’re becoming standard workflow components. The real bottleneck now isn’t capability. It’s governance.
A piece published July 5, 2026 in Health IT Answers by Kajol Shah of Budventure Technologies put it plainly: healthcare AI deployments must budget for the cost of controls — compliance infrastructure, audit logging, access governance, and ongoing monitoring — not just for the model itself. For RCM and coding teams, that framing has direct operational consequences. Organizations that skip this step are borrowing against future audit liability.
Why Governance Is Now the Bottleneck
The pace of AI coding adoption has outrun most organizations’ governance frameworks. Tools that scan clinical documentation and suggest risk-adjustment codes, flag missing diagnoses, or trigger prior authorization requests are now touching electronic protected health information (ePHI) at scale. Under the HIPAA Security Rule, any system that accesses, processes, or stores ePHI must have administrative, physical, and technical safeguards in place — regardless of whether it’s operated by a vendor or built internally.
This matters for coding departments because AI coding agents typically integrate directly with EHRs, CDI platforms, and payer APIs. Those integrations extend the HIPAA compliance perimeter, and failing to account for them creates audit exposure that wasn’t present in purely manual workflows.
The OIG flagged this problem directly in its February 2, 2026 Medicare Advantage Industry Segment-Specific Compliance Program Guidance (MA ICPG) — the first MA compliance guidance since 1999. Among its specific concerns: AI algorithms embedded in EHR platforms that prompt physicians to add risk-adjusting diagnoses not supported by the clinical record. That’s not just a documentation problem. It’s a compliance failure that originates in the technology stack, and the financial liability falls on the plan — and, through audit, on the coders and CDI staff who accepted the AI’s output.
Three Decisions Every RCM Team Must Make Before Deploying a Coding AI Agent
1. Define What the Agent Can Touch
The most consequential governance decision is scope. What data can the AI access — just the current encounter note, or the full chart? Can it query historical claims? Can it surface payer contract terms to calculate expected reimbursement? Can it write to the EHR, or only suggest?
Each data boundary has a corresponding access control requirement. An AI agent with read access to the full patient chart needs role-based permissions scoped to that use case, audit logs capturing every query, and a business associate agreement with the vendor that addresses AI-specific risks. An agent that also writes — flagging codes in the EHR, adding CDI queries, or populating claim fields — requires additional controls governing when human review is required before those outputs take effect. Defining these boundaries before deployment is not optional; it determines the HIPAA risk posture of the entire system.
2. Build Auditability In from Day One
HCC risk adjustment coding is routinely audited by OIG, CMS, and Medicare Advantage payers conducting RADV reviews. If an AI agent suggested a code, and that code appears in an encounter record, the suggestion is effectively part of the coding decision trail. Auditors don’t distinguish between human-generated and AI-suggested codes — the documentation standard is the same.
Recent OIG audit findings make this concrete. In its 2026 audit of Priority Health (Contract H2320, Report A-07-22-01208, issued March 31, 2026), OIG found that 252 of 300 sampled enrollee-years contained diagnosis codes not supported by the medical record — resulting in $4.4 million in estimated net overpayments. In a parallel audit of Gateway Health Plan, 232 of 286 sampled enrollee-years had unsupported codes. Neither audit was about AI specifically, but they demonstrate the audit risk that attaches to any unsupported HCC code, regardless of how it was generated.
AI coding systems must produce explainable outputs. Not just “HCC 85 suggested,” but “HCC 85 suggested based on the attending note dated [date], referencing a diagnosis of major depressive disorder, confirmed in the problem list.” That traceability protects the organization during audit and forces vendors to build explainability into their products from the outset — not as an afterthought.
3. Budget for Ongoing Control Costs, Not Just Launch
The most common governance mistake is treating AI deployment as a one-time project with a defined go-live date. Coding AI systems are not static. Model versions update, clinical terminology expands, payer edits change, and documentation practices evolve. A system that performs correctly at launch can degrade if monitoring and governance are not actively maintained.
Ongoing control costs for a medical coding AI agent typically include:
- Model performance monitoring — first-pass acceptance rate, denial rate on AI-suggested codes, and HCC capture drift over time
- Periodic access reviews to confirm permission scope hasn’t expanded beyond the original design
- Vendor risk assessments when business associate agreements are renewed or when the vendor updates its underlying model
- Coder education when the system adds new code categories, changes suggestion logic, or updates its clinical NLP engine
These aren’t abstract compliance requirements. They map directly to the categories of OIG audit findings: unsupported codes, inadequate internal controls, and failure to detect noncompliance before submission to CMS.
Build vs. Buy: The Right Question Is About Control, Not Cost
Many RCM teams are evaluating whether to deploy a vendor’s AI coding platform or build a custom solution. The right question isn’t which approach costs less upfront. It’s which approach gives the organization the level of audit control it needs for the risk it’s accepting.
A vendor SaaS solution is appropriate when workflows are standardized, integration needs are limited, and the vendor’s security controls are independently audited (SOC 2 Type II, HITRUST). A custom or hybrid approach is appropriate when the organization has complex multi-system integrations, payer-specific coding rules that require custom logic, or when audit trail requirements exceed what the vendor provides by default.
The NIST AI Risk Management Framework (NIST AI RMF) offers a structured reference for evaluating AI governance across design, deployment, and ongoing monitoring. For coding teams comparing vendor platforms, it provides a consistent vocabulary for asking vendors the right questions: How is the model evaluated before release? How are errors detected and reported? What happens when the model produces an incorrect code suggestion that a coder accepts?
ONC’s HTI-4 Final Rule, referenced in the same July 5 Health IT Answers analysis, reflects continued federal emphasis on interoperability, transparency, and FHIR-based data exchange for health IT systems — including AI tools that integrate with certified EHR modules. Even when an AI coding agent is not itself a certified EHR component, the data provenance, source attribution, and user permission requirements that apply to the surrounding systems extend to the AI layer.
What This Means for Coders and CDI Teams
Governance decisions get made at the technology and compliance level, but coders and CDI specialists bear the consequences. When an AI agent suggests a code without an auditable reasoning trace, the coder who accepts that suggestion absorbs the audit risk. When a vendor retrains its model mid-quarter and coding behavior changes without notification, coders who rely on it without awareness face unexpected denial patterns they can’t easily diagnose.
The practical implications are straightforward. Before go-live, coders should know what documentation the AI used to generate each suggestion, how to access that information if an auditor asks, what happens when they override a suggestion, and who they notify when the system produces codes that don’t match clinical expectations. If that workflow isn’t documented before deployment, it needs to be. An AI coding system without a documented override and exception process is a liability, not an asset.
Governance isn’t the barrier to AI adoption — it’s the condition that makes AI adoption sustainable. Organizations that build the compliance framework first will scale their AI coding programs faster, with fewer audit disruptions, than those that treat governance as a post-deployment problem.
Medikode’s automated medical coding platform is built with auditability and documentation traceability at its core — so coding teams can accept AI suggestions with confidence and compliance teams can respond to OIG requests without reconstructing the decision trail from scratch.