Why every healthcare AI vendor turns into an assurance project
Security teams are stretched thin, and every new AI vendor means another set of claims to reconcile against clinical workflow risk. What arrives is a packet built from policies and infrastructure controls, and it’s useful as far as it goes. It describes what the controls are meant to do. It doesn’t say what a control reported for any one encounter, and that is what your security and clinical-informatics reviewers are trying to establish.
So the work lands on people. Clinical, compliance, privacy, security and procurement each open the same vendor from a different angle, and each assembles a private picture of it, because there’s no shared record of what the controls reported, which decision was taken, and what was deliberately left out. Multiply that by the number of AI tools now entering a health system and an assurance organization starts forming around every vendor, one review at a time.
The alternative is to make one artifact the requirement: a signed record from the live workflow, written so that all five reviewing teams can read it for their own purposes. The record shows what the control reported, and a reviewer can check that it’s intact and who signed it. It doesn’t tell you whether a note was clinically correct, whether every encounter was captured, or whether the system is safe or compliant, and it can’t confirm that events happened the way the record says. Those still get checked separately. What changes is that the reconciliation work stops being rebuilt from scratch for every vendor.
A common procurement question
The vendor’s security packet describes the intended controls. What shows which control ran, what it decided, and which parts of the workflow it covered?
What a health system gets
The work takes one vendor workflow at a time, and each piece of it is designed to be handed to the next reviewer without rewriting.
Runtime evidence requirements
We help you translate vendor AI risk into evidence requirements attached to a real workflow, not a generic AI policy packet. That means control requirements written for the workflow in front of you, mappings that carry across OVERT, ATLAS, OWASP, HIPAA and your own internal policies, and a named set of record fields your reviewers should require before a pilot becomes an operational dependency.
An evidence pack pattern
Know what evidence to ask a vendor for. Policy documents still have a place. Signed records show what a control reported; deployment, testing and coverage evidence show how it ran and how much of the workflow it covered. The pack gathers the signed runtime records, the control coverage and exception summaries, and a data-flow description with an evidence-boundary record, so a reviewer can see what was covered and what was deliberately left outside the record.
A reference sprint
Start with one vendor workflow and create the evidence pattern other departments can reuse. The sprint produces a map of the runtime surface, a decision about where controls sit locally, and an evidence pack that reads to a buyer and to an auditor without translation. The workflow after that starts from the pattern rather than from a blank questionnaire.
Operational follow-through
AI oversight isn’t a one-time document. Regulations change, vendor models update, and clinical workflows drift. Follow-through ties regulatory updates back to the runtime evidence they touch, sets the triggers that reopen a vendor assessment, and turns trends in the records into specific control improvements rather than another questionnaire cycle.
Free checklist
Make runtime evidence a condition of every vendor review.
A procurement-ready checklist your security and clinical-informatics reviewers can attach to an AI vendor review. It names signed runtime records (OVERT format) as one requested artifact, so reviewers can check who signed a vendor’s record and that it’s intact. What the record does and doesn’t settle is set out above.
Free. No form, no email.
Get the checklistBeyond questionnaire review
A good AI vendor review asks for the runtime evidence a health system will need later: intake, control requirements, record generation, evidence review and action.
Intake
Identify the exact clinical workflow, data boundary, tools, user roles, and decision points before a pilot becomes an operational dependency.
Control requirements
Define what gets held, narrowed or denied, what gets logged and verified, and what stays local, before that vendor workflow can pass review.
Signed records
Ask for signed records of what the controls reported in the live workflow. The record can leave out selected PHI, prompt, secret and patient-specific fields; the surrounding data flows are reviewed on their own.
Evidence review
Use an evidence pack that maps records to HIPAA, state AI laws, SOC 2, internal policies and clinical safety requirements.
Action
When risk is found, act on a specific control, workflow, or vendor obligation instead of reopening a generic questionnaire.
Where the rules stand
State and federal AI rules are still settling, and the timelines keep shifting. The transparency and disclosure obligations now taking shape reward health systems that can show how their AI behaves in production, and runtime evidence is what lets you show it. Two of these duties already apply. The other two have dates.
| Regulation | Impact | Status |
|---|---|---|
| HIPAA Security Rule risk analysis | Existing risk-analysis duties apply to risks and vulnerabilities affecting ePHI, including relevant AI data flows and systems | In force; proposed-rule changes assessed separately |
| Texas H&S Code §183.005 (SB 1188) | A practitioner using AI for diagnostic purposes under the section must disclose that use to patients | In force since Sep 1, 2025 |
| Colorado SB 26-189 | Notice and disclosure duties for covered automated decision-making technology (ADMT) used in health-care decisions | Jan 2027 |
| EU AI Act | System-specific classification; some medical-device AI may follow Article 6(1)/Annex I and some uses may fall within Annex III | Dec 2, 2027 for relevant Annex III duties; Aug 2, 2028 for relevant Annex I product-embedded duties |
Build the evidence requirement before the next vendor review
Pick one high-risk AI workflow. Glacis will help map the runtime surface, define local controls, and assemble the evidence pattern your review process can reuse.
Talk to us