Legal
Records of processing
The summary a data protection officer asks for: what is processed, on whose behalf, for what, for how long, where it goes and how it is protected. Both halves — the processing we do for customers, and the processing we do for ourselves.
A working draft, not a final text
A public summary of an Article 30 record, not the record itself. The full record for a specific customer is that customer's own document, and we will fill in our half of it on request. Nothing here has been through a lawyer.
Two records, not one
Article 30 asks a processor for a record of the categories of processing carried out on behalf of each controller, and asks a controller for a fuller record of its own purposes. CallAgent is both, for different data, so this page has two halves and does not blur them.
The processor half covers everything a call produces. The controller half covers the people who use the product and the people who fill in a form on this website.
This is a summary written for a prospect's due diligence, published so the first question does not need an email. It is not the internal record, which names an actual customer and is theirs.
Processing carried out for customers
One category of processing, described honestly rather than split into six to look thorough: operating a voice platform on the customer's behalf.
That consists of connecting the telephone leg, streaming the caller's audio to a transcription vendor, sending the resulting text and the conversation history to a language model, converting the reply to audio through a speech vendor, and writing what happened to the customer's own records. When recording is enabled, the audio is stored. When tools are configured, the assistant writes into the systems the customer connected.
The controller is the customer. The data subjects are everybody on a call. The purpose is whatever the customer's assistant is for, and it is not ours to describe.
| Controller | The customer organization. |
|---|---|
| Processing | Operating a voice platform: telephony, transcription, model inference, speech synthesis, recording, tool execution. |
| Data subjects | Callers, called parties, the customer's staff, third parties mentioned on a call. |
| Categories | Telephone numbers, audio, transcripts, model messages, tool arguments and results, event payloads, timestamps, costs. |
| Special categories | Not sought. Reachable in practice — a caller to a clinic will state a health condition. |
| Recipients | The sub-processors on the published list, and any system the customer connected a tool to. |
| Transfers | To the United States with the default vendor configuration. |
| Retention | Recordings 90 days, transcripts and structured outputs 365, events and logs 90, unless changed. Analytics: no window. |
Processing carried out for ourselves
Four purposes, and the list is short because the product is not the business model of a company that collects things.
Running accounts: a name, an email address, a role and an organization membership, kept for as long as the account exists. Billing: usage, credits and invoices, kept for as long as tax law requires. Answering the contact form: what somebody typed, plus an HMAC of their IP address rather than the address itself, kept until the conversation is over. And server logs, which are operational and short-lived.
The legal basis is contract for the first two, legitimate interest for the third and the fourth. There is no marketing profiling, no lead scoring, no enrichment against a third-party database, and no advertising audience built from anything here — which is easy to promise and is also why there is no analytics on this site.
| Accounts | Name, email, role, organization. Basis: contract. Kept while the account exists. |
|---|---|
| Billing | Usage, credits, invoices. Basis: contract and legal obligation. Kept as tax law requires. |
| Contact form | Name, company, email, telephone, what they asked for, hashed IP. Basis: legitimate interest. |
| Guest articles | Author name, email, the uploaded document, hashed IP. Basis: legitimate interest. |
| Server logs | Operational. Basis: legitimate interest. |
| Not done | No profiling, no lead scoring, no data enrichment, no advertising audiences, no analytics. |
The general description Article 30 asks for
Organizational separation enforced at query level rather than in application code; role-based access within a customer organization; credentials encrypted under a key separate from the application key; signed, short-lived URLs for every object read; an append-only audit record of changes; transport encryption to every provider; a nightly retention job; and optional post-call redaction of personal data in transcripts.
The honest counterweight, in the same paragraph rather than a footnote: no certification, no third-party penetration test, no separation of duties on the operator side, no automated breach detection, and no retention window over the audit log itself.
Who to write to
There is no appointed data protection officer, because the criteria in Article 37 are not met and appointing one on paper would be worse than saying so.
Write to the contact address on the contact page, or use the form there. A question about a specific person's data almost always needs to go to the company that person rang rather than to us — the data-rights page explains why, and how to find out which company that was.
A route to a person, which is the point of publishing this
A DPA nobody can ask a question about is a PDF. If your review turns up something this page does not cover, or something it gets wrong, the form reaches the person who wrote it.
The other European documents
None of the seven documents in this set has been through a lawyer. They are engineering statements about a running system, published because a wrong description is worse than a missing one, and they will be reviewed before anybody is asked to sign anything.