What we record, who can see it, and what we have not built yet.

1 · What is captured

Transcription is not outsourced. Audio is transcribed by self-hosted Whisper on a GPU machine we run in the EU. There is no third-party transcription service in the path — the audio does not leave infrastructure we control before it becomes text.

2 · Consent, and how capture starts

Nothing is captured until a host confirms three specific statements and a jurisdiction acknowledgement. The wording is exactly what they see, and the server re-checks all four before the notetaker is dispatched:

“I am a legitimate participant in this meeting (host or invited attendee).”

“I will inform every participant that the meeting is transcribed and analysed by Unseen Dynamics — and that afterwards a neutral memo is emailed to all attendees and the full transcript to me, as the person whose Unseen Dynamics workspace is capturing it (available to any attendee on request) — and give them a real chance to decline (remove the bot / not analyse).”

“Capture is not prohibited here — by law (an all-party-consent jurisdiction), by an employer/organisation policy, or in a context with a heightened expectation of privacy.”

The interface also warns, before capture:

“If any participant is in an all-party-consent US state (CA, CT, DE, FL, IL, MD, MA, MT, NH, OR, PA, WA), treat the whole meeting as all-party. Under GDPR, consent must be freely given, specific, and informed. When unsure, don't capture.”

A workspace must also have accepted a Data Processing Agreement before any capture is possible. That gate is enforced in order, server-side: authenticated, then subscriber, then DPA, then attestation, then quota.

The notetaker is visible

It joins named in the participant list as notetaker@unseendynamics.ai, described as Unseen Dynamics — transcribing & analysing. There is a public notice page written for people who find themselves in a captured meeting, reachable without an account.

One precision. We describe the notetaker as joining visibly and being named in the participant list. We do not claim it posts an announcement into the meeting chat, because we have not verified that it does.

Four ways to object

• Before the meeting — any single meeting can be excluded from capture.
• During it — the host can remove the notetaker mid-call. No report is produced.
• For the whole workspace — auto-capture can be paused across every connected calendar.
• Without an account — a participant can use our erasure-request form, which reaches both the host and us.

3 · Who can see what

Organisation-wide visibility is a per-person grant, never a role side effect. Being an admin does not give access to content. The workspace owner holds the grant by default; anyone else has to be given it explicitly, and both granting and revoking are recorded.

The personal read, and the one caveat

No manager, workspace admin or Unseen Dynamics staff account can access an individual's personal read. That is enforced at four independent layers — a database policy that admits only the subject with no administrative path, a column-level revoke on the legacy fields, an organisation view that structurally never selects a read, and an email step-up challenge for sessions arriving through an employer-controlled mailbox.

What we will not claim. We do not say “your employer can never reach your personal read”. An employer who controls the mailbox a person signs in with can request a sign-in link and impersonate them, and that route is closed only for someone who has set their own credential. Until a person has done that, the mailbox is still the credential. We would rather state the limit than let the stronger sentence stand.

4 · Retention — and what is not yet true

The policy. A transcript belongs to the subscription that captured it. The copy in your workspace is deleted automatically six months after the meeting, and the copy on our transcription machine with it. One copy is outside that: the full transcript is emailed to the host as a file attachment, and that copy is the host’s to keep or delete — we cannot reach it. Before then, the person who owns the subscription can delete it at any time, and deletion is immediate rather than queued. Nobody else can delete it — not another workspace member, not us on a whim — and a participant asking for deletion goes to that owner, or to us, through the routes in section 6.

Reports, memos and personal reads are retained until the owner deletes them. An earlier description of this product as a “zero-storage” architecture was wrong and is withdrawn — section 1 describes what is actually stored.

A claim link for a personal read is valid for seven days. That is how long the link works. It is not a countdown on the read, which stays available once the person has signed in.

5 · Research use

Nothing from your meetings enters our research set unless you opt in, and the default is off for every account.

When it is on, what is written is a row of numbers and true/false values only — speaker count, durations, whether a purpose was stated, whether next steps were clear, counts of decisions and questions — keyed by a salted hash, readable only by us, and enforced by the database rather than by application code. No transcript text, no quotes, no names, and never the meeting title. A per-meeting opt-in can never override an account-level opt-out.

6 · Your rights, and how they work here

• Access — write to us. There is no self-service export yet; we assemble it manually.
• Erasure — through the host, or directly via our erasure-request form with no account required. Actioning it is a manual step today.
• Objection — any of the four routes in section 2. A standing objection is recorded manually.
• Portability — by email, on request.
• Rectification — on request. Note that a report is a description of a recorded conversation, so the usual remedy is deletion rather than amendment.

We have not yet published a response-time commitment or an escalation path. That is on the list below.

7 · Where things run

Application and database in the EU — Vercel and Supabase, Frankfurt. Analysis on Anthropic models, called server-side. Transcription on our own GPU machine in the EU. The full current list, including what the previously published page omitted, is on the sub-processors page.

8 · Google data, and the Limited Use rules we accept

Two Google connections exist and they are separate. Neither is required to use the product, each is consented to on its own, and each can be disconnected on its own.

Google Calendar — connected so the system knows which meetings to send the notetaker to. The scope is read-only (calendar.events.readonly): the connection cannot create, edit or delete anything in your calendar. From each upcoming event we read four things and nothing else — the title, the start and end time, the video-conference join link, and the email addresses of the invited attendees.

Those four fields do two jobs, and both are features you can see in the product: deciding which meetings to capture, and routing the memo and each person’s private personal read to the right address. Attendee addresses are used for that routing and for nothing else. They are not added to a marketing list, and we send those addresses nothing but the memo and a person’s own read.

Google Drive — read-only, and only for a Diagnostic Sprint, where it reads the documents an engagement is built on. It runs on a separate Google Cloud project from the calendar connection, so consenting to one is not consenting to the other.

The Limited Use commitments

Unseen Dynamics’ use and transfer of information received from Google APIs to any other app adheres to the Google API Services User Data Policy, including the Limited Use requirements. Specifically, for data obtained through Google APIs — Google Calendar, Google Drive and Google Meet:

• we limit our use of the data to providing or improving user-facing features that are prominent in the product’s interface — the meeting notetaker, the meeting report, the memo, your personal read and the Sprint report;
• we do not transfer the data to others except as necessary to provide or improve those features, to comply with applicable law, or as part of a merger or acquisition after obtaining your explicit consent;
• we do not use the data for serving advertisements, and we never sell it or transfer it to advertising platforms, data brokers or information resellers;
• we do not allow humans to read the data, unless we have your affirmative agreement for specific messages or documents, it is necessary for security purposes such as investigating abuse, to comply with applicable law, or for internal operations where the data has been aggregated and de-identified.

The fourth one needs a note, because section 3 is more specific than the standard wording. Our own staff accounts can see meeting metadata — the title, the times and the invitee list a calendar connection supplied — on the internal screens we use to operate and support the product, and that is not an aggregated-and-de-identified read. We would rather you read that in the access table than infer it from a clause. No staff account can reach a personal read.

9 · How the data is protected

Mechanisms, not intentions — each of the following is running today, and section 10 lists what is not. We hold no SOC 2 and no ISO 27001, so what follows is the mechanism itself rather than an auditor’s word for it.

• In transit. Everything is served over HTTPS/TLS. The site sends a two-year HSTS policy covering subdomains, so a browser that has seen it once will not fall back to an unencrypted connection, and an enforcing Content-Security-Policy limits what a page may load or connect to.
• At rest. The database and its backups are encrypted at rest with AES-256. Google OAuth refresh tokens carry a second layer on top of that: the application encrypts each one with AES-256-GCM under a 256-bit key held outside the database before it is written, so a copy of the database on its own does not yield a usable Google credential.
• Who can reach what. Enforced by the database rather than only by application code — row-level security policies scope each account to its own rows, so a query asking for someone else’s connection returns nothing instead of depending on a check somebody remembered to write. Google data is read and processed server-side only, and the module that handles encryption keys cannot be built into a browser bundle at all; that is enforced at build time, not by convention.
• Administrative access. Entering our internal admin area requires a second factor (TOTP) on top of signing in. What a staff account can then see is the access table in section 3.
• Keys and credentials. API keys, OAuth client secrets and the token-encryption key live only in our hosting provider’s secured environment store. None is in source code and none is in the database. Rotating the token-encryption key is a defined procedure that re-encrypts the existing tokens, so a rotation does not force everyone to reconnect — which matters, because a forced reconnect is how a connection quietly stops working.
• Where it is processed. The EU throughout — database in Frankfurt, application in Vercel’s EU region, transcription on our own machine in the EU. Section 7 and the sub-processors page have the full list.

Revoking and deleting are different, and we keep them apart

Revoking. Disconnecting a calendar (Meetings → Calendar) or a document folder revokes the token with Google straight away, cancels the change-notification subscription we hold on that calendar, and marks the connection revoked. Reading stops there.

Deleting. Revoking makes the stored credential dead; it does not by itself erase it. The token is deleted when you erase your account — which takes your workspace, its connections and its meetings with it — or when retention removes what it belonged to, on a thirty-day scheduled grace. The routes for asking are in section 6, which also says plainly that actioning an erasure is still a manual step and that we have not yet published a response time.

AI and machine learning

We do not use data obtained through Google APIs (including Google Calendar data) to develop, improve, or train generalized or non-personalized AI or machine-learning models.

What the AI does instead is read one meeting, or one engagement, and write its report, memo and personal reads. The models are Anthropic’s, called server-side under commercial terms that exclude the use of inputs for training. We train no model of our own on your data: the only thing that outlives a meeting for us is the numeric research row described in section 5, and only if you opted in.

10 · What we have not built

• The retention sweep. Section 4. This is the most consequential gap and it has our attention.
• Per-speaker redaction. A person's words can appear in the memo, in the host's report and in other people's personal reads. Removing one person cleanly from all three is unsolved, so we cannot promise it.
• Security certifications. We hold no SOC 2 and no ISO 27001. Saying so is more useful than implying otherwise.
• A published position under the EU AI Act. We ask buyers to think about AI governance; we owe them our own answer and do not have it written down yet.

Questions, or a request about a specific meeting: info@unseendynamics.ai. A fuller pack covering the consent model, the access matrix and the works-council material is available on request — and the German and Swedish specifics are here.