Privacy Policy

Last updated: 2026-08-15

This Privacy Policy explains what personal data ChatURP processes, why, and on what legal basis. It implements our obligations under Articles 13 and 14 of the EU General Data Protection Regulation (GDPR) and § 25 TDDDG.

1. Controller

Maximilian Anton Palm (Bots & Bits, Einzelunternehmen) Gutzkowstraße 4 10827 Berlin, Germany Phone: +49 176 42094582 Email: [email protected]

Full operator details: see Imprint.

We have not appointed a Data Protection Officer because we are not required to under Art. 37 GDPR / § 38 BDSG. For any privacy question, email the address above.

2. Categories of data processed

Your own AI assistant. If you connect an AI assistant of your choosing to ChatURP (profile menu → Connect Claude), ChatURP sends that assistant what it asks for — your programs, knowledge-base answers, download links. From there the data is processed by the assistant and its provider under your own agreement with them, outside our control; we are neither its controller nor its processor for that. An AI program review your assistant requests is run by our model provider exactly as described for the AI program review above.

About your IP address. We do not shorten or anonymise it. Our own code uses the full address, held in memory only, to rate-limit requests and damp abuse; it is not written to any table we own and does not survive the request. It is nevertheless recorded in two logs whose retention we do not set: the access log of the web server that serves the application, which lives as long as the container instance handling your traffic, and Supabase's platform logs, whose retention follows the Supabase plan we are on. We are not quoting a number of days for either, because neither is a period we control.

We do not sell personal data. We do not use your prompts, generated programs, or chat history to train AI models, and we have licensed no one else to do so. Our model provider is contractually prohibited from using what we send it to develop or improve its models unless we explicitly agree to that use — clause 4.2 of the OpenAI Services Agreement our account is on — and we have not agreed to it, so this is an obligation we can point at, not a policy statement we are repeating. We do not use behavioural advertising, third-party analytics, A/B testing, or session replay. We do keep a small amount of first-party, aggregate feature-usage counting (which features get used — see the table above) to guide what we build; it is attributed to your account, deleted when you delete it, and never shared or sold.

3. Subprocessors

We rely on the third parties listed below. Their contractual position is not the same for each — most are our processors under Art. 28 GDPR, while Paddle acts as an independent controller (merchant of record) — so we set it out party by party under the table rather than as one blanket sentence.

What is actually in place, processor by processor. We would rather be precise here than reassuring:

• Supabase – Supabase's standard Terms of Service incorporate its Data Processing Addendum by reference (clause 7 (b) of those Terms), and that Addendum provides that acceptance of the agreement has the same effect as signing the EU Standard Contractual Clauses. It therefore binds our account without a separate signature. We have not negotiated or counter-signed a bespoke agreement, and the Supabase contracting entity named in that Addendum is Supabase Pte. Ltd., Singapore, even though our project's data is stored in Stockholm.
• OpenAI – OpenAI's Data Processing Addendum is incorporated by reference into the OpenAI Services Agreement our account is on: clause 5.3 provides that where the service is used to process personal data, OpenAI and we will comply with that Addendum, which clause 5.3 states is incorporated by that reference into the Agreement. It therefore binds our account without a separate signature, in the same way Cloudflare's and Supabase's do. We are additionally executing it through OpenAI's own signature flow, which returns a countersigned copy naming us as controller; we will say so here once we hold it. It applies the EU Standard Contractual Clauses of Commission Implementing Decision (EU) 2021/914 on a controller-to-processor basis. Clause 4.2 of the Services Agreement is the one that matters most here: OpenAI will use what we send only to provide the service, comply with the law, enforce its policies and prevent abuse, and will not use it to develop or improve its models unless we explicitly agree — we have not, and there is no setting on our account that opts in. Preventing abuse is the exception that carries a retention consequence: prompts and outputs are held in OpenAI's abuse-monitoring logs for up to 30 days by default, which is why we do not claim zero retention anywhere. On termination OpenAI deletes our content from its systems within thirty days (clause 11.3). For customers in the EEA the Agreement applies Irish law and names OpenAI Ireland Ltd, Dublin, as OpenAI's address for notices (clauses 16.3 and 16.5); the inference itself runs on OpenAI's infrastructure in the United States. Until 7 August 2026 this role was filled by Fireworks.ai, Inc. in the United States, and until 2 August 2026 by DeepSeek in China, for which no data-processing agreement or transfer safeguard was obtainable at all.
• Paddle – Paddle's Master Services Agreement, which we accepted when we opened the account, is expressly not an Art. 28 processor agreement: it provides that each party acts as an independent controller, and the sharing of data between Paddle and us is governed by Paddle's Data Sharing Addendum on a controller-to-controller basis with the EU Standard Contractual Clauses. One narrow flow — us passing your account email address and display name to Paddle so it can create your customer record — looks more like processing on our instructions than controller-to-controller sharing. We have asked Paddle to confirm the allocation in writing and will update this section with the answer.
• Cloudflare – Cloudflare's Self-Serve Subscription Agreement, which we accepted by using the service, provides at clause 6.1 that Cloudflare will handle personal data in compliance with its Data Processing Addendum, "which is hereby incorporated by reference into this Agreement". That Addendum (version 6.4) therefore binds without a separate signature, and it applies the EU Standard Contractual Clauses. Cloudflare, Inc. is additionally an active participant in the EU-U.S. Data Privacy Framework, the Swiss-U.S. framework and the UK Extension, which under the Addendum's own definitions means the transfer to it is not a restricted transfer.
• Resend – Resend's Terms of Service state that they, the Privacy Policy and the Data Processing Addendum together form the entire agreement, and that Addendum provides that it becomes legally binding when the customer enters into the agreement, without separate execution. It binds our account on that basis, and it incorporates the EU Standard Contractual Clauses, Module Two (controller to processor), by reference. The contracting entity is Plus Five Five, Inc., San Francisco, California. What Resend receives is the recipient address, the subject line and the full body of our own account and billing mail.
• manitu – We hold a signed Auftragsverarbeitungsvertrag (Art. 28 (3) GDPR processing agreement) with manitu GmbH, concluded on 2 August 2026, covering all current and future contracts under our customer account. It provides that processing takes place exclusively within Germany, the European Union or the European Economic Area, and it carries an annex of technical and organisational measures under Art. 32 GDPR. manitu is the SMTP relay configured for the mail Supabase Auth sends on our behalf — signup confirmation and password reset — so what it handles is your email address and the content of those two messages, in Germany.

Where nothing is in place we say so above rather than imply otherwise. We are working to close each gap and will update this section as each is settled; we will not name a date we do not control.

A current list is maintained on this page. We notify you by email of any change in subprocessors at least 14 days in advance for processors that handle account or billing data.

4. International transfers

Some subprocessors are located outside the EU/EEA. The position for each:

• Paddle (UK) – Commission adequacy decision of 28 June 2021 (Art. 45 GDPR). Paddle's Data Sharing Addendum additionally applies the EU Standard Contractual Clauses on a controller-to-controller basis.
• Supabase (Singapore / United States) – your data is stored in Stockholm, but Supabase is not an EU-established company and its staff and tooling can reach the project. The EU Standard Contractual Clauses in Supabase's Data Processing Addendum cover that access.
• Resend (United States) – Resend's Data Processing Addendum, which binds on acceptance of its terms, incorporates the EU Standard Contractual Clauses, Module Two (controller to processor). Resend additionally states that it complies with the EU-U.S. Data Privacy Framework and the UK Extension. It engages its own subprocessors under a general written authorisation, with 14 days' notice of any change.
• Cloudflare (United States) – Cloudflare, Inc. is an active participant in the EU-U.S. Data Privacy Framework (and the Swiss-U.S. framework and UK Extension), which we verified on the U.S. Department of Commerce's public participant list. Its Data Processing Addendum, binding on us through clause 6.1 of the subscription agreement, provides that a transfer to the United States made under that Framework is not a restricted transfer. The same Addendum applies the EU Standard Contractual Clauses to anything that falls outside it.
• OpenAI (United States) – the EU Standard Contractual Clauses (controller to processor), incorporated into OpenAI's Data Processing Addendum, which binds our account through clause 5.3 of OpenAI's Services Agreement. OpenAI is not certified under the EU-U.S. Data Privacy Framework, so this transfer rests on the Clauses rather than on the Framework, and we have carried out and documented a transfer impact assessment for it. OpenAI engages its own infrastructure and support providers, which operate in the United States and a number of other countries; changes to that list are published by OpenAI and we track them.

What is sent to the model provider. Each time you generate or edit a program, our backend sends to OpenAI's API in the United States:

• our own system instructions and excerpts from our own documentation;
• the free-text instruction you typed;
• your robot program, in our internal structured representation;
• configuration derived from any robot installation file attached to the conversation — tool-centre-point definitions, I/O signal names, payload settings;
• the earlier turns of that conversation, condensed when it runs long.

A second, smaller call produces the chat title from the first 800 characters of your message and the first 600 characters of the reply.

What is sent for a Diagnostics AI analysis. The Diagnostics tools read your support file in your browser; the file itself is never uploaded to us and never reaches the model provider. When you ask for an AI analysis, what does leave your browser is a selection from what was read: the log rows inside the timeframe you chose, at the severities you chose — their timestamps, event codes, message text, and the software component that raised each one — the robot's model, serial number, software versions and installed URCaps, and the free-text problem description you typed. It goes to the same provider, in the same country, under the same terms as above. For an AI analysis of the logs, the robot program and the installation file are deliberately not sent, and no analysis prompt is written to any database of ours.

What is sent for a Performance report. A Performance report is built on our servers from the recording, the program and the installation file inside the support file — a .urp and a .installation from a PolyScope 5 robot, or the .urpx bundle from a PolyScope X one, which carries its application with it. Since 11 September 2026 the report also carries two AI-written sections; to produce them we send the same provider, in the same country and under the same terms, the report's own findings, the robot's identity, and the program and installation file as structured data. The provider holds that for up to 30 days in its abuse-monitoring logs; we store the two AI sections on your account with the report's identity so a report you have paid for can be regenerated free, and delete them with your account.

What is sent for an AI program review. The AI program review (Program review in the menu) takes a robot program on its own, with no support file and no log files involved. To produce the review we send the same provider, in the same country and under the same terms as above, the program itself as structured data, together with the installation and variables files if you supply them — for PolyScope X, the .urpx bundle, which carries its application with it. The provider holds that for up to 30 days in its abuse-monitoring logs. We store the finished review on your account so one you have paid for can be re-opened rather than bought again, include it in the data export under Account → Profile, and delete it with your account. We do not store the prompts, and we do not keep the program file itself.

Where the analysis is kept. The analysis we produce is stored on your account, so a run you have paid for survives a reload and can be re-opened on another device rather than living only in the browser that made it. It contains our own findings and the log lines they quote. We keep it until you delete your account, because deleting it earlier would revoke something you bought; it is included in the data export under Account → Profile, and it goes with the account when you delete that. We do not store the prompts themselves, the log rows we sent, or the support file.

What is not sent: your user id, account identifier, email address, name, billing data, or your IP address. The call is made server-to-server from our own backend, so the source address is ours, and the optional user field of the API request is deliberately left empty.

We nevertheless treat what we do send as capable of containing personal data. The instruction is free text, and programs and installation files carry names you chose, so a colleague's name, a customer or site name, or an address can end up in the content we transmit.

Retention at the provider. OpenAI keeps prompts and outputs for up to 30 days in abuse-monitoring logs, and deletes them after that unless it is legally required to keep them longer or needs them to protect the service or a third party from harm. That is OpenAI's default for API traffic, and it is the one retention we cannot switch off from our side: zero-retention processing has to be applied for and approved by OpenAI. Repeated context is additionally cached so that a long conversation does not have to be re-processed from scratch on every turn, and cached input lives as long as its cache entry. So the accurate statement is "held for up to 30 days for abuse monitoring", not "never kept" — and it is not used to train or improve any model either way (§ 2).

We have changed model provider twice, and said so each time. Until 2 August 2026 this went to DeepSeek in China: there was no adequacy decision for the People's Republic of China and no data-processing agreement or Art. 46 safeguard available for that transfer, because DeepSeek offers neither. We moved to Fireworks.ai in the United States to end that, and on 7 August 2026 to OpenAI, also in the United States, for the quality of the model. Both of those transfers rest on the Standard Contractual Clauses with a documented assessment behind them; the move away from China was the one that changed our legal position, and the move to OpenAI changed the retention statement above.

The agreements we rely on — OpenAI's, Supabase's and Cloudflare's Data Processing Addenda, Paddle's Data Sharing Addendum, and our Auftragsverarbeitungsvertrag with manitu — are either published by those providers or held by us, and we will point you to the current version of any of them on request. For anything else here, write to [email protected].

5. What we store in your browser

ChatURP stores the entries below. They are all strictly necessary to run the service, so they do not require consent under § 25 (2) TDDDG.

We set no cookies at all. Everything here is local storage, session storage or your browser's own database, none of which is transmitted to a server on its own. Session storage is deleted when you close the tab; the others stay until you clear them or we remove them.

Most of these are preferences. The ones that hold more than a preference are described in the table above; they include your sign-in token, the edits you have made but not yet saved (chaturp:tree-edit-queue:<key>), and, if you use Diagnostics, the last few support files you opened together with the findings of any analysis you have already paid for. Those copies stay in your browser; clearing your site data removes them.

We use no advertising or profiling storage, and no third-party trackers. The only analytics-related entry is a per-session de-duplication key (listed above) that stops our first-party feature-usage counting from recording the same action twice; it holds no behavioural profile and is cleared when you close the tab. If we ever add non-essential storage, we will ask for your consent first.

6. Fonts and third-party assets

The interface uses the open-source Inter and JetBrains Mono typefaces, served self-hosted from our own infrastructure. No font request is made to Google or any other third party.

7. Payment processing (Paddle)

When you start a checkout, Paddle.com Market Ltd. is loaded as an independent controller and acts as merchant of record: it collects your name, billing address, country of residence, and payment instrument; it calculates VAT and issues invoices in compliance with EU law. Paddle's own privacy notice applies in addition: https://www.paddle.com/legal/privacy

The Paddle SDK is loaded lazily, only on the Pricing and Account → Billing pages, to minimise data transfer.

8. Your rights under GDPR

You have the right to:

• Access (Art. 15) - request a copy of personal data we hold.
• Rectification (Art. 16) - correct inaccurate data.
• Erasure (Art. 17, "right to be forgotten") - delete your account and associated data, subject to retention obligations such as tax law.
• Restriction of processing (Art. 18).
• Data portability (Art. 20) - receive your data in a structured, machine-readable format.
• Objection (Art. 21) - object to processing based on legitimate interest.
• Withdraw consent (Art. 7 (3)) at any time, without affecting the lawfulness of prior processing.

Most of these are self-service in Account → Profile. Otherwise email [email protected]. We respond within 30 days (Art. 12 (3) GDPR).

You may also lodge a complaint with your local supervisory authority. For users resident in Germany, that is typically the data-protection authority of your federal state; for users elsewhere in the EU, the authority of your country of residence.

9. Security

We use TLS in transit, encryption at rest, hashed passwords (bcrypt via Supabase Auth), and least-privilege access controls. Despite our efforts, no system is fully secure. Report suspected breaches to [email protected]. We will notify affected users and supervisory authorities under Art. 33-34 GDPR where required.

10. Children

ChatURP is not directed at minors. Using the Service requires full legal capacity to enter into a binding contract, so it is restricted to persons aged 18 or over (see Terms § 2.1). We do not knowingly process the personal data of anyone under 18. If you believe a minor has signed up, contact us and we will remove the account.

11. Automated decision-making

The Service uses large language models to generate program drafts. We do not use automated decision-making with legal or similarly significant effects in the sense of Art. 22 GDPR. Generated programs are advisory output; the human operator decides whether to deploy them.

12. Changes

We may update this Policy. Material changes will be notified by email at least 14 days in advance. The current version is always available at /privacy.