1. Parties
Data Controller: You ("Customer"), the AI deployer, agency, or platform using Audact services. Where you are yourself a processor towards your own end-client rather than a controller, this agreement operates as a sub-processing agreement and the same terms apply. Which of the two roles you hold is fixed per deployment in the agreement you sign, not by this page.
Data Processor: the Audact company named as processor on the order form you sign. Two companies exist and they do different work. Audact AI Ltd, 71-75 Shelton Street, London WC2H 9JQ, United Kingdom (company no. 17059133) holds the intellectual property. AUDACT AI LIMITED (Ireland, CRO 822514, incorporated 29 July 2026) is the EU operating company, and it is the entity named as the contracting party in the imprint and in the footer of this site. Whichever of the two is named, it processes interaction metadata on your behalf as a Processor under GDPR Article 28, on the terms below.
Which of the two is party to your contract is an open point, and this section states that rather than assuming it. An agreement signed with Audact AI Ltd is assigned to AUDACT AI LIMITED by written notice, effective on the date of that notice and with no degradation of Customer rights. This section does not assert that every existing agreement has already been assigned, because that is not established here. Before signature the order form governs; if you need it settled first, ask legal@audact.ai which entity is your processor today and get the answer in writing.
2. Scope of Processing (GDPR Art. 28(3))
Subject matter & duration: Provision of the Audact compliance platform; duration equal to the underlying service agreement plus any retention period mandated by law.
Nature & purpose: Compliance validation, evidence-chain generation, and audit-trail maintenance as instructed by the Customer through the platform configuration.
Data categories: Call metadata (timestamps, jurisdiction identifiers, policy decisions, validation results, evidence hashes, consent records); call audio in transit, and retained only where the Customer switches recording on; transcribed conversational text; the output released to the caller; and the receipt, policy and consent records that follow from it. Where the Customer’s use case brings special categories of personal data within Article 9 into a governed interaction, the Customer as controller determines the Article 9 condition and instructs Audact accordingly.
Data subjects: End-users / callers / chat participants of the Customer’s AI deployment.
Not retained: Audio passes through the sub-processors listed in section 3 (speech-to-text, text-to-speech and the language model) because a governed call cannot be governed without it. It is not retained by default. Where the Customer switches recording on, call audio is kept for up to 90 days and then deleted. Beyond what compliance validation requires, no further personal data is stored. All personal data is encrypted; erasure via crypto-shredding (coming soon): the key that decrypts the payload will be destroyed, so the sequence remains checkable while the content is gone.
Processor obligations (Art. 28(3)): Audact (a) processes only on documented Customer instructions; (b) ensures personnel are bound by confidentiality; (c) implements Art. 32 security measures (section 5); (d) engages sub-processors only on the terms in section 3; (e) assists the Customer with data-subject rights and Art. 32-36 obligations; (f) deletes or returns Customer Data on termination (section 8); (g) makes available information necessary to demonstrate compliance and allows audits as set out in section 10.
Duration of processing is set out per object in section 2A, because the six things a governed call leaves behind are not kept for the same reason and are not kept for the same length of time.
2A. Retention, per object
A governed interaction leaves six things behind. They are kept for different reasons, for different periods, and — this is the part that matters — they are not all set by the same party. One row each.
- Object
- Call audio
- Default period
- Not retained. Where the Customer switches recording on: up to 90 days, then deleted
- Configurable
- Yes — off by default
- Why it is kept
- Operational: playback and dispute handling. The receipt does not need it
- Who sets the period
- Customer, in the deployment configuration
- Object
- Transcript
- Default period
- No default period is published. It is agreed per deployment
- Configurable
- Yes
- Why it is kept
- Operational and contractual: it is what both parties can read back
- Who sets the period
- Customer and Audact, in the order form
- Object
- Released output — what the agent actually said or sent after the gate
- Default period
- As for the transcript: agreed per deployment, no default published here
- Configurable
- Yes
- Why it is kept
- Evidentiary: it is the action the receipt is about
- Who sets the period
- Customer and Audact, in the order form
- Object
- Receipt metadata — hashes and decision fields, no content
- Default period
- For the term of the agreement, and afterwards for as long as a rule that applies to the Customer requires it
- Configurable
- Yes
- Why it is kept
- Evidentiary
- Who sets the period
- Customer, from its own sector rule. Audact applies the period and does not set it
- Object
- Security logs — application and server logs
- Default period
- 30 days
- Configurable
- By Audact, on the log group
- Why it is kept
- Operational: security and availability
- Who sets the period
- Audact, at infrastructure level
- Object
- Billing events
- Default period
- None are produced yet — payment processing appears in section 3 as "Stripe (when live)". Once billing runs, the period is the statutory bookkeeping period of the company that invoices you
- Configurable
- No
- Why it is kept
- Fiscal
- Who sets the period
- Statute, through whichever company in section 1 is your counterparty
Where a period is not established, this table says so rather than naming a month. Two of the six point at a setting rather than a number, and one of them depends on a question section 1 leaves open.
No retention period follows from the AI Act. Article 50 is a transparency duty and sets no retention period, and the Commission guidelines C(2026)5054, point (73), state that a full provenance chain is not mandatory. Where a period does apply, it comes from this agreement or from a rule that applies to the Customer's own sector.
The organisation defines the mandate; Audact enforces it. Retention follows the same division. The Customer sets the periods its own rules require and Audact applies them; Audact does not advise the Customer how long it must keep anything.
Evidence-chain records are kept for the term of the agreement and thereafter only as long as your applicable rule requires. No retention period follows from the AI Act; the period that governs is the one in your agreement.
3. Sub-processors
All third parties that process data on behalf of Audact or our clients. This list is maintained as required under GDPR Article 28.
- Sub-processor
- AWS (Frankfurt)
- Purpose
- Infrastructure hosting, CDN (CloudFront), DNS (Route 53), WebRTC transport (self-hosted LiveKit)
- Data processed
- All platform data
- Location
- EU (Frankfurt) for hosting; CloudFront and Route 53 are global services with points of presence outside the EU.
- Sub-processor
- Telnyx
- Purpose
- SIP telephony
- Data processed
- Call audio in transit, telephony metadata
- Location
- EU PoPs, SCCs
- Sub-processor
- Deepgram Nova-3
- Purpose
- Speech-to-text
- Data processed
- Audio in transit (no retention configured)
- Location
- US (EU endpoint), SCCs
- Sub-processor
- Mistral (Voxtral)
- Purpose
- Text-to-speech
- Data processed
- LLM-generated text
- Location
- EU
- Sub-processor
- Mistral / OpenAI
- Purpose
- LLM inference (mini models), selected per agent configuration
- Data processed
- Conversational text (no retention configured)
- Location
- EU (Mistral) / US EU-endpoint (OpenAI), SCCs
- Sub-processor
- freeTSA.org
- Purpose
- RFC 3161 timestamping
- Data processed
- Digest only — no readable content
- Location
- External public service
- Sub-processor
- Google Workspace
- Purpose
- Email, docs
- Data processed
- Business communications
- Location
- US/EU, SCCs
- Sub-processor
- Slack
- Purpose
- Internal communications, including notifications of website enquiries
- Data processed
- Internal messages; enterprise enquiry form fields (name, organisation, email, sector, volume, message) and IP address
- Location
- US, SCCs
- Sub-processor
- Notion
- Purpose
- Wiki / documentation
- Data processed
- Internal operational data
- Location
- US, SCCs
- Sub-processor
- Linear
- Purpose
- Project management
- Data processed
- Internal project data
- Location
- US, SCCs
- Sub-processor
- 1Password
- Purpose
- Credential management
- Data processed
- Encrypted credentials
- Location
- Canada/EU
- Sub-processor
- Stripe (when live)
- Purpose
- Payment processing
- Data processed
- Billing data
- Location
- US/IE, SCCs
Sub-processor list last updated: 5 October 2026
The current sub-processor list is also published on our Trust Center.
We give at least 30 days notice before adding or replacing a sub-processor. You may object in writing within that period on reasonable grounds; if no acceptable solution is found, you may terminate the affected service.
4. Data Residency
Primary application hosting: Frankfurt. AWS eu-central-1; a backup region in AWS eu-west-1 (Ireland) is being set up. Customer compliance data (interaction metadata, evidence chains, audit logs) is stored and processed on that infrastructure, inside the EEA.
A number of the sub-processors listed in section 3 are established outside the EEA. Where they process personal data, the transfer mechanism is the Standard Contractual Clauses (Module 3, processor-to-processor, Decision (EU) 2021/914) together with appropriate technical and organisational measures. The table above states, per sub-processor, what it processes and where.
5. Security Measures (GDPR Art. 32)
- Encryption at rest (AES-256) and in transit (TLS 1.3)
- Encryption of PII so that crypto-shredding can apply (coming soon): the key that decrypts the payload will be destroyed, so the sequence remains checkable while the content is gone.
- SHA-256 hash chains for evidence integrity. Each governed interaction produces a compliance receipt; the Customer can recompute the input hash, the output hash and the link to the preceding receipt from the exported file alone, without a key and without access to Audact systems. The exact form is published at /sample-receipt-readme.txt.
- Role-based access control (RBAC)
- SOC 2 Type II: planned, no auditor engaged, sequenced after the first paying deployments
- Vulnerability scanning of dependencies and infrastructure. No external penetration test has been carried out yet; a first test is scheduled before the first paying deployment.
Audact is not certified to ISO 27001 and holds no SOC 2 report today. A SOC 2 Type II is planned, and the timing follows the first paying deployments. Where this agreement refers to third-party audit reports, it refers to reports that do not yet exist.
6. Data Subject Rights
The controller has one month under Article 12(3) to answer the data subject, extendable by two further months. Audact's own period below is the time in which Audact assists that controller, and it is not the controller's deadline.
Audact assists the Customer in fulfilling data subject requests (access, rectification, erasure, portability) within 72 hours of notification. Erasure via crypto-shredding (coming soon): the key that decrypts the payload will be destroyed, so the sequence remains checkable while the content is gone.
7. Breach Notification (GDPR Art. 33(2))
The 72 hours are the Customer's, not Audact's. Article 33(1) gives the controller 72 hours to notify its supervisory authority, counted from the moment the controller becomes aware. Article 33(2) puts no fixed deadline on a processor: it requires notification to the controller without undue delay. A processor that treated the 72 hours as its own budget would hand the controller a deadline that had already run.
It matters more than it reads: under the EDPB's breach-notification guidelines the Customer is regarded as aware once Audact is aware. Audact's notification is therefore not scheduled against those 72 hours — every hour it takes is an hour off the Customer's own deadline. Audact notifies without undue delay after becoming aware and in any event no later than 72 hours, which is an outer limit and not a target. Where the Customer needs a shorter fixed window written into the contract, it is agreed in the order form; this published draft does not set one. Notification includes: nature of the breach, categories and approximate number of data subjects and records affected, likely consequences, and measures taken or proposed to address the breach and mitigate its effects. Where a detail is not yet known, Audact says so and follows up in phases rather than delaying the first notification. Audact provides reasonable assistance to enable the Customer to fulfil its Art. 33 and 34 obligations towards supervisory authorities and data subjects.
8. Term & Termination
This DPA is effective for the duration of the service agreement. Upon termination, Audact deletes or returns all Customer Data within 30 days (phase (3) of the off-boarding lifecycle), except where retention is required by EU or Member-State law that applies to the Customer or to Audact, or by the periods agreed in section 2A. Cryptographic evidence chains may be retained in non-personal, hash-only form to preserve audit integrity for the period that applies under section 2A.
No period here follows from the AI Act. Article 50 is a transparency duty and sets no retention period, and a ten-year ceiling is a rule that applies to the Customer's sector rather than one Audact sets. Both sit in section 2A, in the row where the party that sets them is named.
9. International Transfers
Customer compliance data is stored and processed inside the EEA. Where the sub-processors listed in section 3 that are established outside the EEA process personal data, including call audio in transit and conversational text, the transfer mechanism is the Standard Contractual Clauses (Module 3, processor-to-processor, Decision (EU) 2021/914), supplemented by appropriate technical and organisational measures.
10. Audit Rights
On reasonable written request, and no more than once in any 12-month period, Audact makes available the information necessary to demonstrate compliance with this DPA, including third-party audit reports once such reports exist. Where the Customer reasonably requires a further audit, the parties agree scope, timing and cost; audits must not disrupt other customers and are subject to confidentiality.
11. Contact
DPA inquiries: dpo@audact.ai
Version history
Last amended on 8 October 2026. Earlier versions of this document are available on request.
Related documents
