Skip to main content
Audact
See the offer

Data Processing Agreement

Last updated: 8 October 2026

This is a published draft under counsel review. Two things it depends on are not settled: which of the two Audact companies is the processor (section 1 says so rather than assuming it), and which Standard Contractual Clause modules apply in the chain between Audact and the Customer, which follows from that same answer and from whether you buy direct or through an agency. Read this as the shape of the agreement, not as the executed text. The document you sign is the order form and the DPA attached to it; where the two differ, the signed one governs.

If you need either point settled before you sign, ask legal@audact.ai and get the answer in writing.

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.