Why Your RCM Vendor's "AI" Probably Isn't: A Technical Guide...

Every revenue cycle management vendor in 2026 claims to use artificial intelligence. Every press release, every booth at HIMSS, every sales deck features "AI-powered" somewhere in the first three slides. The word has become so ubiquitous in healthcare technology marketing that it has lost almost all meaning.

This is AI-washing — the practice of labeling technology as "artificial intelligence" when it's actually rules-based automation, simple keyword matching, basic statistical models, or in some cases, manual processes with a software interface. It's not unique to healthcare, but the consequences in healthcare are uniquely severe: organizations making six- and seven-figure technology decisions based on AI claims that don't reflect the actual technical capabilities of the platform.

The problem isn't that rules-based automation is bad. It's useful. It has a place. The problem is that when a vendor calls rules-based automation "AI," they're making a promise about capabilities that the technology can't deliver — and the buyer won't discover the gap until they're months into an implementation and the platform can't do what the sales demo implied it could.

This guide provides a technical framework for evaluating AI claims in healthcare technology — specific questions to ask, red flags to watch for, and tests that separate genuine AI from marketing language applied to traditional automation.

The AI-Washing Spectrum

Not all AI-washing is equally deceptive. It exists on a spectrum from aggressive exaggeration to reasonable-but-imprecise marketing.

Level 1: Pure Rules Marketed as AI

What it actually is: Hard-coded if/then rules. If diagnosis code = X and procedure code = Y, then flag as potential denial. If claim field Z is missing, then reject. The rules were written by humans, don't learn from data, and don't change unless a human programmer updates them.

What the vendor calls it: "AI-powered claim scrubbing," "intelligent denial prevention," "smart workflow automation."

How to identify it: Ask the vendor to describe a specific scenario where the system learned something new from your data that it didn't know before. If the answer is about "configuring rules" or "customizing settings," it's a rules engine.

The capability gap: Rules engines can't detect novel denial patterns. They can't identify the subtle payer behavior shift that's about to cause a spike in denials next month. They can only catch what they've been explicitly programmed to catch. Every new denial pattern requires a human to identify it, write a rule, test the rule, and deploy it.

Level 2: Basic Statistics Marketed as Machine Learning

What it actually is: Statistical models — regression, threshold analysis, basic pattern matching — that use historical data to set fixed parameters. Common examples: claims are flagged for review if they exceed a dollar threshold, denial probability is estimated from a static lookup table of denial rates by code.

What the vendor calls it: "Machine learning-powered prediction," "AI analytics," "predictive denial intelligence."

How to identify it: Ask how often the model retrains. If the answer is "quarterly" or "when we release updates," it's a static statistical model, not a learning system. Ask what happens when a payer changes its rules mid-quarter. If the answer is "we update the rule set in the next release," the model isn't learning — it's being manually updated.

The capability gap: Static models degrade over time. Payer rules change, coding guidelines update, practice patterns shift. A model calibrated on last year's data becomes less accurate every month. True machine learning continuously retrains on new data, adapting to changes in real-time.

Level 3: Narrow ML Marketed as Comprehensive AI

What it actually is: Genuine machine learning applied to one narrow function — typically claim status prediction or basic coding suggestion — while the rest of the platform runs on rules and manual workflows.

What the vendor calls it: "AI-native platform," "end-to-end AI automation," "fully AI-powered RCM."

How to identify it: Ask the vendor to name every function in the platform that uses machine learning models vs. rules-based logic. If the answer is evasive or focuses on a single capability, the platform has a narrow ML feature inside a traditional rules-based architecture.

The capability gap: A platform that uses ML for denial prediction but rules for coding, manual processes for authorization, and static logic for payment posting isn't an "AI platform" — it's a traditional platform with an AI feature. The compound value of AI — where insights from one function improve performance across all functions — only exists when AI is the platform architecture, not a bolt-on.

Level 4: Genuine AI-Native Architecture

What it actually is: Machine learning and natural language processing as the foundational technology layer. Models that learn from every claim, every denial, every payment, every payer interaction. Systems that improve continuously without manual rule updates. NLP that reads clinical documentation and understands context, not just keywords. Prediction, recommendation, and automation capabilities that span the entire revenue cycle.

What the vendor calls it: The same things as Levels 1-3 — which is exactly the problem. The language is identical, so the buyer can't distinguish genuine AI from marketing AI based on the vendor's description alone.

The Technical Evaluation Framework

Test 1: The Learning Test

Question to ask: "Can you show me a specific example where the system learned something from our data that improved its performance — without any human programming the change?"

What genuine AI looks like: "After processing your first 10,000 claims, the model identified that Payer X denies claims with diagnosis Z when the place of service is 22 but not when it's 11. This pattern wasn't in our initial training data — the model discovered it from your specific claims history and adjusted its scrubbing rules automatically."

What AI-washing looks like: "Our team of experts continuously updates our rule set based on industry trends." (This is human programming, not AI learning.) "The system adapts to your specific needs through our configuration process." (This is manual setup, not machine learning.)

Why it matters: The fundamental value proposition of AI is that it improves with data. A system that doesn't learn from your data will perform the same on day 365 as on day 1 — which means you're paying for AI but receiving static automation.

Test 2: The Novel Pattern Test

Question to ask: "If a payer changes its denial rules tomorrow and starts denying a claim type that was previously accepted, how quickly does your system detect and respond to the change? Walk me through the technical process."

What genuine AI looks like: "Our denial pattern detection models continuously analyze incoming denials. When the denial rate for a specific payer-code combination increases above the expected baseline, the system flags the pattern within days, adjusts the claim scrubbing logic automatically, and alerts your team with the specific change detected."

What AI-washing looks like: "We monitor payer updates and update our edits accordingly." (This is manual monitoring, not AI detection.) "Our team releases regular updates to reflect payer changes." (This is a software update cycle, not real-time learning.) "We have access to industry data that keeps our rules current." (This is a data subscription, not AI.)

Why it matters: The healthcare revenue cycle is a moving target. Payer rules change constantly — often without formal notification to providers. A system that can't detect and respond to changes in real-time is fundamentally limited in its ability to prevent denials.

Test 3: The NLP Test

Question to ask: "Does your system read clinical documentation? If so, show me what it extracts from this operative note and how it uses that extraction."

What genuine AI looks like: The vendor can demonstrate the system reading an unstructured clinical note and extracting specific clinical details — diagnoses, procedures, laterality, severity indicators, medical necessity elements — and using those extractions for coding suggestions, denial risk assessment, or documentation quality scoring. The extraction handles variations in language, abbreviations, and physician documentation styles.

What AI-washing looks like: "Our system analyzes structured data fields from your EHR." (Structured data analysis is database querying, not NLP.) "We use templates to standardize documentation." (Templates are input forms, not AI.) "Our coding suggestions are based on the codes selected by the coder." (This is a lookup table, not NLP — it doesn't read the note, it reads the code.)

Why it matters: Clinical documentation is unstructured text. The richest data in the revenue cycle — the data that determines coding accuracy, medical necessity, denial risk, and compliance — lives in physician notes, operative reports, and clinical assessments. A system that can't read and understand this text is limited to working with the structured data that humans have already extracted and entered.

Test 4: The Prediction Specificity Test

Question to ask: "Your platform predicts denials. For a specific claim, what does the prediction look like? What information does it give me beyond 'this might be denied'?"

What genuine AI looks like: "For claim #12345: Denial probability 87%. Predicted denial reason: medical necessity (CARC 50). Predicted payer response time: 14 days. Recommended action: attach clinical documentation supporting medical necessity criteria per Payer X's LCD for this procedure. Similar claims with this documentation attached have a 92% acceptance rate. Priority: high — claim value $4,200, filing deadline in 28 days."

What AI-washing looks like: "The claim is flagged as high risk." (Flagging without specificity is a threshold alert, not a prediction.) "The denial probability is 78%." (A probability number without actionable context is a statistical output, not intelligence.) "We recommend reviewing this claim." (Telling you to review a claim is not a recommendation — it's passing the work back to you.)

Why it matters: The value of prediction isn't the prediction itself — it's the specific, actionable intelligence that accompanies it. Knowing a claim will be denied is useful. Knowing why it will be denied, what specific documentation will prevent the denial, and how to prioritize it against other at-risk claims is transformational.

Test 5: The Architecture Test

Question to ask: "Is your AI a feature within your platform, or is AI the platform architecture? How many of your platform's functions use machine learning models vs. rules-based logic?"

What genuine AI looks like: "AI is the platform architecture. Our coding engine uses NLP models trained on millions of clinical documents. Our denial prevention uses prediction models trained on hundreds of millions of claims. Our payment posting uses pattern recognition for ERA matching. Our analytics use predictive models for cash forecasting. Each function feeds data back to the others — denial outcomes improve the coding model, coding accuracy improves the denial model, payment patterns improve the analytics."

What AI-washing looks like: "We use AI for [one specific function] and have plans to expand AI across the platform." (One feature isn't a platform.) "Our AI layer sits on top of our proven rules engine." (An AI layer on a rules engine means the rules engine is doing the work and the AI layer is providing marginal enhancements.) "We've integrated AI capabilities from [third-party AI provider]." (Integrated third-party AI is a vendor relationship, not a platform architecture.)

Why it matters: The difference between "AI feature" and "AI architecture" is the difference between a car with an AI-powered navigation system and a self-driving car. Both "use AI." One is fundamentally more capable than the other.

Red Flags in Vendor Evaluations

Red Flag 1: The Demo Uses Canned Data

Every AI demo should be able to process your data — your claims, your documentation, your payer mix. If the demo exclusively uses pre-loaded sample data with impressive results, ask to run it against your actual data. Genuine AI that works should work on your data. Systems that only demo well on prepared data often have models that aren't generalizable.

Red Flag 2: "AI" Is Only Mentioned in Marketing

Read the vendor's technical documentation — not the marketing materials. If the word "AI" appears frequently in sales decks and press releases but is absent from technical architecture documents, implementation guides, and API documentation, the AI may be marketing rather than technology.

Red Flag 3: No Model Performance Metrics

Genuine AI vendors can tell you their model's performance metrics: precision, recall, accuracy rates for specific tasks, false positive rates, improvement curves over time. If the vendor can't provide specific model performance data — or only provides aggregate metrics like "95% accuracy" without defining what "accuracy" means in context — the AI claims may not be backed by rigorous model performance.

Red Flag 4: "Proprietary" Means "Don't Ask"

When asked technical questions about the AI, vendors sometimes respond with "our approach is proprietary." While intellectual property protection is legitimate, a refusal to discuss architecture, model types, training data approach, or evaluation methodology at any level of detail is a red flag. A vendor with genuine AI capabilities should be able to explain — at a high level — how their AI works without revealing trade secrets.

Red Flag 5: The Vendor Can't Explain the Training Data

Every machine learning model is only as good as its training data. Ask: What data was the model trained on? How much data? From what types of organizations? How current is the training data? How is new data incorporated?

A vendor that can't clearly articulate their training data strategy either doesn't have AI models or has models trained on insufficient or inappropriate data.

Red Flag 6: No Continuous Improvement Evidence

Ask the vendor to show how the platform's performance has improved over time for existing customers. Genuine AI should show measurable improvement curves — denial prediction accuracy improving as the model processes more data, coding suggestions becoming more accurate over months, fewer false positives as the system learns the organization's specific patterns.

If the vendor can only show static performance metrics ("our system achieves 95% accuracy"), the system isn't learning — it was calibrated to that accuracy and stays there.

The Practical Impact of AI-Washing on Revenue Cycle Performance

AI-washing isn't just a marketing annoyance. It creates measurable financial harm when organizations make purchasing decisions based on capabilities that don't exist.

Scenario: Denial Prevention

A vendor claims "AI-powered denial prevention" that predicts and prevents denials before they occur.

If it's genuine AI: The system learns your specific payer patterns, detects novel denial trends within days, automatically adjusts claim scrubbing, and provides specific prevention recommendations for each at-risk claim. Denial rate drops measurably within 60-90 days as the model learns your data.

If it's rules-based automation marketed as AI: The system catches denials that match pre-programmed rules — the same denials your current system catches if properly configured. Novel denial patterns aren't detected until a human identifies them and creates a new rule. Denial rate improvement is marginal and plateaus quickly.

Financial gap: A genuine AI platform that reduces denial rate from 12% to 6% on $20 million in claims recovers $1.2 million annually. A rules-based system that reduces denial rate from 12% to 10% recovers $400,000. The $800,000 difference is the cost of AI-washing.

Scenario: Coding Optimization

A vendor claims "AI-powered coding" that reads clinical documentation and suggests optimal codes.

If it's genuine AI: The system reads the full clinical note using NLP, extracts clinical details, maps them to the most specific and accurate codes, and identifies documentation gaps that could improve code specificity. Coding accuracy improves over time as the model processes more of your organization's documentation.

If it's basic automation marketed as AI: The system presents a lookup table of frequently used codes based on historical patterns, or it maps structured EHR data fields to code suggestions. It doesn't read unstructured notes. It doesn't understand clinical context. It doesn't improve with data.

Financial gap: NLP-powered coding that improves HCC capture by 15% for a Medicare Advantage population of 5,000 members can increase risk-adjusted revenue by $500,000-$1,000,000 annually. A lookup-table "AI" provides minimal HCC improvement because it can't read the clinical documentation where the conditions are described.

Questions That Cut Through AI-Washing

Use these in your next vendor evaluation. They're designed to be answerable by genuine AI platforms and difficult to answer convincingly by rules-based systems with AI marketing.

"Describe your model architecture for [specific function]." Genuine answer includes model type (transformer, ensemble, neural network), training approach, and inference process. AI-washing answer deflects to "proprietary" or responds with marketing language.
"How does your system handle a payer rule change that it hasn't seen before?" Genuine answer describes anomaly detection and adaptive learning. AI-washing answer describes manual update processes.
"Show me the performance improvement curve for a current customer over their first 12 months." Genuine answer shows measurable, continuous improvement. AI-washing answer shows a single point-in-time metric.
"What percentage of your engineering team works on machine learning?" Genuine AI companies have large ML engineering teams (30-50%+ of engineering). Companies with "AI features" may have a small data science team (5-10%) that maintains a few models.
"What happens if your AI makes a wrong recommendation?" Genuine answer describes feedback loops — how incorrect recommendations are used to improve the model. AI-washing answer describes human review processes that catch errors.
"Can your system explain why it made a specific prediction or recommendation?" Genuine AI platforms provide interpretable outputs — the specific factors that contributed to a prediction. Systems without real AI can't explain what they can't actually predict.
"How do you measure and report AI model performance to customers?" Genuine answer includes regular model performance reports with precision/recall metrics, improvement trends, and false positive analysis. AI-washing answer provides aggregate outcome metrics (denial rate, collection rate) without attribution to AI vs. human effort.

What Genuine AI-Native RCM Actually Looks Like

Genuine AI-native revenue cycle management has specific technical characteristics that distinguish it from traditional automation:

Continuous learning. The system processes every claim, denial, payment, and payer interaction as training data. Models retrain on ongoing data — not on quarterly release cycles. Performance improves measurably over time.

Natural language processing. The system reads and understands clinical documentation — operative notes, progress notes, discharge summaries — in their unstructured text form. It doesn't depend on structured data entry or template fields.

Prediction with specificity. Predictions include the specific reason, the specific recommended action, and the confidence level. Not just "high risk" flags.

Cross-functional intelligence. Insights from one function improve all others. Denial patterns improve coding recommendations. Coding accuracy improves denial predictions. Payment posting patterns improve AR management. The entire platform is interconnected.

Measurable improvement. The vendor can demonstrate — with your data — that the system performed better in month 6 than in month 1, and better in month 12 than in month 6. Not because rules were updated, but because the models learned.

The healthcare revenue cycle deserves better than marketing language. It deserves technology that actually works the way it's described. The organizations that learn to distinguish genuine AI from AI-washing will make better technology decisions, achieve better financial outcomes, and avoid the costly disappointment of discovering — months into an implementation — that the "AI" they purchased is a rules engine with a new name.

Why Your RCM Vendor's "AI" Probably Isn't: A Technical Guide to Spotting AI-Washing