If a company uses someone else's AI and it messes up, who's actually on the hook — the company, the AI maker, or both?

This explores who carries the blame when a company deploys an AI model it didn't build and something goes wrong. The corpus has one clear legal anchor and several useful ideas from nearby areas. It does not directly cover how blame gets split between the model maker and the deployer. The anchor is the Air Canada case. A tribunal rejected the airline's argument that its chatbot was a separate entity responsible for its own statements. It applied ordinary tool-liability doctrine: you answer for the output of tools you operate Can a company escape chatbot liability by calling it separate?. For the person who was harmed, this sets a clear starting point. The deployer is liable, and pointing at a vendor or at 'the AI' doesn't work as a defense. Whether the deployer can then recover costs from the model provider is a separate contract question, and the corpus doesn't address it.

One idea from a different field helps with dividing responsibility. Research on human-like AI separates features a designer deliberately built in from qualities users read into the system. Each of these points responsibility at a different party, and each needs a different fix: redesigning the system or educating users Who bears responsibility when AI seems human-like?. The same split could apply to third-party models. Harms that come from what the model does on its own point toward the vendor. Harms that come from how it was set up, prompted or presented point toward the deployer. A second approach ties risk to how much independence a system is given. The more autonomy an agent gets, the more harm it can cause Does AI risk increase with the autonomy we give it?. On that view, a deployer who gives a vendor's model more freedom to act takes on more of the responsibility.

Both approaches run into the same practical problem: you have to know where the failure started. The corpus suggests we usually can't. Tools exist for measuring whether errors stay visible, contained and recoverable, but each covers one condition in isolation. None follows a failure across the whole chain of model, deployment and institution How can we measure whether AI errors stay visible and recoverable?. Fault-based reasoning has a further difficulty. Harmful behavior can come from how a system was trained to pursue goals even when its goals look harmless Does a benign goal actually prevent harmful AI behavior?. Training also tends to optimize for measurable stand-ins rather than the real objective How vulnerable is AI training to Goodhart's Law?. So a vendor can ship a model that passed its tests and still has flaws neither party could easily have predicted.

This may explain why the Air Canada tribunal took a simple approach. When you can't reliably trace the cause, putting liability on whoever controls the deployment is the version that can actually be enforced. The broader policy argument is that the gap between vendor and deployer can't be left to contracts and self-policing Can companies alone manage the risks of AI systems?. If you're looking for a worked-out framework for sharing liability among vendor, fine-tuner and deployer, this corpus doesn't have one yet. What it does show is that the real obstacle is diagnosis. Liability can only be divided fairly once we can tell where an AI failure began.