Who's liable when your AI vendor gets breached

The AI vendor that screens the company's job applicants sends a note on a Friday evening: unauthorized access to a database. The data processing agreement has been signed for two years. Nobody yet knows if that piece of paper covers what happens next.

Carlos Andrés Ramírez · 2026-09-19

The AI vendor that screens the company's job applicants sends a note on a Friday evening: unauthorized access to a database. The data processing agreement has been signed for two years. Nobody yet knows if that piece of paper covers what happens next.

That Friday plays out the same way more than once: someone pulls up the data protection clause in the vendor contract, finds it, exhales, and then someone else asks who is supposed to call the regulator. That is where the relief ends. The contract states what the vendor must do. It almost never states what the company itself has to do in the meantime, on what timeline, or with exactly what information.

The confusion runs deeper than wording. Signing a data processing agreement with an AI vendor feels like pushing the risk outward. Legally, it barely moves anything. In front of the affected customer and in front of the regulator, the company is still the one that chose that vendor, handed over the data, and has to answer first, even when the failure happened three layers down, inside infrastructure it has never seen from the inside.

The symptom

Who is liable when an AI vendor suffers a data breach?

The short answer, and the one nobody wants to hear, is: the same party that would be liable if the breach had happened on its own servers. Frameworks like the GDPR treat the company that collects the data as the controller and the AI vendor as the processor, and that distinction does not change who has to notify the regulator or who faces the penalty once the deadline passes. The vendor may carry its own duty to disclose, but the company's clock does not start when it finds out. It starts when the vendor knew, and those two moments rarely line up.

• Nobody at the company can say, without calling the vendor, exactly what data that system held: names, emails, contracts, full histories.
• The contract caps damages at a few months of fees, far below what it actually costs to notify people and respond to a real incident.
• The legal notification deadline runs from the moment the vendor detects the problem, not from the moment it tells the company, and that gap eats whole days.
• Legal finds out mid-crisis that nobody ever wrote down who drafts and who signs the notice to the affected customer: the vendor, the company, or both.
• The company's continuity plan assumes its own systems can fail, but never considered what to do when the system that fails is an outside vendor holding part of its data.

The problem underneath

Why isn't a contract enough?

Because a data processing agreement describes a relationship under normal conditions, and a breach is, by definition, the abnormal condition nobody negotiated for. The confidentiality clause and the data protection clause exist so the vendor does its job well every ordinary day. They do not exist to tell the company what to do the afternoon that job goes wrong: who gets called first, with what information, and who pays for calling late or calling wrong.

And there is a piece almost no company has, and it only shows up once it's too late: an inventory of exactly what data goes to each AI vendor. Not the contract language about which categories it may process, but the actual list of what is flowing into that system today. Without it, the first hour after the notice gets spent figuring out how big the problem is, instead of fixing it.

A data processing agreement protects the vendor from being sued unfairly. It does not protect the company from having to answer first.

BECOME

The framework

What has to be decided before that email arrives?

Data inventory

The actual, current list of what data each AI vendor receives, not the generic category named in the contract. Without it, the first hour of any incident is lost figuring out what was even in there.

Vendor notice window

How many hours the vendor has to tell the company once it detects a problem, written as a number, not as "without undue delay." That legal phrase obligates nobody to move fast.

Who notifies whom

Who drafts and who signs the notice to the regulator and the notice to the affected customer: the vendor, the company, or both, and in what order. Deciding this mid-crisis costs twice the time of deciding it beforehand.

Liability cap

The financial limit the contract places on the vendor, measured against what an incident actually costs: notification, customer support, an external audit, a penalty if one lands. Most AI contracts set that cap far too low.

Containment plan

What gets cut first once the vendor reports an incident: access, data syncing, live integrations. Without this written down, the company decides under pressure and usually takes longer than the incident allows.

None of these five is an exotic legal clause. They are five operational decisions sitting buried inside a thirty-page contract nobody reopens after signing, one that only gets read closely on the day of the incident, when there is no time left to negotiate anything.

Pull the contract you currently hold with your main AI vendor and look for the notification window in hours, not days. If no number appears, you don't have an incident response agreement. You have a confidentiality clause wearing a different name.

Let's design your response framework