Sub-Processor List

Last Updated: 2026-10-03 · Data Processor: Auspex Streamline S.L., Spain (EU)

Aelo uses the following sub-processors to provide its services. This list is maintained pursuant to GDPR Article 28(2) and our Data Processing Agreement with customers.

Customers are notified at least 30 days in advance of any new sub-processor being added, and may object in accordance with the DPA.

Audio Processing (ASR)

#	Provider	Purpose	Data Processed	Location	Transfer Mechanism
1	ElevenLabs	Speech-to-text transcription (Scribe v2)	Audio recordings (voice data)	US	EU-US DPF + SCCs fallback

Data sensitivity: HIGH — Audio recordings contain voice data (potential biometric data). ElevenLabs is the only speech-to-text sub-processor: audio is sent to no other ASR provider, for any tenant. Deepgram was removed on 2026-09-11 (see below).

AI Analysis (LLM)

#	Provider	Purpose	Data Processed	Location	Transfer Mechanism
2	OpenAI	LLM analysis of transcripts; answers to the Customer's own criteria about each conversation; extraction of the questions customers ask and of the reasons they decline (Voice of Customer, Pro plan and above); answers to users' questions about a call, about a CRM deal, lead, contact or company, or about all the records the user may see (AI assistant); vector representations (embeddings) of transcript and chat segments and of search queries for search by meaning	Transcripts, analyses, assistant questions and filters, CRM entity names, transcript and chat segments and search queries (with pattern-based PII redaction applied, which removes phone numbers, emails, card numbers and IBANs, not names — a CRM entity name or a customer name in a filter can be a person's name); sent without anonymisation — names and other content stay as written, only phone numbers, emails, card numbers and IBANs may be masked: the Customer's own configuration (criteria wording and answer values, sales script, glossary, analysis guidance, forbidden words, CRM field names) and the names of the employee and of the other party to the conversation	US	EU-US DPF + SCCs fallback

Transcripts are sent to the LLM provider directly for analysis. OpenAI is the only LLM sub-processor; the OpenRouter gateway and Anthropic as an alternate provider are no longer used. Pattern-based PII redaction (phone numbers, emails, card numbers, IBANs) is applied before any transcript is transmitted; it does not remove names, and the Customer's own configuration listed above is sent without anonymisation (names and wording as the Customer wrote them; at most phone numbers, emails, card numbers and IBANs are masked). If the Customer has the Voice of Customer section, the redacted transcript of each newly analysed conversation is sent again in a separate request to extract the customer's questions and, for a sales conversation, the outcome and decline reason. If the Customer has defined criteria, their wording (question, guidance and answer values) is sent with the redacted transcript in a separate request; when the Customer checks a draft wording, the same is done for up to 20 recent conversations, and those answers are not stored. The AI assistant sends the user's question together with the redacted transcript and analysis of the record — or, for a question about a CRM deal, lead, contact or company, of the linked records the user may see, with the entity's name and, for a deal, its outcome in the CRM where known (won, lost or still open); questions receive the same pattern-based redaction before they are stored and transmitted. For a question about all the records the user may see, the redacted question is also sent to the embeddings endpoint to find the closest records, and the redacted transcripts and analyses of up to 12 of them are sent with it, together with the question's filters (period, record type, category and customer name); the question's vector is not kept. For search by meaning, redacted segments of transcripts and chat conversations — and the text a user types into search, redacted the same way — are sent to OpenAI's embeddings endpoint; only the resulting numerical vectors of the segments are kept (Cloudflare Vectorize, below), not the text.

Authentication

#	Provider	Purpose	Data Processed	Location	Transfer Mechanism
3	Clerk	User authentication and session management	User accounts (name, email), sessions, login events	US	EU-US DPF + SCCs fallback

Data sensitivity: MEDIUM — No call content or transcripts. Only user account data.

Data Storage

#	Provider	Purpose	Data Processed	Location	Transfer Mechanism
4	Neon	Primary database (PostgreSQL)	Transcripts, AI analyses, metadata, user data	EU (Frankfurt, `eu-central-1`) at rest; vendor is US-incorporated and may access data for support	EU-US DPF + SCCs fallback (covers vendor access, not storage)
5	Cloudflare	Infrastructure: R2 (audio storage), D1 (edge metadata), Workers (compute), Vectorize (search index)	Audio files (R2), metadata (D1), numerical vectors of redacted transcript and chat segments with record and employee identifiers and no text (Vectorize), all data in transit	EU at rest — R2 audio bucket in Western Europe, D1 metadata database in Eastern Europe; Workers execute at the edge location nearest the request; the Vectorize index region is not pinned; Workflows state, Queues, Workers Logs/Traces, Workers Analytics Engine, KV and Durable Objects are not pinned to the EU (see below)	Cloudflare DPA + SCCs

Where the data actually sits: the two stores that keep customer content for its whole retention period — the database and the audio storage — are located in the European Union. The database region and the storage bucket region were verified against the live production configuration on 2026-08-02, not inferred from vendor defaults. Compute is the exception — a Worker runs at the Cloudflare edge location closest to the incoming request, so processing may occur outside the EU even though those two stores do not. The search index (Vectorize) is the other exception: it holds no transcript or chat text — only numerical vectors computed from redacted segments, with identifiers of the record, project, organization and transcript, the record type and, when known, the employee's identifier and the date — and Aelo has not pinned its region, so it is not covered by the EU-at-rest statement above. The text shown next to a search result is read from the transcript in the EU database. Cloudflare's other stores are the third exception: they are not pinned to the EU, and Cloudflare does not name the countries in which they keep data. Workflows state (the working state of the processing pipeline) holds transcript and chat text while a record is processed, and then for 1 day, or 7 days if processing failed. Queue messages carry webhook payloads, CRM entity names and chat text, for up to 4 days. Workers Logs and Traces record about 10 % of production requests, and logs are kept for 7 days; structured logs in Workers Analytics Engine carry record and trace identifiers and error messages and are kept for 3 months. KV holds short-lived dashboard caches and integration tokens; Durable Objects hold coordination state without transcript text.

Communications

#	Provider	Purpose	Data Processed	Location	Transfer Mechanism
6	Resend	Transactional email delivery: analysis reports, alerts and record notifications, role digests and the monthly Voice of Customer email; and Aelo's own account, invitation, billing and minute-usage emails	Recipients' email addresses and delivery metadata, and what each email says (never transcripts or audio): analysis reports of calls and chats, sent to the addresses the Customer configures for a project (which need not belong to Aelo users) — the record identifier, channel, average quality score and the value of each quality metric; alerts — a link to the record (carrying its identifier), the rule name, severity, the call's channel and AI-assigned category, a masked caller reference (first name with surname initial, or the last 3 digits of the phone number) and, when present, the model's short written reason; record notifications — a link to the record (carrying its identifier) and the channel with a masked caller reference; for a ready record also its category, quality score, duration and direction, for a failed record a fixed description of the failure; daily and weekly role digests, on by default and switchable by each user — the organisation name, quality and sales metrics and alert counts; a supervisor's digest names the top employee and the employee at risk with their quality scores; an employee's own digest carries their score, its trend, the comparison with the team and their rank; the daily digest of a client or a supervisor also lists up to five objection reasons left unhandled the previous day, by their standard names, with the number of conversations in which each went unhandled out of those in which it came up, and the share of objections that could not be recognized — with no customer wording; the monthly Voice of Customer email, on by default and switchable by each user — the organisation name, the number of analysed conversations, competitor names, feedback levels and market-signal types with their counts, and the number of conversations in which a customer named a need, with no customer wording. Sent for Aelo's own purposes as controller (Privacy Policy B.1, B.4): invitations and account emails — the inviter's or user's name, the organisation name, the role and, in an invitation, the single-use, time-limited acceptance link; budget and balance notices — the amount spent and the budget limit, or the current prepaid balance; auto-recharge failure notices — the top-up amount and the number of failed attempts; minute warnings and pause notices — minute usage and the organisation name; the pause notice of an eligible free-tier organisation also offers bonus minutes with their amount and deadline.	US	EU-US DPF (Resend is certified for non-HR data) + SCCs fallback; SCCs for the employee-performance data in role digests
7	SendPulse	Marketing email automation: the onboarding series and the usage signals that steer it. Aelo's own, as controller (Privacy Policy B.5) — nothing here is sent on a Customer's instruction. A contact is created, and every item in the next column is sent, only for a person who gave separate marketing consent; consent is recorded per person, can be withdrawn at any time, and a withdrawal stops all of it	Only for such a person: the email address and — contact variables — display name (the email address where no name is set), interface locale, signup source (web or the CRM's name), plan (free or paid), signup date, and two behavioural flags (whether a data source has been connected, whether an analysis has run) — these three for a new account, and for someone who gives consent later only the part their organizations show (below); at web sign-up also the self-declared role, team size and industry (for a CRM owner the role is the fixed value “client”). When the organization later moves to a paid plan, the plan is set to paid on the contacts of its owner accounts who consented; when it sends its first record or gets its first analysis, the flags are set to true on the same contacts. A person who consents after that — including in the CRM embedding, where an existing user or a non-owner can consent — has their plan and flags raised to what the organizations where they are an account owner show, never lowered, and nothing is written for what those organizations do not show. One event, when the organization uses 80 % of its included minutes: the email address, the organization's identifier, minutes used and included, and the language, for each organization administrator who consented. No call content, transcripts, caller data or customer data.	EU (Germany) — the SendPulse API endpoint resolves to Hetzner infrastructure in Falkenstein, Germany (verified 2026-08-02). SendPulse does not publish a per-account storage region, so this reflects the service endpoint rather than a contractual commitment.	SCCs retained (storage region not contractually confirmed)

Data sensitivity: MEDIUM for Resend — email bodies carry content derived from calls (quality metrics, AI-assigned categories, model-written alert reasons) and named employees' quality scores; no transcripts or audio. LOW for SendPulse — only the email addresses and onboarding and account-usage metadata of people who consented to marketing; no call content or transcripts.

Observability

#	Provider	Purpose	Data Processed	Location	Transfer Mechanism
8	Langfuse	LLM observability (traces, cost tracking) — active only when observability is enabled	LLM traces, token counts, latency. No raw transcripts.	EU (Germany)	Not required (EU→EU)

Data sensitivity: LOW — Operational traces only. No PII, no call content. Langfuse is an optional observability layer; when it is not enabled, no data is transmitted to it.

Application Monitoring & Error Tracking

#	Provider	Purpose	Data Processed	Location	Transfer Mechanism
9	Sentry	Error tracking, performance tracing, and session replay for the Aelo web application and its API layer. Not applied to the background call-processing pipeline, which does not currently send data to Sentry.	Platform user's name, email address, and Aelo account identifier (for signed-in users); the connecting device's IP address, received by Sentry's ingest endpoint at the network level (not attached to events by the application — `sendDefaultPii: false`); the URL (path) of the page or API request associated with an error or trace; error messages and stack traces, which can incidentally include data being processed at the time of the error; breadcrumbs — a short log of recent in-app navigation, network requests, and console output leading up to an event; session replay recordings for a sample of browser sessions (approximately 10%), and for every session in which an error occurs, with on-screen text and form inputs masked and media blocked by default	EU (Germany) — the Sentry organisation is hosted in the EU region for both the browser SDK and the API layer; ingest endpoints resolve to `ingest.de.sentry.io`. Sentry's operating entity is US-incorporated and may access data for support.	SCCs (cover vendor access, not storage)

Data sensitivity: MEDIUM–HIGH — unlike Langfuse above, Sentry receives the signed-in platform user's name, email address, and account identifier; the connecting IP address at the network level; breadcrumbs of recent navigation and network activity; and the URLs of pages and API requests. Session replay recordings mask on-screen text and block media by default, but URLs are not covered by that masking, and — beyond the roughly 10% sample — every session in which an error occurs is recorded. Error text is not filtered for content, so it can incidentally include data being processed at the time the error occurred.

Voice Analytics (Self-Hosted)

#	Provider	Purpose	Data Processed	Location	Transfer Mechanism
10	Hetzner	Infrastructure hosting for Aelo's self-hosted acoustic service, which derives objective voice-delivery metrics (speaking rate, pauses, pitch variation, voice stability) from call audio	Audio recordings (voice data), processed transiently — no audio is retained by the acoustic service	EU (Germany)	Not required (EU→EU)

Data sensitivity: HIGH — Audio recordings contain voice data (potential biometric data). The acoustic service is operated by Aelo on Hetzner infrastructure; it processes audio transiently (a temporary file that is deleted immediately after analysis) to compute metrics and does not retain recordings.

Alert & Notification Delivery

#	Provider	Purpose	Data Processed	Location	Transfer Mechanism
11	Telegram	Alert & notification delivery via Telegram's Bot API — an individual platform user's personal alert channel (opt-in: the user links their own chat through a one-time link to Aelo's platform bot), and, independently, a project-level team channel an org admin configures to point at a Telegram group	Message text only, sent through Aelo's own bot account: for a business alert, the rule name (as written in your organisation), its severity, the call category and a link back to Aelo, with a severity marker. No identity for either the other party to the call or the Aelo user associated with the record reaches Telegram — not a name, not a phone number, and not even a masked form of either — and no transcript excerpt or model-written explanation of why a rule fired. This applies to both personal and team destinations. Only business-alert messages are sent to Telegram; other notification types (record-ready, failure, billing and budget notices, collaboration, administration, system health) are not. Everything else stays in the platform, behind the recipient's normal access rights.	British Virgin Islands (Telegram Messenger Inc.); group companies in the BVI and Dubai, UAE	None offered — Telegram publishes no DPA and offers bot operators no SCCs (see below)

Data sensitivity: MEDIUM — no identity for either the other party to the call or the Aelo user associated with the record is sent to Telegram in any form. The recipient's own Telegram account identifies that recipient to Telegram,. Both Telegram destinations are opt-in: nothing is sent until the platform user links their own chat, or an org admin configures a destination group.

Telegram: what is and is not in place

We state this plainly rather than implying a protection that does not exist.

Who the counterparty is. Telegram's Bot Platform Developer Terms of Service form an agreement with Telegram Messenger Inc., a company incorporated in the British Virgin Islands (BVI Business Companies Act 2004; registered office c/o Vistra (BVI) Limited, Wickhams Cay II, Road Town, Tortola). Telegram's Privacy Policy names its parent Telegram Group Inc. and Telegraph Inc., both in the BVI, and Telegram FZ-LLC in Dubai, UAE.
Where the servers are. Telegram states that the data of users who signed up from the UK or the EEA is stored in third-party data centres in the Netherlands, on servers Telegram owns. That statement is scoped to where the Telegram account was registered; Telegram does not publish a storage location for bot traffic specifically, and a recipient who registered elsewhere is not covered by it.
No data processing agreement. Telegram publishes no DPA for the Bot API and offers bot operators no Standard Contractual Clauses. Its Bot Platform Developer Terms state that the relationship establishes no agency, partnership or joint venture, and that Telegram has no affiliation with bot developers; the data-protection obligations in those terms run from the bot operator, not to it. Telegram's Privacy Policy correspondingly describes a user's messages to a bot as data the user sends to a third-party bot developer. There are therefore no Article 28 processor commitments, no audit rights, and no sub-processor list from Telegram covering this channel.
No adequacy decision. Neither the British Virgin Islands nor the United Arab Emirates appears in the European Commission's list of countries and territories recognised as providing an adequate level of data protection.
What we do instead. Because no contractual safeguard is available, we limit the channel rather than the paperwork: it is off unless you turn it on, it is per-chat, and the payload is reduced. Since 12 August 2026 a Telegram message has carried no identity for either the other party to the call or the Aelo user associated with the record: no name, no phone number, no masked form of either, no transcript excerpt, and not the model's own written explanation of why the rule fired. A code allow-list also limits what can be sent: only business alerts are sent to Telegram, and any other notification type is not. You can disable either destination at any time, after which nothing further is sent.
Telegram's EEA representative. Telegram has designated the European Data Protection Office (EDPO), Avenue Huart Hamoir 71, 1030 Brussels, Belgium, as its representative under Article 27 GDPR.

If your organisation requires Article 46 safeguards for every recipient of personal data, do not enable Telegram delivery. Email, in-app notification, your own webhook and your own Bitrix24 chat remain available and are covered by the arrangements described elsewhere in this list.

Summary

#	Provider	Data Risk	Location
1	ElevenLabs	HIGH (audio)	US
2	OpenAI	HIGH (transcripts, analyses, criteria text, assistant questions, CRM entity names; redacted segments, search queries and assistant questions for search embeddings)	US
3	Clerk	MEDIUM (accounts)	US
4	Neon	HIGH (all data)	EU (Frankfurt) at rest; US vendor access
5	Cloudflare	HIGH (audio + metadata; search vectors with record and employee identifiers)	EU at rest (R2 Western Europe, D1 Eastern Europe); compute at the nearest edge; Vectorize search index (vectors and identifiers, no text) — region not pinned; Workflows state, Queues, Logs/Traces, Analytics Engine, KV, Durable Objects — not pinned to the EU
6	Resend	MEDIUM (call-derived metrics and alert reasons, named employee scores)	US
7	SendPulse	LOW (contact + onboarding and usage metadata; only for people who gave marketing consent)	EU (Germany) — endpoint verified, storage region not contractually confirmed
8	Langfuse	LOW (traces)	EU
9	Sentry	MEDIUM–HIGH (platform user identity incl. IP, page & API URLs, breadcrumbs, session replay; error text may incidentally include data being processed)	EU (Germany) — storage; US vendor access
10	Hetzner	HIGH (audio) — self-hosted acoustic service	EU (Germany)
11	Telegram	MEDIUM (recipient's own Telegram account; no other-party or Aelo-user identity in the message)	British Virgin Islands (group: BVI + UAE)

Not Sub-Processors

Integration	Why Not a Sub-Processor
Bitrix24	Customer's own CRM. Aelo sends data to a Customer-configured webhook URL, and — using the Customer's own connected Bitrix24 integration — posts messages to a Bitrix24 group chat the Customer designates (for example, team alert delivery), both on the Customer's instruction. Bitrix24 is the Customer's processor, not Aelo's sub-processor.
Uspacy CRM	Customer's own CRM. For the separately activated Calls Beta, Aelo receives subscribed CRM activity events, resolves completed calls, retrieves the Customer-provided recording and minimum related metadata, and writes the resulting note or supported CRM comment back to the Customer's own Uspacy space on the Customer's documented instruction. Uspacy operates under the Customer's own arrangements and is the Customer's processor, not Aelo's sub-processor.
Bitrix24 (Aelo's own portal)	Our own Bitrix24 portal, which we use as our CRM and support desk. When a signed-in user writes to us through the in-app support chat, their name, email address, avatar image URL (when set), organization name, subscription tier — with the subscription status appended when it is not active, e.g. "Pro (past_due)" — role, organization identifier, the page the app was on when that identity was loaded, and the content of the conversation itself are passed to that portal so the operator can help without asking who is writing. This is personal data we process as controller for our own support purposes (see Privacy Policy, Section B.3), not Customer call data processed on a Customer's behalf — no transcripts, recordings, or analysis results are involved.
Stripe	Our payment processor for Aelo's own billing (subscriptions, prepaid top-ups, auto-recharge). When a billing customer record is created, Stripe receives the organization name, the initiating user's email address, and Aelo's internal organization identifier; card details are collected by Stripe directly and never reach Aelo. This is personal data we process as controller for our own billing purposes (see Privacy Policy, Section B.4), not Customer call data processed on a Customer's behalf — no transcripts, recordings, or analysis results are involved.
n8n	Self-hosted by tenant. Aelo sends webhook to tenant-provided URL. n8n processes data under tenant's control.
Hosts the Customer designates in a `fileUrl`	Customer's own storage or telephony provider. When the Customer supplies a URL through the public API, Aelo opens an outbound connection to that address on the Customer's instruction and downloads the recording. The Customer chooses the host and controls what it serves; it holds the data under the Customer's own arrangements, not Aelo's. No additional sub-processor is involved in the retrieval itself: the hostname is resolved and the downloaded file is stored through Cloudflare (sub-processor #5 above, whose scope already covers R2 storage and all data in transit).
The Customer's own telephony provider	The Customer's own telephony service, connected in one of two ways, both on the Customer's documented instruction. With the Customer's own credentials (UniTalk, Binotel, Stream Telecom): the Customer enters the credentials for their own account with that provider, and Aelo calls the provider's API with them to read the call log, download the recording of a completed call, and read the line directory used to label which line a call arrived on. By webhook (Ringostat): the provider posts completed calls to Aelo and supplies the recording's address in the payload, which Aelo then opens to download the file; Aelo holds no credentials for that provider and does not call its API. In both cases Aelo does not choose the provider, holds no commercial relationship with it, and does not determine which calls it records or how long it keeps them — the Customer configures what is in scope. The provider holds that data under the Customer's own arrangements and is the Customer's processor, not Aelo's sub-processor. Once a recording is downloaded it is stored through Cloudflare (sub-processor #5 above) and processed by the sub-processors listed in this document.
Customer-configured alert & notification webhooks	An endpoint the organization (project team channel) or an individual platform user (personal channel) configures to receive alert notifications. Aelo sends an HTTP POST to the organization- or user-designated URL on their instruction; the receiving system is operated under their own arrangements, not Aelo's.

Change Notification Policy

New sub-processor: Customers notified via email at least 30 days before processing begins
Objection right: Customers may object within the 30-day notice period
Removal: If objection cannot be resolved, customer may terminate the affected service
Updates: Published at this URL and in the Aelo documentation

Contact

For questions about sub-processors or data processing:

Auspex Streamline S.L.
C.I.F.: B56341829
Calle Velarde 13, 4B
35010 Las Palmas de Gran Canaria
Canarias, Spain
Email: privacy@aelo.cloud

Deepgram removal: Deepgram was removed as a sub-processor on 2026-09-11 and is no longer engaged for any tenant. Aelo's code no longer contains a Deepgram integration: no code path can transmit data to it, and no service reads a Deepgram credential. Removing a sub-processor requires no advance notice under the Change Notification Policy above, which governs additions; this entry records the change. The last audio processed by Deepgram was on 2026-05-01.

Sentry sub-processor entry: integrated since 2025-10-31 (both apps). The browser SDK was dark in production from 2026-02-19 to 2026-06-10 due to a malformed DSN configuration value — not continuous use throughout that window. This entry disclosed as of version 1.12 (the prior versions 1.10 and 1.11 existed only in an unmerged branch and were never published).

Search entries (OpenAI embeddings; Cloudflare Vectorize): in use since October 2025, disclosed as of version 1.23. Until release 2.44.0 (2026-09-25) each vector was stored together with the text of its transcript segment, to which the pattern-based PII redaction had not been applied, and with the segment’s speaker label and timestamp, and search queries were sent for embedding without it; that text was removed from the index — by a full rebuild of the index and a purge of the vectors of deleted records — before this disclosure was published.

OpenAI entry, corrected in version 1.26: version 1.25 listed the text of the Customer's criteria under “with PII redaction applied”; criteria wording was not redacted at all at that time (from version 1.27, phone numbers, emails, card numbers and IBANs in it are masked; names and the rest of the wording are sent as written). Versions up to 1.25 also did not say that pattern-based redaction leaves names in place (CRM entity names, a customer name in an assistant filter), nor name the Customer configuration and the employee and other-party names, which were sent without any redaction.

Version 1.27: the analysis-profile text is no longer listed — a custom analysis profile's prompt text is stored but not sent to OpenAI; the analysis is built from the profile's category and settings.

Version 1.28: the Resend entry now lists what transactional emails carry. Earlier versions said “Email addresses, delivery metadata. No call content.” and rated it LOW; analysis-report emails, alerts and role digests already carried the quality metrics, masked caller references, model-written alert reasons and employee scores listed above.

Version 1.29: the Resend entry adds the record link in alert and record-notification emails, the channel and masked caller reference in failure notices, the organisation name in minute warnings and pause notices, and the bonus-minute offer in an eligible free-tier organisation's pause notice; the Resend mechanism now says its DPF certification covers non-HR data, with SCCs for employee-performance data.

Version 1.30: the SendPulse entry now lists everything that is sent and says it is sent only for a person with marketing consent. Earlier versions said so for the onboarding series, but the plan update on upgrade, the two onboarding flags and the 80 % minutes event (which carries the organization identifier and the minutes) were sent for the organization's first client or administrator without checking consent; they are now sent only for a person who has it.

Version 1.31: the Telegram entry now states that only business-alert messages are sent to Telegram (rule name, severity, call category, link) and that other notification types are not; this is enforced by an allow-list in the sending code.

Version 1.32: the Cloudflare entry now names the stores that are not pinned to the EU — Workflows state, Queues, Workers Logs/Traces, Workers Analytics Engine, KV and Durable Objects. Earlier versions named only the database and the audio storage as the stores holding customer content, although Workflows state and Queues also hold transcript and chat text for days.

Version 1.33: the Resend entry adds the objections block of the daily client and supervisor digest — up to five unhandled objection reasons of the previous day by their standard names, their conversation counts and the share of objections that could not be recognized, with no customer wording.

Version 1.34: OpenAI's purpose adds the extraction of customer questions and decline reasons for the Voice of Customer section (Pro plan and above) — a separate request over the same redacted transcript; no new sub-processor.

Document ID: SPL-Aelo-2026-001 · Version: 1.34