{
    "title": "Who Is Responsible for AI Actions? | XDALC",
    "description": "Identify responsibilities across AI design, deployment, permissions and oversight, so an automated decision does not leave affected people without answers.",
    "heading": "Who Is Responsible When an AI Acts?",
    "content": "<p>“The AI decided” describes part of an event, not a complete account of responsibility. An outcome also reflects the people who selected the system, configured its access, chose its operating context and decided how errors would be handled. XDALC treats these choices as part of the explanation.</p>\r\n<h2>Separate the system's task from human accountability</h2>\r\n<p>A system can be assigned operational duties: respect a permission boundary, disclose uncertainty or stop an unsafe action. Its ability to perform those duties should be evaluated. Assigning them does not remove the responsibilities of designers and operators for making them possible.</p>\r\n<p><a href=\"/definitions/responsibility-and-accountability\">Responsibility and accountability</a> include being able to explain relevant choices, investigate failures and support correction. This is an account of XDALC's governance approach, not a determination of legal liability in any jurisdiction.</p>\r\n<h2>Identify the decisions behind the outcome</h2>\r\n<p>Consider an assistant that sends a confidential file to an unintended recipient. The investigation should examine more than the final generated message. Who granted access? What authorization was required for transmission? Which controls checked the destination? Were the limitations known? Could the user see what was about to happen?</p>\r\n<p>Different actors may control different parts of the chain. A model provider, application developer, deploying organization and authorized user need not have identical duties. Their roles should be made explicit instead of assigning all blame to the least informed participant or to the model alone.</p>\r\n<h2>Give responsibility practical form</h2>\r\n<ul><li>Name an operational owner for the deployment and a route for reporting problems.</li><li>Document the system's purpose, permitted actions and material dependencies.</li><li>Assign authority to interrupt unsafe activity and approve recovery.</li><li>Decide who investigates consequential failures and communicates corrections.</li><li>Review these arrangements when capabilities or access change.</li></ul>\r\n<p>A name on a document is insufficient if the person lacks the access, time or authority needed to act. Accountability depends on a workable arrangement, including escalation when the immediate operator cannot resolve a problem.</p>\r\n<h2>Keep distributed work understandable</h2>\r\n<p>When one agent delegates to another, the chain of responsibility should remain reconstructable. A consequential action needs a traceable mandate, not simply a record that several systems agreed. Contracts or technical boundaries between providers should not make it impossible for an affected person to find a meaningful point of contact.</p>\r\n<p>Records should be proportionate. Understanding a permission failure may require a task identifier and relevant authorization, not a permanent copy of every private interaction. Oversight should respect the same information boundaries it is intended to protect.</p>\r\n<p>The preamble and Articles 2, 14 and 15 of <a href=\"/versions/xdalc-v002\">proposed XDALC-V002</a> ground this interpretation. Read alongside <a href=\"/definitions/human-oversight\">human oversight</a>, <a href=\"/definitions/delegation\">delegation</a> and the <a href=\"/implementation\">implementation guides</a> when translating responsibilities into an actual deployment.</p>",
    "license": "https://creativecommons.org/licenses/by/4.0/"
}