CHAI Risk Categorization — Governance Front-Matter

A reusable, fillable pre-deployment gate for any framework or app in the Clinical Epistemology portfolio. Completing it is the system's governance "birth certificate" — the record of the risk under which it earned the right to be deployed. Structured on the CHAI Risk Categorization Tool (v3).
Score each modifier honestly. "N/A" and "Need More Info" are valid, first-class answers — do not assign a Low a system has not earned.
How to complete (6 steps).
  1. Align on the use case — fill the header from the CHAI Applied Model Card or equivalent (intended use, users, patient population, deployment scope).
  2. Read all modifiers end-to-end before scoring, so inter-modifier dependencies are visible.
  3. Score each modifier Low / Medium / High — or N/A / Need More Info — recording rationale and evidence.
  4. Review as a set: did any score change once you saw the whole picture? Update and note why.
  5. Name the mitigation: for every Medium/High, cite the CRRF gate (or organizational control) that addresses it, and record any residual gap.
  6. Complete both domains. Any single High → conduct a rigorous risk assessment before deployment. If the solution is SaMD, FDA guidance governs.

Domain 1 · Life & Patient Safety

#Risk modifierLow / Medium / High (abbrev.)ResponseRationale & evidenceCRRF gate
1Distance From PatientHow close the AI is to the patient. L: no direct impact / back-office. M: indirect (scheduling, non-clinical). H: semi-direct or direct in patient care. Gate 7
2Decision AutonomyHow much human judgment stands between output and action. L: Assistive — human decides. M: Augmentative — human on the loop. H: Autonomous — AI decides. Gate 7
3Consequences of FailureWorst-case severity if the output is incorrect. L: no meaningful harm. M: temporary/reversible harm. H: permanent harm, disability, or death. Gates 4–5
4Use Context & ComplexityCriticality of setting + complexity of population. L: non-critical / outpatient, stable. M: inpatient/urgent, complex but stable. H: life-critical/emergency, complex or unstable. Gate 1
5Monitoring DifficultyHow hard/resource-intensive to monitor output. L: embedded real-time monitoring. M: partial; periodic. H: must be developed / resource-intensive manual. Gate 9
6React TimeTime to react before serious consequences. L: time for reaction/planning. M: limited time. H: very little / none. Gate 8
7Breadth of Potential HarmHow broadly harm could spread across patients/sites. L: single / small number. M: moderate; multiple units/clinics. H: widespread; systems/populations. Gate 6
8Cross-System PropagationHow far an incorrect output could cascade. L: isolated. M: integrated, limited connections. H: deeply embedded; single point of failure cascades. Gate 3
9Population Sensitivity / DisparityRisk of exacerbating disparities/bias. L: minimal. M: some disparity risk. H: significant; could reinforce inequities for vulnerable groups. Gates 6, 8

Domain 2 · Technology & Data

#Risk modifierLow / Medium / High (abbrev.)ResponseRationale & evidenceCRRF gate
1Use of Sensitive DataSynthetic vs. de-identified vs. PII/PHI. L: synthetic/nonconfidential. M: de-identified (Safe Harbor, residual). H: PII/PHI directly exposed. Gate 3
2Accuracy of DataValidity, conformance, correct coding. L: validated, standardized to ontologies. M: generally reliable, inconsistent coding. H: unvalidated values common; unharmonized. Gate 4
3Completeness of DataMissingness, coverage, fragmentation. L: well-populated; gaps unlikely. M: some gaps; mitigations applied. H: high missingness; fragmented. Gate 3
4Veracity of DataSource reputability, provenance, freshness. L: reputable, clear provenance, current. M: generally reputable; lagged/variable. H: opaque/unreliable/stale sources. Gate 3
5Data TransparencyDocumentation of data used to train/validate. L: complete provenance/catalog shared. M: partial documentation. H: none. Gate 8
6Sufficiency & RepresentativenessCoverage of populations/subgroups in deployment. L: large, longitudinal, representative. M: adequate; depth/breadth limits. H: small/narrow; poor generalizability. Gates 2, 6
7Model Security VulnerabilitiesTechnical deployment/attack surface. L: application-bound, no external interfaces. M: internal-facing. H: internet-facing. Gate 9
8Model Lifecycle ManagementDesign, retrain, version, rollback governance. L: documented, automated, auditable, rollback-capable. M: inconsistent; partial validation. H: no structured lifecycle; uncontrolled updates. Gate 9
9Monitoring, Incident Detection & ResponseRuntime detection of drift, errors, integrity issues. L: automated, timely, integrated with incident mgmt. M: partial; manual review. H: minimal/absent; no AI-incident separation. Gate 9
10AI Detection & TraceabilityWhether AI influence is visible/auditable. L: outputs labeled; full audit trails. M: partial labeling/auditability. H: AI influence invisible to users. Gate 8
Licensing & scope. Structured on the CHAI Risk Categorization Tool (v3), published by the Coalition for Health AI under CC BY-NC-ND 4.0. This is an independent internal template that aligns to the CHAI Tool; consult the source document for authoritative modifier definitions. A governance aid, not clinical, legal, or regulatory advice. Fillable in-browser; no data is stored — use Print / Save as PDF to retain a completed copy.