The learner assigns governance decisions to an accountable authority and designs cross-functional collaboration and escalation when performance and harm indicators conflict

Accountability in AI governance belongs to someone with authority to act, not merely to everyone who attended a meeting. A data team may build the model, an outside company may supply infrastructure and a service officer may use the output, yet a named person must authorize purpose, use limits and stop thresholds. Map the sequence: propose a use case, assess impact, acquire data, design, test, release, monitor, respond to incidents and retire. For each stage record who performs the work, who owns the decision, who must be consulted and who receives notice. If a committee collectively 'owns' everything without a final decision holder, nobody may be able to stop a harmful service in time. A small RACI matrix exposes that gap: Responsible performs the work, Accountable owns the result, Consulted provides input and Informed receives the decision. Multiple people may work on a task, but assign one accountable owner for a specific decision so veto authority cannot vanish between teams. A contract does not simply transfer the deploying organization's accountability to its supplier. The supplier may owe documentation, testing support and incident notice, while the deployer still decides whether use is suitable in its own context and whether its staff can review output. These role labels describe an operating design for the example; they are not a universal statement of legal obligations in every jurisdiction. Different decisions need different expertise. For an application triage assistant, the product owner states the service objective, the data team tests group performance and rare cases, privacy specialists examine data rights, lawyers identify duties in the relevant jurisdiction, operations tests whether officers can override advice, and user researchers obtain affected people's perspectives. The point is not to

collect ceremonial signatures. Specify the question each function answers and the evidence it will provide. If a high-impact question remains unanswered, defer release or narrow use rather than treating silence as approval. Governance structure should reflect organizational scale and use risk. A small organization may use one owner and a periodic cross-functional review rather than a permanent specialist department, but still needs recorded decisions and escalation. A larger one may separate builders from independent reviewers to reduce incentive conflicts. Higher risk calls for stronger evidence before release and faster monitoring afterward. Copying an elaborate policy into a team unable to execute it is ineffective. Document actual capacity, then choose controls that can be tested. An escalation policy names a signal, response time and authorized actor. If an AI tool begins issuing automatic denials outside its approved purpose, the operations owner should halt that path promptly, preserve case records and alert the risk team to assess people affected. Investigation follows containment of continuing harm. A slight metric decline without direct harm may instead warrant a scheduled, bounded review. The response differs with actual or likely severity and reversibility. Do not turn every anomaly into the same incident script. Stress-test the responsibility map. If the product owner is absent, who can disable the tool? If the vendor withholds test information, who can suspend procurement? If the use changes from staff support to automatic decision, who requires a new impact assessment? An unanswered question means the gate is incomplete. Training should enable users to recognize tool limits, reporting channels, data they must not enter and ways to correct outputs. Test awareness with a scenario and the person's action, not only with a count of slides opened.