How BroomAI handles your data

1. What BroomAI is

BroomAI is an AI workforce platform for multi-channel e-commerce sellers. A seller (the store owner) connects their store and communication channels, then hires named AI agents:

• Ava — General Manager. Triages messages, produces a daily brief. Read-only.
• Jim — Shipping. Fulfils orders, updates tracking, manages holds. All writes require owner approval.
• Maya — Inventory. Monitors stock, drafts supplier reorder emails.
• Sarah — Customer Support. Reads a dedicated support inbox, drafts grounded replies.
• Kai — Analytics. Reads store and web-analytics data to surface insights. Read-only toward the store.

Every action that changes the store or sends an outbound communication is intercepted and held for the owner's explicit approval before it runs (propose → approve → execute). Agents propose; the owner approves; only then does the action execute.

2. Our role as data processor

2.1 Under UK GDPR Article 28, BroomAI acts as a data processor when processing store customer personal data on behalf of the store owner (data controller). BroomAI acts as data controller for account and billing data.

2.2 All processing of store data and email data by BroomAI's AI Agents is carried out on the store owner's documented instructions as expressed through: (a) the Terms of Service (including the Data Processing Agreement); and (b) the owner's active configuration and use of the Platform.

2.3 BroomAI processes personal data only to the extent necessary to operate the agents the owner has hired. Data minimisation principles apply throughout.

2.4 The formal controller/processor arrangement, sub-processor authorisations, and deletion obligations are in the Data Processing Agreement.

3. Data we access & collect

Data falls into four groups:

3.1 Account & authentication data

• Store owner identity — the Google account email used to sign in, gated by an allowlist. Used to authenticate the owner and bind them to their shop.
• OAuth credentials — encrypted access/refresh tokens for Shopify and Google. Never exposed to the browser; never logged.

3.2 Store (Shopify) data

• Orders, fulfilments, line items, and tracking.
• Products, variants, SKUs, inventory levels, and images.
• Customer records associated with orders (name, email, address, phone) — read to fulfil orders and verify support requests.
• Aggregate analytics (sessions, conversion rate, traffic sources) via Shopify reports.

3.3 Communication data

• Owner conversations — messages exchanged between the owner and their agents (dashboard chat and Telegram), stored to maintain conversation context.
• Support email — inbound customer emails to the dedicated support inbox Sarah works, plus the replies she drafts/sends. Stored as support tickets.

3.4 Owner-provided configuration

• Business profile, agent settings, knowledge-base notes, and supplier contacts.
• Payment data for token top-ups is handled entirely by Stripe — see Sub-processors. We never see or store card numbers.

4. Shopify data & OAuth scopes

BroomAI connects via Shopify's standard OAuth install. The access token is verified, encrypted (AES-256-GCM), and stored server-side. All webhook payloads are verified with HMAC-SHA256 before processing.

4.1 Requested scopes & why

Scope	Why BroomAI needs it
read_customers	Verify that a support request comes from the order's customer (sender email must match order email) and personalise order lookups.
read_draft_orders	Resolve an order number that exists only as a Shopify draft — used by the order-lookup fallback and order search.
read_reports	Power Kai's native Shopify analytics (sessions, conversion rate, traffic sources). Independent of the optional GA4 connection in §6.
write_orders	Add order notes/tags and manage order state on the owner's instruction (approval-gated).
write_fulfillments	Jim fulfils orders, updates tracking, and manages holds (approval-gated).
write_products	Maya edits products, variants, SEO, and images (approval-gated).
write_inventory	Maya adjusts and moves inventory across locations (approval-gated).

Shopify treats write_X scopes as supersets of read_X. When required scope sets grow, connected stores are shown a Reconnect banner requiring re-authorisation.

4.2 Protected Customer Data

Customer personal data (name, email, address, phone) is used only to deliver owner-requested functionality, retained only as long as needed, encrypted in transit and at rest, and excluded from observability/analytics exports.

4.3 Webhooks

BroomAI subscribes to orders/create and inventory_levels/update for proactive monitoring. Every webhook body is HMAC-SHA256 verified before any processing.

4.4 Mandatory privacy webhooks

BroomAI implements Shopify's three required privacy webhooks, each HMAC-verified:

• customers/data_request — records the request for the store owner (data controller) to respond to;
• customers/redact — erases that shopper's personal data stored by BroomAI; and
• shop/redact — sent ~48 hours after app uninstall; purges all of the store's personal and operational data and removes stored credentials.

5. Gmail data & OAuth scopes

5.1 Gmail access is per-store and opt-in. Each store connects its own Google account through a dedicated OAuth consent screen separate from the sign-in flow.

5.2 Two distinct purposes:

• Owner account (Maya) — composes supplier reorder emails and sends them only after the owner approves the full email and recipient. Draft-only mode is available.
• Support inbox (Sarah) — reads inbound customer email, drafts replies, and (only if the owner enables auto-send, off by default) sends them; otherwise the owner approves each reply.

Scope	Class	Why BroomAI needs it
.../auth/gmail.modify	Restricted	Read inbound support email via incremental history sync so Sarah can triage and reply; apply organising labels. We do not permanently delete messages.
.../auth/gmail.send	Sensitive	Send supplier drafts (Maya) and support replies (Sarah) that the owner has approved, threaded into the correct conversation.
.../auth/userinfo.email	Basic	Identify which Google account is connected, shown to the owner in settings.

We request gmail.modify rather than full mail scopes because we never need to permanently delete messages or manage account settings.

5.3 Inbound email flow

New mail is delivered via Gmail's users.watch → Google Cloud Pub/Sub push → a verified webhook. Only changes since the last sync cursor are fetched. Deterministic guards run before any reply: an identity check (sender email must equal the order email), automatic escalation of refund/cancel/dispute requests, and field-whitelisting that strips internal data before the model sees it.

6. Google sign-in & Google Analytics (GA4)

6.1 Google sign-in

Owner authentication uses Google OAuth (OpenID Connect) through a separate OAuth client from the Gmail and Analytics integrations, requesting only basic profile/email. Sign-in does not grant any Gmail, Analytics, or Drive access. Access is gated by an email allowlist — unrecognised accounts see a "Request Access" screen rather than being signed in.

6.2 Google Analytics (GA4)

GA4 is an optional, per-store, opt-in connection that powers the Kai analytics agent with web-analytics data (sessions, traffic sources, conversions) that Shopify's native reports don't expose. It uses its own dedicated OAuth client — separate from both sign-in and Gmail — and is strictly read-only: BroomAI can never modify a GA4 property. The owner can connect or disconnect GA4 at any time; disconnecting revokes the token with Google and clears the stored credentials.

Scope	Class	Why BroomAI needs it
.../auth/analytics.readonly	Sensitive	Read-only access to the GA4 property the owner selects, so Kai can report sessions, traffic sources, and conversion trends. No write access is requested or possible.

7. Google API Services — Limited Use affirmation

8. AI processing — what goes to the model

8.1 What is sent. To generate a reply, triage an email, or carry out an instruction, the relevant content is sent to Anthropic's API over TLS. Only data necessary for the specific task is sent.

8.2 No training on your data. Calls are made through Anthropic's commercial API under terms where submitted data is not used to train Anthropic's models.

8.3 Deterministic guards. Inventory arithmetic, oversell detection, identity verification, and critical-action escalation are deterministic code, not AI model decisions. The model renders results and makes bounded, low-stakes judgments within those guardrails. The model can only narrow what an agent does, never widen it past these guards.

8.4 AI accuracy disclaimer. AI systems are known to produce erroneous, misleading, or confabulated outputs ("hallucinations"). No AI output should be treated as authoritative without human review. All material store changes and outbound customer communications require the owner's explicit approval. BroomAI's liability for AI errors is excluded and limited as set out in Section 13 of the Terms of Service. The Business, as data controller, is responsible for human oversight over all AI Agent activity.

9. PII redaction and observability

9.1 We use Braintrust for observability of AI calls. Before any trace leaves our process, a redaction layer removes personal data: emails, phone numbers, names, addresses, postal codes, IPs, and card-shaped numbers are replaced with salted hashes. Safe identifiers (order ID, SKU, quantity) pass through. Raw customer PII is never shipped to the observability layer.

9.2 When the observability key is unset, no traces are emitted.

10. Storage and encryption

• Where. Application data lives in a PostgreSQL 16 database hosted on Railway (EU/US region per deployment). Redis is used for transient queues and short-lived OAuth nonces (10-minute TTL).
• In transit. All connections — to Shopify, Google, Anthropic, Stripe, and between services — use TLS/HTTPS.
• At rest — credentials. Every OAuth access and refresh token is encrypted with AES-256-GCM using a 256-bit key held only in the server environment. Tokens are decrypted on demand in memory and never written to logs or returned to the browser.
• Webhook secrets. Stored encrypted; webhook authenticity verified with timing-safe HMAC comparisons.

11. Security practices

• OAuth CSRF protection — every OAuth flow uses a single-use state nonce (server-side, short TTL) verified on callback.
• Token-based API auth — the API accepts only short-lived Bearer JWTs; a fresh token per session; every request scoped to the caller's own shop.
• HMAC verification — all Shopify webhooks and Gmail Pub/Sub pushes are verified before any work is done.
• Human-in-the-loop — no store mutation or outbound email runs without explicit owner approval. The owner can pause any agent at any time.
• Audit trail — every executed write is recorded (who proposed it, which approval resolved it, inputs and outputs).
• Data minimisation — customer-facing lookups use field-whitelisted views; internal data is stripped before it can reach the model.
• Access controls — role-based access limits system access to authorised BroomAI personnel. Production environments are isolated from development.
• Incident response — BroomAI maintains a documented incident response procedure covering detection, assessment, containment, notification, and review.

12. Sub-processors

Sub-processor	Purpose	Data shared	Transfer mechanism
Anthropic (Claude API)	AI agent reasoning, triage, reply generation	Message/email content and order facts. Not used for model training.	UK IDTA / SCCs
Railway	Application hosting, PostgreSQL, Redis	All application data, encrypted as above	SCCs / UK IDTA
Google (Gmail / OAuth / Pub/Sub / Analytics)	Email integration, owner sign-in & GA4 analytics	Per granted scopes; Limited Use policy applies	UK Adequacy / SCCs
Shopify	Store data source and write target	Per granted scopes	UK Adequacy / SCCs
Stripe	Token top-up payments	Stripe-hosted Checkout only. BroomAI never receives card numbers.	UK IDTA / SCCs
Braintrust (optional)	AI observability (can be disabled)	Redacted traces only — PII removed before export	UK IDTA / SCCs
Telegram	Owner messaging channel	Owner ↔ agent messages, if connected	SCCs

13. Retention and deletion

13.1 Disconnecting an integration. On disconnection, BroomAI immediately revokes the token with the provider and clears stored encrypted credentials. Agents lose all access immediately.

13.2 Shopify mandatory deletion. BroomAI honours Shopify's shop/redact webhook automatically ~48 hours after app uninstall: all store personal and operational data is purged and stored credentials are removed. The billing ledger is retained under a tax/accounting legal basis.

13.3 Customer data requests. On receipt of a customers/redact webhook, BroomAI erases the relevant shopper's personal data in support tickets.

13.4 Gmail-derived data. Email content is retained only as support-ticket context. It is never repurposed or shared beyond the sub-processors listed above, and is removed on inbox disconnection or account deletion.

13.5 Account deletion. On full account closure, all personal and operational data is deleted within 30 days, except billing records retained for the legally required 7-year period.

13.6 Data export. During the subscription term, owners can export data through the dashboard where export functionality is available. Export all required data before cancellation — BroomAI is not responsible for retaining data after termination.

14. Your controls

• Connect/disconnect any integration (Shopify, Gmail, GA4, Telegram) at any time from the dashboard.
• Hire/fire agents — removing an agent removes its access to the corresponding data surface.
• Approve or reject every store change and outbound email. Auto-send is off by default and opt-in per agent.
• Pause any agent conversation to take over manually at any time.
• Per-agent permissions — e.g. email "drafts only" vs. "send allowed"; granular lookup toggles for customer support.
• Request data export or deletion via contact@broom-ai.com.

15. Data breach response

15.1 In the event of a confirmed personal data breach: (a) BroomAI will notify the affected store owner without undue delay upon confirming the breach following reasonable investigation; (b) notification will include, to the extent available, the nature of the breach, categories and approximate number of data subjects, BroomAI's privacy contact details, likely consequences, and measures taken or proposed; (c) the store owner, as data controller, is solely responsible for notifying their own customers and the ICO under Articles 33 and 34 of the UK GDPR; and (d) BroomAI's notification does not constitute an admission of liability, which is subject to the limitations in Section 13 of the Terms of Service and the DPA.

16. Legal framework and document hierarchy

16.1 This Data Handling Reference is a summary. The binding legal framework is: (a) the Terms of Service — commercial agreement, liability limitations, disclaimers; (b) the Privacy Policy — UK GDPR Art.13 disclosure, lawful bases, data subject rights, retention; and (c) the Data Processing Agreement — Art.28 processor obligations, sub-processor authorisations, technical and organisational measures, deletion.

16.2 Every account holder accepts the Terms of Service (incorporating the Privacy Policy and DPA) in-app before using the Platform.

17. Contact