RUAIH focus area 4 — Monitoring and validation

Every other focus area could, in principle, be satisfied at a desk. Area 4 cannot: it is about the model running — validated before it touches care, watched while it does, and connected to an incident route when something goes wrong.

The three controls

Local validation. Before deployment: the model tested on your data, in your workflow, with a protocol and a recorded result. The vendor’s validation answers “does it work?”; local validation answers the question that matters to a surveyor — “does it work here?”

Post-deployment monitoring. After deployment: performance tracked against a locked baseline, with a threshold that triggers action and an owner whose name is on it. The evidence — a monitoring plan and the accumulating record of checks against it — is the artifact no budget can compress, which is why preparation orders put this clock among the first to start.

AI safety event reporting. A route: staff know where an AI-involved incident goes, and the record shows events actually travelling it. Most organisations bolt this onto existing patient-safety reporting — the control is that AI events are identifiable as such, not lost in the general stream.

Why this area decides certifications

Drafted documents converge under deadline pressure; monitoring histories do not. When surveys begin, the difference between organisations will not be who has a policy — everyone will — but who has four quarters of dated attestations against a locked baseline. This is precisely the record HAI-OS keeps as a side effect of operating: baselines locked, drift computed against thresholds, enforcement and sign-offs on a hash-chained audit trail you can watch working in the live demo.