Published on

You Own the AI Liability, Not the Vendor

Authors
  • avatar
    Name
    Parminder Singh
    Twitter

Last week, The Register reached out to the major AI application vendors—Microsoft, SAP, Oracle, Salesforce, ServiceNow, and Workday—and asked a simple question: How much liability do you accept when your AI agents make bad decisions? Microsoft and SAP declined to comment. Oracle, Salesforce, ServiceNow, and Workday didn't respond. That silence is your answer. For every CISO and CRO deploying AI today, that silence has a direct consequence: You are the insurer of last resort for your vendor's model.

Contractual Liability

Enterprise AI contracts are being written with liability shifted back to the deploying organization. The vendor's position, echoed by senior technology lawyers, is that while they may warrant that a model was tested for bias, the moment that model interacts with your data or your "prompt engineering," the liability is yours [1].

It's a standard indemnity carve-out. Right now, vendors are winning the negotiation. When an AI agent issues an incorrect credit decision, discloses sensitive data (PII/PHI), or executes a destructive workflow based on a hallucinated instruction, your organization owns the outcome.

The question for leadership is: What does "owning the outcome" actually require of your infrastructure?

Guardrails

Most engineering teams conflate guardrails (runtime controls) and audit records (audit evidence), which are two distinct functions.

In a regulatory inquiry or a breach post-mortem, the guardrail that fired is irrelevant if its action wasn't recorded indelibly. When a regulator asks to see the policy applied to a specific request at a specific millisecond, a per-decision audit record is the only valid answer.

Self-Attestation

There is a fundamental architectural flaw in most AI deployments: If the application generates the AI decision and also writes the compliance log, you have a self-attestation problem.

In any other regulated industry, the system under audit cannot be the system generating the audit record. This is why a CFO doesn't sign the audit of the financial statements they prepared. If your application controls the log, your audit trail has three failure modes:

  1. Selective Logging: The application logs successes but "misses" edge-case failures.
  2. Suppression: During an incident, logs can be wiped or modified by the same system that failed.
  3. Loss on Crash: The application crashes after the AI model responds but before the log is committed. The action was taken, but the evidence is gone.

Write-Path independence

True audit independence requires a decoupled proxy architecture that sits between the application and the AI model. The proxy must commit the record before the response returns to the application.

In this flow, the application never has custody of the write path. It cannot suppress the record, and a crash at the application layer cannot erase the event.

$10 Billion Liability Gap

Gartner estimates that by mid-2026, unlawful AI-informed decision-making will generate over $10 billion in remediation costs and damages. This coincides with the EU AI Act's full enforcement for high-risk systems in August 2026.

Article 12 of the Act explicitly requires "automatic recording of events (logs) over the lifetime of the system" to ensure traceability. This requires:

  • Recording the period of use (timestamps).
  • Input data (prompts).
  • Identification of natural persons involved.

Standard application logs cannot meet this level of granularity or independence.

Architectural Missing Piece

If your AI traffic routes directly from your application to a model provider (OpenAI, Anthropic, Bedrock), you have a liability gap. Your application logs what it "decides" to log, and the model provider logs what it wants for its own telemetry—which you don't control.

There is no "Third Party" in that architecture whose sole job is to witness the transaction.

DeepInspect

DeepInspect.ai provides the independent write-path for your AI applications. By sitting at the API layer, we capture every interaction before it reaches your application code.

  • Identity-Aware: We tie every request to a specific user and role.
  • Policy-Centric: We record exactly which rule was triggered (Redact, Block, Allow).
  • Tamper-Evident: The record is committed before the application even sees the model's response.

The vendor silence regarding liability is a signal to shore up your defenses. If the vendor won't stand behind the model's decision, you need an architecture that can prove exactly why you did.

See how DeepInspect generates independent audit trails at the API layer.