Ask most organizations who owns AI-related risk, and the answer comes quickly. Risk does. Compliance does. Legal does. IT does. The vendor does. That last answer is more common than most leadership teams realize. Some organizations have genuinely concluded that because the AI system was built, trained, and delivered by an outside party, responsibility for what it produces travels with it. The answer is almost always a function or an entity outside the organization, rarely a person, and almost never the person making the decision the risk is attached to. That distribution of accountability feels comprehensive on an org chart. When an AI-influenced decision produces an adverse outcome, the question of who is responsible takes longer to answer than the question of what went wrong.
Air Canada learned this the hard way. When a customer asked the airline’s chatbot about bereavement fare policy after his grandmother died, the chatbot gave him incorrect information, telling him he could retroactively apply for a reduced fare within 90 days. He booked a full-price ticket based on that guidance. When he sought the refund, Air Canada refused. In the subsequent tribunal proceeding, the airline argued that the chatbot was a separate legal entity responsible for its own actions and that the company could not be held liable for information it provided independently. The tribunal rejected that argument entirely. The chatbot was part of Air Canada’s website. Air Canada owed the customer a duty of care. Air Canada was responsible for all information available through its systems, regardless of which system delivered it. The airline was ordered to pay. No individual clicked send. The organization deployed the system. The organization owned the consequence.
The tribunal’s ruling, however, only resolved the question the customer needed answered. It did not resolve the questions the organization needed to answer internally, and there are three of them, each belonging to a different layer of accountability.
The first is backward-looking. Who within Air Canada was responsible for the fact that a customer-facing AI system was deployed without accurate policy information, without guardrails that prevented incorrect guidance from being delivered with confidence, and without a governance structure that would have caught the gap before it reached a grieving passenger? The instinctive answer in most organizations is IT, because the chatbot is a technology, and technology belongs to IT. That answer is precisely the problem. Deploying a customer-facing AI system that makes policy representations is not a technology event. It is an organizational event that happens to involve technology, and treating it as anything less distributes accountability in a way that guarantees gaps.
Consider what a complete pre-deployment governance process would have required. Legal would need to confirm that the policy language loaded into the system reflected the most current and accurate version of the fare rules, not a prior version, not a vendor interpretation, not a summary written for a different purpose. Customer service would need to test representative interactions to verify that outputs matched actual policy in the conditions customers were most likely to encounter, including edge cases involving bereavement, illness, and other circumstances where policy precision matters most. Compliance would need to evaluate the risk profile of allowing an automated system to make binding-adjacent representations to customers without human review and determine whether the consequences of an error would fall within the organization’s documented risk tolerance. Engineers would need to design the conversation workflow with explicit decision points that triggered a human-in-the-loop flag when a customer query involved policy interpretation, financial commitment, or emotionally sensitive circumstances, rather than allowing the system to respond with uniform confidence regardless of query complexity. And someone would need to own the ongoing review of logged interactions, not just to detect errors after they caused harm, but also to identify drift between what the system communicated and what the policy actually required before a customer relied on the wrong answer.
None of those functions can substitute for the others. Legal can confirm the policy language without knowing how the system will interpret and deliver it under varied query conditions. Customer service can test standard interactions without anticipating the edge cases compliance would flag. Engineers can build a technically functional workflow without the policy expertise to know where human judgment is required. Compliance can evaluate risk categories without the operational knowledge to know which interaction patterns actually trigger them. Each function sees part of the picture. No function sees all of it. The governance structure assembles those partial pictures into a complete pre-deployment review, assigns ownership of each component, and ensures that no system reaches a customer until every function has answered its part of the question.
The second is present-looking. Once the failure was identified, who had the authority, the mandate, and the resources to investigate what went wrong, document the root cause, and ensure the finding entered the organization’s institutional memory rather than being resolved quietly and filed away? Fixing the immediate problem, correcting the chatbot’s policy information, is not the same as understanding why the error existed, how long it had been producing incorrect guidance, how many other customers received the same wrong answer, and what other gaps in the same system remain undetected. Without a named owner for that investigation, the organization satisfies the tribunal and learns nothing.
The third is forward-looking, and it is the one most governance frameworks never reach. Who is responsible for ensuring the conditions that produced the failure cannot produce it again? Not the same failure in the same system. The conditions: insufficient pre-deployment review, absent policy alignment checks, no mechanism for a deployed AI system to flag uncertainty rather than assert confidence, no cross-functional ownership of deployment decisions, and no feedback loop that would surface customer-facing errors before they become tribunal proceedings. Those conditions exist across systems, not just the one that failed. The owner of forward accountability is not the person who deployed the chatbot. It is the leader who is responsible for the governance environment in which the chatbot was deployed, without adequate safeguards. That person may not know they own that accountability. In most organizations, no one has told them.
When internal accountability is diffuse, undocumented, or assumed rather than assigned across all three layers, the organization can satisfy the tribunal yet leave every gap open. The customer is made whole. The system is patched. The conditions that produced the failure remain intact, unowned, and waiting.
That outcome contains the clearest possible statement of how AI accountability works in practice. The question is not which system produced the output. The question is which organization put that system in front of a customer and allowed it to make representations on its behalf. The name attached to the consequence belongs to the organization that made that decision, and that accountability does not transfer to the vendor who built the system, the platform that hosted it, or the technology team that configured it.
Risk ownership in AI governance is not simply a structural question. It is a question about where the burden of attention, preparation, and consequence actually falls in day-to-day operations. When that burden is distributed broadly across functions without clear assignment, it tends to fall on frontline employees making AI-influenced decisions without the authority, training, or organizational cover to push back against the systems they use.
The vendor deflection compounds this problem in a specific and consequential way. An organization that points to a vendor as the responsible party for AI risk has not transferred its exposure. It has removed its own capacity to manage it. Vendors build and deliver AI systems. They do not govern how those systems are used, what decisions they influence, or what happens to the people affected by those decisions. When an organization relies primarily on vendor representations to evaluate AI risk rather than developing independent judgment, it has ceded the very capability that governance requires. The system may belong to the vendor. The decision belongs to the organization. That distinction does not change when something goes wrong.
That misplacement of accountability is not accidental. It reflects how most governance structures are designed. Policies are written at the enterprise level. Accountability is assigned to functions. Oversight is documented in frameworks. The actual decisions get made by individuals who were not in the room when any of that was designed and who experience governance primarily as a constraint on their workflow rather than a resource they can use. The gap between where risk ownership is documented and where risk is actually encountered creates a burden that lands silently on people who never agreed to carry it.
A consistent pattern emerges across organizations that have examined this gap closely. Executives tend to report that accountability for AI-influenced decisions is clear, documented, and understood across the organization. Employees working within those same organizations describe something different: a lack of clear guidance, an absence of formal escalation paths, and a cultural environment in which raising concerns about AI outputs is more likely to create friction than to prompt action. The accountability leadership that is believed to exist is often experienced at the operational level as the assumption that someone else has handled it.
When leadership believes accountability is settled and employees experience it as absent, two things happen simultaneously. Real risks accumulate unaddressed because the people closest to them have no clear channel to surface them, and the people with authority to act have no clear signal that anything needs attention. When an adverse outcome eventually occurs, the accountability vacuum is exposed under the worst possible conditions: after a consequence rather than before it, in a context where someone will need to explain what governance was in place and whether it was actually used.
The burden-placement problem is most acute in frontline roles, where AI influence is most direct and decision authority is most constrained. A frontline employee using an AI-assisted tool to support a material decision, whether in hiring, credit assessment, clinical prioritization, or client-facing recommendations, may have no practical ability to challenge the output, no training to evaluate it, and no escalation path they believe will be taken seriously. The governance framework may address all of these gaps in principle. The frontline worker encounters none of those provisions in practice.
To illustrate, consider a financial services firm where AI-assisted scoring tools support loan recommendations. The organization has an established governance framework and documented oversight protocols. Frontline loan officers are expected to review AI-generated scores before approving or declining applications. In practice, volume pressures and throughput metrics make deep review rare. Officers follow AI recommendations in the majority of cases, not because they trust them unconditionally, but because questioning them creates delays, and delays create performance problems. When a discriminatory pattern in the scoring model eventually surfaces, the governance record will show that human review was required. It will not show that human review was genuinely possible given the conditions under which decisions were made. A name is attached to each approval. The conditions that shaped that approval are invisible.
Requiring review without creating the conditions for meaningful review shifts accountability to individuals without transferring authority, resources, or protection. The organization retains the governance documentation, and the individual absorbs the consequence. That arrangement does not reduce risk. It relocates it downward to the people with the least power to manage it and the least protection when something goes wrong.
Addressing this requires organizations to examine not only who is named as accountable in governance documents, but what the people carrying that accountability are actually equipped and empowered to do. The organizations that close this gap follow the accountability chain all the way to the decision point and ask honestly whether the person making the decision has what they need to make it responsibly. Leadership determines whether that question ever gets asked. When leadership treats accountability as a governance checkbox rather than a daily operational condition, the burden of AI risk settles on the people least able to bear it, and the organization calls that governance.