Data Processing Agreement

Effective as of: August 25, 2026

This Data Processing Agreement ("DPA") forms part of, and is incorporated into, the Terms of Service (the "Terms") between Veillant (enkeltmandsvirksomhed, CVR 46669207, Rødovre Port 52, 5. 1., 2610 Rødovre, Denmark) ("Veillant", "we", "us") and the customer using the Service ("Customer", "you"). It governs Veillant's processing of personal data on your behalf under Article 28 of Regulation (EU) 2016/679 ("GDPR") and the Danish Data Protection Act (databeskyttelsesloven). Where this DPA conflicts with the Terms on data protection, this DPA prevails. Capitalized terms not defined here have the meaning given in the Terms or the GDPR.

This DPA is entered into by your acceptance of the Terms, which satisfies the written-form requirement of GDPR Art. 28(9) (electronic form). A countersignable copy is available on request at the contact address in Section 12.

1. How the Service works, and who is responsible for what

The call path. You keep your own published telephone number with your own operator, and you forward calls to a number operated by Veillant. Callers dial your number: they are never given, and never dial, a Veillant number. You decide whether to forward, when, and for which lines.

Roles. For the personal data of the people who call your forwarded line ("Caller Data"), you are the controller and Veillant is the processor (GDPR Art. 4(7), 4(8)). You determine why calls are answered and what the assistant is configured to say and do; Veillant processes Caller Data only to provide the Service and only on your documented instructions, which consist of the Terms, this DPA, and your configuration of the Service. You are the party that owes callers the information required by GDPR Art. 13. For your own account, configuration, knowledge base and billing data, Veillant is an independent controller as described in the Privacy Policy; that processing is outside this DPA.

The three processing flows this DPA covers:

(1) The live call. Call audio is streamed to and from an AI model in real time so the assistant can hear and answer. Nothing about the caller is persisted by Veillant.
(2) Call record keeping and aggregated analytics. Veillant writes an operational record of each call (company, assistant name, AI model, start time, duration, token counts, cost, test flag, status) containing no caller identifier of any kind, and derives the aggregated, content-free counters described in Section 6. The transcript is processed in memory and discarded; it is never stored.
(3) The escalation notice. When the assistant cannot help and you have enabled email escalation, Veillant sends you an email carrying the caller's telephone number, the caller's name if given, and a short reason and note written by the AI, so you can call back. Veillant persists none of it; delivery is performed by the email sub-processor in Annex I. This is the only flow in which identifiable Caller Data leaves Veillant's systems, it exists because you asked for it, and it is delivered to the email address your account signs in with.

What Veillant determines on its own account, and says so (GDPR Art. 28(10)): (a) the spoken notice at the start of every call: its wording, its version and the languages in which the Service will answer at all are fixed by Veillant as a compliance control under Art. 50(1) and 50(5) of Regulation (EU) 2024/1689 (AI Act), cannot be edited or disabled by the Customer, and are enforced in code (if no approved notice exists in the configured language, the call is refused); (b) anonymous system signals pooled across all customers with no customer, account or caller identifier, used to operate and improve the Service, for which Veillant acts as controller to the extent they were ever held to be personal data; and (c) the analytics categories: the fixed list of generic reason categories is defined by Veillant and is not editable by the Customer. The Customer's own catalog items also enter the menu the AI chooses from; they are the Customer's data, counted by internal identifier, never as model-written text. Nothing in this paragraph relieves Veillant of its processor obligations for flows (1) to (3).

2. Subject matter, duration, nature and purpose

Subject matter: processing of Caller Data to answer, understand and respond to telephone calls forwarded to the Service by the Customer.
Duration: the term of the Terms, plus the wind-down in Section 8.
Nature: real-time receipt, transmission and processing of call audio; automated generation of spoken responses; where enabled, transmission of an escalation notice by email; writing of an operational call record and aggregated counters containing no caller identifier.
Purpose: operating the AI telephone assistant the Customer has configured. Full detail in Annex I.

3. Types of personal data and data subjects

Data subjects: natural persons who call a line the Customer has forwarded to the Service.
Types of data: the caller's voice and what the caller chooses to say, processed in transit and in memory to respond; the caller's telephone number as presented by the network, used in transit to derive a coarse country-level region and, where escalation is enabled, placed in the escalation email; and the caller's name and any detail the caller volunteers, where the assistant escalates.
Special categories (Art. 9): callers may volunteer special-category data (for example health information) without being asked. You must ensure you have a valid Art. 9(2) condition for such processing. Veillant's design reduces this exposure (no audio, no transcript, no caller identifier is stored), but the escalation email is the exception: it carries free text and can carry whatever the caller said. You control whether email escalation is enabled.
What is never written to Veillant's storage: call audio; the raw transcript; the caller's telephone number; any other caller identifier. Annex II describes how this is enforced.

4. Veillant's obligations (Art. 28(3)(a) to (h))

Instructions. We process Caller Data only on your documented instructions, including for international transfers, unless required by Union or Member State law (in which case we inform you before processing, unless the law prohibits it). We will immediately inform you if, in our opinion, an instruction infringes the GDPR or other Union or Member State data protection provisions.
Confidentiality. Every person authorised to process Caller Data is bound by a written confidentiality undertaking or a statutory obligation of confidentiality, surviving the end of their engagement.
Security. We implement the technical and organizational measures in Annex II (Art. 32).
Sub-processors. We engage sub-processors only under Section 5.
Data subject rights. Taking into account the nature of the processing, we assist you with appropriate measures in responding to data-subject requests. Understand what this can deliver: Veillant holds no caller identifier and cannot search its systems for a named caller, a number or a specific call, so there is nothing on our side to retrieve, rectify or erase. What we can do, and will do within 10 working days of a written request, is (i) confirm in writing what categories of data the Service does and does not hold, in a form you can forward to the requester, and (ii) request deletion of any delivery record held by the email sub-processor for an escalation notice you identify. Requests reaching the assistant during a call are logged for you and, where you have email handover enabled, sent to you by email so a person can act on them.
Assistance with Art. 32 to 36. We assist you, taking into account the information available to us, with security, breach notification, data protection impact assessments and prior consultation.
Deletion or return. Section 8 applies.
Audit and information. Section 9 applies.

5. Sub-processors (Art. 28(2), 28(4))

You give Veillant general written authorization to engage the sub-processors listed in Annex I and published at veillant.eu/subprocessors. We impose on each sub-processor data-protection obligations no less protective than this DPA, and we remain fully liable to you for their performance (Art. 28(4)). We will publish any intended addition or replacement on the Subprocessors page, and notify Customers who have registered an address for that purpose, at least 30 days before the new sub-processor begins processing Caller Data. Within those 30 days you may object in writing on reasonable data-protection grounds; if the objection cannot be resolved, you may terminate the affected part of the Service, or the Terms entirely if the sub-processor is essential, with a pro-rata refund of prepaid fees for the unused period.

6. Aggregated analytics, and what a counter can and cannot say

The Service counts, for every account, content-free aggregates about the calls it answers: calls per hour of day, coarse country of the calling number, whether the call was handled or escalated, whether it was resolved, call length in six coarse buckets (never exact seconds), and the reason of the call, chosen by the AI from a closed menu consisting of the Customer's own catalog items (stored by internal identifier, never as text) and a fixed list of generic categories. Free text produced by the AI is never stored: any output outside the menu is discarded before writing.

Reason counters carry no time axis at all: they are lifetime running totals with no date. The dashboard shows a snapshot refreshed at most once per week, only after the account has answered a minimum number of calls, and a visible counter never advances by fewer than five calls, so no visible change can be matched to an individual call. Each dimension is stored in its own row and the combination is never written together, so no stored record describes an individual call.

7. Personal data breach (Art. 33(2))

We notify you without undue delay after becoming aware of a personal data breach affecting Caller Data, and in any event within 48 hours of becoming aware, so you can meet your own 72-hour obligation under Art. 33(1). The notification describes, to the extent then known, the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, the measures taken or proposed, and a contact point; where not all information is available at once, it is provided in phases without further undue delay.

8. Deletion and return (Art. 28(3)(g))

Because no call audio, no raw transcript and no caller identifier is written to Veillant's storage, there is no Caller Data held by Veillant at the end of the Service to return or delete; escalation notices live in your own mailbox and are yours to manage. Deletion is available to you at any time from account settings. It takes effect immediately in the sense that matters: your subscription stops renewing, your assistant stops answering, you are signed out on every device, and the Service closes to you at once. The data itself is erased 30 days later, a grace period that exists so a deletion made in error, or by someone who reached your account without authorisation, can be reversed; we email a cancellation link at the moment of the request. If you would rather it were erased immediately, write to us and we will carry it out without the waiting period. After those 30 days we delete the account record, which cascades to all linked data, including operational call records and aggregated counters, and we release any telephone number rented for your assistant. Where Veillant terminates, deletion completes within 30 days of the effective date of termination.

8.1 What survives, and for how long. Two kinds of record survive deliberately: the records that you accepted given versions of our legal documents, and the records of the deletion being requested, cancelled or carried out. They carry the account email address and our internal account identifier; the IP address they were created from is erased together with the account. Both are kept for five years from the end of the calendar year in which the account closed, and are then erased. The basis is Art. 17(3)(e) and the retention period Danish bookkeeping rules impose on the invoices those records explain. The administrative log of other changes made in the account is kept for 12 months from each entry. Analytics rows that carry a date are deleted after 24 months even while the account is open. Records held by our payment provider and our email provider follow their own retention rules and are outside this Section.

8.2 How the periods are enforced. An automated job runs daily, applies every period stated in this Section, and records what it deleted. Residual copies may persist in point-in-time database backups for up to seven days after deletion until the provider's rolling window expires. Backups are used only to restore the Service after a failure; where a restore takes place, deletions that fell inside the recovered window are applied again.

8.3 Your own content during the wind-down. Account, configuration and knowledge-base content remains exportable from account settings throughout the 30 days, so a deletion never removes your route to a copy of your own material.

9. Audit and information (Art. 28(3)(h))

We make available the information necessary to demonstrate compliance with Art. 28 on written request, within 30 days, and allow for and contribute to audits, including inspections, by you or an auditor you mandate. Unless a supervisory authority requires otherwise or a breach affecting you has occurred, audits are limited to once in any 12-month period, on 30 days' written notice, during business hours, under reasonable confidentiality undertakings, without unreasonable disruption, at your cost. We may satisfy a request with an up-to-date third-party certification or audit report covering the relevant controls, where one exists.

10. Records

Veillant maintains a record of the categories of processing carried out on your behalf (Art. 30(2)) and makes it available to you or a supervisory authority on request.

11. Liability, order of precedence, term

Each party's liability under this DPA is subject to the exclusions and limitations in the Terms. Nothing limits either party's liability to a data subject or a supervisory authority under Art. 82 or Art. 83 GDPR, or excludes liability that cannot lawfully be excluded. In case of conflict: (1) the standard contractual clauses referred to in Annex I, where they apply to a transfer; (2) this DPA; (3) the Terms. This DPA takes effect on acceptance of the Terms and continues until the Terms end and Section 8 has been performed; Sections 8 to 12 survive.

12. Governing law, jurisdiction, contact

This DPA is governed by the laws of Denmark, excluding its conflict-of-law rules. The courts of Denmark have exclusive jurisdiction, with venue of first instance at the Copenhagen City Court (Københavns Byret). This does not affect any right a data subject or supervisory authority has under Art. 79 or Art. 82 GDPR, nor any mandatory jurisdiction rule. Contact for all notices under this DPA: privacy@veillant.eu.

Annex I. Description of the processing

Controller: the Customer. Processor: Veillant (identified in the preamble).
Data subjects: natural persons who call a line the Customer has forwarded to the Service.
Categories of personal data: (1) the caller's voice and what the caller says, in transit and in memory only; (2) the caller's telephone number, in transit only, used to derive a coarse country and, where escalation is enabled, placed in the escalation email; (3) the caller's name and volunteered details, where the assistant escalates; (4) operational call metadata with no caller identifier; (5) aggregated counters as described in Section 6, containing no caller identifier and, for call reasons, no date.
Frequency: continuous, for the duration of each call, and on each escalation.
Duration: live processing for the duration of the call; records and counters for the life of the account, then erased 30 days after closure under Section 8, except the two records named in Section 8.1.

Sub-processors of Caller Data (locations as at August 25, 2026; the live list, including each provider's stated retention, is /subprocessors):

OpenAI: real-time speech-to-speech model, end-of-call aggregate analysis, knowledge retrieval. Call audio and content in transit and in memory. Contracting entity for EEA customers is OpenAI Ireland Ltd; processing takes place in the United States today, and the onward transfer out of the EEA is carried out by that entity under the safeguards of the OpenAI Data Processing Addendum. Model training on this data is disabled for Veillant's organization.
Twilio: telephony; receives the forwarded call and carries the media stream. Caller number and call audio. Call processing in Twilio's Irish region; the contracting entity for a Danish company is Twilio Ireland Limited; call metadata is held partly in the United States. Transfer mechanism per the Twilio Data Protection Addendum.
Resend: delivery of the escalation notice email. The caller's number, name if given, and the AI-written reason and note. United States.
Neon: PostgreSQL hosting for records and counters. No caller identifier, metadata only.
Vercel: web application hosting; transient request handling. United States and global edge.
Railway: hosting of the real-time voice bridge; call audio in transit. United States.

Transfers. Sub-processors of Caller Data process it in the United States today, except where a location above says otherwise. Veillant does not represent that Caller Data is processed within the EEA. Where a sub-processor contracts through an EEA entity, the transfer of Caller Data out of the EEA is carried out by that entity under its own data processing addendum, which provides the safeguards Chapter V GDPR requires (standard contractual clauses under Commission Implementing Decision (EU) 2021/914, or an adequacy decision under Art. 45); for the remaining sub-processors the transfer mechanism is the one stated in that sub-processor's data processing addendum. You instruct Veillant to carry out these transfers to provide the Service; this instruction can be withdrawn only by terminating, because the Service cannot run without them. Veillant intends to move telephony and AI processing to European regions; no representation is made that this has happened, and any change will appear on the Subprocessors page before it takes effect. Service providers for Customer account data (Google for sign-in, Stripe for billing) are not sub-processors of Caller Data.

Annex II. Technical and organizational measures (Art. 32)

No call audio stored. Audio is streamed and discarded; there is no audio store.
No raw transcript stored. The transcript is processed in memory at call end and discarded. What is kept is a count against a fixed set of categories or the internal identifier of a catalog item, never the words spoken and never text produced by the model.
No caller identifier stored. The call record has no field capable of holding a caller's number or name; the number is used in transit and never written to database, logs or analytics.
Recording is impossible in production, by construction. The recording facility is a development tool, gated by a fail-closed environment check that no flag or configuration can override in production, verified by a dedicated automated check that runs in continuous integration.
Aggregates are decoupled and delayed. Counters are stored one dimension per row, never as a per-call combination; the reason dimension carries no date at all; the dashboard shows a weekly snapshot, only after a minimum number of answered calls, and a visible counter never advances by fewer than five calls.
Encryption in transit everywhere (TLS; authenticated secure WebSockets for media); at rest via the database and hosting providers. Secrets live in deployment configuration, never in the repository, with automated secret scanning failing the build on detection.
Tenant isolation. Every query is scoped to the owning account; no query path returns another customer's data.
Authentication and authorization through a central guard on every page and API route; privileged routes require a server-side role.
Webhook and stream authenticity. Telephony webhooks are rejected without a valid provider signature; the voice bridge accepts a stream only against a signed token.
Rate limiting at the network edge and application layer.
Prompt-injection controls. Customer text is screened by an AI review gate and fenced as untrusted content before it can influence the assistant; the gate is designed to catch instruction-like content and fails open by design so a reviewer outage never blocks a save; call content is never printed to deployed logs.
Fail-closed legal gate. Without an approved spoken notice in the configured language, the call is refused before any AI processing, in all entry paths.
Point-in-time encrypted backups with a rolling recovery window.
CI gates on every change to the protected branches: type checking, linting, static security analysis, dependency audit failing on high severity, secret scanning, build actions pinned by commit hash; the production branch is protected.
Versioned legal controls. The spoken notice and the legal documents are versioned; published copies are frozen; the accepted version is stored per customer. The administrative audit log survives account deletion.