Data processing agreement

Last updated 4 November 2026

This agreement applies whenever DeadPixel Studio UG (haftungsbeschränkt), Zeltinger Str. 77, 13465 Berlin ("we", the processor), processes personal data on behalf of a customer of ChatFrom ("you", the controller). It forms part of our terms of service and is concluded when you accept them, so there is nothing extra to sign. If you need a copy signed by both sides for your records, write to rouzbeh@deadpixelstudio.io. Where this agreement and the terms differ on data protection, this agreement applies.

1. Subject and duration

We process personal data to run your chatbots on ChatFrom, for as long as you use ChatFrom. On the free Hobby plan, we delete each conversation 14 days after its last message, with the notes and callback requests for calls before then. When the contract ends, section 9 applies.

2. What we process, for whom and why

Purpose. Storing and searching your chatbot's knowledge; answering the people who talk to your chatbot, with the AI model you choose; keeping a log of those conversations for you; notifying you when a visitor asks for a person or books a call; and, if you turn memory on, keeping short notes about returning visitors.

Kinds of personal data.

• the messages visitors write and the answers your chatbot gives;
• a random visitor id, or, in a chat app, the visitor's id there (on WhatsApp their phone number) and display name, and, if you turn memory on, notes about a visitor;
• a token your website or app passes for its signed-in user, which goes only to the tool servers you mark to receive it and is not stored;
• contact details a visitor chooses to give, such as a name, an email address or a phone number;
• ratings and comments visitors leave on answers;
• the text of files visitors attach in the chat, and what an AI model read in a picture they attach, if you turn files on;
• any personal data contained in the documents, websites and questions and answers you add;
• the sign-in email addresses of the people on your account.

People concerned. Visitors of your websites and users of your apps who use the chat, people named in the material you add, and the members of your team who use ChatFrom. We do not ask for special categories of data (Art. 9 GDPR). If your chatbot is likely to receive them, tell us before you go live.

3. Your instructions

We process the data only on your documented instructions: these terms and this agreement, and the settings you choose in ChatFrom. If we are required by law to do otherwise, we tell you first, unless the law forbids it. If we think an instruction breaks data protection law, we tell you and may wait until you confirm or change it.

4. Confidentiality

Everyone we authorise to process the data is bound to confidentiality, by contract or by law.

5. Security

We take the technical and organisational measures described in Annex 1 and keep them up to date with the state of the art. We may change them, as long as the level of protection does not drop.

6. Sub-processors

You agree that we use the sub-processors listed in Annex 2. We will tell you by email at least four weeks before we add or replace one. You may object for a reason related to data protection within that time; if we cannot resolve the objection, either side may end the contract when the change takes effect. We bind every sub-processor to data protection obligations that are at least as strict as these, and we remain responsible to you for their work.

7. Helping you with requests and assessments

We help you answer requests from the people concerned, to see, correct or delete their data. In ChatFrom you can read every conversation and every note, download or delete one conversation or everything kept about one person, delete notes, have conversations deleted 30 days, 90 days or a year after their last message, and delete a chatbot with all its data. For anything else, write to us and we do it within ten working days. If a request reaches us directly, we pass it to you and do not answer it ourselves. We also help with data protection impact assessments and consultations with authorities, as far as it concerns our part.

8. Personal data breaches

If we become aware of a breach of security that affects your personal data, we tell you without undue delay, and where possible within 48 hours. We tell you what happened, which data and how many people are likely affected, the likely consequences, and what we have done and propose to do. Where we do not know everything yet, we tell you what we know and follow up.

9. At the end of the contract

When the contract ends, we delete your personal data within 30 days, including copies, unless the law requires us to keep it. Before the end you can ask us to hand over your conversations in a common, machine-readable format. Backups of the server are overwritten in their normal cycle.

10. Information and audits

We give you the information you need to show that this agreement is met. You or an auditor you appoint, bound to confidentiality, may check it, after at least 30 days' notice, during business hours, and not more than once a year unless there has been a breach or an authority requires it. We will usually answer first with documents; an inspection on site is for when they are not enough. You bear your own costs of an audit.

11. Transfers outside the European Economic Area

We transfer personal data to a country outside the European Economic Area only under the conditions of Art. 44 to 49 GDPR: to a country or company covered by an adequacy decision of the European Commission, such as the EU-U.S. Data Privacy Framework, or under the Commission's standard contractual clauses. Annex 2 shows where each sub-processor handles data.

Annex 1: Technical and organisational measures

Where the data is

• The app and the engine that writes answers run on a server in Frankfurt, Germany. The database and sign-in run in Frankfurt, Germany.
• Each customer's chatbots are kept apart: the database lets a signed-in person reach only their own account's rows (row-level security), and each chatbot's knowledge is stored and searched separately.

Access

• People sign in to ChatFrom with a one-time link to their email address; there are no passwords to steal.
• The server accepts administrative access only with SSH keys, never with a password, and its firewall is open only for web traffic and SSH.
• Access to the server and the database is limited to the people who run ChatFrom.

Encryption

• All traffic to and from ChatFrom, and between ChatFrom and its sub-processors, is encrypted with TLS.
• The database is encrypted at rest by its provider.
• Credentials you store, such as API keys and webhook addresses, are never sent back to the browser in full; the dashboard shows a mask.
• The credentials of the services and chat apps you connect, the tokens of accounts people link in a chat app, and your other secrets (custom actions' headers, a tracing secret, the Slack hand-off webhook, your OpenRouter key and each chatbot's tool token) are encrypted in the database (AES-256-GCM) with a key kept apart from it.

Keeping the service secure

• The part of ChatFrom reachable from the internet runs in a locked-down container: a read-only file system, no operating-system privileges, no place a downloaded program could run from, and limits on CPU, memory and processes.
• Each container receives only the secrets it needs.
• Every build is checked for known vulnerabilities in the software it uses, and a build with a critical one is refused; the check also runs weekly.
• Requests are rate-limited per visitor and per address. Visitor IP addresses are used for this in memory only and are not stored.

Availability and monitoring

• Containers restart on their own when they fail, and new versions are rolled out without interrupting the service.
• The service is checked around the clock, and errors reach the team at once.
• The engine's data (each chatbot's knowledge, its files and paused workflow steps) is copied every night to the same server, and the last seven copies are kept; the server is also backed up weekly by its host.

Minimising data

• The technical log records events with internal ids, not the content of conversations. Error reports are set not to include personal data.
• By default the chat keeps its visitor id and its copy of the conversation only until the browser tab is closed. Recognising returning visitors is a setting you turn on, and only with your visitors' consent.
• No analytics runs in the chat on your website.
• Deleting a chatbot deletes its knowledge, conversations, notes and callback requests at once.

Annex 2: Sub-processors

You choose the AI model for each chatbot, and with it the provider that writes its answers. If that model cannot be used at a given moment, for example because its provider stops serving it, a visitor's message is answered by another model from the same provider where it offers one, so that the visitor still gets an answer; its answer is never written by a provider you did not choose. Every call names that provider to OpenRouter as the only one to use, with no fallback to another company's servers, and the small steps below are kept with their provider the same way. The small steps around an answer (rewriting a follow-up question for the search, searching your documents, keeping notes when memory is on, reading a picture a visitor sends) use ChatFrom's own models, currently from OpenAI, through OpenRouter. If you put your chatbot on WhatsApp, Telegram, Slack, Discord or Crisp, the bot, app, number or workspace is yours, in your own account with that service, and not our sub-processor. Email is the exception: the address a chatbot answers from is ours, on our Resend account, so email sent to it is processed by us and by Resend as our sub-processor. If you connect your own Langfuse or LangSmith account to trace your chatbot, that service is yours, not our sub-processor. We will tell you at least four weeks before this list changes, as section 6 describes.