When an AI system fails, the questions come fast.

AI fails in ways traditional systems do not

Conventional software breaks predictably — it crashes, it has a bug, it goes down. AI systems fail differently and often more quietly: they produce a discriminatory pattern of decisions, generate confident falsehoods, leak data they were trained on or fed, drift in behavior over time, or do something no one anticipated because no one fully understood the system's behavior in the first place. These failure modes create legal exposure that traditional software rarely does — discrimination claims, defamation or misrepresentation from false outputs, privacy violations, contractual breach, and regulatory liability under the AI-specific laws. Understanding that AI fails in distinct ways is the starting point for managing the risk, because you cannot prepare for or respond to a failure mode you do not recognize.

Who is liable when the AI gets it wrong

The instinctive answer — “blame the vendor” — is usually wrong, and that is the hard lesson at the center of AI liability. Regulatory obligations frequently sit with the organization deploying the AI, not the company that built it: under Illinois's employment-AI law, for instance, the liability for a discriminatory hiring tool generally runs to the employer. And the vendor contract, as the procurement page details, is typically drafted to push risk back onto the customer through liability caps and carve-outs. So when an AI system causes harm, the deploying organization often finds itself holding exposure it assumed the vendor would absorb. Mapping where liability actually lands — across the deployer, the vendor, and any intermediaries — is the analysis that determines who bears the cost, and it is far better done before an incident than during one.

Incident response: the first hours and days matter

When an AI incident hits, the response in the first hours and days shapes the legal outcome. The disciplined sequence resembles other incident response but with AI-specific dimensions: contain the issue and stop ongoing harm; preserve the evidence — logs, model versions, inputs, outputs, and the record of human oversight — because that evidence determines both liability and defense; assess what notification or disclosure obligations are triggered (to regulators, affected individuals, or contractual counterparties); and manage the communications and remediation. The organizations that handle this well are the ones that built the logging and oversight discipline in advance, because you cannot preserve an audit trail that was never created. This is precisely where defensible governance pays off — the controls that felt like overhead become the evidence that protects you.

Defense built on operational understanding

Defending an AI incident — or advising through one — requires understanding what actually happened inside the system, which is where genuine operational experience separates real counsel from guesswork. Adam approaches AI risk and incident response as someone who runs adversarial review protocols and a guardrails framework in his own production AI system, holds the AIGP credential, and understands how these systems fail because he has had to prevent and diagnose failures in practice. The difference between advising from a textbook and advising from operational experience is sharpest exactly here, in the moment after something has gone wrong: knowing what the logs should show, what a defensible control looks like, and how to reconstruct what the system did.

Preparation is the real protection

Most of the value in AI liability work is preventive: building the governance, logging, human-oversight, and vendor-contract posture that both reduces the chance of an incident and produces the evidence to defend one. For organizations that want it, the firm builds an AI incident-response plan in advance, alongside the governance framework, so the first hours after a failure follow a plan rather than improvisation. When an incident has already occurred, the firm advises on containment, preservation, disclosure, and liability. Engagements are hourly, on a retainer, or scoped — and the strong recommendation is always to do the preparation before it is needed.

What usually goes wrong

The most damaging failure is discovering after an incident that nothing was logged — no record of model versions, inputs, outputs, or human oversight — so the organization cannot reconstruct what happened, cannot demonstrate its controls, and cannot mount a defense, because the evidence was never created. A close second is the organization that assumed the vendor would absorb the liability and finds, mid-incident, that the contract capped the vendor's exposure and the regulatory obligation sits with the deployer. The third is improvised response — reacting to an AI failure with no plan, missing disclosure deadlines, failing to preserve evidence, and compounding the original harm with a botched response.

Related

• AI Governance Frameworks & Policy →
• AI Vendor & Procurement Contract Review →
• Fractional AI Governance Counsel →