The AI Accountability Principle

Patterns Already In Motion

Consider these four scenarios. None of them is a real incident. Each scenario is written from a pattern likely to become common enough in enterprise AI use, that an executive reading this paper could recognize as a potential situation within their own organization.

Lead Capture Becomes a Privacy Incident: A marketing team needs a campaign-specific landing page that captures lead data, scores it, and writes qualified leads into their CRM. Historically this would have been a two- to three-month effort: a specification to engineering, resource request to IT, a security review, legal/privacy consultation, accessibility consideration, integration testing, and a change request. This time the team uses AI to build the landing page and supporting code. A campaign manager describes the goal and what the page should do. The AI generates the web form, the scoring logic, and new API endpoints with the CRM integration. The team ships the page to the public website. A choice made by the AI writes captured lead data into a CRM object accessible to another process outside the data-sharing terms the company has stated in its usage policy. The exposure results in a customer complaint. The team that built the page does not understand production system schemas. The teams that own production systems did not review the new API’s. The privacy officer learns about it from outside counsel.

A Fabricated Benchmark Reaches the Board: An FP&A analyst is preparing scenario models for a quarterly board meeting. The CFO asked for a sensitivity analysis of a proposed price increase. The analyst uses AI to compile competitor pricing benchmarks and assemble them into a clean comparison exhibit. The AI returns a confident, well-formatted table. One row cites a competitor’s gross margin and average selling price with a footnote attributing the figures to a recent industry report. The analyst includes the table in the deck. The CFO presents it. The board approves a pricing change informed in part by the comparison. Two quarters later, a strategy consultant working on an adjacent project asks the analyst for the source of the benchmark. The industry report exists. The figures attributed to it do not. The pricing change has been in market for six months.

Months of Incorrect Billing & Invoices: A developer is implementing a field-level discount calculation in the billing service. The change is small. The AI proposes an implementation plan. The developer reviews and approves it. The AI completes implementation, creates a pull request, and a teammate approves it. In production, the calculation works correctly for most customers. For customers on a legacy contract the AI was not made aware of, the code silently calculates an incorrect service total. The pattern was discovered by a customer’s accounts payable team, which disputed the charge. By the time the engineering team identified the issue, three months of billing had been affected.

AI RIF List Fails Adverse-Impact Review: An HR business person is preparing material for an upcoming reduction in force (RIF). They use AI to analyze performance reviews, tenure, role criticality, and recent project assignments to produce a recommended personnel reduction list. The list reaches the executive sponsoring the labor force reductions. The executive asks for two changes and approves. An HR staff member runs the standard adverse-impact analysis on the final list before announcement. The analysis flags a disparity by protected class that did not appear in the executive’s review, because the executive reviewed a list whose composition was determined before the analysis ran. Legal pauses the announcement. The reduction proceeds late, negatively affects quarterly operating performance, and requires an internal investigation into how the analysis was constructed.

Different business functions, different consequence categories: regulatory exposure, decision integrity, financial accuracy, and employment law. Four different combinations of organizational role-holders who would normally have been consulted and were not. The AI use cases are different in each scenario, the failure modes are different, and the remediation paths are different. What’s consistent is the question we should all be asking, “Who has accountability when AI is the main actor in the workflow and side steps the organizational role-holders?”

In each scenario, the work performed routed around several organizational role-holders, domain experts who would historically have been part of the workflow, would have reviewed the artifact, or would have provided input the final product depended on. In the first scenario, those role-holders included engineering, security, privacy, accessibility, and change management. In the second, they include FP&A leadership and the data analyst function that vets external sources. In the third, they include the architecture, quality assurance, and database administration whose job it is to know which customer objects sit outside the normal data pattern. In the fourth, they include the HR analytics function who may be required to run protected-class analysis before, not after, an employee list has executive approval. The role-holders bypassed are different in every case. The fact that role-holders were bypassed is the consistent theme here and the subject of this Policy document.

The Policy document does not claim that AI knowingly did something wrong. The observations and real-world experiences are that AI compresses multiple steps in a cross-functional workflow into a single process, initiated by an employee or in an automated process. When something went wrong in each of our scenarios, responsibility cannot transfer to the tool, it remains with the human roles the org chart already codified. The org chart is what customers, courts, regulators, and boards refer to when something goes wrong.

This is the issue this Policy attempts to address. Stated as a principle, the AI Accountability Principle reads as follows:

AI does not respect organizational structure. When an employee entrusts AI to perform cross-functional work, the role-holder(s) who would normally have been included or consulted is bypassed but the responsibility for the outcome cannot be placed on the organization’s AI system.

Before stating the principle in an operational form, this chapter explores two of the most common defenses organizations attempt and that have failed when an AI workflow caused unexpected organizational damage. Understanding why those defenses fail is the foundation on which the AI Accountability Principle, and everything that follows from it, rests.

Why “AI Gave Me the Answer” Is Not a Defense

When an AI-assisted action causes harm, the first defense an employee reaches for is a version of “but the AI told me”. This is a sympathetic instinct. It follows the unfortunate pattern of redirecting responsibility to other sources: the analyst who allowed AI to use an untrusted system of record, an engineer whose AI made calls to an external party’s API. In these cases, the relying party is usually not the sole bearer of consequence. The relied-upon resources share some culpability. The “AI gave me the answer” defense extends this familiar logic to AI output. It assumes that because the AI produced a convincingly confident answer, the human’s duty of care had been partially or completely satisfied by the act of consulting the tool.

The case that established the failure in clear terms is Mata v. Avianca, decided in the Southern District of New York in 2023. An attorney was opposing a motion to dismiss in a personal injury case. He used a general-purpose chat assistant to draft his brief. The brief cited federal court decisions in support of his client’s position, complete with case names, citations, and quoted passages from the opinions. None of the cited decisions existed. The chat assistant had fabricated all of them.

When opposing counsel could not locate the cases and the court raised the issue, the attorney returned to the same chat assistant and asked if the cases were real. The AI chat tool confirmed they were. It added that they could be found on Westlaw and LexisNexis. The attorney filed this confirmation with the court.

The judge imposed a $5,000 sanction on the attorney, his colleague, and the firm. The attorney testified that he had been “operating under the false perception that this website could not possibly be fabricating cases on its own.” The court did not accept this as a basis for relief. The AI chat’s vendor was not a party to the sanction. The duty of professional verification belonged to the attorney.

The case is often cited as a hallucination story. It is also something larger. It is the working example of what happened when a professional treats conversational AI as if it were a trustworthy system. The attorney did not fail because the AI was intentionally deceptive or because his judgment was unusually lax. He failed because he asked the AI to verify itself, and the AI did what conversational AI typically does: it produces another fluent, confident response. To be fair, as of the writing of this Policy paper, the frontier model companies have been working hard to reduce or remove this well-documented behavior from their models.

Three things we must take from this 2023 case however. First, using AI does not transfer the user’s duty of care to the tool. The duty stays with the user. It also stays with the role-holders beyond the user in the org chart if the output side-stepped their domains. The “AI gave me the answer” defense fails because the duty of ensuring accuracy was never the AI’s to begin with. Responsibility does not transfer to a technology that cannot be held responsible, even one that claims intelligence.

Second, the verification step is the user’s responsibility, and verification has a specific meaning. Verification means checking the output against an authoritative source separate from the AI. A conversational AI asked to verify its own output produces another conversational output. Users must not assume that conversational AI even has the ability to check external sources. Primary source documents, an authoritative database, a subject-matter expert, an independent system of record are valid verification. The Mata attorney’s testimony, that he believed the website could not possibly be fabricating cases, was the precise mistake the Policy must prevent: it conflated a conversational system with an authoritative system, and it accepted self-confirmation as evidence.

Third, the user’s belief about the tool’s reliability does not change or eliminate a “standard of care”. An attorney’s duty to verify citations is a duty regardless of what tool produced the citations. An analyst’s duty to verify the source of a benchmark is the same. A developer’s duty to test code against potential edge cases that matter to the business is the same. The introduction of AI into any business workflow does not relax the standard because of the tool’s claimed intelligence. The standard must still be met by a real person, and a real person will be held responsible.

The Limits of “Separate Entity”

The second defense to explore is the organizational analogue of the first. When an AI tool causes harm to a customer or other party, the organization may be tempted to argue that the AI is a separate actor; that its outputs are of its own design, that the organization should not be held responsible for AI’s output. The defense attempts to follow patterns of external liability. Companies regularly disclaim responsibility for the actions of independent actors, for the failures of vendors, and for the behavior of automated systems they did not build. The “separate entity” defense extends this logic to AI deployed by the organization.

The defining case in a customer-facing context is Moffatt v. Air Canada, decided by the British Columbia Civil Resolution Tribunal in 2024. A customer used the airline’s customer-facing chat assistant to ask about bereavement fares. The chatbot told him he could book a full-priced fare immediately and apply later for a bereavement refund within ninety days. He did so. When he submitted the refund request, the airline refused it. The airline’s actual policy did not permit retroactive bereavement claims. The chat assistant misled the customer regarding the airline’s policy.

The airline’s defense in the tribunal is perhaps the cleanest statement of the “separate entity” argument on record. The airline argued that the chatbot was “a separate legal entity responsible for its own actions” and that the customer should have verified the chatbot’s response against the policy page elsewhere on the website. The tribunal rejected both arguments. It held that the chatbot tool was an extension of the airline’s website, that the airline owed customers a standard of care for information presented anywhere on its site, and that it was reasonable for the customer to rely on the chatbot’s response. The airline was ordered to pay damages.

The case is small in financial terms. The principle the case establishes is significant. A tribunal in a regulated jurisdiction has stated explicitly that for accountability purposes, an AI tool deployed on a company’s website is part of the company. The tool cannot be treated as a separate entity that the company hosts. The customer’s reliance on the tool’s output is a reasonable reliance, and the company owes the same standard of care for AI-mediated interactions that it owes for human-mediated ones.

There are three lessons to take away from these cases. First, an AI tool deployed by an organization is an extension of the organization for accountability purposes. Any technical separation between the tool and the rest of the organization’s systems is not a legal separation. The tool is part of the organization in the way that any other system the organization runs is part of the organization. This is true regardless of whether the tool was built internally, procured from a vendor, or assembled from multiple vendor components.

Second, the organization owes the same duty of care for AI-mediated interactions that it owes for human-mediated ones. A customer reading an AI-generated response on the company’s website is owed the same accuracy that the customer would be owed if a human representative had given the response. A job applicant being screened by an automated system is owed the same legal protection against discrimination as an applicant screened by a human recruiter. The medium does not change the duty.

Third, procurement of a tool does not insulate the organization. Misconfiguration does not insulate it. The vendor’s terms of service, the vendor’s public statements about responsible AI do not insulate the organization. The organization chose to deploy the tool. The organization is responsible for what the tool produces. The customer or the regulator or the court does not have to resolve the vendor question to hold the organization responsible. The organization has to resolve the vendor question on its own time.

Why Existing Frameworks Are Not Enough

A reasonable reader, having followed the two preceding sections, might ask why this Policy should state an operating principle at all. Organizations have accountability frameworks. Courts and regulators have demonstrated precedence in how they will rule. The cases are already on record. If the standard of care is unchanged by the introduction of AI, what does an Enterprise AI Policy add? Why now, and why state any principle for us to operate from?

The answer is that along with the confidence-inspiring output AI can create, AI can side-step the conditions under which existing organizational accountability frameworks were designed to operate. The frameworks themselves are not obsolete because of AI. The assumptions on which these frameworks rest are, and that is why they are not enough.

Consider the following usages of technology within an organization today. Workplace automation expands the productivity of a domain’s role-holder doing a specific job: a configuration management tool extended the number of servers a systems administrator could manage. Data analytics extends a data scientist’s ability to provide new business insights. A CRM extends individual deal data into accurate, high-level regional and global forecasts for Sales leaders. In each case, a domain-specific role-holder remained in the loop. The organizational accountability framework worked because the framework’s assumptions still held: the work was being done by the role-holder, the domain expert, or by someone under the role-holder’s direction, with the role-holder’s awareness.

Generative AI assistants and retrieval-augmented systems are different in kind. They act as domain experts but lack any authority. Any employee can use them to do work that would previously have required a specialist, or at a minimum, someone with experience in the role. The general-purpose, natural language nature of the tools, and their ability to reflect what is appropriate for the requested task, is what makes them attractive and popular. Yet, the rate of output capability by design, bypasses the purposeful and protective paths the org chart provides.

Agentic systems extend this even further, they take actions in the world. They send messages, modify records, call APIs, produce changes at speeds and volumes that exceed human capability. A traditional automation system that misbehaves is often corrected during the interactive session by the functional user that owns it. An agentic system that misbehaves can produce hundreds or thousands of actions before any function that owns it knows there’s a problem.

This produces a condition that existing accountability structures were not designed for. Work from AI that affects the organization is being produced and executed outside the traditional consultative paths of the org chart, and at a pace that does not allow those paths to effectively maintain control. Most organizations already have accountability frameworks: RACI matrices identifying who is responsible, accountable, consulted, and informed; approval hierarchies; audit trails; compliance reviews. These frameworks are good and they work, but they share an assumption AI is not bound to and knows nothing about.

The assumption is that the work is being done by the role-holder identified in the framework, or by someone under the role-holder’s direction. The frameworks assume the people doing the work know who the role-holders are and route work through them. They assume consultative paths exist as part of the workflow. When the work is being done by an employee using a tool that the role-holders did not select, configure, or supervise, the framework’s assumptions break. The RACI matrix still names the right people but the work AI performs no longer passes through them, so the controls the framework relies on are not triggered.

This is what the Accountability Principle in this Policy restores. By stating that role-holder authority and responsibility are not changed by the introduction of AI, the Principle re-attaches the existing accountability framework to the work that is actually happening. The framework continues to apply. The role-holders continue to own their domains. The introduction of AI does not redraw or negate the org chart, and any operational policy that follows from the Principle must reinforce, not concede that point.

The cost of not stating the Principle is also worth naming directly. Without it, organizations default to vendor and tool-level governance. They choose the products. Admins set policies in admin consoles. Users receive training, run exercises, and supervisors write acceptable use policies. All of this is necessary, yet none of it is sufficient for use with AI. These address what the tools do. They do not address who is responsible for what the tools produce. The four scenarios in the beginning of this chapter each contained that ambiguity. In each case, the employee using the tool would have said they were just doing their job faster. They were also, in each case, doing several other people’s jobs at the same time, without the consultation that could have prevented or reduced any harm done.

The Accountability Principle states this directly so that the question of ownership cannot be avoided. The Principle does not assign new responsibility. It refuses to allow the existing responsibility to be moved, side-stepped, or usurped.

The AI Accountability Principle

The principle reads as follows.

AI is a technology tool, not a delegate. As with all other technologies, accountability for the output of an AI system is attached to the human who used it, to the role-holder accountable for the domain it affects, and to the organization that deployed it.

The first sentence handles the categorical work. It places AI alongside every other technology the organization deploys. It ensures AI is removed from the category of human agents to whom work, outcomes, and responsibility can be delegated. A delegate is someone to whom the task is transferred. The distinction is intentional, it is operational. It determines who, not what, can be named when something goes wrong.

The second sentence establishes the unavoidable requirement of joint accountability. It dictates that legal and operational liability for an AI system’s output rests simultaneously across three tiers: the individual operator, the domain custodian, and the deploying organization. These obligations are concurrent and non-delegable. An employee is not absolved from negligence because internal domain expertise exists elsewhere. Domain custodians are not relieved of their oversight duties because an automated process bypassed them. Finally, the deploying organization cannot extinguish its ultimate liability by asserting a defense of third-party vendor reliance.

We now see three corollaries surfacing as a result of the Principle: operational consequences, legal consequences, and structural consequences. Each claim is revealed and discussed below, and may appear in later chapters of this Policy.

The first claim concerns review authority. Domain custodians must retain review and veto authority over AI-assisted work products involving their domain, regardless of who used the AI tool. This corollary is the operational consequence of the principle inside the organization. If the HR function is accountable for the legality of workforce decisions, the HR function requires review and veto authority over AI-assisted workforce analyses regardless of which team produced them. If the legal function is accountable for the soundness of legal positions, the legal function requires review and veto authority over AI-assisted legal drafting regardless of who or what initiated the drafting. This corollary applies wherever AI-assisted work crosses into a domain whose role-holder structurally owns the outcome.

The second claim concerns organizational disclaimers. The organization cannot disclaim responsibility for the behavior of AI tools it has deployed, regardless of how those tools were procured, configured, or marketed. This corollary is the direct consequence of the cases discussed previously. Procurement, configuration, or vendor terms of service do not insulate the organization. Even vendor public statements about responsible AI do not insulate the organization. As it has always been the case, the organization is responsible for what it deploys and the outcomes of those systems. The corollary addresses the “separate entity” defense at the policy level so that this defense is discouraged by the organization after an incident occurs.

The third claim concerns the accountability structure itself. The accountability structure of the organization, who is responsible for what outcome, is not modified or nullified by the introduction of AI tools. The org chart defines, governs, protects, and determines responsibility. This corollary is the structural consequence of the principle. It is a refusal of any argument that AI tools warrant a new accountability category outside the existing structure. Since AI projects are found within, and not external to, existing organizational structures, there is no separate AI accountability. There is the existing accountability, applied to AI-assisted work.

It is also useful to state and understand what the principle does not say, because each of these clarifications will prevent misreading future chapters that would otherwise have to be defended against repeatedly.

1. The principle does not say AI cannot be used for consequential work. It says the consequential work must still route through the role-holders and domains accountable for the outcome. The presence of AI in the workflow is not the issue. The absence of consultation, review, and veto with the accountable domain custodian is.

2. The principle does not say every AI output requires human pre-approval. It says the policy distinguishes outputs, and applies appropriate levels of review. A blanket pre-approval requirement would be unworkable and slow down the efficiencies expected through AI’s usage. An absence of any requirement would be a failure of governance and the policy. The middle ground, via calibrated review thresholds, is where the operational work lives.

3. The principle does not say AI tools are untrustworthy. It says placing trust in a tool does not transfer responsibility from the human or the organization to the tool. A tool can be reliable and the user can still be responsible. A tool can be unreliable and the user is still responsible. The principle is silent on the question of how trustworthy any specific tool is, because the answer to that question varies by tool, by its configuration and management, and its reliability over time. Chapter 4 takes up the trustworthiness question through a tiered framework that calibrates the degree of harness around AI to the kind of work the AI tool is being used for.

The principle answers one question definitively, “Who is responsible for the outcome when AI is in the workflow?” The same parties would have been responsible if AI were not in the workflow: the human or humans who used it, domain custodians, and the organization that deployed it. The answer does not change with AI because it proclaims to possess adjacent human intelligence. It is a technology tool and cannot be a delegate for responsibility.

Applying The Principle

Stating the principle and its corollaries feels like academic work. Showing what’s required by the policy in a deployment resembling current enterprise practices is not. Consider a deployment whose architecture is increasingly common: a customer-facing operational agent that runs on a tech stack involving three distinct technology parties and the enterprise.

A foundation model provider supplies the model reasoning, inference, and agent capabilities. A platform vendor supplies the runtime on which AI agents can execute, the tools that can be called, and the surface through which they interact with customers. Next is a governance vendor supplying an overlay that is designed to monitor agent behavior, log decisions, and flag anomalies for human review. The deploying enterprise configures the agent for its specific customer-facing functions: billing inquiries, claim handling, return processing, scheduling, or some equivalent customer-touching workflow. The enterprise designs the agent to take defined actions on the customer’s behalf. The three technology parties are technically distinguishable. Each is also contractually distinguishable. All of them most likely have public statements about how each supports responsible AI usage.

In our deployment, the agent takes an action that was within the scope the enterprise authorized, and harms a customer. The platform’s runtime executed the action. The governance overlay did not flag the action, either because the behavior did not match the overlay’s anomaly patterns or because the patterns were not tuned for this kind of harm. The customer wants to know who is responsible.

The Accountability Principle resolves the question without ambiguity. The deploying enterprise is accountable to the customer. It deployed the tool. The tool acted within the scope the enterprise authorized. The customer’s counterparty in any complaint, claim, or regulatory action is the enterprise, not any of the vendors in the stack. The vendors may be the right targets for some of what follows from the incident; root cause investigation, contractual claims, indemnification, but the customer is not in a contractual relationship with anyone but the enterprise. The enterprise’s obligations to the customer are owed in full regardless of which vendor’s component produced which part of the failure.

Inside the enterprise, the role-holder accountable for the outcome would be the most senior role-holder responsible for the customer-facing function in which the agent operates. The fact that the agent was built and run by a different function inside the enterprise does not transfer full accountability to that function. The agent acted in the billing or claims function, and that function’s leadership shares in its outcomes whether the work was initiated by humans, by AI, or by a combination of both.

The illustration demonstrates two things carried forward into later chapters: the accountability question is tractable even in deployments with many parties. The principle does not require the deploying organization to resolve every technical question about how the harm occurred before accepting responsibility for it. The organization is responsible because it deployed the tool. The internal investigation, contractual recourse, and the technical root cause are all important, but none of them is a prerequisite to understanding accountability. Accountability is the starting point. Everything else is what the organization does following the position of having accepted it.

This is also why the principle has to be stated first, before the chapters that follow. Chapter 4 will specify a trust and harness framework that helps the organization decide which AI deployments are suitable for which kinds of work, with deployment tiers ranging from open-ended chat to purpose-built agents and skills with explicit harness instructions. Chapter 7 will specify the consultation thresholds that determine when role-holders must be involved before AI output becomes consequential.

The Foundation for What Follows

This chapter has covered six important concepts that are foundational to understanding why this Policy exists. The four hypothetical, but increasingly possible scenarios in Section 1 showed how AI workflows can route around the role-holders an organization already relies on. There are visible patterns when using AI that cross functions, business contexts, and risk/consequence categories. Sections 2 and 3 addressed two defenses that organizations have already attempted and that have already been rejected by courts and regulators: the “AI gave me the answer” defense in Mata v. Avianca, and the “separate entity” defense in Moffatt v. Air Canada. Section 4 explained why generative and agentic AI requires the principle to be stated now, even though the standard of care it preserves is not new. Section 5 stated the Accountability Principle in two sentences, revealed three corollaries, and gave explicit clarifications of what the principle does not say. Section 6 illustrated the principle in a deployment scenario whose structure resembles both current and future enterprise practice.

Having stated the AI Accountability Principle, the chapter sets up what the rest of the policy will cover. Part II will present the operational requirements. It covers the trust and harness framework, tool selection and approval, data classification, decision rights, verification, audit trail, change management, incident response, training, and governance structure. Part III adapts those requirements to the work of specific business units, because the accountability questions look different in Engineering than in Sales, and different in Legal than in HR. Part IV adds in industry-specific overlays that healthcare, financial services, education, government, and critical infrastructure operators must demonstrate to their regulators. Part V translates all of it into an implementation sequence: a maturity model, a phased adoption plan, and a measurement program that an organization can put into practice without waiting for a complete rewrite of its existing risk and compliance program. This chapter is foundational by design. The prescription is given in the work of the chapters that follow.