What leaves your Mac when AI writes meeting notes

You are on a plane, mid-meeting with a client, when the network drops. Zoom still has the microphone and the conversation keeps moving. You start the note. The recording continues, the transcript appears and the voices remain separated because the work is happening on the Mac in front of you.

By default, recording, transcription, speaker separation and the written-up note all happen on your Mac. There is no Noats server that receives your meetings. Meeting content stays local throughout that default workflow. Choosing a cloud model changes the path only for the content that the selected model needs.

We built the system around paths you can name. A privacy promise is something a company can change. An architecture that keeps the default meeting workflow on your Mac cannot be talked out of it. That is why local first is an architectural fact, not a label we place over an unknown route.

Follow the recording before you follow the promise

Noats notices when an app takes your microphone and offers to record. Recording starts when you start the note, and there is nothing to connect first. It captures the Mac’s audio and microphone directly. The resulting recording stays on your Mac.

Transcription and speaker separation run on Apple silicon, so once the models are on your Mac a meeting on a plane with the network off is transcribed the same as one at your desk. We wanted the location of that work to remain concrete even when the meeting itself moves between an office, a train and a kitchen table.

Noats separates the voices in a meeting and lets you name each one, during the call or after it. The names belong to that meeting. There is no enrolment step. The speaker-separation process is scoped to each meeting, which keeps the labels tied to the conversation where you chose them.

Whatever your Mac’s microphone hears is attributed to you. The voices on the other end of a call are split into speakers, and you choose their names.

By default your notes are written up by a model running on your Mac. The resulting note joins the recording, transcript and speaker labels in your local archive. Your audio, transcripts, speaker labels, notes, folders and chat history are written to a database and plain files in your own Application Support folder. Any note exports as markdown with a keystroke.

The app contains no analytics and no telemetry. We chose that architecture because the useful answer to a privacy question is a route someone can inspect: audio enters the Mac, local models process it and files land in a folder the person using the Mac owns.

Notice the few times the network opens

By default, the only network activity is the app update, the model catalogue when you open Models and the model downloads you approve. For an update, the app asks updates.noats.ai whether a newer version exists and fetches it. Automatic update checks can be switched off in Settings under About.

Opening Models loads the model catalogue. An approved download brings the selected model to the Mac so it can run there. These catalogue and download paths do not send meeting content to Noats. Once the required models are present, recording, transcription, speaker separation and the default written note continue on the local path.

You can also choose where a note is written. You can connect Anthropic, OpenAI or OpenRouter with your own key, point Noats at an OpenAI-compatible server or use your ChatGPT plan. We make that choice explicit because it changes the recipient of the content needed to write the note.

For a cloud choice, the note and transcript content that request needs goes directly to the selected provider under its own terms. Transcription and speaker separation still happen on the Mac. Nothing routes through us. The network path begins with the model you selected rather than changing the rest of the meeting workflow.

Anthropic requests go directly to Anthropic, while OpenAI requests made with your key go directly to OpenAI. OpenRouter requests go directly to OpenRouter and then through the provider route it supplies. Requests to an OpenAI-compatible server go directly to the endpoint you configured. ChatGPT plan requests use your existing OpenAI session from the Codex CLI.

Choose the OpenAI route you actually intend

For a ChatGPT plan, you sign in to OpenAI in your terminal through its Codex CLI. Noats picks up that session, so the login never passes through the app. We use the session you established in the terminal for the request, and the content needed to write the note goes directly to OpenAI.

ChatGPT sign-in and an OpenAI API key are separate authentication routes with separate controls. OpenAI describes different data controls for ChatGPT sign-in and API-key authentication. ChatGPT workspace controls govern the first route. API organization retention and sharing settings govern the second, so the route you select determines which set applies.

For API-key requests, OpenAI’s API data guidance states that API data is not used for training unless the customer opts in. Default abuse-monitoring logs may contain prompts and responses for up to 30 days, with additional rules for particular endpoints. Those terms belong to the direct OpenAI route.

Provider terms differ beyond OpenAI. Anthropic explains that commercial API inputs and outputs are normally deleted within 30 days, subject to its listed contractual, safety-policy and legal exceptions. A person connecting Anthropic should review those terms as part of choosing that recipient.

OpenRouter explains that it stores request metadata and does not store prompt or response content unless specified logging or improvement settings are enabled. The policy of the underlying provider also applies. We treat that downstream provider route as part of the choice because OpenRouter supplies it for the request.

Look at provider credentials on their own path

API keys you enter are encrypted with macOS’s own secure storage, backed by your Keychain. Apple describes Keychain protection and access controls for short sensitive values such as keys and login tokens. Those protections apply to the provider keys you choose to enter.

Meeting files follow the local archive path described earlier. Audio, transcripts, speaker labels, notes, folders and chat history are written to a database and plain files in your own Application Support folder. We keep that storage account separate from the credential path so each question has a precise answer.

The same separation makes an inspection easier. A provider key belongs in macOS secure storage, while a recording belongs with the meeting files in your Application Support folder. A markdown export goes where you save it. Each artifact has a named place rather than disappearing behind a broad claim about privacy.

This is also why the absence of analytics and telemetry matters at the architectural level. The app does not create a second stream of usage events beside the meeting workflow. We can describe the local files, the approved model downloads and every optional provider route without adding an unseen measurement path.

A cloud selection changes one defined edge of that map. The selected provider receives the note and transcript content its request needs under its terms. The recording, transcription and speaker-separation steps remain on the Mac. That narrow change is easier to assess because the credential, request and meeting files each keep their own route.

Bring this map to the next review

A local data path gives counsel specific facts for a confidentiality review. Professional duties and recording consent remain separate legal questions that depend on the representation, participants and jurisdiction. The architecture supplies evidence about recipients and data movement. It does not replace the legal analysis attached to a particular meeting.

ABA Formal Opinion 512 calls for a fact-specific assessment of disclosure and access risks before representation-related information enters a generative-AI tool. It also directs lawyers to understand the tool’s terms of use, privacy policy and related contractual terms before making that choice.

Before enabling a cloud model, identify the recipient, authentication route, content sent, retention rules and training controls. With Noats, the architectural change is narrow and visible: only the selected model request takes the cloud path. We can name the provider and the content involved without treating the whole meeting workflow as one undifferentiated service.

The local route remains equally concrete. Noats captures the Mac’s audio and microphone, creates the transcript on Apple silicon, separates speakers for that meeting and writes the note with a local model by default. The recording, transcript, speaker labels and written note then remain together in the local archive.

Noats requires macOS 14.2 or later on Apple silicon. It is free during the beta. Those requirements place the local transcription and speaker-separation work on the hardware where the meeting is recorded, giving the default path a clear beginning, a clear processing location and a clear destination.

The next time a client, security reviewer or colleague asks where a meeting goes, start with the artifact in front of you and follow it. The recording leads to the local transcript, the transcript leads to the chosen model and any optional cloud request leads to its named provider. That path is the answer we intend to keep making visible.