Want this content delivered right to your inbox?
Why accountability, not just capability, determines whether AI adoption earns lasting trust
Table of contents
Why accountability, not just capability, determines whether AI adoption earns lasting trust
Responsible AI adoption means giving every AI system in your organization a named owner, a defined review cadence, and guardrails sized to the harm it could cause if it fails. It is not a values statement posted on an intranet page. It is an operating discipline, and most organizations discover they do not have one only after something breaks. That discovery is no longer hypothetical. Two recent legal cases show what happens when an AI system does exactly what it was built to do and the organization around it has no one watching. Neither company lost because its model was broken. Both lost because nobody owned the decision the model was making.
Why Boards Are Asking About This Now
In November 2022, a customer asked Air Canada’s website chatbot about bereavement fares. The bot told him he could book at full price and apply for a refund within ninety days of travel, which was wrong. The airline’s actual policy required the request before travel. When the customer filed for the refund and Air Canada denied it, the case went to the British Columbia Civil Resolution Tribunal. Air Canada argued the chatbot was “a separate legal entity responsible for its own actions.” The tribunal rejected that outright, ruling that a company is responsible for all the information on its website, chatbot included, and ordering Air Canada to pay damages \[SOURCE: American Bar Association, Business Law Today, “BC Tribunal Confirms Companies Remain Liable for Information Provided by AI Chatbot,” February 2024 \- https://www.americanbar.org/groups/business\_law/resources/business-law-today/2024-february/bc-tribunal-confirms-companies-remain-liable-information-provided-ai-chatbot/\]. The second case is less about a model malfunctioning and more about nobody asking whether it should have been built the way it was. In 2023, the U.S. Equal Employment Opportunity Commission settled with iTutorGroup, a tutoring company whose AI-driven recruiting software was configured to automatically reject female applicants aged 55 and over and male applicants aged 60 and over. More than 200 qualified candidates were filtered out before a human ever saw their application. iTutorGroup paid $365,000 and agreed to anti-discrimination training and hiring oversight changes . The software had not malfunctioned. It applied the age thresholds exactly as configured. Nobody had reviewed whether those thresholds should exist in the first place. Both cases share a pattern that matters more than either individual ruling: the exposure lived in the human layer around the AI, not in the technology itself. That is the layer responsible AI adoption is meant to govern. Neither company was a startup moving fast and breaking things. Air Canada and iTutorGroup are established organizations with legal departments, HR departments, and presumably some version of a vendor review process. The gap was not a lack of process in general. It was a lack of process wrapped specifically around the AI system in question, at the moment it started making decisions that used to require a human.
What Responsible AI Adoption Actually Requires
Strip away the vendor marketing and the compliance checklists, and responsible AI adoption comes down to four conditions that have to be true at the same time. A named owner, not a committee. Every AI system in production needs one person accountable for its outputs, the same way a P\&L has an owner. A steering committee that meets quarterly is not an owner. An owner is the person who gets the escalation call at nine at night when the system does something wrong. A review cadence matched to how fast the system changes. A model that gets retrained monthly needs monthly review. A static rules engine that has not changed in two years does not need the same cadence, but it still needs one, because the world around it changes even when the system does not. Guardrails sized to the blast radius. A chatbot answering internal HR questions and a chatbot answering customer refund questions are not the same risk, even if they run on the same underlying model. The amount of oversight should scale with what happens if the system is wrong, not with how impressive the technology is. An escalation path that gets used. Both the Air Canada and iTutorGroup cases show what happens when the escalation path exists on paper but nobody exercises it before an outside party does. A guardrail nobody checks is not a guardrail.
Where Existing Frameworks Fit, and Where They Do Not
Two named frameworks come up constantly in AI governance conversations, and it is worth being precise about what each one actually does. NIST published its AI Risk Management Framework, known as AI RMF 1.0, in January 2023\. It organizes AI risk management into four functions: Govern, which builds the accountability and policy foundation; Map, which establishes context for a specific system; Measure, which tests the system against trustworthiness criteria; and Manage, which turns those measurements into prioritization and response decisions It is voluntary guidance, not a regulation, and organizations are meant to adopt as much of it as fits their use case. The EU AI Act takes a different approach: it sorts AI systems into four risk tiers, unacceptable, high, limited, and minimal, and attaches binding obligations to each tier. Unacceptable-risk systems are banned outright. High-risk systems require a full conformity assessment and ongoing monitoring. Limited-risk systems, like a chatbot that could be mistaken for a person, mainly require disclosure. Minimal-risk systems face no specific obligation. A third reference point, ISO/IEC 42001, works differently again. Published in December 2023, it is the first international standard written specifically for AI management systems, and unlike NIST’s framework, it is certifiable: an organization can bring in an accredited auditor and be certified against it, the same way companies certify against ISO 27001 for information security. It focuses on the management system around AI, risk assessment, system lifecycle controls, and oversight of third-party AI suppliers, rather than on any single model or deployment. For a board asking “how do we prove we are doing this responsibly to an outside party,” certification is the lever NIST and the EU AI Act do not pull. Three different tools, three different jobs: NIST gives you a shared vocabulary and a voluntary process. The EU AI Act gives you binding legal obligations if you operate in or sell into Europe. ISO 42001 gives you something a customer or regulator can independently verify. None of them, on their own, tells an organization who owns the chatbot on its refund page. In Voltage Control’s facilitation work with organizations building out AI governance councils, the question leaders ask first is almost always which framework to adopt. That is the wrong first question. NIST’s framework and the EU’s risk tiers are both checklists for a decision-making system an organization still has to design and staff. Neither one tells you who owns the chatbot on your refund page. Neither one runs the review meeting. The framework is the vocabulary. The four conditions above are the operating system underneath it.
Common Pitfalls Teams Hit
A handful of patterns show up repeatedly in organizations trying to stand up responsible AI adoption after the fact rather than from the start. Governance gets treated as a one-time audit instead of an ongoing practice. A single risk assessment at launch does not account for a model that gets retrained, a vendor that changes its underlying system, or a use case that quietly expands past what was originally reviewed. The assessment goes in a binder. The system keeps changing. Eighteen months later, nothing about the original sign-off still describes what is actually running in production. Ownership sits with the vendor relationship, not the outcome. Someone owns “the chatbot contract,” tracking renewal dates and per-seat pricing. Nobody owns “what the chatbot tells customers,” which is a different job entirely and the one that actually carries legal exposure. That gap is exactly where Air Canada lost: someone almost certainly owned the vendor relationship. Nobody owned the accuracy of what the bot said on a bereavement policy page. Shadow AI usage outruns the official rollout. Employees adopt AI tools faster than any governance process gets built for them, so by the time a formal review exists, half the organization has already found workarounds using tools nobody vetted, on data nobody classified. Governance built only for the sanctioned tools misses most of the actual exposure. Guardrails get set once and never revisited against the system’s actual blast radius. A tool that started as an internal drafting aid quietly becomes customer-facing, embedded in a workflow nobody flagged as a scope change, and nobody re-scores the risk. The system’s blast radius grew. The oversight around it did not. The teams that recognize their organization in more than one of these patterns are not behind because they moved too fast on AI. They are behind because the governance layer was designed for the systems they had eighteen months ago, not the ones running today.
A Practical Starting Point for Leaders
Standing up responsible AI adoption does not require solving all of this at once. It requires a sequence. Step 1: Inventory what is actually running. Before assigning owners or setting review cadence, list every AI system currently in production or pilot, including the ones employees adopted on their own. You cannot govern what you have not counted. Step 2: Assign one accountable owner per system. Not a committee. A name, tied to the outcome the system produces, not the vendor contract that procured it. Step 3: Score each system’s blast radius. Rank systems by what happens if they are wrong, not by how sophisticated they are. A customer-facing chatbot with policy authority outranks an internal drafting tool even if the internal tool uses a more advanced model. Step 4: Set a review cadence tied to each system’s rate of change. Systems that retrain or get reconfigured frequently need frequent review. Static systems still need a review date, just a less frequent one. Step 5: Build the escalation path before you need it. Decide, in writing, who gets notified when a system produces a wrong or harmful output, and what happens next. Test that path once with a hypothetical before you find out it does not work during a real incident. Step 6: Put a date on the next review, for every system, before you close this out. The inventory in step one is only useful if it gets revisited. A governance effort that ends with a document instead of a standing calendar invite tends to look, in eighteen months, exactly like the pitfalls above. None of these steps require a large team or a new department. They require a decision about who is accountable, made before the system ships rather than after a tribunal or a regulator makes it for you. Responsible AI adoption is not a slogan for the leaders who get this right. It is the difference between an AI program that scales because people trust it and one that stalls the first time it produces a headline. If your organization is past the pilot stage and still figuring out who owns what your AI systems say and do, that is the conversation worth having now, before an outside party has it for you. Voltage Control’s facilitation team works with executive teams to design exactly this kind of AI governance structure, from ownership models to review cadence to escalation design. Book a free intro call with our facilitation team to talk through where your organization stands.
