Picture a customer service AI that did everything right. It stayed inside its guardrails. It respected its escalation thresholds. The human review it was meant to trigger happened. And the customer was still harmed: given an answer that was technically correct but wrong for their situation, or pushed through a process that met every rule and left them worse off.
Who owns that outcome? In most companies, the honest answer is nobody, because the question was never assigned. This article is about that gap, and how to close it before it becomes a dispute.
Most AI governance only covers the AI breaking a rule
AI governance, as most companies practise it, is built around rule-breaking. The guardrails define what the AI must not do. The monitoring watches for violations. The escalation paths catch the AI when it steps outside its limits. When something goes wrong, the review asks: which rule was broken, and how do we stop it breaking again.
That covers one kind of failure. It does not cover the other kind: the AI that broke no rule and produced a bad outcome anyway. When the review asks "which rule was broken" and the answer is "none", the process has nowhere to go. The harm is real, the customer is real, and the governance framework has no owner for it.
Why compliant harm happens
Compliant harm is not rare or exotic. It happens because rules are general and customers are specific. A guardrail says the AI may issue refunds up to a limit; it does so, correctly, for a customer whose situation actually needed escalation to a person. An escalation threshold is set for the average case; a customer outside the average falls just below it and never reaches a human. Every rule was followed. The rules were simply not written for this customer.
Kevin Davis, who writes KD Be Schemin, makes a related point about why governance has to be active rather than written down: the controls that matter are enforced at the moment of action, not filed in a policy. But even perfectly enforced rules only cover the situations the rule-writers imagined. Compliant harm lives in the situations they did not.
Accountability has to be assigned before deployment
The fix is not more rules. You cannot write a rule for every situation, and trying produces a framework too rigid to run. The fix is to name, before deployment, who owns the outcome when the rules were followed and the customer was still harmed.
This is prospective accountability: deciding the owner in advance, rather than discovering after an incident that no one holds it. The owner is a named person, not a committee, with two responsibilities. They own the customer-facing response when compliant harm occurs, the redress. And they own the feedback loop: every case of compliant harm is evidence that a rule was wrong for a real situation, and someone has to be accountable for feeding that back into the guardrails.
What the redress model looks like
The customer on the receiving end of compliant harm does not care that the AI followed its rules. They care that they were harmed and that someone puts it right. So the company needs a redress model decided in advance: how a customer harmed by a rule-following AI raises it, who reviews it, and how it is made good.
Without a redress model, compliant harm has only two endings. The customer gives up, and the company loses them quietly. Or the customer escalates outside the company, to a regulator or in public, and the dispute is litigated after the fact on someone else's terms. A redress model decided before deployment is what keeps the resolution inside the company's hands.
The case the framework forgets
A governance framework that only handles rule-breaking covers the easier half of the problem. The harder half, and the more common one, is the AI that followed every rule and still left a customer worse off. That case needs a named owner, decided before an incident forces the question.