Deployment changes the evidence available about an AI system. Real users create new prompt distributions, connect tools, discover failure modes, and depend on outputs in ways a laboratory test may not capture. Post-deployment policy should actively collect performance and incident data for the system's lifetime. The plan must define normal telemetry, protected reporting channels, severity levels, investigation ownership, reporting deadlines, containment powers, and conditions for suspension or retirement.
Counts need a denominator. If $k$ relevant incidents occur over exposure $E$, estimate the rate as $$\hat\lambda=\frac{k}{E}.$$ Exposure might be one million decisions, user-hours, generated documents, or tool actions, chosen to match the hazard. Track severity-weighted loss $L=\sum_i w_i/E$ as well as count, because ten harmless formatting failures are not equivalent to one irreversible rights impact. Publish the denominator definition whenever rates are compared.
Zero observed incidents does not establish zero risk. Under a simple constant-rate event model, if no event is seen over exposure $E$, an approximate ninety-five percent upper bound is $$\lambda_{95}\approx\frac{-\ln(0.05)}{E}\approx\frac{3}{E}.$$ The assumptions may fail when events are correlated, reporting is incomplete, or risk changes over time. The bound is most useful as a reminder that rare-harm evidence requires enough exposure and an effective detection process.
Create a severity taxonomy before the first incident. Include actual harm, credible near misses, loss of control, security compromise, prohibited output, systematic subgroup disparity, and failures of required human oversight. Triage should consider magnitude, number of people exposed, reversibility, vulnerability, legal significance, and likelihood of recurrence. Preserve logs and versions while minimizing unnecessary personal data. A suspected causal link may justify containment and an initial report before a full root-cause conclusion is available.
Reporting clocks should start from a defined awareness event and become shorter for more severe or widespread incidents. A staged process can send a prompt initial report, followed by verified facts and corrective actions. Do not delay notification merely to produce a polished narrative. Internally, route the report to engineering, security, legal, operations, and affected service owners. Externally, use the authorities and downstream recipients required for the jurisdiction and role, while keeping an auditable record of what was sent and when.
Close the loop by converting incidents into controls. Monitor rates, subgroup outcomes, complaint volume, overrides, and distribution drift against baselines. Trigger rollback or exposure limits when thresholds are crossed, then verify remediation on held-out and live data. Each incident packet should include system and model versions, timeline, exposure denominator, detection source, severity, affected groups, causal confidence, containment, notifications, root cause, corrective action, owner, and follow-up date. A monitoring program succeeds when it changes the system, not when it merely accumulates dashboards.