Transparency report

What Souveräne Systeme does with your data, and what it does not do. In plain language, verifiable in the open source code.

In one sentence

By default, we cannot read content you retain because your browser encrypts it; plaintext exists during active processing, and the core stores saved result content readably only if a standard account explicitly chooses plaintext for that category, while live and raw content bypasses the core and is never stored.

You do not have to take our word for this: you can verify the boundaries in the published source code at git.souveraene-systeme.de.

The rest of this report explains what that means, where your data resides, who handles it, and where plaintext exists.

What we never do

• Write live or raw processing content to disk. Audio, document input, email bodies, transcripts and translations are held only in memory during processing and are overwritten afterwards, without even being written to temporary storage. Saved results are separate and follow the storage level described below. Site Watch also persists the encrypted, service-readable comparison snapshot described below; it does not persist the plaintext.
• Log content. Our logs contain metadata (time, event type, account reference), never the content of your conversations, documents or emails.
• Choose advertising networks, analytics services or US corporations as our recipients. Our own provider chain contains none. If you explicitly bring a US search provider, derived queries go there on your instruction; that separate case is documented below.
• Use your content to train AI models. Neither we nor our AI processing providers do so; non-retention is contractually agreed. A search provider’s stated use of derived queries is documented separately below.
• Sell your data. In no form and to no one.
• Load trackers, analytics or third-party fonts. Our website and application set no analytics cookies, embed nothing from third parties and serve all resources from our own server.

What we do, and where it happens

Our system is deliberately divided into two separate halves. This is central to the data-protection commitment, so it is described in detail here.

        You / your browser
        creates a random account key locally
        derives its wrapping key from your password
           |                          \
   Administration and storage          \  Live/raw content (direct, TLS):
           v                            \ audio, text, decrypted config
   Core server (Hetzner, DE)             \
   Accounts · billing · invoices          \
   ZK blocks · optional plaintext         v
   saved results · no live/raw data   Processing, in three locations:
                                     Permanent services (netcup, Nuremberg)
                                     Model response     (AKI.IO, Berlin)
                                     GPU sessions       (Scaleway, FR/PL)
                                     active plaintext · memory only

The core server in Germany (at Hetzner Online GmbH) handles administration: accounts, billing, invoices and schedules. It also stores saved results. The default is a zero-knowledge block encrypted in your browser, which the core cannot open. If you explicitly select plaintext for a result category, the core stores that result readably but does not parse or index its payload. This option is blocked server-side for accounts subject to statutory professional secrecy obligations. Live and raw content never passes through the core.

The processing plane is where the actual AI work takes place: transcription, translation, chat responses and email classification. It necessarily sees plaintext, but active processing is only in memory and only for the duration of the run; plaintext is not written to storage. Site Watch has one deliberate persistent comparison state: the core stores the latest snapshot encrypted to the monitoring service’s key, and that service can decrypt it for the next run. Customer-visible findings are separately encrypted to the customer’s key. Since 30 August 2026, processing has operated in two locations, divided according to whether a service runs continuously or is created for a session:

• Permanent services — chat, document processing, Matrix bot and site monitor — run on a dedicated server operated by netcup GmbH in the Nuremberg data centre. Until 30 August 2026 they ran at Scaleway SAS. The move changed the provider, not the data categories.
• The model response in chat has been produced by AKI.IO GmbH in Berlin since 21 September 2026, in data centres located exclusively in Germany. Before that this interface sat at Scaleway SAS; the move changed the provider, not the data categories. Since 1 October 2026 Site Watch also checks there whether a change concerns your monitoring instruction. Classification and summaries of incoming email for Postvogt, and translation and summaries of a Klangskript recording without a GPU session, will follow (decided, not yet switched).
• GPU sessions — Klangskript, Open Notebook, the podcast companion and the dedicated instance — continue to run at Scaleway SAS in France and Poland, as do the embeddings of your knowledge base and the two on-demand services for Klangskript recording (transcription there) and Postvogt. A live instance is destroyed after the session.

Your browser creates a random account key during registration. On sign-in, it derives a wrapping key from your password and uses that key to open the sealed account key; changing the password reseals the same account key under a new wrapping key. For live and raw content, the browser connects directly to processing, bypassing the core server. The account key never leaves your device.

Two services depart from this diagram in opposite directions. The dedicated instance moves processing to a GPU machine assigned solely to your account for the duration of the session and destroyed afterwards. There is no other account on that machine against which isolation needs to be justified. The Terminal leaves our infrastructure in the other direction: it displays the command line of your own computer, the browser connects to 127.0.0.1, and neither keystrokes nor output pass through our servers. It is therefore a display, not a service operated by us.

The Python sandbox works in the same direction. To calculate rather than generate figures, the assistant can write and run small Python programs: to analyse a table, determine a deadline or trace what a formula does. This program runs in your browser, not on our servers. It reaches exactly one address, the program components on our own server, and nothing else: no third-party services and not even our own APIs. Your file does not leave your device for this purpose.

Two further statements are necessary. The program’s output is sent to the model. It is the answer to the question you asked and follows the same route as the text of an attachment would in any case. This introduces no new recipient. The sandbox also reads the original file, not only the text extracted from it. It can therefore reveal material that text extraction did not capture, including further worksheets, formulas and embedded objects. The same route and recipient receive more of the file.

Your results: you choose the level

For stored results (chat histories, documents and their analysis, Klangskript results and research reports), you choose a level for each category:

• Zero knowledge (default): encrypted in the browser; we hold only a data block that we cannot read.
• Plaintext: stored readably on our servers only if you explicitly enable this for the relevant category.
• Ephemeral: nothing is stored; it is discarded after the session.

The plaintext level is blocked server-side for accounts subject to statutory professional secrecy obligations. The core neither parses nor indexes a plaintext result payload. Live and raw data (audio streams) remain ephemeral at every level. Your knowledge base including its files, Kanban, Postvogt digests, and Deadline Watch’s contract text and clause quotations are always encrypted and cannot be changed to another level. The reminder label, contract end date and notice period are different: the core stores them as readable metadata because it uses them to calculate and send reminders.

Where we need to be candid

One point calls for plain language rather than marketing. Postvogt (email triage) must run while you are away from your device. To make this possible, your mailbox configuration is additionally encrypted so that our processing plane can open it for a background run. Put plainly: for background runs, our processing plane at Scaleway can decrypt your mailbox credentials; our core server cannot. Always connect mailboxes with an app password, never your main password. Email content is processed only in memory, the email body is not stored outside your mailbox, and only you send messages. What survives a run is one digest entry per email — sender, subject, category and a summary — which the processing plane encrypts to a key belonging to your account. It can be read only in your browser and is deleted after 30 days.

There is one exception, and you choose it: if you connect the Matrix bot, Postvogt also creates a notice for each email — sender, subject, language, summary and the email’s identifier — encrypted so that our bot service can open it; otherwise it could not post it to your room. It waits at most seven days and is deleted as soon as the bot has posted it. You set which categories are reported; suspected spam is off by default. If you write in the thread of an email, the processing plane reads that one email live from your mailbox as far as the bot needs it for a translation or a reply draft, and the bot service passes it to the chat’s language model for that purpose — in memory only, without storage. The bot files a draft only after your “yes”; only you send messages.

Matrix bot: the second place where we need to be candid

The Matrix bot is an assistant in your Matrix rooms. We do not operate a messenger. You create a bot user on a homeserver and we sign in with that account. The bot’s address, user ID and password are held only in encrypted form; none appears in plaintext on our core server. Room content is processed only in memory, is not written to disk and is not logged. With a Postvogt subscription, one notice per new email is added that our bot service can open, see above. You can revoke access without involving us by changing the bot user’s password or signing its device out on the homeserver.

The homeserver is your choice, and that choice matters more than it first appears. Any server works technically, including an account with a public provider. We strongly recommend one of your own because end-to-end encryption protects message text, not the surrounding circumstances. The homeserver operator sees who shares which room, when and how much is written, the IP addresses of every connected device, and room names, topics and member lists in plaintext. Matrix encrypts the message, not room state. A room named after a client matter reveals its subject through the name. The homeserver also manages each account’s device list. Anyone controlling it can try to add another device that reads future messages; mutual device verification is the only defence. Another homeserver is also not our processor; you assess and accept responsibility for that connection. If you do not want to operate a server, you can rent a managed Matrix server (for example, etke.cc). We have no commercial relationship with that provider either.

The point requiring plain language is knowledge access. If you enable it, the bot service receives a key to your knowledge base and can read it while the connection exists; previously only your browser could do this. Without the exception, the bot could not use your organisation’s knowledge because there is no browser in the room to decrypt it. The function is disabled by default; you decide. Answers using knowledge appear only in rooms where every present member is on your allowlist. Disabling access withdraws the key, and access ends within one minute at the latest. The Matrix bot is blocked for accounts subject to statutory professional secrecy obligations.

Web research: the third place where we need to be candid

Web access is disabled by default. If you enable it, derived search queries leave our infrastructure. This is a deliberate exception to our general rule, and we state it rather than conceal it.

Consent is not the same in every feature. In chat, selecting a search provider in settings is standing permission until you revoke it. The first time you switch on web research in chat, a one-time notice names the recipient and its retention and must be confirmed; after that the switch starts on, and one click turns it off for the current browser session. There is no routine confirmation for each query. One exception: once a fetched page, a search result or rows from your connected database have entered the current turn, each further outgoing request is shown with its content and sent only after confirmation, because that content could carry instructions that look like part of your question. Every query is cleared of recognised personal data before sending and remains visible in the trace, with the provider for each search. Research instead shows the complete planned queries verbatim and sends them only after you approve the plan. A separately selected context provider is a separate permission: choosing a search provider does not authorise it.

The requests pass through our own search-egress server in Nuremberg. This is a separate netcup server from the permanent content-processing plane. In chat, an individual page can be fetched only from an address already named in the conversation or returned by a search or context tool in that turn. In Research, you select search results before they are fetched. If you provide a starting address, Research may also discover addresses beneath it from the site’s published robots.txt and sitemap.xml files or, if there is no published directory, from one level of links on the starting page. Discovery reads no destination page content. The resulting list is shown to you for selection before any of those pages is fetched. There is no recursive crawler.

Two kinds of fetch can run without a person present at that moment: a site monitor you configured and an armed workflow to which you granted web access for that one schedule. Both obey the target’s robots.txt on every run and use distinct product identifiers, SouveraeneSystemeWatch and SouveraeneSystemeWorkflow; interactive retrieval uses SouveraeneSystemeFetch. An armed workflow does not receive a customer-owned search-provider key: a background search that needs such a key is refused and does not fall back to our provider.

The search engine receives the search terms and the IP address of our server. It does not receive your IP address, account identifier, a session reference, your documents or chat histories. Our search server creates no log of the requests, not even temporarily.

The search provider does create one. Omitting that sentence beside the preceding one would be misleading. You select the search provider yourself in settings. The European provider we offer is Staan (European Search Perspective, Paris), a joint venture of Qwant and Ecosia with its own European index. According to the provider, it retains the search query, time and market identifier for 25 months and uses them to improve its ranking. That is the provider’s own purpose, not processing on our instructions. Its data processing agreement also takes the position, in clause 2, that search queries are not personal data. We do not share that legal opinion. We accepted the agreement on 20 September 2026 and told the provider in writing, at the same time, that for us Annex 1 of that same agreement governs: it lists the search query as a category of data processed, with provision of the service as the purpose. We have asked how this relates to the retention for their own ranking. No answer so far; we will record the outcome here.

Why we nevertheless offer the function: without it, users conduct research themselves using a large search engine and paste the result into chat. The query then leaves their own computer with their IP address, browser and account with that provider. Omitting the function protects no one; it merely moves the disclosure to a place we can no longer identify.

The distinction from searching with a large provider is therefore not that we search invisibly on your behalf. It is this: minimal derived search terms instead of your full question, no link to you at the search provider, European infrastructure, and no use for training. The function is blocked for accounts subject to statutory professional secrecy obligations.

Calendar: the fourth place where we need to be candid

You connect your own calendar through CalDAV. We do not operate a calendar and we do not store a single appointment. Your calendar remains the repository; we only read and write there. This is not modesty but the simpler design. A calendar of our own would mean maintaining a second source of truth, synchronising it with yours and then exporting the appointments back to your phone.

You choose who operates your calendar server, and that operator is not our processor. As with the homeserver, you choose it and hold the contract; we transmit data there on your instructions. If you use your existing provider’s calendar, its privacy policy applies to that connection, not ours.

Credentials and the calendar address are stored with us only in encrypted form. For a question in chat, your browser decrypts them and passes them with the request. The processing plane holds them for the duration of that single call and no longer. Nothing is ever written without asking: the assistant shows what it would create, change or delete and acts only after your approval. When changing or deleting, it may also touch only entries that it found in your calendar immediately beforehand; it cannot invent an appointment that does not exist.

The connection to the Matrix bot is the point requiring plain language. To send reminders on its own, it must be able to open your calendar credentials because there is no browser in the room to do so. Put plainly: the bot service can decrypt your calendar credentials while it runs, the same exception as for knowledge access and for the same reason. Reminders appear only in rooms where every present member is on your allowlist, and appointment content then resides on your homeserver. Without Matrix, the function remains in chat and this exception does not apply. The calendar connection is blocked for accounts subject to statutory professional secrecy obligations.

Nextcloud: the fifth place where we need to be candid

You can connect your own Nextcloud. The assistant then reads files from it and, after your confirmation, stores results there. As with the calendar, your Nextcloud is not our processor but your own system. Your documents do not move to us.

The scope of access is the point requiring plain language. A Nextcloud app password cannot be restricted to one folder and reaches the entire drive of your account. This is a property of Nextcloud, not a decision by us, but you should know it before entering the credentials. If that is too broad, use a password-protected share link to one folder instead. Contacts, Deck, file search and calendar are then unavailable because they belong to the account, not the folder. We do not accept shares without a password; without one, the stored value would be a secret in the form of an address rather than a credential.

The connection is stored encrypted in your vault and opened in your browser for each request. Credentials are never written to a log, error message or response. Paths and filenames are never written to logs or error responses; an authorised listing or search result necessarily returns the requested names and paths to your client. A path such as “/Clients/Meier GmbH/Termination.pdf” identifies your client. Access is revoked in your Nextcloud, not with us: revoke the app password or delete the share. A button on our side would depend on action by us. The connection is blocked for accounts subject to statutory professional secrecy obligations.

Your own database: the sixth place where we need to be candid

You can connect your own database (PostgreSQL or MySQL/MariaDB). The assistant then runs read-only queries, each one shown to you beforehand with its target and the complete SQL text for confirmation. As with Nextcloud and the calendar: your database is not our processor but your own system.

Only read-only statements are permitted — enforced technically through a keyword allowlist and a read-only transaction, not merely by asking the language model politely. The connection runs encrypted (TLS), and we check the server name against the address you provided; there is no plaintext fallback. The interface shows you the addresses that need to be allowed on your side, so you can pass them to your firewall.

The credentials sit encrypted in your vault and are opened in your browser for each individual call. SQL text, host, database name and the returned values are never written to a log or an error message. The connection is blocked for accounts subject to statutory professional secrecy obligations.

Your own search provider: the seventh place where we need to be candid

You can direct web search to a provider with which you have a contract and for which you store your own key: Brave Search or Perplexity Search. Both are US companies. This is where one of our commitments reaches its limit, and we state it rather than leave it to the small print: our provider selection remains European. Yours does not have to be.

We offer this for the same reason as web search in general. Anyone who subscribes to a search engine will use it, if necessary in another window with their own IP address, browser and account there, and then copy the result. Not offering the option would keep no query away from these providers. It would only move the query somewhere we could no longer separate anything from it.

What we separate: the provider receives the derived search query and the address of our server in Nuremberg, not your IP address, account identifier or a session reference. Your key is stored with us encrypted, opened in your browser for the individual call and passed through, never retained. The same feature-specific consent, query visibility and personal-data check described above continue to apply.

What we cannot separate, and this is the material point: your key is a stable identifier to the provider. It can associate the queries received under that key with one another. This is not possible with our provider because all queries there come from one pool. The provider’s terms state what else it does and how long it retains data. It is your contractual partner, not our processor, and we cannot make commitments on its behalf.

The function therefore remains disabled until you enable it for each provider. It is never preselected, never runs without your key, and does not silently fall back to our provider during an outage. A query directed to your provider is not sent somewhere else instead. Web search remains blocked for accounts subject to statutory professional secrecy obligations even with their own key: a contract between you and a search engine does not cure a breach of professional secrecy.

Our commitments

• Ephemeral where possible. Active plaintext is not written to storage, and a session GPU instance is destroyed afterwards. Saved results and Site Watch’s encrypted comparison snapshot follow the explicit rules above.
• European infrastructure with no US parent company. Every service provider we engage is based in the EU (Germany, France, Poland, the Netherlands and Austria); none belongs to a US group. This commitment applies to our own provider selection. It does not prevent you from bringing your own web-search provider, including a US provider; see below.
• Zero-knowledge configuration. The core cannot read stored glossaries and custom instructions. Your browser opens them locally and sends plaintext only to the processing plane for active work.
• No password reset that restores your content. Recovery codes take its place. A lost key is the price of our not having it. We communicate this openly instead of installing a back door.
• A separate route for professional secrecy obligations: planned, not yet in operation. Under our own rule, anyone subject to a statutory duty of confidentiality (§ 203 StGB) must not use standard processing. This rule is enforced in the system: chat, documents, web research, Matrix bot, calendar, Nextcloud, your own database, image generation and the dedicated instance are blocked server-side for these accounts. The separate route itself has not yet been built. Its provider has been selected (IONOS SE, Germany), and the § 203 clause appears in that provider’s terms. What is missing is written confirmation that it applies to our contract, which we require before any processing may take place there. Nothing has been processed there to date. Until this is complete, we cannot serve professionals subject to secrecy obligations, and we state this rather than leave a qualification to appear only at contract signing.

For those who want to verify it

You do not have to trust the commitments above; you can inspect them in the source code. It is available at git.souveraene-systeme.de under AGPL-3.0-or-later. The relevant locations are frontend/src/lib/auth/ for browser-side account-key generation, unwrapping and resealing, while core/src/core/security.py and tiers.py contain the access checks. Signed-in users can also see the zero-knowledge boundary live in the application’s vault through a specific example: plaintext on their own device on the left and the precise encrypted block our infrastructure receives on the right.

After publication, we will link directly to the relevant locations here:

• How content is overwritten in memory after processing
• How the core enforces the selected storage level and rejects plaintext for accounts subject to statutory professional secrecy obligations
• How the account key is generated, unwrapped and resealed in the browser and never leaves it
• The complete list of service providers and their roles (see below)

Service providers (sub-processors)

Payment processing is not included in this table, although we engage it. You add credit through Mollie B.V. (Amsterdam, Netherlands). For the payment itself, Mollie is an independent controller, not our processor. As a payment institution, the company is subject to its own regulatory obligations, including anti-money-laundering controls, retention and fraud prevention, and does not act on our instructions in those matters. There is correctly no data processing agreement under Art. 28 GDPR for this activity; Mollie’s privacy policy applies. We give Mollie the amount, a general description and your account identifier, but not your name or email address. We receive the amount, time, payment method and outcome. We never see your card or bank details; only Mollie holds them.

Servers and providers that you choose yourself are not included in this table: your Matrix homeserver, calendar server, Nextcloud, your own database and a search provider you bring. They are not our sub-processors because we do not engage them. You enter the contract, select the provider and instruct us to transmit data there. For your record of processing activities, they are recipients, not part of our processor chain.

As a matter of policy, we send no content, identifying information or session data by email, including to you and in support requests. Email is used only for metadata, billing, sign-in processes and general correspondence.

For your data protection officers

You do not need your own IT legal department to assess us. These documents are public — you need not request them and need not wait for a reply. They are written in German, the language of the contracts they belong to:

• Overview of technical and organisational measures (Art. 32 GDPR) — what is built, and in a section of its own, what is not
• List of sub-processors — including the recipients that are explicitly not sub-processors, and why
• Record of processing activities (Art. 30 (1)) and the record of processing on behalf of controllers (Art. 30 (2))
• Art. 35 threshold assessment — one line per processing activity, including where the answer is “no impact assessment required”
• Personal data breach procedure (Art. 33/34)

The DPA template itself is not ready yet. Both annexes above are finished and can be attached unchanged; the contract text is with our lawyers. We write this here rather than promise the document and deliver later — anyone who needs a contract should know where they stand before they ask.

Questions these documents do not answer: markus@souveraene-systeme.de

Change log

We record changes to data processing or service providers here so that it remains visible that nothing is moved silently.

Your rights

You have the right of access (Art. 15 GDPR), rectification (Art. 16), erasure (Art. 17), restriction of processing (Art. 18), data portability (Art. 20) and objection (Art. 21), as well as the right to lodge a complaint with a supervisory authority (Art. 77 GDPR).

Controller: Markus Schlueter, Wiesenstrasse 19, 16552 Schildow · markus@souveraene-systeme.de