Privacy Policy
1. Introduction
This Privacy Policy explains how Auspex Streamline S.L. ("Auspex", "we", "us") processes personal data in connection with Aelo — AI Communication Analyzer ("Service", "Platform").
Aelo is a B2B SaaS platform that provides AI-powered call analysis for businesses. We act as a data processor — our customers ("Customers", "Controllers") record calls and decide how the data is used. We process the data on their behalf, according to their instructions.
This policy covers two types of data processing:
- Section A: Data we process on behalf of Customers (call recordings, transcripts, analyses) — we act as Processor
- Section B: Data we process for our own purposes (platform accounts, website visitors) — we act as Controller
Section A: Processing on Behalf of Customers (Processor)
A.1 Our Role
When Customers use Aelo to analyze calls, the Customer is the Controller and we are the Processor. This means:
| Responsibility | Who |
|---|---|
| Deciding to record calls | Customer (Controller) |
| Obtaining consent from call participants | Customer (Controller) |
| Informing call participants about recording and AI analysis | Customer (Controller) |
| Determining retention periods | Customer (Controller) — configurable 1–365 days; 365 by default |
| Responding to data subject rights requests | Customer (Controller), using the tracked workflow and applicable product or support procedure |
| Securely processing and storing data | Auspex (Processor) |
| Providing rights-request tracking and applicable product or support procedures | Auspex (Processor) |
| Ensuring sub-processor compliance | Auspex (Processor) |
A.2 Data We Process on Behalf of Customers
| Data Category | Description | Retention |
|---|---|---|
| Audio recordings | Call recordings supplied by the Customer — uploaded through the app, sent through the public API (directly, or as a URL for Aelo to fetch — see A.3), or received via webhook from connected telephony/CRM | Customer's retention period (365 days by default, configurable 1–365); deleted together with transcripts |
| Transcripts | Text transcriptions generated from audio by ASR providers | Customer's retention period (365 days by default, configurable 1–365) |
| Search vectors | Numerical vector representations (embeddings) of segments of call transcripts and chat conversations, computed after the pattern-based PII redaction described in A.3 and stored in Cloudflare Vectorize so that users can find records by meaning. Each vector is stored with the identifiers of the record, project, organization and transcript it belongs to, the record type (call or chat) and the segment's length, and — when known — an identifier of the employee who handled the conversation (their user ID in Aelo, in the connected CRM or telephony, or the value supplied through the public API) and the record's date — and without any transcript or chat text; the text shown next to a search result is read from the stored transcript. | Follow the record: rebuilt from the current transcript when the record is transcribed again (if that build fails, the earlier vectors stay until the next index rebuild) or the index is rebuilt, and removed from the index after the record is deleted — by a user, at the end of the retention period or together with its project — normally within a few hours; while a large volume of deletions is being processed, removal can take several days |
| AI analyses | Quality scores, sentiment analysis, key points, sales indicators | Follows transcript retention |
| Criteria and their answers | Questions the Customer defines to be asked of every conversation — the name, the question, optional guidance on what counts, the answer values, and where the criterion applies (conversation categories, projects, channels) — and, for each analysed conversation within a criterion's scope, its answer: yes or no, a 0–100 score or one of the Customer's values, or that no confident answer was possible, with verbatim quotes taken from the PII-redacted transcript, a short explanation written by the model and — when known — an identifier of the employee who handled the conversation (their user ID in Aelo, in the connected CRM or telephony, or the value supplied through the public API) | Answers follow transcript retention and are deleted together with the record; criteria themselves are kept for the duration of the Customer's account (an archived criterion is kept so that past answers stay readable) and are cascade-deleted when the account is deleted |
| Customer questions and decline reasons | For an organisation with the Voice of Customer section (Pro plan and above), for each conversation analysed after this was introduced: the questions the customer asked — a one-sentence summary written by the model, the customer's verbatim words taken from the PII-redacted transcript, for a call the second at which they were said, the question's subject (from a fixed list), whether the employee answered it and at which stage of the conversation it was asked; and, for a sales conversation, how it ended (progressed, postponed, declined or no decision) and, when the customer declined, the reason (from a fixed list) in the customer's words with their verbatim quote, and whether the customer stated the reason or the model inferred it. Phone numbers, emails, card numbers and IBANs in them are masked, and a summary or quote that may contain an identification number (such as a contract or order number) is not stored | Follows transcript retention; deleted together with the record and its analysis |
| Voice-delivery metrics | Objective acoustic measurements derived from call audio — speaking rate, pause patterns, pitch variation, and voice stability. Not voiceprints and not used to identify individuals. | Follows transcript retention |
| Communication metadata | Phone numbers, call duration, timestamps, caller IDs | Follows transcript retention |
| Alert data | Notifications triggered by analysis thresholds. Always shown in-app; additionally delivered by email and the recipient's configured personal channels. Personal email and webhook messages may include a masked caller reference — first name with surname initial, or the last 3 digits of the phone number — and an AI-generated reason when present. Personal Telegram receives only business alerts, in a contact-free form with neither the caller reference nor the AI-generated reason; no other notification type is sent to Telegram. Project team channels receive a reduced summary — rule, severity, call category and record link — with no identity for either the other party to the call or the platform user associated with the record, no phone number, transcript excerpt or AI-generated reason. | Follows transcript retention |
| Emailed reports and digests | Email addresses the Customer configures for a project to receive analysis reports (which need not belong to Aelo users), and the reports, notifications and digests emailed to them and to the Customer's users — see A.3 and, for what each email carries, the Sub-Processor List | Recipient addresses: until the Customer changes them or the account is closed. Emails already sent are outside Aelo's control: copies stay in the recipients' mailboxes and in the email provider's delivery logs, and deleting a record does not recall an email sent about it |
| CRM deal-stage data | When the Customer connects Bitrix24 and enables stage-based evaluation, the linked deal's CRM stage ID, pipeline/funnel identifier, and stage phase (e.g. discovery, negotiation) — captured at analysis time to select the matching evaluation scorecard. Where Bitrix24 gives the stage no phase, Aelo uses the phase the Customer set for that stage or, failing that, derives it from the stage's name and marks it as derived. Applies only to calls linked to a Bitrix24 deal. Additionally, once per call, Aelo reads the deal's stage history to determine whether the deal advanced, held, or regressed in the ~7 days after the call (or by deal close), storing that per-call result to show a progression indicator in the Customer's dashboard. | Follows transcript retention |
| CRM org-structure data | When the Customer connects Bitrix24 and runs the org-structure import (Settings → Team → Org Structure), Aelo reads the portal's department tree and employee directory and stores: department identifiers, names, parent-department links and sort order; which employees belong to which departments; and the department head named by the portal. Employees are matched to existing Aelo accounts by email address, and the resulting pairing of the portal's user ID with the Aelo account is stored. For portal employees with no matching Aelo account, Aelo stores the portal's own identifier for that employee, their email address when the portal provides one, their name, and their department membership — shown to the administrator by name so the gap can be resolved — until an Aelo account for them is created (when an invitation is sent to them, or through their first sign-in inside the connected CRM's embedded app), at which point Aelo links the two automatically and deletes this interim record. The same applies to a department head the portal names who has no Aelo account yet: the head's portal identifier and name are stored on the department. If Aelo can identify that head's new account using the portal's own identifier, access to the department's records is granted automatically, unless an administrator has manually assigned a different head, which always takes precedence and survives later imports. This data determines which call records a department head may open — a head sees the records of everyone below them in the tree. The import replaces the previously imported tree in full. | Duration of the Customer's account (cascade-deleted when the account is deleted); the tree is replaced in full on each import, and an individual not-yet-matched employee's record is deleted sooner, as soon as an Aelo account for them is linked |
| CRM deal-outcome data | When the Customer connects Bitrix24 and enables stage-based evaluation, the linked deal's outcome status (open/won/lost), pipeline/stage identifiers, and close and sync timestamps — synced periodically from Bitrix24 to show a deal-outcome funnel (call volume by won/lost, broken down by average call-quality score) in the Customer's dashboard. Applies only to deals in a connected Bitrix24 pipeline. | Duration of the Customer's account (cascade-deleted when the account is deleted) |
| Assistant conversations | Questions a Customer's user asks the AI assistant about a call or chat record, or about a CRM deal, lead, contact or company across the records linked to it, or about all the records the user may see; for a question about all records, the filters it was asked under (period, project, agent, record type, category, customer name); the generated answers with the transcript excerpts and timecodes they cite; the list of records each answer was built from; and the identity of the asking user. Questions receive the same pattern-based PII redaction as transcripts before they are stored, and only the stored text is sent to the LLM provider. | Customer's retention period (365 days by default, configurable 1–365); a question and its answer are also deleted when the record they were asked about, or any record the answer was built from, is deleted — usually together with that record, otherwise by a routine scheduled cleanup |
A.3 How We Process This Data
- Customer supplies audio — uploaded through the app, sent through the public API, or received via webhook from connected telephony/CRM
- Alternatively, on the Customer's instruction, Aelo retrieves the audio itself: the Customer supplies a URL through the public API, and Aelo opens an outbound HTTPS connection to that address and downloads the file. The Customer designates the host; Aelo resolves the hostname through Cloudflare's DNS-over-HTTPS resolver (1.1.1.1) before connecting, and stores the downloaded file as in the next step
- Aelo validates and stores audio (encrypted, Cloudflare R2 with AES-256-GCM server-side encryption)
- Audio sent to the ASR provider (ElevenLabs) for transcription
- PII redaction applied to the transcript (phone numbers, emails, payment card numbers, IBANs) on the current application repository write paths — before it is stored; see the next step for the scope and limits of this control
- For new transcripts processed through the current application repository write paths, the redacted transcript is stored in Neon PostgreSQL and the unredacted transcript text is not retained through those paths. This control was not applied retroactively: earlier transcript, preview, metadata and word-timestamp rows were not rewritten and may retain the text originally written. All such rows remain subject to the Customer's configured retention period. Original audio is not text-redacted and is retained as described in A.2.
- If the Customer has connected Bitrix24 and enabled stage-based evaluation, and the call is linked to a Bitrix24 deal, Aelo reads the deal's current CRM stage (stage, pipeline, and phase — where Bitrix24 gives none, the phase the Customer set for the stage, else one derived from the stage name) to select the evaluation scorecard used in the next step
- Transcript (with PII redaction applied) sent to OpenAI for analysis
- If the Customer has defined criteria, the redacted transcript is sent to OpenAI again, in a separate request, together with the wording of the criteria that apply to the conversation (question, guidance and answer values, as the Customer wrote them; at most phone numbers, emails, card numbers and IBANs are masked), to answer them; the answers and their quotes are stored (see A.2). When the Customer checks a criterion's wording before saving it, the same is done for up to 20 recent analysed conversations within the criterion's scope with the draft wording; those answers are shown to the Customer and not stored
- If the Customer's organisation has the Voice of Customer section (Pro plan and above), the redacted transcript is sent to OpenAI again, in a separate request, to find the questions the customer asked and, for a sales conversation, how it ended and the reason the customer declined; the results and their quotes are stored (see A.2). Conversations analysed before this was introduced are not processed in bulk; a conversation the Customer re-analyses is processed like a new one
- For search by meaning, segments of the transcript — or of the chat conversation — and the text a user types into search, both with the same PII redaction applied, are sent to OpenAI to compute numerical vector representations (embeddings). Only the vectors of the segments are stored, in Cloudflare Vectorize, with the identifiers listed in A.2 and without the text; the vector of a search query is used for that search only and is not stored
- When a Customer's user asks the AI assistant a question about a call, the question (with the same PII redaction applied) is sent to OpenAI together with the redacted transcript and the stored analysis of that record to generate the answer; the question, the answer and the excerpts it cites are stored as an assistant conversation (see A.2)
- When a Customer's user asks the AI assistant a question about all the records they may see, the question (with the same PII redaction applied) is sent to OpenAI's embeddings endpoint to find the closest records by meaning in the search index, and the redacted transcripts and analyses of up to 12 of the closest records the user may see, within the filters they chose, are sent to OpenAI to generate the answer, together with the filters the question was asked under (period, record type, category and customer name); the question's vector is not stored, and when no record matches, no answer is generated by the model
- When the question is about a CRM deal, lead, contact or company, what is sent to OpenAI is drawn only from the records linked to it that this user is permitted to see (up to the 2,000 most recent): the name of the CRM entity (with the same PII redaction applied) and, for a deal, its outcome in the CRM where known (won, lost or still open); a one-line index of those records with their date, type and a short summary of their stored analysis; and, within a fixed size limit and most relevant to the question first, their stored analyses and redacted transcripts. The conversation is stored the same way (see A.2)
- Call audio is additionally processed by Aelo's self-hosted acoustic service (hosted on Hetzner infrastructure in Germany, EU) to derive objective voice-delivery metrics (speaking rate, pauses, pitch variation, voice stability); the audio is processed transiently and not retained by that service
- Analysis results stored and delivered to Customer's CRM. Where the Customer has connected a CRM, Aelo also delivers the call transcript there: attached to the call record when the Customer switches that on; posted to the timeline of the call item when delivery targets a Bitrix24 Smart Process, alongside the analysis report; and written into a CRM field the Customer designates only if the Customer switches that on (off by default). Each carries the transcript as stored by Aelo, with the PII redaction described in A.3 already applied; the field copy is truncated when it exceeds the field's capacity
- Aelo emails analysis reports (the record's quality metrics) to the addresses the Customer configures for a project, which need not belong to Aelo users. Daily or weekly role digests and a monthly Voice of Customer email go to the Customer's users by default, and each user can switch them off; a supervisor's digest names employees with their quality scores. These emails are sent through Resend (A.4); what each one carries is listed in the Sub-Processor List. Emails never carry transcripts or audio
- If the analysis triggers a business alert rule, Aelo delivers a notification: always in-app; additionally by the channels the recipient or organization configured. Personal email and webhook messages may include a masked caller reference and the model's short written reason. Personal Telegram receives only business alerts, with neither field; no other notification type is sent to Telegram. Project team channels receive a reduced message containing rule, severity, call category and record link, with no identity for either the other party to the call or the platform user associated with the record, no transcript excerpt or model-generated reason
- On a recurring schedule, if the Customer has connected Bitrix24 and enabled stage-based evaluation, Aelo re-checks each linked deal's status in Bitrix24 (pipeline, stage, and won/lost outcome) to keep the deal-outcome funnel in the Customer's dashboard current, and reads the deal's stage history to determine whether it advanced, held, or regressed after the call, storing that per-call result to display a progression indicator alongside the call
- Data retained for the Customer's configured retention period — 365 days by default, adjustable by the Customer between 1 and 365 days (see A.2) — then automatically deleted
A.4 Sub-Processors
We use third-party sub-processors to provide the Service. The complete list is maintained at our Sub-Processor List.
| Provider | Purpose | Location |
|---|---|---|
| ElevenLabs | Speech-to-text transcription | US |
| OpenAI | AI analysis of transcripts, answers to criteria and to assistant questions, extraction of customer questions and decline reasons, and search embeddings (transcripts pattern-redacted; Customer configuration and names sent without anonymisation — at most phone numbers, emails, card numbers and IBANs in them are masked; see the Sub-Processor List) | US |
| Neon | Database storage | EU (Frankfurt) at rest; US vendor access |
| Cloudflare | Infrastructure, audio storage, search index (vectors and identifiers, no transcript text) | EU at rest (audio in Western Europe, metadata in Eastern Europe); compute at the nearest edge; the search index region is not pinned; Workflows state, Queues, Workers Logs/Traces, Workers Analytics Engine, KV and Durable Objects are not pinned to the EU — Workflows state and Queues hold transcript and chat text while a record is processed and for a few days after (see the Sub-Processor List) |
| Hetzner | Self-hosted acoustic voice-metrics service (audio processing) | EU (Germany) |
| Clerk | Platform authentication | US |
| Resend | Email delivery of analysis reports, alerts, record notifications and digests — see the Sub-Processor List for what each email carries; no transcripts or audio | US |
| SendPulse | Marketing email automation (onboarding series and the usage signals that steer it) — Aelo's own, as controller; everything is sent only for a person who gave separate marketing consent (see B.5); no call content | EU (Germany) — endpoint verified; storage region not contractually confirmed |
| Langfuse | LLM observability (optional; traces only, no transcripts) | EU |
| Sentry | Error tracking, performance tracing, and session replay for the web application and API — not the call-processing pipeline. Receives the signed-in platform user's name, email, and account identifier; the connecting IP address at the network level; page/API URLs; breadcrumbs of recent navigation and network activity; error text, which can incidentally include data being processed at the time of the error; session replay recordings for a sample of sessions (~10%) and for every session in which an error occurs, with on-screen content masked. See the Sub-Processor List for the full breakdown. | EU (Germany) — storage; US vendor access |
| Telegram | Opt-in alert delivery through Telegram's Bot API. Personal and team Telegram messages contain no identity for either the other party to the call or the Aelo user associated with the record, no phone number in any form, no transcript excerpt and no model-generated reason. Only business-alert messages are sent to Telegram; other notification types are not. No DPA or SCCs are offered by Telegram for the Bot API — see A.5 and the Sub-Processor List | British Virgin Islands (group: BVI + UAE) |
Customers are notified at least 30 days before any new sub-processor is added. The complete, authoritative list (with transfer mechanisms) is maintained at our Sub-Processor List.
A.5 International Data Transfers
Auspex Streamline S.L. is established in Spain (EU). Some sub-processors are located in the United States.
For transfers of personal data outside the EU/EEA, we rely on:
- EU-US Data Privacy Framework (DPF) — where the sub-processor is DPF-certified
- Standard Contractual Clauses (SCCs) — the 2021 version approved by the European Commission
- Transfer Impact Assessments (TIAs) — conducted for each transfer
One exception, stated plainly: Telegram alert delivery. Telegram Messenger Inc. is incorporated in the British Virgin Islands, publishes no data processing agreement for its Bot API and offers bot operators no Standard Contractual Clauses; neither the British Virgin Islands nor the UAE holds a European Commission adequacy decision. None of the three mechanisms above is therefore available for this one destination. The channel is off by default and sends nothing until you or one of your users explicitly connects a chat; what is sent is reduced and limited to business alerts (see the Sub-Processor List for the exact fields). If your organisation requires a contractual safeguard for every recipient, do not enable it — the other delivery channels are unaffected.
A.6 Security Measures
| Category | Measures |
|---|---|
| Encryption | TLS 1.2+ in transit; AES-256-GCM server-side encryption at rest (R2 SSE active by default); database encryption (Neon native); provider API credentials (speech recognition, AI analysis, email delivery) and the credentials of connected telephony and CRM integrations additionally sealed by the application with AES-256-GCM and bound to their own record, so a database read alone does not yield a usable key |
| Access control | Role-based access (RBAC); organization-level tenant isolation |
| Data minimization | For new transcripts processed through current application repository paths, pattern-based PII redaction (phone, email, payment card, valid IBAN) is applied on write and before LLM processing. Original audio is unchanged; word-level timestamps are not retained for records processed after this control was introduced, while earlier transcript, preview, metadata and word-timestamp rows were not migrated; Customer-configured retention (365 days by default, 1–365 range) |
| Integrity | Webhook authentication: per-installation secret, HMAC signature or sender IP allowlist, depending on the provider; Zod input validation; SQL injection prevention (ORM) |
| Availability | Cloudflare edge network; database replication; idempotent processing |
| Monitoring | Production logs capture denied authorization attempts and selected security-relevant events. Coverage does not extend to a customer-facing history of every action. |
| Authentication | Interactive access: multi-factor authentication via Clerk. Programmatic access (public API): bearer API keys issued per organization, which do not use Clerk or multi-factor authentication — a key is stored only as a SHA-256 hash (the plaintext is shown once at creation and never retained), is valid solely for the organization that issued it, carries separate read and write scopes, may be given an expiry, and takes effect as revoked on the next request after revocation |
A.7 Data Subject Rights
Call participants (Data Subjects) should contact the Customer (Controller) to exercise their rights. The Customer is responsible for verifying the identity of the Data Subject, recording and reviewing the request in Aelo where applicable, fulfilling the approved request through the available product or support procedure, and responding within the legally required timeframe. Aelo's DSR workflow tracks requests and decisions but does not yet execute approved requests automatically.
| Right | GDPR Article | How Aelo supports the request |
|---|---|---|
| Right of access | Art. 15 | Request intake, review and status tracking; approved request fulfilled through available export/support procedures |
| Right to erasure | Art. 17 | Request intake, review and status tracking; approved deletion performed through available deletion/support procedures |
| Right to rectification | Art. 16 | Request intake, review and status tracking; approved correction handled through the applicable product/support procedure |
| Right to data portability | Art. 20 | Request tracking plus available machine-readable exports; scope confirmed per request |
| Right to object | Art. 21 | Request intake, review and status tracking |
| Right to restrict processing | Art. 18 | Handled through the Controller's documented instruction and applicable support procedure |
| Withdraw consent | Art. 7(3) | Consent event can be recorded; downstream action depends on the applicable processing context |
A.8 Recording and Interception of Communications (ePrivacy)
The recording and interception of electronic communications is regulated by the ePrivacy Directive (2002/58/EC, Article 5(1)) and its national implementations. The Customer (Controller) is solely responsible for complying with applicable ePrivacy/telecommunications laws when recording calls, obtaining any required consent for recording under national law, and providing required pre-recording announcements or notifications.
The Customer, as Controller, determines the legal basis for recording and analysing communications under the laws applicable to it. To assist Controllers in demonstrating compliance, Aelo provides a consent journal — an audit trail of consent events recorded per organization and per call record, including consent withdrawal. However, Aelo does not record calls — the Customer's telephony system performs the recording and transmits audio to Aelo for processing.
A.9 AI Processing
Aelo uses artificial intelligence to analyze call transcripts. Important limitations:
- Employee emotion recognition in the workplace is a prohibited practice under the EU AI Act (Art. 5(1)(f)), in force since 2 February 2025. Aelo does not perform emotion recognition or emotion scoring of agents or call participants.
- Sentiment analysis is text-only and customer-side only. The sentiment values in an analysis are computed by the language model from the transcript text alone, and they measure the customer's expressed sentiment during the conversation. The system does not produce a sentiment or emotion score for the agent/employee.
- Voice-delivery metrics are call-mechanics measurements, not emotion signals. Of the acoustic measurements, only three operational values — speaking rate, speech-to-silence ratio, and pause count — are shared with the language model, under an explicit instruction not to infer any participant's emotional state from them. Pitch variation, voice stability, and loudness are never included in model prompts, and no acoustic measurement contributes to any score.
- AI assistant answers are AI output, not verified statements. The assistant answers only from the transcripts and analyses it is given — of the record, of the linked records of a CRM deal, lead, contact or company, or of up to 12 records matching a question about all records, in each case among those the user may see — and cites the excerpts it relied on; a claim it cannot match to the transcript is marked as not confirmed. The limitation on automated decision-making below applies to these answers as well.
- AI analysis results are not used for automated decision-making with legal or significant effects without human review (GDPR Art. 22).
- Customers must inform call participants that AI is used to analyze calls (AI Act Art. 50 transparency obligation).
A.10 Data Breach Notification
In the event of a personal data breach affecting Customer data:
- We notify the Customer without undue delay and in any event within 48 hours of becoming aware
- We provide: nature of breach, categories and approximate number of records affected, likely consequences, measures taken
- The Customer is responsible for notifying the supervisory authority (within 72 hours for GDPR) and affected Data Subjects
Section B: Processing for Our Own Purposes (Controller)
B.1 Platform User Accounts
| Element | Description |
|---|---|
| Data subjects | Customer employees who access the Aelo platform |
| Data collected | Name, email address, role, organization, login history |
| Purpose | Platform authentication, authorization, usage analytics |
| Legal basis | Performance of contract (Art. 6(1)(b)) |
| Retention | Duration of service + 30 days post-termination |
| Third parties | Clerk (authentication), Cloudflare (infrastructure), Sentry (error tracking and performance monitoring — records the signed-in user's name, email address, and account identifier; see A.4), Resend (account and invitation emails — the user's or inviter's name, the organisation name, the role and the invitation link; US, EU-US Data Privacy Framework) |
B.2 Website Visitors
| Element | Description |
|---|---|
| Data subjects | Visitors to our website and documentation |
| Data collected | IP address, browser information, pages visited |
| Purpose | Website functionality, analytics, security |
| Legal basis | Legitimate interest (Art. 6(1)(f)) |
| Retention | 90 days |
| Third parties | Cloudflare (CDN, security); Umami (self-hosted, cookieless analytics — aggregate page-visit statistics only) |
B.3 Support Conversations
| Element | Description |
|---|---|
| Data subjects | Platform users who contact us through the in-app support chat |
| Data collected | 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 (address and path only, without query parameters), and the content of the conversation itself. Passed automatically when the user is signed in, so the conversation does not begin with identification questions. |
| Purpose | Answering support requests, and recognising a returning user so their earlier conversations remain available to the operator |
| Legal basis | Performance of contract (Art. 6(1)(b)) |
| Retention | Duration of service + 30 days post-termination |
| Third parties | Bitrix24 (Aelo's own portal, used as our CRM and support desk) |
B.4 Billing
| Element | Description |
|---|---|
| Data subjects | The platform user who initiates a payment action (subscribing, topping up prepaid credit, or saving a card for auto-recharge) on behalf of their organization |
| Data collected | Organization name, the initiating user's email address, and Aelo's internal organization identifier — passed to our payment processor when a billing customer record is created. This applies to every self-serve payment, including prepaid top-ups by Pay-as-you-go organizations that have no subscription. Card details are collected directly by the payment processor on its own pages and never reach Aelo's systems. |
| Purpose | Subscription billing, prepaid credit top-ups, auto-recharge, invoicing, and payment records required by tax and accounting law |
| Legal basis | Performance of contract (Art. 6(1)(b)); legal obligation (Art. 6(1)(c)) for tax/accounting records |
| Retention | Duration of service; payment records thereafter as required by applicable tax and accounting law |
| Third parties | Stripe (payment processing; US — EU-US Data Privacy Framework). Resend (budget, balance and auto-recharge notices and minute-usage emails — amounts spent, budget limits, the prepaid balance, the top-up amount and number of failed attempts, and minute usage with the organisation name; the pause notice of an eligible free-tier organisation also offers bonus minutes with a deadline; US, EU-US Data Privacy Framework). Stripe processes payment data for our own billing as our processor; it is not a sub-processor of Call Data — see the Sub-Processor List |
B.5 Marketing Email (Newsletter & Onboarding Series)
| Element | Description |
|---|---|
| Data subjects | A person who asks for the newsletter, in any of the three places we offer it: the marketing checkbox at web sign-up or in the embedded Marketplace flow; the one-time question shown when a CRM portal account is linked to a web account; or Settings › Notifications, where it can be switched on and off at any time. Recorded per PERSON, not per organization: the consent is attributed to that user, and nobody else in the organization is enrolled by it — installing the CRM app seeds an organization's whole staff, and none of them are subscribed by that. Outside the embedded consent screen only an account owner or administrator is offered the newsletter; the checkbox on the embedded consent screen is shown to every user who signs in there with a deliverable e-mail address, whatever their role, and ticking it subscribes that person alone. An account with no deliverable e-mail address — as a CRM portal user has before linking — cannot be subscribed under any circumstances |
| Data collected | Email address, plus the contact variables that decide which message is sent: display name, interface locale, self-declared role, team size and industry (both optional, absent from the embedded flow), the signup source and date, the plan (free/paid), and two behavioural milestone flags — whether a data source has been connected and whether an analysis has run. Beyond sign-up, three updates reach the same contact, each only for a person who holds this consent: the plan changes to paid when the organization moves to a paid plan; the two flags are set when the organization sends its first record and gets its first analysis; and, when the organization has used 80 % of its included minutes, one event carrying your email address, the organization's identifier, the minutes used and included, and the language, sent for each administrator who consented. If you consent after your organization is already active (at sign-up, in Settings or in the CRM embedding), your plan and flags are raised to what the organizations where you are an account owner show, never lowered, and nothing is written for what they do not show. No call content, no transcripts, no customer data of any kind |
| Purpose | The onboarding email series: setup guidance, feature introductions, and product news — and the signals above, which only decide which message is sent (for example, no reminder to connect a source once one is connected, and no upgrade message once the plan is paid or the 80 % threshold is reached) |
| Legal basis | Consent (Art. 6(1)(a)). Always a separate, unticked opt-in or an explicit action of its own — never bundled with the Terms or this Policy, which are a precondition of using the product, and never a default. The grant is written to the consent journal with the user, timestamp and document versions, and neither the series nor any of the signals above is sent without it: the organization's first client or administrator is not enough, each person must hold the consent themselves. Withdrawing it stops all of them |
| Retention | Until consent is withdrawn or the account is closed; the withdrawal event itself is retained as evidence of when consent ended |
| Third parties | SendPulse (marketing email automation, receiving only what is listed under Data collected; see A.4 and the Sub-Processor List) |
| How to withdraw | Withdraw it in the platform under Settings › Notifications (consent type marketing_email) — the same place it is switched on, so withdrawing is no harder than consenting — use the unsubscribe link in any message of the series, or write to privacy@aelo.cloud — each one stops delivery. A withdrawal recorded in the platform is written to the consent journal against your user and unsubscribes your address from the series; because it is attributed to you personally, it affects only your subscription and no colleague's. Withdrawing marketing consent changes nothing about the service — it is not a precondition of anything |
B.6 Your Rights (Section B Data)
For data we process as Controller (Section B), you can exercise the following rights by contacting us at privacy@aelo.cloud:
- Access — Request a copy of your personal data
- Rectification — Correct inaccurate data
- Erasure — Request deletion of your data
- Restriction — Limit how we process your data
- Portability — Receive your data in a portable format
- Object — Object to processing based on legitimate interest
- Withdraw consent — For marketing communications
We will respond within 30 days (GDPR) or 45 days (CCPA). You also have the right to lodge a complaint with your local supervisory authority. For Spain: Agencia Española de Protección de Datos (AEPD), www.aepd.es.
4. Children's Data
Aelo is a B2B service not directed at children. We do not knowingly process personal data of children under 16.
5. Changes to This Policy
We may update this Privacy Policy from time to time. Material changes will be communicated to Customers via email at least 30 days before they take effect.
6. Contact
Data Processor / Controller:
Auspex Streamline S.L.
C.I.F.: B56341829
Calle Velarde 13, 4B
35010 Las Palmas de Gran Canaria
Canarias, Spain
Privacy inquiries: privacy@aelo.cloud
For call participants: Please contact the company that recorded your call. They are the Controller of your data and responsible for responding to your requests.
Document ID: PP-Aelo-2026-001 · Version: 1.40