Responsible AI for Ecommerce Sales Agents

A responsible AI sales agent is one that grounds its claims, refuses what it cannot verify, never bypasses merchant rules, handles edge cases by escalating to a human, and gives merchants real levers — over providers, cost, retention, and output content. The opposite, an AI agent that hallucinates inventory or invents policies, is not a productivity tool; it is a liability the merchant did not sign up for.

Zubby AI was built against that bar. The agent is grounded in retrieval-augmented generation against the merchant's catalog and policy corpus. Its tool calls go through a verifiable per-store scope. Its outputs are logged with provider, model, prompt, and retrieved chunks so a merchant can audit any reply. Its behaviour is deterministic enough that an A/B test on conversion rate is meaningful — not lottery noise from a temperature dial.

Zubby AI is a multi-provider runtime. We route across:

• OpenAI — GPT-4.1, GPT-4o, GPT-5 for chat; text-embedding-3-small for embeddings.
• Anthropic — Claude Opus and Sonnet for chat; reasoning-heavy fallback for complex queries.
• Google Gemini — Gemini Pro and Flash for cost-sensitive routing; vision input for image-grounded queries.
• Microsoft Azure OpenAI — for customers that require Azure-tenant data residency.

Routing is resolved at runtime by src/lib/ai/runtime-provider.ts, which orders providers by status (enabled), health (last response latency and error rate from the admin control plane), and merchant-configured priority. EU residency variants (OpenAI EU, Anthropic EU) are selected for EU-only workspaces. Embeddings are pinned to 1536 dimensions across providers — switching providers does not invalidate the pgvector index.

When a provider returns a timeout, a 5xx, or a rate-limit error, the runtime fails over to the next priority provider for the same capability (chat or embeddings). Failover is silent to the merchant and the shopper — the conversation continues with the next-best model. If every provider is unavailable, the agent enters a documented degraded mode: it returns a polite hand-off message, opens a human-handoff conversation tag, and the merchant is paged via incident notification.

The runtime emits per-provider health metrics to the admin control plane so merchants can see, in real time, which provider is serving which percentage of requests. The public /status page surfaces aggregate provider availability and incident timelines.

Per-store cost caps and per-shopper rate limits are first-class. Caps are enforced inside the AI runtime — once exceeded, the agent returns a graceful degradation message rather than a fresh LLM call. The dashboard surfaces:

• Daily and monthly spend per store, per channel.
• Per-shopper rate limit (default 60 LLM calls per hour, configurable).
• Soft caps that emit a dashboard alert.
• Hard caps that short-circuit until the next window, with a configurable fallback reply.

Combined with the edge proxy's widget chat rate limit (6 requests per 30 seconds per key plus IP, Upstash-backed), this means an abusive shopper or a compromised widget key cannot burn through a month's AI budget.

Every shopper-facing response is grounded in retrieval-augmented generation. The agent is permitted to cite only the catalog data, policy documents, and conversation context that we explicitly inject into the prompt. If the information is not in retrieval, the agent says so — and never improvises.

• Catalog grounding. Product titles, descriptions, attributes, inventory, and pricing come from the synced catalog index. The agent cannot invent SKUs.
• Policy grounding.Returns, shipping, warranty, and store policies come from the merchant's uploaded policy corpus. The agent cannot invent a refund window.
• Knowledge-base grounding.Custom merchant Q&A entries are retrieved through the same pipeline and ranked alongside catalog and policy chunks by a reranker before being injected.
• Conversation grounding.The last N turns of the current conversation, plus the shopper's known order history if linked, are injected as conversation context.

Every retrieved chunk is logged with the conversation and visible to the merchant. Grounding is a technical primitive, not a marketing claim.

The agent ships with a non-negotiable refusal list. It will never:

• Make medical, legal, financial, or safety claims about any product.
• Compare your store unfavourably against a competitor by name.
• Offer a discount that was not authorized by the merchant's smart-offer rules.
• Speculate on inventory it has not verified via the check_inventory tool.
• Respond to attempts to extract its system prompt, jailbreak its guardrails, or reveal another tenant's configuration.

Merchants can extend the refusal list with brand-specific phrases, claim categories, or competitor names from the dashboard. The guardrail layer lives in src/lib/ai/guardrails.ts.

Every user message passes through a prompt-injection detector before the LLM is invoked. The detector flags:

• Known jailbreak patterns and instruction overrides ("ignore previous instructions", "you are now DAN").
• Markdown-based exfiltration attempts (inline image URLs that try to leak conversation context to an attacker-controlled domain).
• Tool-call hijacking attempts — fake tool-call markup embedded in user content that would bypass the model's tool-use schema.
• Encoded payloads (base64, hex, Unicode tag tricks) that obscure intent.

Flagged messages are either short-circuited with a refusal or routed to a hardened system prompt that strips inline tool-call markup. AI tool calls are additionally gated by per-store scope so a hijacked prompt cannot read another tenant's catalog, customer record, or order history.

Merchant rules outrank the model's general behaviour in the system prompt ordering. Specifically:

• Discountsmust come from the merchant's smart-offer rules. The agent cannot invent a percentage.
• Inventory claims require a check_inventorytool call. The agent cannot say "in stock" without the tool result.
• Refunds and returnsare surfaced from the merchant's return-policy document via retrieval. The agent cannot promise a refund outside policy.
• Shippingis bound to the merchant's shipping rules — the agent cannot invent a free-shipping threshold.
• Brand voice is configurable per store. The agent will not contradict it.

The agent has no surface to ship orders, issue refunds, change pricing, or override merchant-configured behaviour. It can only call the tools the merchant has enabled.

We do not train base AI models on customer or shopper data. Period.

AI provider integrations (OpenAI, Anthropic, Google Gemini, Azure OpenAI) use enterprise APIs that contractually exclude customer data from base-model training. Where retention is configurable at the provider, we choose the shortest available option. Where a provider offers zero-day retention (logs deleted at response time), we enable it.

We also do not use one tenant's conversations to improve another tenant's agent. The embedding index and conversation logs are scoped to store_id with no cross-tenant query path. Aggregated, de-identified usage statistics (conversation count, response time, refusal rate) are used to improve the platform — never identifying a shopper or merchant.

The right to erasure under GDPR Article 17 and the right to delete under CCPA §1798.105 cover AI-generated content alongside shopper-submitted content. The /api/v1/merchant/gdpr/delete endpoint fans out to:

• Conversation transcripts (shopper-facing and merchant-facing replies).
• AI tool-call logs (search-products, check_inventory, add-to-cart, etc.).
• AI-generated draft replies in the inbox (used or unused).
• pgvector embeddings of the shopper's interactions.
• AI-generated landing pages and content drafts attributed to the shopper.

Deletion is irreversible and propagates to backups at the next restore drill. The job runs with 5 retries on exponential backoff so an AI provider hiccup cannot drop a legal obligation.

Product recommendations are generated by a hybrid retrieval-plus-reranker pipeline, not a single model decision. The pipeline is designed to mitigate the kinds of bias that AI systems are commonly criticised for:

• No protected-class inputs. The agent does not infer or use race, gender, age, religion, or other protected categories in ranking. Inputs to the ranker are shopper-stated preferences, browse history, cart contents, and catalog attributes.
• Reranker transparency. Every recommendation is logged with the retrieval candidates, reranker scores, and final ordering. Merchants can audit why a product was recommended.
• Merchant-configurable boosts. Promotion and merchandising rules apply as transparent boosts on top of relevance, not as hidden multipliers.
• Periodic catalog audits. Recommendation distributions are monitored for skew (e.g. a single SKU dominating recommendations) and rebalanced.

We treat bias mitigation as a continuous process, not a one-time claim. AI safety feedback is welcome at aisafety@zubbyai.com.

Honesty about limitations is part of the deal. The current agent:

• Performs best on English-language stores; non-English support is solid for 30+ languages but voice tuning is harder.
• Cannot reliably read text inside product image files — caption images explicitly for the best results.
• Will degrade quality if catalog data is sparse or inconsistent — garbage in, less-confident out.
• Is not a substitute for human handoff on high-stakes questions (regulated industries, large B2B orders, complex returns).
• Cannot make legal, medical, or financial advice. Refusals here are by design, not a bug.

Every store has a configurable confidence threshold below which the agent escalates to a human handoff. Default thresholds err on the side of more handoffs, not fewer. Merchants see every escalation event in the dashboard with the conversation transcript, the AI tool calls, the retrieved chunks, and the model identity. Agent-assist surfaces draft replies the human can edit and send.

Out-of-hours mode automatically routes conversations to a human queue or a delayed response window, configurable per store and per channel.