GDPR Compliance for AI Sales Agents

The GDPR applies whenever an AI sales agent processes personal data of EU or EEA data subjects, regardless of where the merchant is incorporated. For an AI agent that handles shopper conversations, product recommendations, abandoned-cart recovery, and post-purchase journeys, that means almost every shopper interaction is in scope. Zubby AI was designed against this reality from day one — every table is tenant-scoped, every secret is encrypted, every privacy-rights request is a first-class background job, and every cross-border transfer is bound to a documented legal mechanism.

Compliance, however, is more than a checklist. It is a mapping between the GDPR Articles, the technical controls that satisfy them, and the human runbook that handles edge cases. The remainder of this page is that mapping. Where the GDPR gives you choices (lawful basis, retention, transfer mechanism), we explain the defaults and the levers merchants can pull.

Under Article 4, the merchant acts as the Controller of shopper personal data and Zubby AI acts as the Processor. The Controller establishes the lawful basis under Article 6 — typically contract performance (the shopper opted into checkout), legitimate interest (abandoned-cart recovery within 30 days), or consent (marketing channels and tracking pixels).

Article 28 requires a written contract between Controller and Processor. Zubby's Data Processing Agreement satisfies Article 28(3) in full — purpose limitation, confidentiality obligations, security measures, sub-processor terms, assistance with data-subject rights, breach notification, return or deletion at end of contract, and audit rights are all enumerated.

For the merchant's own account data — workspace metadata, billing records, login telemetry, audit logs — Zubby AI is a Controller for the narrow purposes of providing the service, abuse prevention, and security monitoring. That dual posture is unusual but it is honest: a SaaS vendor cannot pretend it has no Controller responsibilities for its own administrative data.

Categories of shopper personal data Zubby AI processes on behalf of merchants:

• Identifiers. Email, IP address, device ID, browser fingerprint hash, shopper account ID.
• Commercial behaviour. Cart contents, order history, browse events, conversation transcripts with the AI agent, post-purchase reviews.
• Communication. Email and SMS recovery payloads, push notification opt-in flags, channel preferences (WhatsApp, Instagram, FB Messenger, Telegram).
• Inferred attributes.Predicted size, LTV bucket, VIP tier, churn risk score. These are derived for the merchant's use only.

What we do not process:

• Special-category data under Article 9 (race, health, biometrics, etc.).
• Payment card primary account numbers — checkout runs in the merchant's PCI-DSS-scoped checkout (Shopify Checkout, WooCommerce + payment gateway). We receive only redacted order summaries.
• Cross-tenant data joins. The data model has no surface that exposes another merchant's shoppers — every query carries a store_id predicate.

Default deployment runs in US-East. EU and UK customers may opt into EU-only processing during signup, in which case all production data — Postgres (with pgvector), Redis (BullMQ queue), object storage, and AI provider routes — is pinned to EU regions and EU sub-processor variants are selected (OpenAI EU, Anthropic EU). The default region for new EU customers is Frankfurt.

For default workspaces, cross-border transfers rely on the European Commission's 2021 Standard Contractual Clauses (Module 2: Controller-to-Processor), incorporated by reference in the Data Processing Agreement. UK transfers additionally use the International Data Transfer Addendum (IDTA). Swiss transfers rely on the Swiss FADP-equivalent SCC adaptations.

A Transfer Impact Assessment is available on request. It covers US public-sector access risk, supplementary measures (encryption with keys held outside the receiver jurisdiction, AAD-binding to prevent unauthorized re-purposing of ciphertext), and the current status of the EU-US Data Privacy Framework.

Article 32 requires "appropriate technical and organisational measures" — a deliberately flexible standard that we satisfy with a defense-in-depth stack:

• Encryption at rest. AES-256-GCM with AAD-bound ciphertexts. The AAD context is derived from (tenant, column, provider, field) using crypto.createHash("sha256"). An attacker with database write access cannot transplant a ciphertext between rows because the AAD verification fails. Implementation in src/lib/secrets.ts.
• Encryption in transit. TLS 1.3 at the edge with HSTS preload on marketing and app domains. Postgres connections require SSL.
• Password hashing. crypto.scrypt with a 16-byte random salt and 64-byte derived key. Verification via crypto.timingSafeEqual. No bcrypt cost-factor downgrades.
• Session integrity. NextAuth v5 JWT sessions with hard-invalidation on credential change — a password rotation or admin-issued revocation immediately terminates every outstanding JWT for that subject.
• Webhook authenticity. HMAC-SHA256 for Shopify, plugin-signed token for WooCommerce, stripe-signature for Stripe — all compared with crypto.timingSafeEqual. Idempotent handlers keyed by provider event ID prevent replay.
• SSRF protection. All outbound HTTP calls from user-controlled URLs pass through assertSafeOutboundUrl, which blocks RFC 1918, link-local, loopback, and cloud metadata addresses with DNS rebinding mitigation.
• Upload safety. Magic-byte sniffing on every image upload — the client-declared MIME type is not trusted.
• RBAC plus audit. Workspace roles (owner, admin, agent, viewer) gate every dashboard action. Audit events record actor, action, target, and ISO timestamp with 24-month retention.
• Penetration testing. Annual third-party penetration test of the public API and dashboard. SOC 2 Type I audit window in progress.

Zubby AI supports the full GDPR data-subject-rights catalogue directly from the merchant dashboard. Where the merchant receives a request first, Zubby AI completes the technical fulfilment well within the 30-day Article 12 window — our internal SLA is 48 hours.

• Right of access (Art. 15).Export a single shopper's data in JSON. Includes conversation transcripts, AI tool-call audit, journey state, and inferred attributes.
• Right to rectification (Art. 16). Edit shopper records inline; changes propagate to downstream connector caches.
• Right to erasure (Art. 17). One-click delete via /api/v1/merchant/gdpr/delete. The fanout removes conversations, pgvector embeddings, journey state, customer record, AI tool-call logs, and CDN-cached avatars. The job runs with 5 retries on exponential backoff so a failed sub-processor call cannot drop a legal obligation.
• Right to data portability (Art. 20). JSON and CSV exports in a schema documented in the public API reference.
• Right to restrict processing (Art. 18). Per-shopper suppression flag respected by every connector and channel adapter.
• Right to object (Art. 21). Opt-out applies end-to-end across email, SMS, in-store widget, and every channel adapter.
• Automated decision-making (Art. 22). The AI agent makes no decision producing legal or similarly significant effects on the shopper. AI outputs are merchandising recommendations and customer-service replies, not credit, employment, or eligibility decisions.

• Conversations: 12 months default. Merchants can shorten the retention window per store.
• Abandoned-cart payloads: 30 days, then anonymised.
• Audit logs: 24 months.
• Backups: 35 days rolling, encrypted, off-region. Erasure requests flag the subject for backup-deletion at the next restore drill.
• End of contract: on Controller request, all personal data is returned (JSON export) or deleted within 30 days. Deletion is irreversible and certified in writing.

In the event of a confirmed personal-data breach, Zubby AI notifies affected Controllers without undue delay and, in any case, within 72 hours of confirming scope. Notifications include nature of the breach, categories and approximate count of records concerned, likely consequences, and the measures we have taken or propose to take. The incident-response runbook is documented in DEPLOY.md.

We publish a public root-cause analysis on /status after resolution. We do not blame customers for vendor breaches and we do not bury incident reports.

• DSAR acknowledgement: 1 business day.
• DSAR fulfilment: 48 hours for self-serve operations; 30 days maximum as required by Article 12.
• Breach notification: within 72 hours of confirmed scope.
• Security questionnaire turnaround: 5 business days on Pro and Enterprise plans.
• DPA counter-signature: 1 business day after entity name is provided.

Data Protection Officer enquiries, DSARs received directly by Zubby, breach reports, and SCC questions go to privacy@zubbyai.com. For security vulnerability reports, use security@zubbyai.com. For counter-signed DPAs and contractual questions, use legal@zubbyai.com.

We currently rely on an external DPO, available via privacy@zubbyai.com with a guaranteed 1-business-day acknowledgement.