Every AI vendor you talk to will show you a demo that works perfectly, a case study with dramatic results, and a reference customer who loves the product. That is not evidence. That is a sales process.
Vendor sales teams are optimized to close deals, not surface limitations. Their job is to make the buy decision feel safe. Your job is to figure out what happens when the model is wrong — because in a community health setting, "wrong" lands on patients who already have fewer safety nets.
This is not an anti-AI argument. It is a due diligence argument. The difference between an AI tool that improves care and one that creates liability is the rigor you apply before you sign.
The Demo Problem
Demos are controlled environments. The data is clean. The patient population is favorable. The workflow is idealized. Every vendor demo you have ever seen was built to showcase the best-case scenario.
Ask yourself: does this demo reflect my patient population? If you serve a predominantly Medicaid population with high rates of chronic disease, social complexity, and language diversity, a demo trained on data from an academic medical center in a metro suburb is not evidence that the tool works for you. It is evidence that the tool works somewhere.
Before the demo ends, ask these questions:
- What dataset was this trained on, and what is the demographic breakdown?
- What is the false positive rate? The false negative rate?
- Can you show me a case where the model got it wrong?
- What happens in the workflow when the model produces an incorrect recommendation?
If the vendor cannot answer the third question, they either do not track failures or do not want to tell you about them. Neither is acceptable.
Clinical Evidence: Published vs. "Validated"
Vendors love the word "validated." It can mean anything from a peer-reviewed randomized controlled trial to an internal analysis the vendor conducted on their own data and has not published.
What to demand:
- Peer-reviewed publications — not white papers, not press releases, not conference posters. Published studies in journals with actual peer review. Ask for the citation.
- Study population relevance — a validation study conducted at Mayo Clinic does not tell you how the tool performs at a 12-provider FQHC in rural Washington. Population characteristics matter. Payer mix matters. EHR workflow matters.
- Sample size and statistical power — a study with 200 patients is a pilot. Treat it as one.
- Independent validation — was the study conducted by the vendor, or by an independent research team? Vendor-conducted studies are marketing. Independent replication is evidence.
If the vendor's strongest evidence is a case study on their own website, you are being asked to take their word for it. That is not due diligence.
Bias Testing: The Question Vendors Hope You Won't Ask
Community health organizations serve populations that are systematically underrepresented in training data — racial and ethnic minorities, patients with limited English proficiency, Medicaid beneficiaries, rural populations, tribal communities. AI models trained on data that underrepresents these groups will underperform on these groups. This is not theoretical. It is documented.
Ask for demographic performance breakdowns:
- How does the model perform across racial and ethnic subgroups?
- What is the performance differential between insured and uninsured patients?
- Has the model been tested on populations with high social determinant burden?
- What is the performance on patients with limited English proficiency?
If the vendor says "we don't have that data," that is your answer. They have not tested for bias in the populations you serve. You are being asked to deploy an untested tool on your most vulnerable patients.
If the vendor says "our model is fair because we removed race from the inputs," that is worse. Removing race as an input does not remove racial bias from the model. Correlated variables — zip code, insurance status, utilization patterns — carry the same signal. This is well-established in the literature and any vendor who does not know it is not ready for the healthcare market.
Integration Architecture: Where Costs Hide
The demo shows the AI tool in isolation. Your reality is an EHR, a billing system, an HIE connection, a dozen interfaces, and staff who are already stretched thin.
Ask about integration before you ask about price:
- EHR integration method — is this a native integration, an API, an iframe, or a separate login? Each has different workflow, maintenance, and security implications.
- Data requirements — what data does the tool need, how often, and in what format? Who builds and maintains the data pipeline?
- Implementation timeline and cost — not the software license, the total cost. Include IT staff time, EHR vendor fees for interface builds, training, workflow redesign, and go-live support.
- Ongoing maintenance — who is responsible when the interface breaks after an EHR update? What is the vendor's SLA for integration issues?
The license fee is typically 30-40% of the true cost of deploying a clinical AI tool. If the vendor is quoting you only the license fee, they are either naive about implementation or strategically omitting the rest.
Regulatory Status: Cleared vs. "Compliant"
Another word vendors stretch beyond recognition: "compliant." Ask specifically:
- FDA clearance — does this tool have 510(k) clearance or De Novo authorization? For what specific intended use? A tool cleared for radiology triage is not cleared for diagnostic interpretation, even if it can technically do both.
- HIPAA — every vendor claims HIPAA compliance. Ask for their most recent third-party security assessment. Ask whether they will sign a BAA before the pilot, not after.
- State regulations — some states have specific requirements for AI in clinical decision-making. Does the vendor know the regulatory landscape in your state?
"FDA-cleared" has a specific legal meaning. "Clinically validated" does not. Know the difference.
Financial Viability: Will They Be Here in Three Years?
Healthcare AI is a crowded market with high burn rates. The vendor that sells you a tool today may not exist when your contract renews.
Basic financial due diligence:
- Funding history — how much have they raised, from whom, and when was the last round? A Series A company with 18 months of runway is a different risk profile than a profitable company with enterprise customers.
- Customer concentration — how many customers do they have? If they have fewer than 20, losing two could threaten the business.
- Revenue model — is this SaaS, per-encounter, or grant-funded? Grant-funded tools disappear when the grant ends.
- Data rights — if the vendor shuts down, what happens to your data? What happens to the model? Can you export your configuration and historical results?
You are not investing in a tool. You are investing in a dependency. Treat the financial diligence accordingly.
Reference Checks: Go Off-Script
Every vendor will give you references. Those references were selected because they will say positive things. That is fine — talk to them anyway, but also:
- Ask the reference what went wrong during implementation. Every implementation has problems. If the reference says nothing went wrong, they are either not being candid or they have not been live long enough.
- Ask about the populations they serve. If the reference is a large health system and you are a critical access hospital, their experience may not transfer.
- Find your own references. Search for the vendor on KLAS, CHIME forums, or LinkedIn. Talk to organizations that evaluated the tool and chose not to buy it. Their reasons are more informative than the reasons someone chose to buy.
- Ask about support responsiveness after go-live. The pre-sales team is always responsive. Post-sale support is where you learn the vendor's true priorities.
Red Flags Summary
Walk away — or at minimum, slow down — when you encounter:
- Resistance to sharing demographic performance data
- No peer-reviewed clinical evidence for the specific use case
- "Validated" without a specific citation
- Integration costs that are vague or excluded from the proposal
- Unwillingness to sign a BAA before a pilot
- No clear answer on what happens to your data if the vendor folds
- References that are all large health systems when you are a safety-net provider
- Pressure to sign before your clinical and IT teams have completed evaluation
Build Your Framework Before the First Sales Call
The best time to evaluate a vendor is before you are in a sales cycle. Build your evaluation criteria, weight them for your organization's priorities, and apply the same framework to every product you consider. Ad hoc evaluation leads to ad hoc decisions — and in clinical AI, the downside of a bad decision falls on patients.
Take the LumenHealth AI Readiness Assessment to build a structured evaluation framework before your next vendor conversation. Know what to ask before they start telling you what you want to hear.
This article is provided for informational purposes and does not constitute legal, regulatory, or clinical advice. Organizations should consult qualified advisors before making AI procurement decisions. LumenHealth provides AI governance assessments for community health organizations and is not affiliated with any AI vendor.
Assess your organization's AI governance readiness
37 questions across five domains. Free facilitated debrief with your leadership team.