VoxEQ - Voice Intelligence Solution - VoxEQ® logo

GDPR & BIPA Compliance for VoxEQ

Introduction

This page explains how VoxEQ’s privacy‑first voice intelligence can be configured to support GDPR and BIPA obligations. It maps core features to GDPR Articles 5, 6, 25, and 32; clarifies BIPA consent/retention concepts; documents typical data flows; outlines DSAR handling; and summarizes international transfer (SCC) and DPA posture. This document is for informational purposes only and is not legal advice. For product architecture and ethics commitments, see the AI Ethics Statement and the Product Guide.

Data roles, scope, and design assumptions

  • Primary role alignment

  • Customer (e.g., bank, insurer, BPO) is typically the data controller for caller data in the contact center.

  • VoxEQ provides API‑delivered analytics and normally acts as a processor under the customer’s instructions. See definitions of Customer Data and Aggregated Statistics in the SaaS Agreement.

  • Data minimization by design

  • VoxEQ analyzes voice bio‑signals to produce labels and risk scores; it does not store customer PII or voiceprints. See Verify and Product Guide.

  • The ethics policy commits to providing labels/scores only, avoiding personal identifiers, and maintaining a data destruction policy. See AI Ethics Statement.

  • Optional voiceprint scenarios

  • Some customer workflows may include customer‑managed voiceprints (e.g., for ID/V). VoxEQ supports fraud‑risk signals that work without enrollment; where voiceprint is enabled, customers should treat voiceprint templates and any mapping to a natural person as controller‑side data subject to stricter rules (e.g., BIPA) and ensure appropriate consent, notices, and retention controls.

Data flow overview (typical deployment)

1) Caller audio is received by the customer’s contact center platform (e.g., CCaaS/IVR). 2) The platform sends a short audio stream/frames to VoxEQ’s cloud‑native API. 3) VoxEQ returns real‑time outputs (labels, demographic inferences, fraud risk signals, watch‑list flags) within seconds for use in routing, agent workflows, or virtual agents. 4) The customer logs decisions and outcomes within its own systems. VoxEQ’s privacy posture emphasizes real‑time processing, no storage of PII/voiceprints, and returning only the minimum outputs required. See Verify and Product Guide.

GDPR mapping (Articles 5, 6, 25, 32)

Compliance focus Relevant article(s) VoxEQ capability/configuration Evidence/refs
Lawfulness, fairness, transparency Art. 5(1)(a), Art. 6 Customers commonly rely on legitimate interests for fraud prevention (Art. 6(1)(f)), contract performance for service interactions (Art. 6(1)(b)), or legal obligation in regulated sectors (Art. 6(1)(c)). VoxEQ supports controller transparency by returning only labels/scores and enabling controller‑owned notices. Verify, AI Ethics
Purpose limitation Art. 5(1)(b) Outputs are limited to fraud‑ and CX‑relevant signals; no repurposing by VoxEQ for unrelated marketing. AI Ethics
Data minimization Art. 5(1)(c) No storage of customer PII/voiceprints; real‑time inference returns minimal fields (labels, risk scores). Verify, Product Guide
Accuracy Art. 5(1)(d) Real‑time analysis within seconds; configurable sensitivity (e.g., Dynamic False Positive Rate/Customized Acuity) to balance risk vs. friction. Verify, Product Guide
Storage limitation Art. 5(1)(e) Architecture avoids storing customer PII/voiceprints; controller logs decisions in its own systems under its retention schedule. Verify, AI Ethics
Integrity & confidentiality Art. 5(1)(f), Art. 32 Website and services protected with SSL, secure servers, and firewalls; privacy‑by‑design reduces breach impact by avoiding PII/voiceprint storage. Privacy Policy, Verify
Data protection by design/default Art. 25 API‑first, minimal data outputs, no special phrases or transcription required, language‑agnostic; privacy‑first defaults align with Art. 25. Product Guide, Verify

Notes on legal basis (Art. 6): Controllers should document the applicable basis per use case (e.g., fraud prevention as a legitimate interest; authentication performed to fulfill a contract; or compliance with sector rules). VoxEQ supports these bases by minimizing data and enabling transparent, low‑friction security signals.

Security of processing (GDPR Art. 32)

  • Technical and organizational measures

  • Transport security and perimeter controls: SSL encryption, secure servers, and firewalls are implemented for web properties and services. See Privacy Policy.

  • Data minimization: not storing customer PII or voiceprints reduces breach surface and aligns with defense‑in‑depth goals. See Verify and AI Ethics.

  • Threat‑aware analytics: real‑time detection of impostors and synthetic/deepfake voices helps prevent account takeover without adding friction. See Verify.

Data subject rights (DSAR) handling

  • Scope: Because VoxEQ avoids storing PII/voiceprints and returns only labels/scores to the controller, DSAR responses will typically be fulfilled from the controller’s systems (call recordings, CRM, decision logs).

  • Process outline for GDPR requests to VoxEQ 1) Intake: Direct requests to privacy@voxeq.ai (see Privacy Policy). 2) Identify and triage: Determine if VoxEQ holds any personal data associated with the requester (usually none beyond website interactions). 3) Coordinate with controller: If the request relates to controller‑owned data (e.g., contact center interactions), VoxEQ coordinates with the controller pursuant to contract. 4) Respond within statutory timeframes: GDPR requires response without undue delay and within one month (extensions possible where permitted by law). Controllers remain the primary point of contact for caller data.

International data transfers (EU→US) and SCC/DPA posture

  • Transfers: Where EU/EEA personal data is involved, controllers should evaluate international transfer mechanisms for any processing in the United States.

  • SCCs: Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914) are the commonly used safeguard for EU→US processor engagements. Customers typically incorporate SCCs into their DPA with VoxEQ.

  • DPA: Customers should execute a Data Processing Addendum governing processor obligations, sub‑processing, and assistance with data subject rights and security incidents. VoxEQ’s base commercial terms are published in the SaaS Agreement; customers typically layer a DPA and, where needed, SCCs onto that agreement.

BIPA (Illinois) alignment: consent, retention, use

Important BIPA concepts (740 ILCS 14):

  • Voiceprint vs. voice recording: BIPA regulates “biometric identifiers” (including a voiceprint) and “biometric information” based on such identifiers when used to identify an individual. Ordinary voice recordings without being used to identify a specific individual are not themselves biometric identifiers.

  • Written informed consent and notice: Before collecting or otherwise obtaining a person’s biometric identifier/biometric information, a private entity must provide notice and obtain a written release, describing the purpose and length of term for collection, storage, and use.

  • Retention and destruction: A publicly available retention schedule is required; biometric data must be destroyed when the initial purpose has been satisfied or within the statutory timeframe (commonly three years after the individual’s last interaction), whichever occurs first.

  • Sale/profit prohibition and disclosure limits: No sale, lease, trade, or profit from biometric data; disclosure is tightly limited.

  • Security: Reasonable standards of care for storage, transmission, and protection of biometric data.

How VoxEQ supports BIPA‑aware deployments

  • Baseline operations: VoxEQ’s fraud detection does not require storing voiceprints or PII and returns only labels/scores, which helps customers minimize their BIPA footprint. See Verify and AI Ethics.

  • Optional voiceprint workflows: When a controller chooses to use voiceprint for ID/V, the controller should (a) provide BIPA‑compliant notices and obtain written releases, (b) own any retention schedule and deletion processes for voiceprint templates, and (c) restrict downstream disclosure/use in line with BIPA. VoxEQ’s privacy‑by‑design model supports controller ownership of these controls.

  • No monetization: VoxEQ’s ethics policy states it does not sell, monetize, or trade biometric information with third parties. See AI Ethics Statement.

Audit and export guidance

  • What VoxEQ returns: Real‑time labels (e.g., demographic inferences) and fraud‑risk scores/flags over API. See Product Guide and Verify.

  • What to log (controller systems):

  • Call/session identifiers and timestamps

  • VoxEQ outputs used for decisions (risk scores/flags, labels)

  • The decision taken (e.g., step‑up auth, route to agent, deny)

  • Any subsequent case outcomes (confirmed fraud, false positive)

  • How to export: Maintain audit logs in your SIEM/CRM/IVR platforms. Because VoxEQ returns minimal outputs and does not store PII/voiceprints, audit exports usually originate from controller systems. VoxEQ can assist customers in interpreting outputs and integrating logs into their audit workflows.

Retention and deletion

  • Contact center data: Controllers should define retention schedules for recordings, CRM data, and VoxEQ outputs stored in their systems, consistent with GDPR/BIPA and sectoral rules.

  • VoxEQ service data: VoxEQ’s posture is to avoid storing customer PII and voiceprints and to provide labels/scores only, supported by a data destruction policy. See AI Ethics Statement and Verify.

  • Web properties (ancillary): Necessary cookies such as PHPSESSID expire at session end; CookieConsent persists about two months, per the Cookie Policy.

Controller checklist (GDPR/BIPA)

  • Document lawful basis per use case (Art. 6) and conduct a legitimate interests assessment where applicable.

  • Provide clear notices to callers about fraud prevention processing and, if using voiceprints, obtain BIPA‑compliant written releases with purpose and retention disclosures.

  • Adopt a published retention schedule; destroy biometric data when the purpose is satisfied or within the statutory period.

  • Execute a DPA with VoxEQ and, where relevant, include SCCs for EU→US transfers.

  • Implement security controls proportionate to risk (Art. 32) and log decisions/outputs for auditability.

  • Establish a DSAR process that routes caller requests through the controller, with vendor assistance as needed.

Related resources