Goodmeet: Privacy by design for AI note-taking
Problem
Today, the market is crowded with AI note-taking apps, many of which claim to be private by default or privacy-first. At Good Systems, we had been searching for an AI note-taker we could trust for both team and personal meetings. We found that most options fall into two categories:
Cloud-first: These services process meeting data on their own infrastructure or through third-party providers. Some use anonymized or de-identified meeting data to improve their own AI models by default, requiring users to opt out. Privacy depends on the service’s architecture, data policies, and settings.
Local-first: These tools can run transcription and summarization models entirely on your device, so meeting content does not need to leave your computer for AI processing.
Although local-first alternatives meet our privacy requirements, their user experience is constrained by the capabilities of the device. In our testing, running models locally could drain the battery quickly, and the quality of the summaries often fell short of what we needed.
Unsatisfied with the available options, we decided to build our own: Goodmeet. Today, we’d like to share how we approach AI note-taking with privacy by design, without compromising the user experience.
Privacy by design and as a feature
Before we started building Goodmeet, we discussed what privacy meant to us. We wanted an AI note-taker we could use for our own meetings, including conversations we wouldn’t feel comfortable sending to another company’s servers. A privacy policy alone wasn’t enough. We wanted the system itself to protect those conversations.
Our requirement was simple:
🔒 No one else can read your meeting data.
That requirement shaped how we built each part of the app, from syncing notes between devices to generating summaries in the cloud. For example, we run an open-weight model (currently Gemma 4) inside Google Cloud’s confidential computing environment for summarization. Your meeting content stays private from us and Google.
Cloud storage: end-to-end encryption and zero-knowledge storage
We want to be able to take notes on one device and read them on another. That convenience shouldn’t require giving a storage provider access to what was discussed. Goodmeet combines a local document store with end-to-end encrypted sync, so our servers can store and deliver your meeting content without being able to read it.
Meeting documents are stored locally on your device. You can read and edit your notes offline. When changes sync, the app encrypts the content before it leaves your device, and your other authorized devices decrypt it locally. Each meeting document has its own encryption key, protected by your account’s encryption keys.
Your device
Document key stays on your device
Goodmeet servers
Store and deliver ciphertext
Your other device
Keys unlocked through approval or recovery
Your device encrypts meeting content before upload. Goodmeet servers store ciphertext without decryption keys. An authorized device decrypts locally using keys unlocked through device approval or recovery. Identifiers needed for sync remain readable to the service. The animation is illustrative and plays once. Use the top-right button to pause, resume, or replay.
Adding a device follows the same principle. After signing in on the new device, you approve it from an existing device using a pairing code. Under the hood, the devices use a password-authenticated key exchange, or PAKE, to establish a secure connection through our server. The code is generated on your device and is never sent to the server. The server relays the exchange without learning the code or the keys being transferred.
If you no longer have an authorized device, you can use your recovery code. The app uses that code on your new device to derive a key that decrypts an encrypted copy of your account’s private key. Our server stores that encrypted copy and non-secret derivation settings, such as a salt. The app never sends us your recovery code or the decryption key derived from it. The encrypted key and settings on our server cannot, by themselves, unlock your meetings.
This is what we mean by zero-knowledge storage: we hold the encrypted meeting content without the keys needed to read it. Some account and sync metadata, such as document identifiers, remains readable to our servers so they can route and sync the encrypted documents. The encryption protects what your meetings contain; it does not hide every identifier the service uses.
On your own device, meeting content is stored in a readable local database. Its protection depends on your operating system, device access controls, and disk encryption; Goodmeet does not add a separate encrypted vault around that local database. End-to-end encryption protects the content as it syncs and while it is stored on our servers.
Transcription: no audio leaves your computer
For transcription, we wanted to keep the most sensitive record of your conversation on your device: the voices themselves. Goodmeet runs speech recognition locally to turn speech into text, so no audio needs to be uploaded to us or a speech recognition provider. By default, Goodmeet deletes the captured audio from your device after transcription finishes successfully. If transcription is interrupted, the audio can remain locally so the app can retry.
We are evaluating NVIDIA Nemotron 3.5 ASR for its multilingual streaming capabilities. The models we use may change, but our requirement stays the same: local transcription keeps your audio on your computer.
Summarization: Confidential Compute
A useful summary should capture the decisions, details, and follow-up work that matter, without making you read the whole transcript again. We also want that experience to work on computers that cannot comfortably run a language model alongside a video call and everything else you have open.
Running summarization in the cloud moves the model’s compute and memory requirements off your device. It avoids the battery cost of running that model locally and gives us a path to support more devices and platforms. It also lets us evaluate tuned models and deploy improvements centrally, without asking every user to download a new set of model weights.
The challenge is keeping the conversation private while the model processes it.
We built our approach around two technologies: Google’s Gemma models and Google Cloud’s confidential computing infrastructure.
Choosing Gemma and giving it a focused task
We tested several models, including Qwen, before choosing Gemma 4 E4B for our cloud summaries. In our evaluations, it cost less to host and started generating text sooner than the alternatives we tried. We expect that cost advantage to hold if we move to the larger 12B model. E4B is also designed for edge devices, with optimizations for mobile chips and accelerators. That gives us the flexibility to run the model on compatible mobile devices. Its support for text, images, and audio also gives us room to explore new features within the same model family.
Gemma is available with open weights, which means we can run the model ourselves and choose the environment in which it processes meeting data. We use Gemma inside our confidential computing deployment. Using a Google model does not require sending the transcript to the Gemini API.
The model is only one part of the result. We also give it a more specific task than “summarize this meeting.” Goodmeet uses templates to guide the structure and emphasis of the notes. A project update and an interview need different kinds of summaries, even when both contain a long conversation and a few action items.
Generating a summary runs inference against the model. It does not train the model or update its weights with your conversation.
Protecting data while it is being processed
Encryption normally protects data as it travels over a network and while it is stored. AI inference adds another requirement: the model needs access to the text while it works.
Confidential computing adds hardware-backed protection for data during processing. Our deployment uses AMD’s CPU and memory protections alongside NVIDIA’s GPU confidential computing on Google Cloud to protect data during inference.
Apple’s expansion of Private Cloud Compute to Google Cloud reflects the same goal: bringing more capable AI processing to the cloud while preserving the privacy users expect on their devices. Its expanded infrastructure uses NVIDIA confidential computing alongside Intel TDX and Google’s Titan chip. Our implementation also uses Google Cloud and NVIDIA confidential computing technologies, with the request protections described below.
Protecting memory during processing is only part of the work. The app also needs to verify that protection and keep meeting content encrypted on its way to and from the cloud. Our implementation connects those protections across the full request and response:
Check signed evidence before sending any meeting content.
Your device
Encryption keys stay on your device
Google Cloud confidential environment
Gemma · confidential node
Readable cloud data stays inside this boundary
1. Your device checks signed attestation evidence covering Google Cloud, AMD CPU and memory protections, and NVIDIA GPU before upload. 2. The transcript is encrypted locally, sent encrypted, then decrypted inside the confidential node where Gemma generates a summary. 3. The node encrypts the summary before sending it back. 4. Your device verifies and decrypts the response locally. Failed verification never falls back to bypassing confidential computing. The animation is illustrative and plays once. Use the top-right button to pause, resume, or replay.
Verify memory protection. Before sending meeting content, the app checks signed attestation evidence to verify the expected environment. The attestation chain covers Google Cloud’s platform, AMD’s CPU and memory protections, and NVIDIA’s GPU. The evidence is bound to the destination and the encryption key used for the request.
Encrypt before sending. The app encrypts the request before it leaves your device. It is decrypted inside the confidential node, where Gemma generates the summary in protected memory. The node and model run within the same confidential computing boundary.
Encrypt the response. The generated summary is encrypted before it leaves that boundary and decrypted on your device. The app checks the encrypted response for tampering and incomplete delivery. If verification fails, it reports an error rather than switching to an unencrypted request.
Operational information, such as request timing and size, remains visible to the service, but meeting content stays out of request and output logs. Operating the service requires knowing whether a request succeeded and how long it took; it does not require recording what was discussed.
Building on Google Cloud
Google Cloud made this approach practical for us. Confidential GKE Nodes let us deploy workloads through Kubernetes while using confidential computing hardware. Our attestation chain brings together Google Cloud platform verification, AMD’s CPU and memory protections, and NVIDIA GPU attestation.
We currently host the model and store meeting data in Belgium and the Netherlands, within the European Union. Keeping this processing and storage in the EU is part of our approach to data residency and GDPR compliance.
We run Gemma with vLLM, package the serving application as a container, and use Google Cloud’s existing deployment and scaling infrastructure around it. This lets us work with familiar infrastructure while adding the verification and encrypted request path that our privacy requirements need.
Together, Gemma’s open weights and Google Cloud’s confidential computing support give us control over both the model and the environment in which it runs. That combination lets us improve summarization without making the user’s computer do all the work or making their meeting content readable to the services delivering it.
Calendar integration: a local connection
Connecting your calendar lets Goodmeet show upcoming meetings, remind you when it is time to join, and open the right notes with the meeting context already attached. You can choose which calendars appear, and calendar access is optional.
For Google Calendar, authorization happens through your browser, and the app completes the connection on your device. Calendar access and refresh tokens stay on that device. The app uses them to communicate directly with Google’s APIs; it does not send those credentials to our backend.
Upcoming events are cached locally, so our servers do not need to fetch or maintain a copy of your calendar to provide reminders. If you attach event details to a meeting note, those details become part of the meeting and follow its encryption and processing protections. The calendar connection itself, including the credentials that allow access to it, remains local.
Conclusion
We started Goodmeet because we wanted an AI note-taker we could trust with our own conversations. That meant thinking about privacy across the whole experience: where audio is processed, how notes sync, who holds the keys, and what happens when a model generates a summary.
Local transcription, end-to-end encrypted storage, and confidential cloud processing each solve a different part of that problem. With Gemma and Google Cloud, we can bring cloud summarization to more devices while keeping meeting content protected. The result is the kind of note-taker we were looking for: useful enough to use every day, with privacy built into how it works.