Owner decision
Who owns the decision when an AI-assisted action is wrong?
Name the business role operationally accountable for authorizing, monitoring, stopping, and repairing the AI-assisted action before use. The tool cannot carry that accountability. Legal responsibility may fall differently under contracts, governing documents, regulation, or law, so the incident record must identify the system, data, business, and legal authority involved.
Use this now: Use an AI incident map with decision owner, tool action, permission, failed check, affected party, containment, repair, and control change.
Owner worksheet
AI incident accountability record
| Check | Write down |
|---|---|
| Business decision owner | Who authorized the use and can stop or repair the business action |
| System and data owners | Who controls the tool, permissions, data, logs, and technical containment |
| Affected party | Who was harmed or exposed and what repair is owed |
| Authority check | Which policy, contract, law, or regulator defines legal responsibility |
Close the decision: Operational accountability must be named before use. Legal responsibility depends on the facts, governing documents, contracts, and applicable law.
Worked example
Illustrative AI-assisted wrong-action accountability receipt
Illustrative only: Hypothetical incident only; notification, privacy, employment, contract, and legal duties require actual policy and qualified review.
| Step | Illustrative input | Replace with your evidence | Completed test or status |
|---|---|---|---|
| Wrong action | Illustrative automation voids twelve invoices after an AI classifier labels them duplicates; four have no confirmed duplicate record. | Exact action log, invoice IDs, model/workflow version, and duplicate evidence. | The example is hypothetical; the action is treated as potentially wrong. |
| Decision and workflow owners | Operations director owns the use decision; automation lead owns workflow controls; controller owns invoice verification. | Approved RACI/decision-right record. | Accountability stays with people and organization, not the model. |
| Authorization failure | No human approval event exists for the void action even though policy requires one above the declared consequence class. | Authorization log and policy version. | Control failure is distinct from model-output error. |
| Containment and affected parties | Disable the void action, preserve logs, restore only from verified records, and identify customers/finance records affected. | Rollback receipt, reconciliation, and affected-party register. | Notification follows actual contract, policy, law, and qualified review. |
| Reuse gate | Do not restore automation until authorization, duplicate-proof requirement, rollback test, verifier, and monitoring pass on final bytes. | Mutation/rollback tests and approval receipt. | Decision: human-owned containment and repair before reuse. |
Decision produced: Hold the business decision owner, workflow owner, and verifier accountable for containment and control repair; do not assign responsibility to the AI system itself.
