What happens when your AI systems act up? Who is liable when these AI systems are violating AI regulations that you’re in scope for? Who is answerable when the regulators knock at the door? Is it the vendor that designed, trained, and provided the AI system, or the company that implemented those systems for their business contexts and presented the outputs to customers, employees, constituents, or the public? The short answer, I’m sorry, is the latter.

The relationship between AI developers and AI deployers is becoming increasingly important amid an aggressive AI push in the competitive market. Third-party AI tools are being employed to make or support business decisions, drive high-end operations, improve service to customers, and more. While vendors can and should be held accountable under contractual obligations, it is the deployers, who present AI-driven products and services directly to consumers and constituents, who are ultimately held liable by regulators. Given that, let’s explore the relationship between deployers and developers, examine the accountability expected of each, and identify steps that can be taken to ensure that accountability is upheld.

Carrying the Greater Risk

The recent Mobley v. Workday case is one of the most striking illustrations of the developer-deployer dynamic in the context of AI governance.  The case revolves around allegations of biased AI outputs. What makes it especially significant is the question it raises. When an algorithm drives outcomes, can the vendor be held liable under anti-discrimination laws? The court allowed the case to proceed under an “agent” theory of liability, finding that Workday’s software was not simply implementing a criterion in a rote way, but was instead actively participating in the decision-making process. In other words, both the developer (Workday) and the deploying organization share accountability, but the burden of regulatory and legal exposure falls most heavily on those who put the AI’s outputs in front of real people, with real consequences.

• Vicarious Liability: Under the foundational corporate law doctrine of respondeat superior, companies bear legal and financial responsibility for harm caused within the scope of their operations, and AI is no exception. This means that when a third-party AI tool causes harm, external lawsuits and regulatory action target the organization that deployed it, not the vendor that built it.
• You Cannot Blame the Tool: Courts have signaled that AI vendors can be held liable as “agents” of the deployer when their algorithms perform tasks traditionally handled by humans. This further blurs the line between tool and actor.
• Contractual Obligations are Limited: While vendors can be held accountable through contracts, regulators hold the deploying organization, and often specific individuals within it, directly responsible for AI-driven outcomes.

Turning Accountability into Governance

Firstly, it is important to accept the liability so that you can prepare accordingly. While deploying an AI system into your digital infrastructure, you need to be mindful of the accountability that regulators expect from your business. Here’s what to do next:

• Conduct a pre-deployment AI risk assessment: Before onboarding any third-party AI tool, evaluate it against the risk frameworks applicable to your business. Understand what category of decision the AI will be supporting (hiring, lending, customer service, operations) and how high-stakes those decisions are. Higher-stakes use cases attract greater regulatory scrutiny and demand more rigorous controls.
• Maintain an AI inventory: Track all AI systems used across the organization, including third-party tools. Shadow AI use cases and invisible AI agents can cause the most harm. Organizations cannot account for technologies they do not know they are using.
• Maintain defensible records: Keeping documentation of AI inventories, risk assessments, governance decisions, approvals, monitoring activities, and training efforts will not relieve you from your liabilities but still should help your case in demonstrating responsible AI governance.
• Establish ongoing monitoring and auditing protocols: Deploying an AI system is not a one-time event but an ongoing operational responsibility. Implement regular audits of AI outputs for bias, accuracy, and drift, particularly when the model is making or influencing decisions that affect employees, customers, or constituents. Document these audits too.

The Buck Stops with the Deployer

The developer builds the AI systems, but it is the deployers who put it to work. That distinction carries the real legal, financial, and human weight. Accepting that accountability will help businesses take the foundational steps towards responsible AI. The organizations that get this right won’t just stay out of trouble but lead the way.