Can a contract clause shift AI liability to the vendor?

A clause can shift contractual risk between the parties. The clause cannot displace regulatory obligations. EU AI Act Article 26 obligations sit with the deployer regardless of contract. HIPAA obligations sit with the covered entity regardless of business-associate language. Texas TRAIGA penalties sit with the deployer regardless of vendor terms.

What evidence will a regulator ask for?

The pattern from EU AI Act review and from OCR HIPAA review is the same: produce, in writing, a record showing what requests touched the affected system, who initiated them, what data was involved, and what policy governed each decision. Six-month minimum retention under Article 19. Often longer under sector-specific obligations.

Are vendor-side logs enough?

Vendor logs cover the vendor's view of the call. They do not include the deployer's identity context, the deployer's data classification, or the deployer's policy state. A regulator's review is of the deployer's system, not the vendor's. The vendor log is a corroborating record at best.

What about embedded AI inside a SaaS product the customer does not see?

Article 26 obligations apply whenever the customer is the deployer of the use. If the SaaS vendor's AI is processing the customer's data on the customer's behalf, the customer is the deployer. The customer carries the audit obligation even when the inference happens inside the vendor's environment.

AI vendor liability: you own it, the vendor will not

In May 2026, The Register asked six of the largest AI agent vendors a direct question: who is liable for the decisions the agent makes. Microsoft and SAP declined to comment. Oracle, Salesforce, ServiceNow, and Workday did not respond. The silence is the answer. The contract language already places the risk on the customer. The regulators are explicit that the deployer owns the obligation. The piece a deployer has to produce is the per-decision audit trail showing what the AI did with whose authority under what policy.

I want to walk through what the regulators actually say, what the vendor contracts already encode, and the architectural shape of the evidence a deployer has to maintain.

What the EU AI Act says about the deployer

The EU AI Act uses "deployer" as a defined term. The deployer is the natural or legal person using the AI system under its authority, except where the use is purely personal and non-professional. Under Article 26, the deployer of a high-risk AI system has its own set of obligations. The provider's obligations under Article 16 do not displace them.

Among the deployer obligations: use the system in accordance with the provider's instructions; assign human oversight to natural persons with the required competence; monitor the operation of the system; keep the automatically generated logs for at least six months under Article 19; report serious incidents.

The deployer's obligations are independent of the contract terms with the provider. A favorable contract clause does not exempt the deployer from Article 26.

What the contracts say

Enterprise SaaS contracts for AI features carry a few clauses that, in combination, place the operational risk on the customer:

Limitation of liability capped at fees paid in the prior 12 months. For a $100K SaaS contract, the cap is $100K. AI-related harm typically exceeds that ceiling.
No warranty of accuracy for AI-generated outputs. The customer agrees the output may contain errors and is responsible for review.
Customer responsibility for end use. The customer accepts that decisions made on the basis of AI output are the customer's decisions.
Indemnity carve-outs that exclude AI output from the IP indemnity.
Data processing addenda that assign the customer as the controller for personal data flowing through the AI feature.

A favorable read of the contract is that the AI vendor handles model availability and security. An honest read is that the AI vendor sells the inference and the customer carries every downstream consequence.

What the regulators have said in the open record

Gartner estimates that by mid-2026, unlawful AI-informed decision-making will generate over $10 billion in remediation costs and damages. The agency framing matters. The cost lands on the entity that made the decision, not on the entity that sold the inference.

The European Commission's high-risk classification guidelines from May 19, 2026 make the deployer-side scope test concrete. A vendor selling an "HR screening assistant" is a high-risk system provider. The customer using the assistant to screen candidates is the deployer of a high-risk system. Both have obligations. The customer's obligations include logging, oversight, and incident reporting under Article 26.

In the US, the Texas Responsible AI Governance Act took effect January 1, 2026 with civil penalties enforced by the Attorney General. The California AI Transparency Act took effect the same day, mandating disclosure for AI systems with 1M+ monthly users. Both statutes assign obligations to deployers, not just to providers.

In the healthcare sector, the OCR's HIPAA enforcement model has always placed responsibility on the covered entity for how PHI is used, including when a business associate runs AI on the PHI. The deployer owns the disclosure obligation.

What a deployer has to produce on its own

The audit artifact the regulator expects is a per-decision record. Each AI request that affected a high-risk decision must be recoverable with five fields:

Principal. Who or what initiated the request. A real human, an agent identity, or a service account with a known owner.
Model and endpoint. Which model, which provider, which version.
Inputs after classification. What data classification applied to the prompt; what redaction or masking was applied.
Policy state at the moment of decision. Which policy version evaluated the request, and what decision (allow, mask, block, escalate) it returned.
Output treatment. What the response contained after policy treatment, and what the deployer-side action was.

The five fields together let an auditor reconstruct what happened, who initiated it, and what governed the decision. The application log alone fails the test because the application controls its own log; the system under audit cannot be the system of record for its own audit.

Why the gap is architectural

Most enterprise AI deployments call models with a static service credential. The credential identifies the application. The natural person on whose behalf the application acted is not on the request. The audit record either fabricates the identity from a session-cookie heuristic or omits it. Article 19 explicitly requires identification of natural persons. The deployer cannot retrofit the identity at log-write time; the identity has to travel with the request.

The same goes for policy state. The application's logic at the moment of decision is one input. The data classification of the prompt, the model version, the response treatment policy, and the gateway-side audit context are different inputs. The application log contains the application's view. The compliance log has to contain all of them.

The fix is at the request layer

The architectural fix is to move the audit and the policy decision out of the application into a gateway. The gateway resolves identity at the request boundary, evaluates policy with full context, writes the per-decision record to an append-only signed store, and returns the treated response to the application. The application stops being the system of record for the AI decisions it triggered. The gateway becomes that system.

The deployer then has an artifact the regulator expects. The artifact is independent of the application's own logs. The artifact survives the failure modes (selective logging, suppression, loss on crash) of application-controlled logging that I walked through in detail at singhspeak.

DeepInspect

DeepInspect is the gateway in the request path. The deployment pattern is a proxy or sidecar in front of any LLM. Identity travels with the request. Policy evaluates at the gateway. Decisions write to a per-decision audit record that is append-only, signed, and retained per the deployer's regulatory profile.

For a deployer whose AI vendor will not answer the liability question, the artifact that protects the deployer is the per-decision audit log. That is the artifact DeepInspect was built to produce.

If you are heading into the August 2 EU AI Act deadline with vendor contracts that place the risk on you, let's talk today about mapping the audit trail.