The complete answer

Everything we retain about your household is held in Switzerland by one Swiss company, under Swiss law, in a data centre in Rümlang — and no single party ever holds the whole picture. The service that hears a voice is given no structure: a recording and a list of proper nouns, and never a record, a schedule or a history. The service that reads text never hears a voice. The relays that carry notifications cannot open them, and the one channel that is not sealed — a text message — never names the request. We ourselves do not read the content — by rule rather than by construction, and the difference is set out below. And your household exists, to every other household on the service, not at all.

These are the four a family office asks last, when the brochure is finished and somebody has to put a name to a decision. They are answered here in the order they are usually asked, and each one is traced to a source rather than summarised from a supplier’s marketing page.

1 · Who processes the voice, and who processes the text? Two different companies, and neither is given what the other has. Speech becomes text at OpenAI, which receives the recording and a list of proper nouns — and no request, schedule or history. Text is split and translated by Anthropic, which receives the transcript and the household’s directory, and never hears a voice. Where a household chose e-mail over handing a link over in person, Resend carries that one message. Everything that is stored — the requests, the people, the schedule, the photographs — is held by Nine and reaches neither of the two above. Notifications travel through Apple’s and Google’s relays sealed against the relay itself.

2 · In which country does that processing happen? Storage is in Switzerland. The speech and language processing is in the United States, and the distinction we draw elsewhere applies here too: for a Swiss customer the counterparty is OpenAI Ireland Ltd. and Anthropic Ireland Ltd. by the express terms of their own addenda, which places the contract in Europe and not the processing. One consequence is worth stating because it is the one people assume away: Anthropic’s direct API offers the inference regions us and global only — there is no dedicated European option to switch to. European residency for that step would mean routing the same model through AWS Bedrock or Google Vertex in an EU region, which is a different supplier relationship rather than a setting. Both endpoints are a single configuration value in our code; the obstacle is the market, not the software.

3 · How long is anything held there, technically? At OpenAI: up to thirty days for abuse monitoring, then deleted, and not used for training. At Anthropic: API inputs and outputs deleted within thirty days of receipt, with training contractually excluded. Both figures were read from the suppliers’ own documentation on 3 August 2026 and are held with their source URL and checksum — the Anthropic figure was corrected from seven days to thirty in that pass, because the shorter number came from third-party write-ups rather than the source. At Nine: for as long as the household’s own retention window says, with backups taken daily and kept thirty days. At Resend the window is the one exception to the pattern: their agreement sets no shorter period while the account runs, and deletion within ninety days of its termination — read from their data-processing agreement on 15 August 2026. It is also the supplier that carries the least: an access link or a code and an address, never the content of a request.

4 · Who could read plaintext, in an exception? Three answers, and only the first is comfortable. Our tooling cannot— the operator console and command line have no path to a request, a message or a photograph. One person can, by one route: the export that answers “give us everything you hold” opens with the founder’s own passkey and writes a line into that household’s security log, so it cannot be used unseen. And Nine’s administrators hold the database and the disks, which means they are technically able to read what sits in it; what stands between is a Swiss contract, Swiss law and their own controls, not our software. We would rather write that sentence than let an adviser find it. The thing that turns it from a matter of trust into a matter of arithmetic is per-household encryption, which is built, tested, and switched on for any household that asks — the reasoning for the default is further down.

The recording is held in the phone’s memory, sent once to be turned into text, and discarded. No table and no file store holds audio. There is no archive of anybody’s voice, here or anywhere we control.

Beyond that the headline is uncomfortable and belongs near the top: no microphone in this product keeps its sound on the phone. Every one of them sends words to somebody. What differs is who.

The long recordings— the one spoken on a principal’s own home screen, and the one spoken in the desk’s capture room; both, not one — are uploaded to us and relayed to OpenAI in the United States. Up to five minutes or about 3.4 MB. That endpoint is a configuration setting: moving it to a European or Swiss provider requires no change to the software, which is honest about portability and also means nothing in the code guarantees who is on the other end.

Every other microphone— beside a message field, in a reply from the desk, in a principal’s own answer, in a staff member’s answer on their link — is heard by the phone’s own recogniser. That audio never reaches our servers. Where it goes then belongs to the browser vendor and is not visible from our code: on iPhone and Android the platform recogniser normally sends it to Apple or Google. We have not verified that by measurement and will not say we have. What we can promise is the part we control — it does not come to us.

When a long recording quietly becomes a device recording. There are four causes: no transcription key is configured; the provider refused over its own account within the last five minutes; it refuses mid-visit; or the browser cannot record at all. The first three are temporary, and words are never lost to a setting or an unpaid bill — only heard less well.

The fourth is not temporary, and we found it while preparing this page. On a browser with no working recorder every voice note takes the device path for good, on a fully paid installation, and the screen says nothing: the recording display is identical either way and the only visible difference — words appearing as they are spoken — reads as the product working better rather than differently. It is a defect, it is named here before it is finished being fixed, and the privacy notice describes it in the same words.

The household does, and this is the part nobody thinks to ask about. With every recording — including one that mentions nobody — a text hint is sent so that names come back spelled correctly. It is assembled in this order: the proper nouns the desk wrote down, then the name of every person in the directory, then the household’s own name. It is capped at 800 characters and cut at the first entry that will not fit.

Three consequences, stated rather than left to be worked out:

• The household’s own name is the first thing dropped, because it is added last. A directory of about forty people sends forty names and not the family name.
• The directory is not filtered to staff. Anyone recorded in it goes, including people marked as outside the household.
• Nobody is told what actually went, because the cut happens on the server at the moment of sending.

None of it is audio and none of it is the request. It is a list of names, and it goes with every note.

It becomes the request, and it stays. To split one spoken sentence into separate requests, the transcript is sent to Anthropic in the United States together with the directory: each person’s name, role, domain and language, the places they serve, those places with their locations and time zones, and the speaker’s local time.

Translating a request or a message afterwards is a separate call carrying only the text and the two languages — never the directory. Both endpoints are configuration settings, like transcription.

Requests, replies, people, schedules, photographs and portraits all sit with Nine Internet Solutions AG, Badenerstrasse 47, 8004 Zurich, in their data centre in Rümlang. The application runs there too. One supplier, one contract, Swiss law and a Swiss forum.

The common arrangement is a European region rented from an American company, and it is worth saying why that is a different thing: storage in Europe is not a European supply chain. Where the disk stands and who can be compelled to reach it are two questions, and only the second one is answered by the name on the contract.

Two public pages — this one and the front page on www.sottov.com — are served by Vercel until 22 August 2026. They carry no household data, no sign-in and no measurement of any kind. Everything a household says reaches Switzerland only.

Backups: taken daily, kept thirty days. The worst case that follows from that is worth stating rather than leaving to be worked out — if the database had to be restored, up to a day of requests and replies could be lost. There is no minute-by-minute rewind.

Four outside companies touch anything a household entrusts to SottoV, and there is no other outbound path in the software: Nine holds the database, the photographs and the running application; OpenAI receives the long recordings with the name list described above; Anthropic receives a transcript with the directory, or a text with two languages; Resend receives an access link or a code and an address, only where a household chose e-mail over handing it over in person. Vercel serves the two public pages described above until 22 August 2026, and receives nothing else.

Every supplier’s data-processing agreement was retrieved on 3 August 2026 and is held with its source URL, retrieval time and SHA-256 checksum, so that what we quote can be checked against what we read. For the two AI suppliers a Swiss customer contracts with an Irish company by the express terms of their own addenda. That does not put the processing in Europe and we do not suggest it does — it puts the counterparty there.

Notifications travel through Apple’s and Google’s relays. The content is sealed against the receiving device’s own key before it is handed over, so the relay carries ciphertext. What it does see is that a message reached a particular device at a particular moment.

One path that is not ours, and belongs here anyway. Chrome on Android inspects incoming notifications on the device and may replace one with a “possibly spam” card. If the recipient taps to report it, Google states that the notification’s content and our address are sent to Google. This is their browser acting on their own tap, after our encryption has done its work. We neither cause it nor see it and no setting of ours prevents it — but a request in plain words can reach Google that way, so we name it rather than shelter behind the fact that it is not our code. A household that chooses content-free notifications closes this door too: a message that names no request has nothing to hand on.

Our day-to-day tooling cannot. The operator command line can create a household, suspend it, count rows and erase it. It has no path to a request, a message or a photograph. That is a property of the code, not a promise about our conduct.

One deliberate exception, and it leaves a mark. When a household asks for everything we hold, somebody has to be able to read it in order to hand it over. That path is reachable only through the founder’s own passkey, and using it writes a line into the household’s own security log. We can look, and we cannot look without the household being able to see that we did.

A rule we keep, not a wall we have built. No operator screen selects a content column — but the words sit readable in the database, so anyone holding that database could read them. Encryption under a household’s own key is what turns this rule into a wall, and it is available on request; the reasoning for the default is below. The difference between a rule and a wall is exactly the difference between trusting us and not having to.

Envelope AES-256-GCM: a key of its own for every household, wrapped under a master key that we hold, with every value bound to its own row so that none can be lifted into another. That last point decides how much the rest is worth, so it is said before the rest: this is a key dedicated to a household, not a key a household holds against us. Customer-managed keys are a different arrangement and we do not offer them today. Destroying a household’s key ends its content everywhere at once — in the live database, in last night’s snapshot, and in any copy anybody ever took. That is a stronger erasure than deleting rows can be. It is built and tested.

It is off by default, because losing that key means the content is gone finally: no restore, no support, no recovery. That is a category of accident this product does not otherwise carry, and not one to hand a household without their asking. Sealing every content column is also a permanent obligation on every future line of code rather than a task that ends, and a product still gaining features carries that badly.

Founding households may switch it on from day one, and asking costs nothing. The default is reviewed at ten households or in six months, whichever comes first — and immediately if a customer asks.

A household chooses ninety days, a year, or to keep everything. The choice is dated and written into its own log, so “kept indefinitely” is an answer somebody gave rather than the absence of one.

When a window passes the words are overwritten rather than the rows deleted: that a request existed, at that hour, and was settled survives — a record about nobody. The proof photograph is deleted outright. It takes effect on the next nightly pass, not the instant the period elapses.

Ending someone’s access takes one action and takes effect immediately, on every device they hold. A departing employee is locked out in seconds, not at the next password change.

Erasing a household exports everything first if the household wants it, then removes it. The erasure rehearses, lists exactly what would go, demands the household’s name typed back, and names anything it could not remove rather than claiming success.

One consequence stated honestly, twice, because it applies to both: for up to thirty days erased or overwritten rows remain inside the backup history until it rolls past. No command can reach into a backup. The one thing that would is destroying a household’s own key — which is the encryption above.

There is no password. No password column exists anywhere in the database. A principal and a chief of staff sign in with a passkey — a private key that never leaves their own device — and a second factor is mandatory for the desk.

A passkey held in an Apple or Google account exists on every device signed into that account, and the signature is perfect on all of them, so hardware the household has never seen does not open it. That device is held until a second channel answers, and the permission then lives as a row we can withdraw rather than a cookie we hope expires.

Staff need no account at all — no download, no password, no e-mail address. They receive a link and a six-digit code, which may be handed over in person, and the link is bound to the browser that answered.

The deliberate trade, named rather than left to be found: a recovery path by e-mail exists, so control of a principal’s mailbox is a route in. It is what stands between a locked-out principal at midnight and losing their household altogether. Where a household would rather not have that door at all, it is a configuration conversation and not a rewrite.

Sign-ins, grants of access and changes to a request go into the household’s own log, as does any export we perform.

This is deliberately narrower than “everything is logged”, which would not be true: opening a stored photograph, or editing a place, a season, or the household’s vocabulary, leaves no entry. We corrected exactly this overstatement on our own website once and will not reintroduce it.

A picture taken in SottoV’s own camera is drawn onto a canvas, so EXIF and GPS never exist in the first place — not stripped afterwards, never created.

Uploading from a phone’s photo library is switched off unless a household turns it on, and such a picture is re-encoded on our servers so the same containers are discarded. What a file claims to be does not decide: the format is read from the bytes. An animated GIF is left as it is, because re-encoding one would flatten it to a single frame.

The phrase usually means one of three things, and they cost different amounts.

“Nothing is stored outside the EU.” True, and has been.

“Nothing is stored outside Switzerland.” Done on 15 August 2026: application, database and photographs all sit with one Swiss company in Rümlang. It took two days rather than the week that was estimated, and the honest reason is not diligence: SottoV was built on standard Postgres, S3-compatible storage and a plain Node server rather than on any one provider’s conveniences, so there was little to unpick. What it did not move is the speech and language processing, or the notification relays, which belong to the phone’s maker.

“No American company is involved at any point.” Then the speech and language providers must be European too. Both endpoints move with a single configuration value. The honest obstacle is quality: the accuracy with which a household’s names, houses and wines come back written correctly is the product, and we will not trade it away quietly. That is a decision to take together, with both options in front of you, rather than a box we would tick.

“Anonymous.” SottoV holds remarkably little, but almost none of it is anonymous. A first name, a house, a schedule and a dinner reservation identify a person to anyone with local knowledge. The correct description is minimal and pseudonymous.

“Your voice never leaves the device.” It does — that is how it becomes text. What is true is that no recording is ever kept.

“Blind by construction.” Not by default. No operator screen shows the text of a request, and the one exception costs a fresh passkey and writes a line into the household’s log. That is a rule we keep. It becomes a wall the day a household switches on its own key, and not before.