When AI Is Wrong,
Who Eats the Cost?
A structural diagnosis of why enterprise AI support breaks down at the first ticket, and the receipt substrate that fixes it before the renewal conversation turns hard.
"Your AI is wrong."
Three words. A support ticket. The end of an enterprise AI adoption story before it ever began. When AI is wrong and nobody can show their work, the customer doesn't blame the model. They blame the platform.
A short essay on AI observability, and a generator for the receipts that unblock it.
Two failure modes, one defect
Every team shipping AI into the enterprise lives inside one of two operating models. The architectural problem is identical in both.
Model A: the vendor supports customers directly. A SaaS where customer admins call the vendor's own support line. Tier 1 reps triage. Engineering eats the escalations. Cost lives on the vendor's P&L.
Model B: the customer's in-house admin runs first response. Common in deeply customizable enterprise platforms. The customer's admin team is the first line; the vendor only sees a ticket when the admin can't reproduce or fix it. Cost lives on the customer's P&L and on the vendor's reputation.
Both models look stable from outside. Both quietly fail at the same point when AI enters the picture.
Scene · Scenario A The vendor's queue
A Tier 1 rep opens a ticket. Subject: "AI output is incorrect: workflow status mismatch." The customer attached a screenshot showing the AI saying approved while the workflow shows legal review.
The rep has the screenshot. They have nothing else. No AI event log. No record of which model ran. No record of what the AI read. No record of when.
So the ticket walks: Tier 1 to Tier 2 to engineering. Three days later, engineering finds it: the AI summarized state at 2:14 PM, the customer was looking at state at 3:47 PM, the workflow advanced in between.
One ticket. One engineer-day. Multiply by every AI surface shipping over the next two years and the engineering load grows linearly with the AI roadmap itself.
Scene · Scenario B The customer's admin console
A federal agency's in-house admin opens his console after a deputy director walks in. "The AI is reading the wrong workflow status. We have a 10 AM briefing. Fix this."
The admin has user audit logs, system audit logs, workflow history. He has zero visibility into the AI. No model attribution. No prompt log. No timestamp of what state the AI read.
So he says "I'll get back to you," opens a P1 with the vendor, and the deputy director walks into the briefing and says the words every enterprise vendor fears: "Our AI feature is unreliable. We're turning it off."
Same root cause. Different cost surface. The vendor doesn't see a renewal at risk until it's already at risk.
Three frictions that quietly kill adoption
I No tooling for the first responder.
Whoever opens the ticket, vendor rep or customer admin, has no instrument to look inside the AI. Audit log doesn't capture it. Activity stream doesn't capture it. So the first responder has two options: close without an answer, or escalate. Both are terrible for adoption.
II The TCO math flips against adoption.
Customers don't ask "is this AI useful?" The ones who evaluate seriously ask: "If we adopt this, who eats the burden when it goes wrong?" Without receipts, the answer is our admins, with no tools. That's an unbounded support cost on an opaque product. So they don't adopt, or they adopt cautiously in one corner of the business, and the rest of the AI roadmap stalls.
III Without receipts, the vendor looks at fault by default.
When the AI is wrong, or looks wrong, and no one can show their work, the customer's executive blames the platform, not the model. Renewal conversations harden. Future AI features get deferred. You cannot ship your way out of a trust deficit you created by being unobservable.
Read the case The receipt principle, six dimensions, and the schema
The principle: every AI action should emit a receipt
The fix is not better models. It is a substrate: every AI action emits a structured, hashed receipt the first responder can read in seconds. Six dimensions, mandatory on every call.
Less than this and the first responder still can't answer. More than this and the schema stops being adoptable.
| Dimension | What it captures | Which support ticket it closes |
|---|---|---|
| Caller identity | Who triggered this AI action: user, system, scheduled job, agent on behalf of a principal | "Was this AI run by me or by someone else?" |
| Model used | Which model emitted the response, at which version | "Did this change because the model changed?" |
| Token and duration telemetry | Cost and latency per call | "Why was this slow? Why did the AI bill spike?" |
| Action type | Summarize, generate, classify, propose, approve, execute | "What kind of work did the AI actually do here?" |
| Substrate causality | Which objects the AI read or wrote, at what state | "What did the AI see when it answered?" |
| Lifecycle status | Proposed, ran, succeeded, failed, reviewed, reverted | "Did this complete? Was it reviewed? Was it rolled back?" |
See the proof The Receipt generator: eight fields, one hash
The Receipt: an AI Bill of Materials generator
The worksheet below is the public form of those six dimensions, expanded into eight fields a builder can fill in for a single AI surface. The output is a canonical, hash-signed receipt, an AI Bill of Materials, that you can publish alongside the surface itself.
Anyone reading the receipt can re-compute the hash and verify nothing was edited after publication. Same primitive as Git commits and software SBOMs. Boring tech, correct tech.
Eight fields
| Field | What to fill in |
|---|---|
| 1 Surface | What AI feature is this? One line. |
| 2 UI location | Where in your product the user encounters it. |
| 3 Caller identity | Who can trigger it. Roles, scopes, manual vs. automated, agent-on-behalf-of. |
| 4 Model | Name, version, provider. |
| 5 Data read | Objects and fields the AI touches on read. |
| 6 Data written | What the AI writes back. "Read-only" is a valid answer. |
| 7 Action type | summarize · generate · classify · propose · approve · execute |
| 8 Lifecycle | Default state, who enables it, opt-in scope, enabled-at timestamp. |
Sample receipt
# ai-receipt v0.1
surface: Summarize open change orders
ui_location: Workflow detail · Summary tab
caller_identity:
roles: [admin, project_manager]
trigger: manual
model:
name: claude-sonnet-4-5
provider: anthropic
version: 2025-05-01
data_read:
- ChangeOrder.status
- ChangeOrder.legal_review
- ChangeOrder.approver
data_written: []
action_type: summarize
lifecycle:
default_state: disabled
enable_scope: tenant_admin
enabled_at: 2026-04-12T00:00:00Z
content_hash: sha256:a3f9c11e7b8d4f02e6c3a91d27f4b71cThe hash is computed deterministically over every field above, excluding itself. Republish the YAML: anyone re-computes and verifies it matches. If a field changes, model version bumps, scope expands, data reach extends, the hash changes. Drift becomes visible.
Optional Ed25519 signature with the publisher's key turns the receipt from verifiable into attributable.
Enterprise AI adoption is a data-plane problem masquerading as a policy problem.
Build the receipt substrate first; the policy follows from what the substrate can measure. Every AI surface ships with an implicit liability question: when this is wrong, who eats the cost?
Receipts don't reduce errors. They move the liability to a place it can be absorbed: by a first responder, by a support ticket that closes itself instead of escalating.
Ship the receipts, or ship the blame.