NIST AI RMF GenAI Profile — A Healthcare-SMB Translation
The NIST AI RMF Generative AI Profile is written for enterprise. Here's the translation a 20–200 person medical practice or hospital-adjacent SMB needs to operationalize it.
NIST published the Generative AI Profile of the AI RMF (NIST AI 600-1) in mid-2024 as a companion to the core AI RMF 1.0. For a large enterprise with an AI governance program, it maps cleanly. For a 20–200 person medical practice, dental group, or hospital-adjacent SMB using ChatGPT and a healthcare copilot, it reads like it’s written for someone else. This post is the SMB healthcare translation — what to actually do, in what order, using the four AI RMF functions as the scaffold.
The four functions, translated
| AI RMF Function | Enterprise version | Healthcare-SMB version |
|---|---|---|
| Govern | AI governance committee, board oversight, AI policy | The physician-owner and the practice manager decide what AI is used and sign a one-page AI acceptable-use policy |
| Map | Enterprise AI inventory, context and stakeholder mapping | List every AI tool touching PHI, what it does, and which vendor holds the BAA |
| Measure | Bias/fairness metrics, model performance monitoring | Track: patient complaints about AI, clinical documentation errors traced to AI, PHI incidents involving AI |
| Manage | AI risk registers, incident response, decommissioning | Add AI incidents to the existing HIPAA incident register; kill the tool if it can’t meet BAA rigor |
Govern — day 1 to day 30
Ownership. In a 20-person practice this is the physician-owner. In a 200-person medical group it’s usually the practice administrator with clinical sign-off from a designated MD. Do not delegate this to your MSP. Your MSP configures; you decide what’s allowed.
Policy. One page. Covers:
- Which AI tools staff may use for patient-related work (name each one)
- What data must never be entered into general-purpose AI (PHI, unencrypted patient identifiers, financial info)
- Who reviews AI outputs before they enter the medical record
- What happens when someone breaks this policy
This policy sits alongside your existing HIPAA policies. It is signed by every staff member during the same annual attestation cycle.
Map — day 30 to day 60
Inventory. Every AI tool touching your data:
| Tool | What it does | Where PHI touches it | BAA in place? | Vendor SOC 2? |
|---|---|---|---|---|
| eClinicalWorks AI Assistant | Note generation | Yes, real-time | Yes | Type II 2025 |
| ChatGPT (personal accounts) | Whatever staff type | Should never | No — general term | N/A |
| Nuance DAX | Ambient documentation | Yes, real-time | Yes | Type II 2025 |
| Ambient scribe X | Ambient documentation | Yes, real-time | ? | ? |
| Internal Gemini tenant | Admin work | Configured to reject PHI | Google BAA | Yes |
The row you cannot fill in — vendor “X” with no BAA and no SOC 2 — is your top finding.
Vendor tier. For each AI vendor:
- Tier 1: signed BAA, current SOC 2 Type II, breach notification ≤72h in contract → approved for PHI workflows
- Tier 2: BAA + basic security attestation → approved for non-PHI admin workflows only
- Tier 3: general terms of service, no BAA → prohibited for anything patient-adjacent
Most SMB practices have ~2 tier-1 vendors, ~3 tier-2, and 8+ tier-3 tools staff are quietly using. The gap between “what’s approved” and “what’s used” is the risk.
Measure — day 60 to day 90
Three metrics, tracked monthly:
1. AI-attributed documentation corrections. How many clinical notes, per month, required correction of AI-generated content? Which AI tool produced them? A rising trend flags either a specific tool problem or an over-reliance problem in a specific clinician.
2. PHI incidents involving AI. Any HIPAA incident where AI was in the pipeline gets tagged. Track separately from general HIPAA incidents. In year one, target zero; anything above three signals a policy or tool problem.
3. Consent and disclosure gaps. How many patients have been informed, per your notice of privacy practices, that AI tools may be involved in their care? Depending on state and payer requirements, this is not just a compliance detail — it’s an increasingly common patient question.
Manage — ongoing
Incident response. Add “AI involvement?” as a field on your existing HIPAA incident report. When it’s yes, the analysis captures:
- Which tool
- What data was involved
- Was the vendor notified within contract SLA
- Root cause: tool defect, misuse, misconfiguration, or vendor breach
Decommissioning. When you retire an AI tool:
- Confirm vendor deletes your data per BAA
- Get written attestation of destruction
- Revoke any API keys or SSO integrations
- Update the AI inventory
What this doesn’t require
- A dedicated AI governance committee for a 30-person practice
- Bias/fairness testing infrastructure — that lives with the model vendor
- ML monitoring tooling — again, on the vendor
- A separate AI risk register — extend the HIPAA one
The AI RMF for a healthcare SMB is a one-hour-a-month exercise once it’s stood up. It becomes an all-consuming project only when you outsource ownership to a vendor selling you their AI governance product.
What auditors and payers are starting to ask
- Do you have an AI inventory and policy?
- Which of your AI tools touch PHI, and do you have BAAs?
- How do you handle AI-generated documentation errors?
- What is your patient disclosure practice?
These are on more HIPAA risk analyses than a year ago. Being ready for the question is a two-month standup, not a two-year program.