Who is harmed and who is accountable

Ethics and responsible AI · Lesson 2 / 22

Accountability is not shared with the model

The first sentence at an incident review is «well, the model produced it». That is not an explanation. The organisation chose the vendor, the use case, where to put a human, and what not to check. Every one of those calls was made by a person with a job title. The organisation is accountable, whoever wrote the code.

Two roles that get confused constantly

The harmed party is whoever the consequence lands on. Often not your customer at all: the candidate you screened out, the person in the generated video, the payee whose transfer you froze.
The accountable person is whoever can stop the use case and whose bonus depends on the result. If no such person exists, the use case is ownerless and nobody will run the incident review.

Separate four positions for every use case: product owner (accountable for the use case existing at all), decision owner (approves thresholds and rules), operator (presses the button), reviewer (samples outputs afterwards). One name may hold two positions, but none may be empty.

Accountability matrix per use case
Use case: ...................................
Product owner:        name, title
Decision owner:       name, title
Operator:             role / team
Quality reviewer:     name, review frequency
Who can stop it:      name + how technically (flag, access, button)
Response time to a complaint: ... working days

Insight. The line «who can stop it and how technically» catches more problems than the rest of the document. It repeatedly turns out that only one engineer can stop the system, they are on holiday, and no kill switch exists.

A separate trap is distributed non-accountability along the supply chain. You bought a service, the vendor bought a model elsewhere, that vendor runs on someone else's infrastructure. Every contract says they merely «provide a tool». The harmed person still comes to you: your logo was on the rejection letter.

Common mistake. Naming «the AI team» or «the data office» as accountable. A team does not sign a decision, does not testify and does not bear consequences. An accountable party is a person with a name and the authority to stop the use case.

Pro tip. Stress-test the matrix with one question: «it is Friday evening, a customer posts a screenshot of the system failing — who gets called first, and who has the right to switch it off?» If the second half has no answer, the use case is not ready to launch.

Cheat sheet

A model is not an accountable subject; the organisation that deployed it is.
The harmed party is often not a customer — remember candidates, payees, third parties.
Four positions: product owner, decision owner, operator, reviewer.
Without a technical way to stop the system, accountability is nominal.

1. Why does «the model decided it» fail as an incident explanation?

2. Which harmed parties are most often left off the list?

3. What makes accountability real rather than nominal?

Task — checked by AI

Take one live or planned AI use case in your organisation and fill in the accountability matrix: product owner, decision owner, operator, reviewer, who can stop it and by what technical means, response time to a complaint. Separately list everyone who could be harmed, including people who are not your customers. State which positions are currently empty and what you will do to fill them.

← Back

🔒 Answer the question correctly to move on to the next lesson.