Data Processing Agreement
Controller ("Customer"): [Your organization]
Processor: Auspex Streamline S.L., C.I.F.: B56341829, Calle Velarde 13, 4B, 35010 Las Palmas de Gran Canaria, Canarias, Spain ("Aelo")
This Data Processing Agreement ("DPA") forms part of the Terms of Service between Controller and Processor for the use of Aelo — AI Communication Analyzer ("Services").
1. Definitions
- "Data Protection Laws" — GDPR (Regulation (EU) 2016/679), and applicable national data protection laws including CCPA, UK GDPR, LGPD.
- "Personal Data" — Any information relating to an identified or identifiable natural person, processed by Processor on behalf of Controller.
- "Sub-processor" — Any third party engaged by Processor to process Personal Data on behalf of Controller.
- "Standard Contractual Clauses" ("SCCs") — The clauses approved by European Commission Implementing Decision (EU) 2021/914.
2. Scope and Purpose of Processing
| Processing Activity | Data Categories | Purpose |
|---|---|---|
| Audio retrieval from a Controller-designated URL | Audio recordings (voice data) hosted at an address the Controller supplies; the URL and its hostname | On Controller's instruction given through the public API, Processor initiates an outbound HTTPS connection to the host the Controller designates and downloads the recording for the processing activities below. The Controller selects the host and controls what it serves; Processor resolves the hostname through Cloudflare's DNS-over-HTTPS resolver before connecting |
| Audio transcription | Audio recordings (voice data), caller metadata | Convert speech to text using ASR providers |
| AI analysis | Transcripts, conversation metadata | Quality scoring, sentiment analysis, key point extraction |
| Customer questions and decline reasons | For a Controller with the Voice of Customer section (Pro plan and above): transcripts with pattern-based PII redaction applied; 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 from the 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 it was asked) and, for a sales conversation, how it ended and, when the customer declined, the reason from a fixed list, in the customer's words with a verbatim quote and whether the customer stated it or the model inferred it | Collect what customers ask and why they decline across the Controller's conversations for the Voice of Customer section, in a request separate from the analysis; the results are stored with the record and are not yet shown in the section |
| Criteria (the Controller's own questions) | The Controller's criteria (name, question, guidance on what counts, answer values — the name is stored only; the question, guidance and answer values are sent to the AI model as the Controller wrote them, at most with phone numbers, emails, card numbers and IBANs masked) and transcripts with pattern-based PII redaction applied; for each answer, the value (yes or no, a 0–100 score or one of the Controller's values, or that no confident answer was possible), verbatim quotes from the redacted transcript, the model's short written explanation and, when known, the identifier of the employee who handled the conversation | Answer the Controller's questions about each conversation within a criterion's scope, in a request separate from the analysis, for display in the call panel, the PDF report, the records filter and the dashboard report; and, on the Controller's request, put a draft wording to up to 20 recent conversations within its scope, showing the answers without storing them |
| Semantic search | Segments of call transcripts and chat conversations, and the text a Controller's user types into search, both with pattern-based PII redaction applied; the numerical vectors computed from the segments, each 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 | Let the Controller's users find records by meaning. Segments and search text are sent to the LLM sub-processor to compute the vectors; only the vectors of the segments are stored (Cloudflare Vectorize), without transcript or chat text, and the text shown with a result is read from the stored transcript. The vector of a search query is used for that search only and is not stored |
| AI assistant (interactive questions and answers) | A Controller user's question about a call record or about a CRM deal, lead, contact or company (with pattern-based PII redaction applied before storage); the transcript and analysis of that record, or of the records linked to that CRM entity that the user is permitted to see, together with the entity's name and, for a deal, its outcome in the CRM where known (won, lost or still open); or a question about all the records the user is permitted to see, with the filters chosen (the period, record type, category and customer name are also sent with the question; projects and agents are not), its embedding (used to find matching records in the search index and not stored) and the transcripts and analyses of up to 12 of those records; and the generated answer with the excerpts it cites | On the request of a Controller's user, generate an answer about a single call record, about a CRM entity across its linked records, or about all the records the user is permitted to see, grounded in their transcripts and analyses via the LLM sub-processor, and keep the conversation for the user to return to |
| Acoustic voice metrics | Audio recordings (voice data) | Derive objective voice-delivery metrics (speaking rate, pauses, pitch variation, voice stability) via Aelo's self-hosted acoustic service |
| Data storage | Audio, transcripts, analyses, metadata | Secure storage for Controller's access and retrieval |
| CRM delivery | Analysis results, scores, key points; the call transcript — attached to the CRM call record where the Controller switches that on, posted to the Smart Process item timeline where delivery targets one, and written into a Controller-designated CRM field only where the Controller switches that on (off by default) | Deliver insights to Controller's CRM system |
| Stage-based scorecard selection | CRM deal stage ID, pipeline/funnel ID, stage name, and stage phase (from Controller's connected Bitrix24; where Bitrix24 gives no phase, the phase Controller set for that stage or, failing that, derived by Processor from the stage name) | When Controller connects Bitrix24 and enables stage-based evaluation, select the evaluation scorecard matching the deal's current pipeline stage |
| Deal-outcome tracking | CRM deal/series identifier, pipeline ID, stage ID, outcome status (open/won/lost), close timestamp, sync timestamp (from Controller's connected Bitrix24) | When Controller connects Bitrix24 and enables stage-based evaluation, periodically sync each linked deal's outcome status to show a deal-outcome funnel — call volume by won/lost, broken down by average call-quality score — in Controller's dashboard |
| Deal-stage progression evaluation | CRM deal stage history (transitions/timestamps), pipeline ID; derived progression result (advanced/held/regressed) stored per call record | When Controller connects Bitrix24 and enables stage-based evaluation, once per call compare the deal's stage at the call against its stage ~7 days later (or at deal close) to derive whether the deal advanced, held, or regressed, shown as a per-call progression indicator in Controller's dashboard |
| Org-structure import | Department tree (identifiers, names, parent links, sort order); department membership per employee, including employees with no Aelo account yet (stored as the portal's employee ID, email when available, and name, until their account is created); and the department head named by the portal, including a head with no Aelo account yet (stored as the portal's identifier and name) (from Controller's connected Bitrix24) | When Controller runs the org-structure import, reproduce Controller's department hierarchy inside Aelo — including employees and a department head who do not yet have an Aelo account — so a department head can open the call records of everyone below them in the tree, independently of project assignment. When such an employee's or head's Aelo account is later created (for example when an invitation is sent to them, or through their first sign-in inside the connected CRM's embedded app), Aelo automatically links them to their stored portal identity and, when it can identify a new head's account by the portal's own identifier, grants that head access to the department's records, unless an administrator has manually assigned a different head. A head assigned by hand in Aelo always takes precedence over the portal's value and survives later imports |
| Email reports and digests | Recipients' email addresses — including addresses the Controller configures for a project that need not belong to platform users — and the content derived from calls and chats that each email carries, listed per email in the Sub-Processor List (Resend): quality metrics, AI-assigned categories, masked caller references, model-written alert reasons and, in role digests, named employees' quality scores. No transcripts or audio. Account, invitation, billing and minute-usage emails are Aelo's own, as controller (Privacy Policy B.1, B.4), and are not part of this activity. | Send analysis reports to the addresses the Controller configures for a project, and alerts, record notifications and digests (digests on by default, switchable by each user) to the Controller's platform users, through a transactional email provider (Resend) |
| Alerting | Analysis metrics and thresholds; personal email and webhook notifications 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. Telegram receives only business alerts, in a contact-free version 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 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. | Notify Controller's platform users about significant events: to each individual user's own configured channels (email, a personal Telegram chat, a personal webhook), and — independently — to a project-level team channel (a Telegram group, Controller's own connected Bitrix24 group chat, or a Controller-configured webhook) Controller sets up |
| Onboarding communications | Not Customer Personal Data processed on the Controller's instruction. Aelo's own onboarding and marketing emails go to a person who gave separate marketing consent, with Aelo as controller (Privacy Policy B.5); what is sent to the marketing-automation provider (SendPulse) is listed in the Sub-Processor List and Privacy Policy B.5, and is sent only for that person | None on the Controller's behalf: listed so that the Controller can see every provider that receives a user's data, and is not part of this activity |
| Application error tracking and monitoring | Platform user's name, email address, and account identifier; the connecting IP address at the network level; page and API request URLs; breadcrumbs of recent navigation and network activity; error messages and stack traces, which can incidentally include Personal Data being processed at the time of the error; session replay recordings for a sample of user sessions (approximately 10%) and for every session in which an error occurs (on-screen text and form inputs masked, media blocked, by default) | Detect, diagnose, and resolve errors and performance issues in the Aelo web application and its API layer. Not applied to the background call-processing pipeline |
Processor shall not process Personal Data for any purpose other than as documented in this DPA and Controller's instructions.
3. Data Categories and Data Subjects
Data Subjects: Call and chat participants (customers, prospects), call agents (employees, contractors), platform users (staff with Aelo access), recipients of analysis reports at email addresses Controller configures for a project, and — where Controller runs the org-structure import — employees appearing in Controller's imported department tree, including employees and a department head who do not yet have an Aelo account. Employees from the connected portal with no matching Aelo account are displayed to Controller's administrator by name so the gap can be resolved; Processor stores their portal employee ID, email (when the portal provides one) and name, together with their department membership, until an Aelo account for them is created, at which point Processor automatically links the two and deletes this interim record. Processor does not create an Aelo account for them on its own.
| Category | Examples | Sensitivity |
|---|---|---|
| Voice data | Audio recordings of calls | High (potential biometric) |
| Conversation content | Transcripts, spoken words | High |
| Communication metadata | Phone numbers, call duration, timestamps | Medium |
| Analysis results | Quality scores, sentiment, key points | Medium |
| Customer questions and decline reasons | Per conversation: up to 10 questions with the model's summary, the customer's verbatim words, subject, whether answered and stage; for a sales conversation, its outcome and the decline reason with the customer's words and a verbatim quote | Medium |
| Criteria answers | Per criterion: yes or no, a 0–100 score or one of the Controller's values, verbatim quotes from the redacted transcript, the model's short explanation, and the employee's identifier when known | Medium |
| Search vectors | Numerical representations (embeddings) of redacted transcript and chat segments, with record, project, organization and transcript identifiers and the record type, and — when known — the employee's identifier and the record's date; no text | Medium (derived; not designed to be read back as text, but may reveal some of the content they were computed from) |
| Voice-delivery metrics | Speaking rate, pauses, pitch variation, voice stability | Medium (derived acoustic measurements; not voiceprint/biometric identification) |
| User account data | Names, email addresses of platform users | Standard |
| Report recipients | Email addresses Controller configures for a project to receive analysis reports | Standard |
| CRM org-structure data | Department identifiers, names, parent links and sort order; which employees belong to which departments, including employees with no Aelo account yet (portal employee ID, email when available, and name); the department head named by the portal, including a head with no Aelo account yet (portal identifier and name); and the pairing of a portal user ID with the matching Aelo account, established by the portal's own employee ID or by email address | Standard (employment/organisational data about Controller's own employees; determines who may open which call records) |
| CRM deal-stage data | Deal stage ID, pipeline/funnel ID, and stage phase (e.g. discovery, negotiation) read from Controller's connected CRM or, where the CRM gives none, set by Controller for the stage or derived from the stage's name in that CRM; also includes the deal's stage history (transitions/timestamps) read to derive a per-call progression result (advanced/held/regressed) | Low (business-process metadata about the deal, not the data subject) |
| CRM deal-outcome data | Deal/series identifier, pipeline ID, stage ID, outcome status (open/won/lost), and close/sync timestamps read from Controller's connected CRM | Low (business-process metadata about the deal, not the data subject) |
| Application diagnostic data | Error messages, stack traces, page and API request URLs, breadcrumbs of recent navigation and network activity, connecting IP address, session replay recordings; platform user's name, email address, and account identifier, captured by the application error-tracking sub-processor | Medium (can incidentally include Personal Data being processed at the time of an error; also includes platform user identity data and connection IP address) |
4. Obligations of the Processor
- Documented Instructions. Processor shall process Personal Data only on documented instructions from Controller.
- Confidentiality. All personnel authorized to process Personal Data have committed to confidentiality.
- Security Measures (Art. 32). Processor implements appropriate technical and organizational measures:
| Measure | Implementation |
|---|---|
| Encryption in transit | TLS 1.2+ for all API communications |
| Encryption at rest | Cloudflare R2 SSE (AES-256-GCM, active by default); Neon database native encryption; 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 |
| Access control | Role-based access (RBAC) with organization isolation |
| Tenant isolation | Organization-level data segregation; cross-org detection |
| Authentication | Interactive access: multi-factor via Clerk; session management. Programmatic access (public API): bearer API keys, without Clerk or multi-factor, stored as SHA-256 hashes with the plaintext never retained; each key is bound to a single organization, carries separate read and write scopes, supports an optional expiry, and is revocable with effect from the next request |
| Security logging | Production logs capture denied authorization attempts and selected security-relevant events. Coverage does not extend to a customer-facing history of every action. |
| Pattern-based PII redaction | For new transcripts processed through the current application repository write paths, supported phone, email, payment-card and valid IBAN patterns are redacted on write and independently before LLM processing; transcript and chat segments sent to compute search vectors, and the text a Controller's user types into search, receive the same redaction before they are sent; the questions a Controller's user asks the AI assistant receive the same pattern-based redaction before they are stored, and only the stored text reaches the LLM. The control does not detect all Personal Data, does not redact original audio and was not applied retroactively: earlier transcript, preview, metadata and word-timestamp rows were not rewritten and remain subject to the Customer's configured retention period. |
| Rate limiting | Sliding-window rate limiting, bucketed per authenticated user or API key. On the public API an additional limiter buckets by source IP address and runs before the key is authenticated |
| Webhook security | Webhook authentication: per-installation secret, HMAC signature or sender IP allowlist, depending on the provider |
- Data Subject Rights. Processor provides a workflow to record, review and track access, erasure, rectification and objection requests. Approved requests are currently fulfilled through the applicable product and support procedures; the DSR workflow does not yet execute them automatically.
- DPIA Assistance. Processor assists Controller in conducting Data Protection Impact Assessments.
- Deletion. At Controller's choice, Processor shall delete or return all Personal Data after end of Services.
- Audit Rights. Processor allows Controller audits and inspections to demonstrate compliance.
- Infringing Instructions. Processor shall immediately inform Controller if, in its opinion, an instruction from Controller infringes Data Protection Laws (Art. 28(3), final paragraph).
5. Obligations of the Controller
- Obtaining consent from call participants where required by applicable law
- Informing Data Subjects about recording, transcription, and AI analysis
- Maintaining records of consent where applicable
- Responding to Data Subject rights requests through the tracked workflow and the applicable product or support procedure
- Configuring the appropriate consent mode and jurisdiction settings before processing
- Ensuring a valid lawful basis for all data submitted to the Service and, where transcripts may contain special categories of personal data (Art. 9 GDPR), establishing an applicable Art. 9 condition
6. Sub-Processors
Controller provides general authorization for the sub-processors listed in the Sub-Processor List. Processor shall notify Controller at least 30 days before adding a new sub-processor. Controller may object on reasonable data protection grounds. If no resolution is reached, Controller may terminate the affected Services without penalty.
7. International Transfers
Processor is established in Spain (EU). For transfers to the US:
| Mechanism | When Applied |
|---|---|
| EU-US Data Privacy Framework (DPF) | US sub-processor is DPF-certified |
| Standard Contractual Clauses (2021) | US sub-processor without DPF |
| Adequacy Decision | Sub-processor in country with EU adequacy decision |
For UK transfers, the International Data Transfer Addendum to the EU SCCs (issued by the ICO) is incorporated.
Exception — Telegram alert delivery. None of the mechanisms above is available for one optional destination. Telegram Messenger Inc., the counterparty for Telegram's Bot API, is incorporated in the British Virgin Islands; it publishes no data processing agreement for that API and offers bot operators no Standard Contractual Clauses, and neither the British Virgin Islands nor the UAE holds a European Commission adequacy decision. Processor therefore makes no representation that a transfer safeguard is in place for this destination. The channel is disabled by default and transmits nothing until Controller or one of Controller's users explicitly connects a chat; only business alerts are transmitted, and the fields are set out in the Sub-Processor List. Controller decides whether to enable it. All other Services and delivery channels are unaffected.
8. Data Breach Notification
Processor notifies Controller without undue delay and in any event within 48 hours of becoming aware of a Personal Data breach. The notification includes: nature of breach, categories and number of records affected, likely consequences, and measures taken.
9. Data Retention and Deletion
| Data Type | Retention |
|---|---|
| Audio recordings | 365 days |
| Transcripts | 365 days |
| AI analyses | Follows transcript |
| Voice metrics | Follows transcript |
| Search vectors | 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 |
| Metadata | Follows transcript |
| Customer questions and decline reasons | Follow the record: deleted together with it, including at the end of the retention period |
| Criteria answers | Follow the record: deleted together with it, including at the end of the retention period |
| Criteria (definitions) | Duration of Controller's account (cascade-deleted when the account is deleted); an archived criterion is kept so that past answers stay readable |
| Assistant conversations | Controller's retention period; also deleted when the record asked about, or any record the answer was built from, is deleted — usually together with that record, otherwise by a routine scheduled cleanup |
| CRM deal-stage data | Follows transcript |
| Emails already sent (reports, alerts, notifications, digests) | Outside Processor's control once delivered: copies stay in the recipients' mailboxes, and Resend keeps delivery logs under its own retention (pending confirmation); deleting a record does not recall an email sent about it |
| CRM deal-outcome data | Duration of Controller's account (cascade-deleted when the account is deleted) |
| CRM org-structure data | Duration of Controller'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 |
| User accounts | Duration of service |
| Application diagnostic data (Sentry) | Governed by the sub-processor's own plan-based retention settings, not Processor's uniform 365-day policy; the exact period is pending confirmation — see Sub-Processor List |
Controller configures retention. The platform default is 365 days on every plan, and the Controller may set its own retention period for its organization within a range of 1 to 365 days (Settings → Organization; organization owner only). Unlimited retention is not available to Controllers — data is always deleted after the configured period. A Controller that sets no value follows the platform default. Processor automatically deletes data exceeding the effective period.
Lowering the period deletes existing data that falls outside the new window; the Processor shows the number of affected records before the change is applied, and the deletion is permanent. Upon termination, Controller has 30 days to export, then all data is deleted within 30 days. The application diagnostic data row above is the one exception — retention there is set by the sub-processor's own plan.
10. Term and Termination
This DPA remains in effect for the duration of the Services agreement and automatically terminates upon termination of Services, subject to post-termination data handling.
11. Liability
Each party's liability under this DPA is subject to the limitations in the Services agreement. Nothing limits liability for breaches of Data Protection Laws to the extent such limitation is not permitted by applicable law.
Document ID: DPA-Aelo-2026-001 · Version: 1.31