Nemosyne
Menu

Privacy

What we hold, and what we do with it.

This policy names the data we actually hold, field by field, the companies that see any part of it, and how to have it deleted. It is written to be checked rather than skimmed: where our behaviour has a limit, the limit is here rather than in a sentence that implies otherwise. The security posture behind it is described separately, with its own list of things we do not do yet, on our trust page.

Effective 7 September 2026 · Version 1

Who we are

Nemosyne is a service operated by Nemosyne AI B.V., registered at Amsterdam, Noord-Holland, the Netherlands. Where this policy says we, it means that company. For anything in this policy, including a request to see or delete your data, write to [email protected].

Nemosyne is organisational memory for professional firms. It reads the documents a firm connects to it, turns them into cited facts, and answers questions from them — through a web console and through AI assistants that connect over the Model Context Protocol.

Whose data, and our role in it

Two different things pass through this service, and we hold a different responsibility for each. Account data — who signed up, which organisation they belong to, what they were billed — is ours: we decide what to collect and why, so under the GDPR we are the controller of it.

Everything your organisation connects — your documents, the passages we cut from them, the facts we extract, and the names and email addresses that appear inside them — belongs to your organisation. Your organisation decides what to connect and why; we hold and process it on their instructions. Under the GDPR we are a processor of it and your organisation is the controller. If you are an employee of a customer firm and want your own data corrected or removed, your firm is the first door: we act on their instruction, and we will help either way.

Nemosyne can also be run by a customer on their own servers. In that case we hold nothing at all — no copy, no telemetry, no update check, because none of those were built. This policy describes the service we host. A self-hosted deployment is governed by the policy of whoever runs it.

Google Workspace data

When someone at your organisation connects Google Drive, we ask Google for one scope: see and download your Google Drive files (drive.readonly). We ask for read access only, and we ask once — the same grant covers every folder and shared drive that account can already reach. We cannot create, edit, delete or share anything in your Drive, because the permission to do so was never requested. Connecting Gmail is a separate decision, on its own consent screen, for its own read-only scope (gmail.readonly) — a Drive connection never carries it.

What we read

Rather than describe this in general terms, here is the actual list. For each file within the folders you choose to connect, we request:

  • The file itself — its bytes, which we parse into text and, where a document is laid out in tables, read with a layout-reading tool on our own servers or page by page through the Claude API.
  • File details — its identifier, name, type, size, last-modified time, and which folders or shared drive it sits in.
  • The file’s sharing list — for every permission on the file, the kind of grantee, the role, and the email address or domain it names, plus whether a link grant is publicly discoverable. This is personal data, and we do not treat it as incidental: it is the reason we can promise that an answer never assembles evidence the person asking is not allowed to see.
  • Who touched the file — the display names and email addresses of its owners and of the person who last modified it, where your connector is configured to record that.
  • What changed since last time — Google’s change feed, so we notice a file that was edited, trashed, or moved out of the connected folders.

We never read your calendar, your contacts, or any Drive file outside the folders your organisation connected. We read your mail only if your organisation connects Gmail, which is the next heading.

If you connect Gmail

A mailbox is its own connector, with its own consent, for one scope: read your Gmail messages and settings (gmail.readonly), which Google classes as restricted. From it we read the same shape of thing we read from a file — who wrote to whom, when, the subject, the message text and the attachments — and we assemble a conversation into a single document. Two limits are worth stating plainly. A captured thread is readable inside Nemosyne only by the account whose mailbox it came from, not by your whole organisation, which is a narrower audience than any file connector produces. And messages your connector excludes by label are never read at all — spam and trash always, plus any label your organisation adds. We cannot send, delete or alter mail, because the permission to do so was never requested.

What we do with it

A connected file is captured onto an append-only record, cut into passages, and read by a language model to extract facts about the companies, people and decisions your firm works with. Each fact carries a citation back to the passage it came from, and each passage carries the sharing list of the file it came from — so a question is answered only from material the person asking could already open. Passages are also turned into numeric embeddings so that search can find them by meaning; an embedding is derived from your text and we treat it as your text.

To do that work, document text is sent to Anthropic’s Claude API for parsing, extraction and answering, and so are a document’s pages when it is read page by page. The passage text that becomes an embedding is sent to OpenRouter, routing to OpenAI (text-embedding-3-small, 768 dimensions) instead, a separate processor for that one step. Each of these acts as our service provider for its own processing, does not receive it for its own purposes, and by default does not use it to improve its own models. We do not train any model on your content, and we have never built the ability to.

When you take it away

Three separate doors, and they do different things. Revoking Nemosyne’s access in your Google account stops us reading anything further, immediately; it does not delete what we already read. Disconnecting the connector in Nemosyne does the same from our side. Deleting the organisation is what erases the material — see section 7, which also names what survives it.

While a connector is running, a change at the source follows through on its own. When Google tells us a file was trashed or removed from the connected folders, or that someone’s access to it was withdrawn, the next poll — every five minutes by default — retires that capture and, in the same request, retracts the facts, summaries and passages derived under the old audience. A citation a now-excluded reader was holding stops opening.

Limited Use

Nemosyne’s use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

Concretely, because that affirmation is worth nothing without it: we use the data we receive from Google APIs only to provide the features described on this site, to the organisation that connected it; we transfer it only to the service providers named in section 5, and only to run those features; we do not sell it; we do not use it for advertising; and we do not allow any human — ours or anyone else’s — to read it except with your organisation’s explicit permission, to resolve a fault you have reported to us, or where the law requires it.

Everything else we hold

Google Drive is one of several sources. The rest of what we hold is short enough to list in full.

  • Other connected sources. Whatever else your organisation chooses to connect: Microsoft SharePoint and OneDrive, Box, Slack, Gmail, Confluence, Jira, Notion, Salesforce, HubSpot, Affinity, DocuSign, and folders you upload directly. Each is read the same way, under the credentials your organisation supplies, and each is subject to everything this policy says about Drive.
  • Your account. Your email address, your name if you give one, the organisation you belong to, your role in it, and — if your firm uses single sign-on — the identifier your identity provider gives us. If your firm syncs its directory, we also hold the group memberships that decide who can reach what.
  • Sign-in and session records. The tokens that keep you signed in and that let an AI assistant hold a connection, each with an expiry, and each deleted when it expires.
  • Credentials you give us. The access tokens for the sources you connect, and any model key you supply, held encrypted and never shown back to anyone, including us.
  • Usage records. Which person, in which organisation, called which tool, and when — this is how work is metered and billed. It records that a call happened, not what was in it.
  • An administrative trail. Who created an organisation, who granted or revoked access, who changed a setting. We keep this deliberately, including after an organisation is deleted.
  • Billing details. Handled by Stripe. Your card never reaches our servers; we hold the customer and subscription identifiers Stripe gives us, and what was charged.
  • Server logs. Ordinary operational records of requests and errors, used to keep the service up and to investigate faults.
  • What you send us. If you email us or fill in a form on this site, we hold the message. The pilot form on this site posts nothing to us — it composes an email in your own mail app, which you send yourself, so nothing reaches us until you press send.

Our lawful bases, in the GDPR’s terms: we process account, session and billing data to perform our contract with your firm; we process usage records, the administrative trail and server logs on our legitimate interest in metering, billing, securing and debugging the service; and we process the contents of your connected sources on your organisation’s instructions, on whichever basis they rely on as controller.

Who else sees it

This is the complete list of companies that process any part of your data for the service we host. There are no others, and we sell or rent data to no one. The same list, with each company’s location and the notice you get before it changes, is on our sub-processors page.

Hetzner
Hosting. The servers your documents, passages, facts and database actually sit on. Germany.
Cloudflare
The published route to the service. Terminates the encrypted connection and sees request metadata in transit.
Anthropic — Claude API
Reading documents, extracting facts, writing answers. Receives document text and the questions asked of it.
Stripe
Payments. Receives your billing details directly; we never hold your card.
OpenRouter, routing to OpenAI (text-embedding-3-small, 768 dimensions)
Turning document text into the numeric form recall searches by. Receives passage text, never a question you ask; does not train on it by default.
Resend
Transactional mail — email verification, invites, password resets, and payment-failure or plan-lapse notices. Receives the recipient address and the letter's contents.

We will also disclose data where the law compels us to. If we are ever ordered to hand over a customer’s material, we will tell that customer unless we are forbidden from doing so. And if the business is ever sold or merged, the data moves with it, under this policy until you are told otherwise.

Where it is stored

Your organisation’s material is held in Germany. Each organisation gets its own database schema and its own object-store prefix — no shared table holds a customer’s documents, facts or passages. The only tables every customer shares are the account, billing and session records, and none of them holds anything the system learned from your documents.

Model processing is the exception to storage in Germany. Sending text to the Claude API is a transfer to Anthropic, which processes it in the United States, outside the European Economic Area. That transfer relies on Anthropic’s standard contractual clauses. If your firm needs model processing to run under your own model keys and your own data-processing agreement, write to us.

How long we keep it

Your organisation’s material is kept for as long as your organisation exists with us. We do not age it out on our own — a memory that forgot things on a timer would not be a memory — so deletion is something you ask for, and it is thorough.

Deleting an organisation drops its database schema and its object-store prefix. The record, the passages, the facts, the summaries and the search index go with them. Its stored credentials are deleted and its sessions are cleared.

Four things survive, and we would rather name them than let you find them: the row saying that organisation existed, with its name retired and never reusable; the usage records that point at it; the entitlement rows naming who could reach it, left inert; and the administrative trail of what was done to it. None of them holds anything read from your documents.

Backups are the honest exception. A deleted organisation’s data stays inside whatever backups were already taken until they age out on their own schedule, and nothing we run reaches into them. Assume this of any vendor who does not say it.

Sessions and sign-in tokens expire on their own and are deleted when they do. Enquiries you email us are kept while we are talking, and afterwards for as long as we need them for our records.

What we do not do

  • We do not train models on your content, and our model provider does not use it to improve theirs.
  • We do not sell or rent your data, and we run no advertising of any kind.
  • This website carries no analytics, no trackers and no advertising cookies. Nothing on the page you are reading reports your visit to anyone.
  • The software phones no home. There is no telemetry and no update check to switch off, because neither was ever built.
  • We do not read your documents casually. No one at this company opens a customer’s material except with that customer’s explicit permission, to resolve a fault they reported, or where the law requires it.
  • We do not use one customer’s material to answer another customer’s question. That separation is structural, not a rule someone has to remember.

Your rights

If you are in the European Economic Area or the United Kingdom, you have the right to ask what we hold about you and get a copy, to have it corrected, to have it deleted, to restrict or object to how we use it, and to receive it in a portable form. Where we rely on consent, you may withdraw it at any time, and that does not affect what we did before.

Write to [email protected] and we will answer within one month. One practical note: for material inside a customer firm’s organisation, that firm is the controller and we act on its instruction — so we will pass your request to them and help them meet it, rather than reaching into their memory ourselves.

If we get it wrong, you can complain to the data protection authority where you live or work. We would rather you told us first, and we will treat it seriously.

Cookies

This website sets no cookies at all. There is no banner because there is nothing to consent to.

The application behind it sets two, both strictly necessary and neither used to track you: one that keeps you signed in, and one that remembers which language you chose.

Who this service is for

Nemosyne is sold to firms for use by their staff. It is not intended for consumers and not intended for anyone under 18, and we do not knowingly hold data about children. Documents a firm connects may of course mention anyone; that material is the firm’s, held under section 2.

Changes to this policy

When this policy changes we will change the date at the top and raise the version. If a change is material — a new sub-processor, a new category of data, a new purpose — we will tell customers directly rather than relying on you to notice.

Contact us

For anything in this policy, including a request to see or delete your data, write to [email protected]. For everything else, [email protected].