Data protection and retention

This page describes how you set the retention, how you provide a disclosure or carry out a deletion and what the installation sends outward. It is meant as the basis for your own deletion policy.

The retention period

In the settings you define a retention period in days. Without a period nothing is deleted automatically; set it during setup to match your deletion policy. What counts is the last change to a conversation, not the date it was created.

What is deleted are conversations including their messages and the shared links created for them, and permanently at that. What is not deleted is the billing data. The usage of a past month therefore stays traceable even when the associated chats are long gone.

Every shortening asks back

If you set or shorten the period, a confirmation prompt appears with the old and the new period and the note that the shorter period will permanently delete additional, older conversations. Extending it later brings nothing back, what is already deleted stays deleted.

The cleanup runs regularly by itself and can additionally be triggered by hand. When it last ran and what it removed is stated next to it.

Disclosure and deletion per person

You reach both from the user list. The order is not arbitrary.

1. Export. The data export delivers the data of this person as one file: account, groups, credit balance, conversations, messages, file metadata and transactions. Files are included as metadata, not as content. Credentials are deliberately not included, so neither the password nor two factor secrets nor stored keys.

2. Delete. Only afterwards delete. After the deletion no disclosure can be given any more, which is why the export button also sits directly in the deletion dialog.

When deleting you decide on the depth: either the account and its content disappear and the transactions remain as a billing receipt, or usage is deleted as well. That is the full GDPR deletion, and the billing receipts are lost in the process. In both cases you confirm by typing the email address exactly.

Telemetry

The shipped state switches telemetry off: the components in use send no usage data to their makers, and search engines do not index the interface. If you take over an existing installation, check this once.

What leaves the instance

The installation runs entirely on your machine; conversations, the search index and uploaded files sit there. Where this machine physically stands is decided by your choice of hoster.

Two things inevitably leave the instance, and you should know them and communicate them internally:

Model requests go to the configured provider. A language model computes where it is operated. In the shipped state that is a provider with processing in the EU. If you additionally connect providers outside the EU, the requests of those cards go there. There is no mode in which a cloud request does not leave the machine. Locally operated models are the exception, but they need suitable hardware.

Web search requests go to external search engines. The search runs through a self hosted meta search which forwards the query to external search engines, though without the identity of the person searching. The queries themselves therefore do leave the instance.

Wording for your privacy notices

Put precisely, the statement reads: storage and inference can be kept in the EU or in Switzerland; with web search the search text leaves the instance, and it does so without any link to the user. Anyone who takes that distinction over verbatim into privacy notices and training is on safe ground even when critical questions come up.

Marking providers outside the EU

Providers that are not EU resident are marked as such in the panel and in the chat, so that the choice is made deliberately. The same rule applies to connectors: a connector whose target system is operated outside the EU has to be marked and does not belong in a customer deployment unasked.

Also note that origin information about providers comes from those providers themselves and that the registered office of a provider is no guarantee of the place of processing. More on that under Models and model cards.

Scope

Provisioning without SCIM. Accounts come into being at the first login through OIDC. Deprovisioning runs through your identity provider: whoever is deactivated there does not get through the sign-in any more and therefore reaches no data. For the complete removal of an account including its data, use the deletion dialog in the panel.

Receipts instead of a payment integration. Usage is recorded in full and issued as CSV and PDF; the payment itself you handle in your own system. Details under Usage, budgets and billing.

Outbound connections from code execution are governed at host or network level, not inside the application. Code execution is switched off out of the box.