Blog
All posts

What Happens to the Thoughts You Share With AI?

· By Michel Valenzuela, Founder of Daryl

You ask an AI to help you write a message.

To explain what you need, you describe the situation: who is involved, what happened, why you are frustrated, and what you hope to achieve.

The final message might be three sentences. The conversation behind it contains much more.

Where does that information go?

The answer involves several separate questions. Where is it processed? Is it stored? Who can access it? Does another service receive it? What can you remove afterward?

Understanding those distinctions helps you make better choices about what you share.

Processing: where the response is generated

Processing is the work required to turn your request into a response.

With cloud AI, the information needed for that request travels to remote infrastructure. With local AI, the model can process it on your own computer.

The application window can look similar in either case. An app installed on your Mac may still use a remote service to generate its answers.

That is why the location of the interface tells you little about the location of the processing.

A useful starting question is:

Does this feature send my conversation to a remote AI service, or generate its response on my device?

For voice, the answer may involve more than one component. Recognising speech, generating a reply, and producing spoken audio are separate tasks. An application can handle them in different places.

Storage: what remains after the conversation

Processing and storage are different activities.

A request can be processed locally and then saved in a file that synchronises elsewhere. A cloud service can process a request under terms that specify particular retention arrangements.

You need to understand both.

Stored information might include conversation history, uploaded files, voice recordings, transcripts, or context preserved for later use. The exact arrangement depends on the application.

For a personal assistant, it helps to distinguish between information you deliberately keep and information the software retains as part of its operation.

Can you see what is saved? Can you choose whether a conversation belongs in your history? Are recordings retained, or only the resulting text?

Those answers should be accessible without requiring you to interpret technical documentation.

Memory: what influences the next conversation

An assistant may preserve selected information to make future interactions more useful.

A preference, project detail, or ongoing goal could help it respond with better context next time. That continuity can be valuable, but it introduces another question:

What is the assistant carrying forward?

Conversation history and memory are related, but they are not necessarily the same thing. An application might retain an entire exchange, extract selected details, or let you explicitly choose what to preserve.

Whatever the approach, people should be able to understand and manage it.

You may want to correct something the assistant misunderstood. A project may finish. A preference may change. Context that was helpful once may become misleading later.

Useful continuity needs a practical way to revise and forget.

Connections: what happens when another service is involved

An AI application may offer web search, browser access, cloud storage, or connections to other tools.

Each connection introduces its own information exchange.

Searching the web requires sending a query. Opening a website connects to that site. Using an external service may require sharing the information needed to complete the task.

This matters even when the AI model itself runs locally.

Before using an online feature, it should be clear what the feature needs to send and where it is going. You should also understand the scope of the permission you are granting.

Permission to retrieve a webpage, for example, does not explain whether an application also retains the page or uses its contents in later conversations. Those are separate behaviours.

Diagnostics: information about how the application works

Applications may collect information to diagnose crashes or understand technical problems.

Diagnostic information can serve a useful purpose. Developers need ways to identify failures and improve reliability.

But the details matter.

A report might contain basic information about the application and device. More detailed logs could contain additional information, depending on how the software is designed.

Users should be able to understand what is collected and whether submitting a report could include conversation content or other personal information.

For a personal AI application, that distinction deserves particular care.

Deletion: what exactly are you removing?

A delete button needs a clear meaning.

Are you removing a visible conversation? A saved file? Context used by the assistant? A recording? Information held by an external service?

These may be separate items with separate controls.

If files are synchronised or backed up, removing the local copy may not explain what happens to other copies. The application and any connected services determine that behaviour.

The practical point is to look for specific explanations. “Delete your data” is more useful when you can see what data the action covers.

A few questions worth asking

You do not need to investigate every technical detail before using AI. Start with the questions that affect your intended use.

QuestionWhat it helps you understand
Where is this request processed?Whether conversation content leaves your device for AI processing
What does the application store?What remains after the interaction
What context carries forward?What may influence future responses
Which optional services receive information?What changes when you enable a connection
What do diagnostic reports include?What may be shared when reporting a problem
What can I review, export, or delete?How much control you have over retained information

Then consider the information you actually need to provide.

You can often examine a situation without identifying everyone involved. A role, an approximate figure, or an anonymised example may be enough to get useful help.

The right amount of context is the amount the task needs.

How this shapes Daryl

Daryl is a personal AI for Mac, currently in development, designed to process its core conversations locally.

That architectural choice reduces the need to send those conversations to a remote AI service. It is a foundation for the experience I want to build.

The surrounding product decisions matter too: what is retained, how permissions work, what future online capabilities involve, and how people manage their information.

Local memory and continuity are part of Daryl’s development roadmap. My intention is to make useful context something people can understand, review, and control.

I want those choices explained through the product itself and its documentation as the relevant capabilities become ready.

Understand the arrangement before sharing the context

AI becomes more useful when it understands the circumstances behind your question.

That is also why its information practices matter.

You should be able to decide what to share with a clear understanding of where it goes, what remains, and what you can change afterward.

For a personal assistant, that clarity is part of the product.

It is one of the standards I’m building Daryl around.

Meet Daryl and get the launch announcement

Back to Daryl

Pre-launch

Get early access.

Daryl is in pre-launch. Leave your email and we'll send you a launch message the moment it's ready.

We'll only use your email to send you the Daryl launch message. Privacy notice