AI notetakers and the NDA you signed last quarter is a question about architecture, not about trust.

Somewhere in the NDA a consultant signed last quarter is a clause about not disclosing client information to third parties without consent, and somewhere in that same consultant's browser tab bar is an AI notetaker with its own data-processing agreement, its own retention window, and its own subprocessor list. The two documents were never written with each other in mind, and nobody involved in drafting either one was thinking about the other. Underneath the search phrasing, the AI notetaker NDA question is whether feeding a confidential call into someone else's cloud model counts as the disclosure the contract prohibits. The honest answer turns on architecture rather than on how carefully the vendor's privacy page was written. If a summary is generated on the device and never leaves it, there is nothing to disclose in the first place. If it is generated in someone else's cloud, the consultant has just made a third-party disclosure decision on the client's behalf, whether they meant to or not.

What the standard NDA advice already gets right

Standard NDA guidance on this takes the question seriously and deserves reading first. It walks through what to check in a vendor's data processing agreement: where servers are located, how long a transcript is retained after the call ends, whether the vendor trains its own models on customer data, and who the named subprocessors are. That is useful homework, and a consultant using any cloud AI tool on client work should do it before they start rather than after a client asks about it.

Even the most careful version of that advice stops short of one thing. It tells the reader how to audit a vendor's retention policy. It never suggests the data might not need to leave the device at all. The omission is understandable: on-device processing for a task like meeting transcription only recently became practical on consumer hardware, and the guidance was written for a market where a cloud round trip was how AI notetaking worked. The whole conversation about AI notetaker confidentiality has been running one layer above where the fix lives.

Running a capable language model inside a browser tab, fast enough to be usable and small enough to fit consumer hardware, is recent. Advice written two years ago had no local option worth recommending, so the genre settled on the only lever available: read the contract, ask the vendor the right questions, hope the answers hold. That lever still matters. It is no longer the only one.

Where "read the retention policy" stops being enough

Auditing a vendor is real diligence. It is also, for three specific reasons, a permanently incomplete answer.

A DPA is not something you can act on in real time.

A data processing agreement describes what a vendor is contractually obligated to do. It says nothing about what happens between now and the moment that obligation is tested, and a consultant has no way to verify compliance from the outside. Trust in a DPA is trust in an audit that hasn't happened yet.

Retention policy is not architecture.

A policy promising deletion after thirty days still requires the data to exist, in transit and at rest, on infrastructure the consultant does not control, for those thirty days. The window can be short and the exposure can still be real, because the question an NDA actually asks is whether the information left the consultant's control, not how long it stayed wherever it went.

Every renewal is a fresh vendor-trust bet.

Terms of service change. Vendors get acquired. A subprocessor list from last year is not a guarantee about this year's. A consultant who read the DPA carefully at signup has no durable reason to believe the same terms still apply eighteen months later, short of re-reading it every renewal cycle, which almost nobody actually does.

Reading a vendor's retention policy answers what they promise to do with the data. It cannot answer the question an NDA actually asks, which is whether the data left your control at all.

Local processing dissolves the question instead of answering it

The architectural alternative removes the vendor-trust question rather than answering it. If a client summary is generated by a model running on the consultant's own machine, there is no subprocessor, no retention window and no DPA to read, because the information was never transmitted anywhere for a third party to process. The claim is not that Callisto is more trustworthy than a cloud vendor. There is nothing to trust. No disclosure occurred, because no transmission occurred.

"Local" means something specific inside Callisto

Concretely: Callisto's local backends run in the browser via WebGPU, executing a LiteRT-LM model inside a shared background worker rather than making a network call. Set the routing priority to local, and once a local model is ready every request goes to it. If the model is still downloading, the request waits rather than falling back to a cloud provider, because a silent fallback is a privacy decision made without telling anyone it happened. A request reaches the cloud only when local processing is unusable or the user has switched it off.

A second local pathway is worth naming. Chrome ships a built-in AI Prompt API of its own, and Callisto can route to that instead of its bundled model on browsers that support it. The privacy property holds either way: the request is served by the browser or the local worker, never shipped to a remote endpoint, so which of the two answers a given request changes nothing about what leaves the device.

Offline is the test that proves it, not a marketing claim

The claim is falsifiable. Cloud routing in Callisto requires an active network connection by construction, so the moment a device goes offline every path to a cloud model closes, whatever the priority setting says. A consultant working from a client site with no wifi, or switching to aeroplane mode before a sensitive conversation, relies on no promise at all. They can watch an AI feature keep working, or refuse to run, with no network path available for anything to have gone anywhere.

The one feature that is hard-restricted to local, no exceptions

One feature in Callisto generates AI content without a button press: the person profile's summarised discussion history, built from the notes accumulated against that person over time. It triggers itself, so it carries a stricter rule than anything else in the product. The automatic version refuses to run unless the local backend is active and ready, with cloud fallback disabled for that specific call. If local isn't available, the summary simply doesn't auto-generate that day, rather than quietly routing a 1-on-1 history to a cloud provider because the on-device model happened to be busy. Anyone who wants to see that boundary directly, rather than take it on description, can run the airplane-mode test against it. A manual refresh of the same summary follows the user's general AI settings like anything else. The difference is consent. The one trigger nobody had to remember to configure is the one that can never reach the network.

Drawing the line between the automatic trigger and the manual one is deliberate. A feature a person invokes carries an implicit acknowledgement that something is about to happen; a feature that fires on its own carries none. That is why a self-triggering summary of confidential 1-on-1 notes is the one place in the product where "ask the user's general settings" is too weak a guarantee, and the code does not treat it as one.

On the rare occasion cloud gets used

Cloud AI here is opt-in and scoped. Three features, no more. Exactly three can send data to a cloud provider: scanning a receipt, generating HTML inside a project's Context Notes, and rewriting a governance deck's executive summary. Each carries a specific disclosure of what is sent, behind a two-click confirmation, and none of the three transmits general workspace context alongside the request. A consultant who never touches those three actions and sets AI routing priority to local depends on no policy promise. They depend on a code path that has no cloud request to make. The everyday work of tagging a meeting note to the client and project it concerns touches none of the three scopes at all; it's plain data entry, not an AI feature, and never leaves the workspace's own database regardless of routing settings.

Why this doesn't resolve the NDA question for the call itself

Callisto does not record calls, does not transcribe audio, and cannot join a meeting. That limit is the important one. If the confidentiality risk is an external notetaker like Otter or Fireflies capturing the raw conversation, on-device processing inside Callisto has nothing to say about it, because that decision happens in a different product before anything reaches Callisto. The local-first design covers what happens to client information once it is inside the workspace, in notes, in a person's history, in a governance summary. A consultant worried about the call itself has to make the same architectural check against whichever notetaker joins it, and a growing number of on-device options now exist for that reason.

What Callisto does not claim

It does not claim end-to-end encryption, and should not be described that way. The protection is architectural default and user-controlled routing, not cryptography, and the platform's security model rests on Postgres row-level security rather than a zero-knowledge design. Nor is cloud AI unsafe in general. It is a disclosure decision that deserves to be made deliberately rather than by default. And it does not claim to remove judgement. A consultant still decides what to write down, still decides whether a summary belongs in a shared account others can see, and no architecture choice substitutes for reading the actual NDA before assuming what it permits.

Getting started

Open Settings and confirm the AI routing priority is set to local, then check which of the three cloud scopes, if any, have been granted, and revoke the ones that were switched on out of habit rather than necessity during onboarding, before there was a specific NDA in mind. The next time an NDA-protected call needs writing up, do it with the network off, exactly like any other meeting note that fans out to the project, the person and the account it concerns, and confirm nothing about the workflow feels different. Nothing should. The confidentiality question that used to require a policy audit becomes one that no longer needs asking.