Harms are not incidents
Organisations have incident processes, and AI harms mostly do not enter them.
An incident process is built around service disruption. Something broke, someone noticed, an alert fired, and a team responded. The defining property is that the organisation experienced the failure.
An AI harm frequently has none of those properties. The system worked as designed. Nothing broke. No alert fired. The organisation experienced nothing at all, because the cost fell entirely on someone outside it: an applicant who was ranked low, a customer whose claim was routed to a slower queue, a person a moderation system removed.
So the harm is invisible to every mechanism the organisation uses to detect problems. It will not appear in monitoring, it will not page anyone, and the affected person often does not know a system was involved and would not know where to complain if they did.
This is the structural reason responsible AI needs its own detection route rather than relying on existing operational processes. What is required is a definition of harm that does not depend on the organisation noticing, plus a channel that lets the affected person tell you.
Without both, a programme can run cleanly for a year while producing exactly the outcomes it exists to prevent, and report success throughout.

