Subprocessors
Effective July 29, 2026 · last updated July 29, 2026
The 15 third parties that process personal data on our behalf, what each one actually receives, and where it operates. This register is compiled from the source code rather than from memory, because a register that has drifted from the software is worse than none. It is the document a customer relies on under their Data Processing Addendum.
How changes are notified
Under §5 of the Data Processing Addendum we give at least 30 days' notice before adding or replacing a subprocessor. Notice goes to each customer's administrative contact by email, and this page is updated at the same time. A customer may object on reasonable data protection grounds within that period; if we cannot accommodate the objection, they may terminate the affected subscription without penalty.
We may replace a subprocessor on shorter notice where it is necessary to preserve security or continuity (a provider suffering a breach, for instance) and will explain why as soon as practicable.
To be notified without being a customer, email privacy@dmcpilot.com.
Reading the health-data column
One class of data in the platform is special category data under Article 9 of the GDPR: dietary requirements and allergies. Because that carries stricter obligations, the tables below say for every provider whether it can receive it.
- Yes, the provider holds or transports this data as part of its normal function. 3 of 15 providers.
- Only if present, the provider does not handle it by design, but could receive it incidentally: inside an error report, a log line, or a specific request that needed it.
- No, the data cannot reach this provider by any path.
Health data reaches an AI provider only when someone asks a question that requires it, over a zero-data-retention endpoint, and each such access is written to the activity log. It is not included in the routine context supplied to the assistant.
The register
Infrastructure
| Provider | Purpose | Personal data received | Location | Health data |
|---|---|---|---|---|
| Supabase | Primary database, authentication and object storage | Everything the product stores: accounts, program and attendee records including dietary and allergy fields, waivers, chat, timesheets including location and IP | United States (us-east-2) | Yes |
| Vercel | Application hosting, serverless execution and scheduled jobs | All request data in transit; operational logs may contain IP addresses | United States, with a global edge network | Only if present |
| Cloudflare R2 | File and document storage, photo albums, database backup target | Uploaded documents and images; encrypted database dumps | Automatic region selection | Yes |
| Upstash | Distributed rate limiting | IP addresses and user identifiers, held transiently as rate-limit keys | United States | No |
| Sentry | Application error monitoring and session replay | Stack traces, user identifier only, scrubbed request context | United States | Only if present |
Communications and payments
| Provider | Purpose | Personal data received | Location | Health data |
|---|---|---|---|---|
| Resend | Transactional email, invitations, proposals, digests, alerts | Recipient name and email address, message contents | United States | No |
| Expo (EAS Push) | Mobile push notification relay for the DMC Pilot iOS and Android app | Device push tokens and short notification previews: sender first name and up to 140 characters of message text. Never dietary, allergy or other health information | United States | No |
| Stripe | Subscription billing, add-ons and usage charges | Billing contact details and payment instrument, which Stripe holds and we never receive | United States | No |
| Cal.com | Demonstration booking on the public website only | Name, email address and any answers given when booking a call | United States | No |
Artificial intelligence
| Provider | Purpose | Personal data received | Location | Health data |
|---|---|---|---|---|
| OpenRouter | Model gateway, the single route by which any model is called | The contents of the prompt for the feature in use | United States | Yes |
| Google (Gemini), via OpenRouter | Assistant answers, document and manifest analysis, safety guards | Program context and attendee names; dietary and allergy fields only when a question requires them | United States | Only if present |
| OpenAI, via OpenRouter | Fallback for assistant answers and guards | As above | United States | Only if present |
| Perplexity, via OpenRouter | Client and destination research requiring web search | Company and destination names only, no attendee data | United States | No |
Operational data sources
| Provider | Purpose | Personal data received | Location | Health data |
|---|---|---|---|---|
| AviationStack / FlightAware | Flight status tracking | Flight numbers and dates only, no personal data | United States | No |
| Mapbox | Geocoding, maps and place search | Addresses and place queries | United States | No |
Why AI providers are listed individually
Every model call in the platform goes through a single gateway, OpenRouter. It would be tempting to list only the gateway and stop, but that would be misleading: a gateway routes, and the provider it selects has its own terms. So the upstream providers are named separately, because they are the ones actually running the inference.
Two settings govern this, and both are applied rather than assumed. Every request is sent with data collection denied, which excludes any provider that stores or trains on inputs. That matters because the gateway's default is to permit them. Requests that could carry health data additionally require zero-data-retention endpoints, which do not retain the request at all; if none is available the request fails rather than routing somewhere that would keep it. Independently, the account-level settings with the gateway exclude every training endpoint and enable zero retention for the providers this platform uses.
One limitation worth naming: zero-retention guarantees do not extend to search plugins, and the research feature performs web search. We therefore send no attendee data on that path at all, only company and destination names.
Location and transfers
Every provider above operates in or from the United States. Personal data of people in the EEA, the UK and Switzerland therefore leaves those territories, which requires an Article 46 safeguard. The technical measures supporting such transfers are in place; the Standard Contractual Clauses and a per-provider transfer impact assessment are outstanding, as stated in §11 of the Addendum. EU data residency is not available today.
What is not on this list
Services that receive no personal data are excluded on purpose, so that the register stays the list of places personal data actually goes. Flight tracking receives flight numbers and dates; mapping receives addresses and place queries. Neither receives a name.
We use no advertising, marketing-automation, data-broker or behavioral-analytics provider of any kind, on the website or in the product. The website's analytics are cookieless and aggregate, see the Cookie Notice.
Questions about this document: legal@dmcpilot.com. Privacy requests: privacy@dmcpilot.com. Security reports: security@dmcpilot.com.