Privacy notice

This notice explains what personal data Cedreon processes, why, where each part of it is processed, and what you can ask us to do about it. It covers the public website, the signed-in workspace and any contact you have with us. We have written it in plain language rather than legal boilerplate, because the people who read it carefully are the people we build for. Where a fact is narrower than the claim the industry usually makes, we state the narrower one.

Who is responsible

The controller for the processing described here is SFF S26 AG, Schuetzengasse 7, 9000 St. Gallen, Switzerland. You can reach us at [email protected]. Cedreon is the product; SFF S26 AG is the company that operates it.

We have not appointed a data protection officer, because we are not required to under Article 37 GDPR. If that changes we will name them here. Data protection questions go to [email protected] and reach a person, not a queue.

Controller or processor: which one we are depends on the data

Both roles apply to us at the same time, over different data, and conflating them is the usual way a notice like this goes wrong.

For the content you put into the product, meaning your messages, your uploaded documents and the replies you receive, we act on your instructions. Where you use Cedreon through an account your employer or your firm provided, THEY are the controller for that content and we are their processor. The terms of that arrangement are the Data Processing Agreement, which is incorporated into our Terms of Service, and Annex 2 to it is the sub-processor list.

For the data we need in order to run a business, meaning your login address, your billing contact, our security logs and the integrity record described below, we are the controller and this notice is the operative document.

If you hold a personal account with no organisation behind it, we are the controller for everything, including your content, and this notice covers all of it.

If your account belongs to an organisation

An organisation account has an administrator, and some of what they can see is worth stating rather than leaving to be discovered.

Your administrator can see the members of the organisation and their email addresses, can see aggregate usage figures for the organisation and per member, can configure the guardrails every member chats under, and can execute agreements that technically restrict which AI providers the whole organisation may reach. They can invite and remove members.

Your administrator cannot read your conversations or your documents. There is no cross-account transcript access anywhere in the product, for administrators or for us. A document is shared with the organisation only when somebody uploads it to the shared library on purpose.

Ask your organisation first about content you put into their account. If you ask us, we will pass the request to them, because it is their instruction to give.

What we collect

We keep the set small on purpose. In practice it is:

• Account and authentication data: your email address, an optional display name, a hashed password, whether your address has been confirmed, and your session cookie. We never store your password itself. If you sign in with Google we store the account identifier Google issues for you: an opaque subject identifier that is not your email address, kept so that we recognise the same Google account next time.
• Organisation membership, if you have one: which organisation your account belongs to, your role in it, and whether a paid seat is assigned to you.
• Customer Content: your chat messages, the documents and files you upload, and the replies you receive. The next four sections are about this, because how it is handled is the substance of the product.
• The placeholder mapping: when the screening layer replaces a value with a placeholder, the link between the two is stored encrypted so your own view can be restored. This mapping is the most sensitive thing we hold and it is treated as such.
• Integrity and operational metadata: an append-only record of each exchange. What it does and does not contain is set out below, and it is more than hashes and timestamps.
• Billing data, if you subscribe: a customer reference and the subscription record. Card details are entered into our payment processor's own hosted forms and never reach our servers.
• Support correspondence: anything you send us by email or through a contact form, and our reply.
• Security and operational logs: request metadata, error records and rate-limiting counters, kept to keep the service standing up and to investigate abuse.
• Website data: a first-party session cookie, and, if you arrive from an advertisement, the campaign name so we know which one reached you.

What AI providers actually receive

This is the part most notices leave vague. Before a request leaves your workspace, Cedreon screens it and replaces detected sensitive values with placeholders such as a bracketed label or a reversible token. The AI provider receives the placeholder, not the value. The original stays encrypted in your workspace and is restored in the reply only for you.

Detection is layered and best effort, not a guarantee. It combines checksum-validated patterns for identifiers such as an IBAN, a card number or a tax number with a recognition model that runs locally on our own infrastructure. Unusual formats, misspellings and values the layer was not built for can be missed. We say so plainly, because a promise of perfect detection would be false, and because screening is a reduction of exposure rather than a process that makes content stop being personal data.

Two things we do not do. We do not send the placeholder mapping anywhere: it never leaves our infrastructure, and no provider receives it. And we never mask a search query on the open web, which is a deliberate exception explained on the switch that turns web search on, because masking a query does not degrade a search, it changes the answer.

The gateway, and what the providers are actually bound to

Every model request is made through one gateway, Eden AI, a French company, on its European endpoint. That endpoint routes only to providers cleared for processing in Europe and refuses a request no such provider can serve, rather than sending it elsewhere. We hold a data processing agreement with Eden AI. Because both parties are established in Europe, no transfer mechanism is required for this leg.

Two promises are usually collapsed into one here, and they are not the same promise, so we separate them.

Use. No provider trains on what you send or uses it for its own purposes. That obligation is contractual: it sits in our agreement with the gateway and in the gateway's own agreements with the companies that serve each model. It was previously enforced as a routing flag on every request, and it is worth saying plainly that the mechanism changed even though the promise did not, because a contract and a per-request constraint are not the same kind of assurance.

Retention. That obligation does not by itself mean nothing is kept. A provider can honour it and still hold a request in its own operational logs for a period. The gateway states that it retains no prompt or completion content, but that is a statement about the gateway and not about the company whose servers actually answer, each of which runs its own retention and abuse-monitoring regime. We therefore make no general statement about what is retained on the provider side, and you should treat any product that makes one as having collapsed these two promises into a single sentence.

Where processing happens

Two different questions, and the honest answer differs between them. Cedreon is developed in Switzerland; that is a statement about the company, not about a server.

The application and your stored data are processed in the European Union under the GDPR, specifically in Frankfurt, Germany, on infrastructure contracted through a European entity. Daily snapshots are held in the same region. Inbound requests transit a content delivery network where TLS is terminated, so request content is processed in the clear at that edge, transiently and in memory, before being re-encrypted to our servers. That is true of every service behind a reverse proxy and is usually left unsaid.

Model inference used to be a separate question with a separate answer, and it is not any more. Every request leaves through the European endpoint described above and is pinned to one named European processor with fallback disabled, so it is served in Europe or it fails. Annex 2 names which company serves which model. What that does NOT settle is who BUILT the model, which is a different question: most of them were built outside Europe, and an organisation that needs both can be placed under a compliance profile restricting it to European-built models.

Optional features add their own locations, and they are the reason this section is not one sentence. Web search, when a conversation has it switched on, sends the query to a provider that operates infrastructure on several continents and whose serving region we do not pin. A connected Google Drive is searched on Google's infrastructure. Both are off by default, and the compliance profile withholds them.

International transfers

Transfers from Switzerland to the EEA rest on the Federal Council's adequacy recognition. The gateway and every company that serves a model are established in Europe and process there, so the model path no longer leaves the EEA and needs no further mechanism. That is a change from earlier versions of this notice, and it is the reason for this version.

What remains outside Europe is the optional half: web search, whose provider does not pin its serving region, and a connected Google Drive. Those rest on the Standard Contractual Clauses with the Swiss addendum recognised by the FDPIC. Both are off unless you switch them on, and a compliance profile withholds them entirely.

The supplementary measure differs between the two, and we state the difference rather than average it. A query sent to your connected Google account is destructively masked before it leaves, so the recipient receives no identifying value the screening layer recognised. A web-search query is sent as you typed it, with no placeholders, because masking a search changes its answer; the safeguard there is that the feature is off until you deliberately switch it on, and the switch says so. We are deliberately careful about how far the masking argument reaches, because the screening is best effort and the mapping stays with us. It reduces what a recipient holds; it does not turn the transfer into something other than a transfer of personal data.

Annex 2 to our Data Processing Agreement names every recipient, what it receives, where it processes and under which mechanism. It is published at /subprocessors and is part of the agreement.

The audit record, and what erasure means

Every exchange is written to an append-only, hash-chained record. That record is what lets a regulated firm show what happened, and it is deliberately not editable: the database refuses updates and deletions to it, and each entry commits to the one before it.

It is not a record of hashes and timestamps alone, and we will not describe it that way. The audit chain holds no plaintext of your prompts or of the model's responses. It retains integrity and operational metadata, which may include identifiers, timestamps, model information, content digests, payload references, screening outcomes, policy results and usage data.

So erasure works in three parts, and we would rather explain it than overpromise. Deleting your data removes the stored copy of your messages and documents. It destroys the encrypted placeholder mapping, which makes the original values unrecoverable, because a digest commits to something without reproducing it and a reference to a deleted row points at nothing. And the chain keeps the entries that prove the sequence was not tampered with.

If your workspace runs in store-nothing mode, no copy of your messages or documents is written at all and no placeholder mapping is retained between turns.

Why we process it, and on what basis

Each purpose has its own legal basis, so here they are one by one:

• To provide the service you asked for, including your account, your conversations and your documents: performance of our contract with you, Article 6(1)(b) GDPR. Where your organisation is the controller of that content, we process it on their documented instructions under Article 28 GDPR.
• To keep the service secure, to prevent abuse and to operate it reliably: our legitimate interest in a service that can be defended and kept running, Article 6(1)(f) GDPR.
• To hold the append-only integrity record: our legitimate interest, and for many of our users their own professional or regulatory requirement to be able to account for what was sent and what was screened. Where your organisation is the controller, holding it is part of the service they instructed.
• To take payment and to keep accounting records: our legal obligation, Article 6(1)(c) GDPR, together with performance of the contract.
• To answer you when you write to us: performance of the contract where you are a customer, otherwise our legitimate interest in replying, Article 6(1)(f) GDPR.
• To send you email about the product: your consent, Article 6(1)(a) GDPR. You can withdraw it at any time, and withdrawing it does not affect what we did before you did.

Who else processes data

The full list, naming each contracting entity, what it receives, where it processes and under which transfer mechanism, is published at /subprocessors and is Annex 2 to our Data Processing Agreement. In outline it is:

• The model gateway, through which every model request is made, and the model providers it forwards to.
• Our hosting provider in Frankfurt, where the application and database run, and our network provider, which terminates TLS at the edge.
• Our payment processor, for subscriptions.
• Our transactional email provider, for address confirmation, seat invitations and replies.
• A web search provider, only in a conversation where you have switched web search on.
• Google, only for an account that has connected its own Drive or Gmail, and only to read what that account already keeps there.

The website, and what we measure there

The public marketing pages carry website analytics, and the signed-in workspace does not.

The analytics are self-hosted: the software runs in a container on our own infrastructure, in the same Frankfurt region, and no third party receives the data. It counts page views and referrers. There is no advertising pixel, no tag manager, no conversion API and no third-party analytics service anywhere on this site.

The signed-in workspace makes no third-party requests at all. Fonts, icons and charts are served from our own servers, which is why the console loads nothing from a content delivery network.

The cookies we set are our own and functional: a session cookie so you stay signed in, and, if you arrive from an advertisement, the campaign name so we can tell which advertisement reached you. The campaign cookie carries no identifier and expires after 30 days.

How long we keep it

By category, because one horizon for everything would be a fiction:

• Account data: for as long as you have an account. Closing it deletes your conversations and documents immediately and irreversibly, and crypto-shreds the placeholder mapping in the same act. There is no recovery window, so export anything you need first.
• Conversations and documents: until you delete them. Deleting is immediate and destroys the placeholder mapping with them. Nothing is written at all in store-nothing mode.
• The append-only integrity record: retained for the life of the account and for a defined period afterwards, which we currently set at 10 years, because its purpose is to be a durable account of what was sent and what was screened, and because the users we build for are subject to professional record-keeping duties on that kind of horizon. We do not claim that Swiss accounting law by itself requires an AI audit log to be kept for 10 years; the accounting-law horizon is the basis for the billing records below, and the retention of the integrity record rests on the purpose just described. It holds no plaintext prompt or model response.
• Billing and accounting records: 10 years, as Article 958f of the Swiss Code of Obligations requires.
• Security and operational logs: kept for as long as they are useful for the purpose that justifies them, ordinarily weeks rather than years.
• Support correspondence: for as long as needed to deal with the matter and to show how it was dealt with.
• Website analytics: aggregate counts only, retained on our own infrastructure.

Your rights

Under the GDPR and the Swiss FADP you have all of the following. Write to [email protected] and we will answer within 30 days, free of charge. Where your organisation is the controller for the content in question, we will pass the request to them, because it is their instruction to give.

• Access: a copy of your data and the information in this notice, Article 15 GDPR.
• Rectification: correction of anything inaccurate or incomplete, Article 16 GDPR.
• Erasure: deletion, Article 17 GDPR. Read the section above on what erasure means here, because we would rather explain the chain than overpromise.
• Restriction: processing paused while something is disputed, Article 18 GDPR.
• Portability: the data you gave us, in a structured, machine-readable format, and sent directly to another controller where that is technically feasible, Article 20 GDPR.
• Objection: to any processing based on legitimate interest, on grounds relating to your situation, and to direct marketing at any time and without giving a reason, Article 21 GDPR.
• Withdrawal of consent at any time, without affecting what was lawful before you withdrew it.
• Complaint to a supervisory authority: the Swiss Federal Data Protection and Information Commissioner, or the authority where you live, work or believe the problem happened.

Automated decisions

We make no decisions about you by automated means that produce legal effects or similarly significantly affect you, within the meaning of Article 22 GDPR. We do not profile you.

Cedreon generates text using AI models, which is automated processing, and the screening layer decides automatically whether a value is masked before a request is forwarded. Neither decides anything about you: the first produces a draft for a person to judge, and the second only ever restricts what leaves. No account is granted, refused, priced or restricted by a model.

Do you have to give us this data

You are not obliged to give us anything. But an email address and a password are what an account technically consists of, so without them we cannot create one, and without payment details we cannot take a subscription. There is no other consequence: nothing here is collected because we would like to have it.

Changes

This notice is versioned. Each version has an effective date and a content hash, and when you accepted our Terms we recorded which version of this notice you were shown along with that hash, so what you were told at the time can be established rather than argued about.

If we change this notice materially we publish it as a new version, say so on this page and, where the change affects you directly, tell you by email.