Horizon Lens — Where does your AI data actually go?
Follow the information, not the label
Imagine using an AI assistant to turn meeting notes into a list of actions. You open an app on your laptop, select a document and receive a summary. Where did the notes go? The window you used is only the starting point. A helpful privacy review follows the input through each stage: reading, processing, storage and sharing. This guide uses that hypothetical meeting workflow to show what to ask, without assuming that every cloud service or local application behaves alike.
A September 2026 Gradio tutorial gives a concrete example of mixed processing. In one image workflow, drawing boxes and making a mask happen locally, while a detection call leaves the machine. Other nodes call hosted models or services. One interface can therefore contain several different data routes; describing the entire app with a single local-or-cloud label can miss the important detail.
For the meeting notes, start with four boxes on paper: source document, summariser, saved result and recipients. Draw each transfer between them. Beside every box, write who operates it and what information it receives. Put a question mark wherever you do not know.
Decide what the task actually needs
Suppose the meeting document contains project decisions, phone numbers, a personal absence explanation and a copied customer email. An action list may need the decisions and assigned owners. It may not need the personal explanation or the customer’s entire message. Create a working copy containing only material needed for the task. Use neutral placeholders in an initial test, then inspect whether the output remains useful before adding more detail.
This is an editorial recommendation to make the exposure deliberate, not a promise that removing names makes a document anonymous. A combination of roles, events and details can still identify a person. Ask whether each included detail helps produce the requested result. If it does not, leave it out rather than asking the assistant to ignore it after you have supplied it.
Apply the same reasoning to access. Our summariser could work from one exported document instead of an entire mailbox. Prefer that smaller input when it does the job. If a connector is necessary, inspect its requested permissions and choose the narrowest suitable option available. Keep access to the source separate from permission to edit it or send the finished summary.
Check what local processing includes
NVIDIA’s September 2026 account of Perplexity Portable Computer describes local workflows that can selectively escalate work to cloud models, with permission requested before content is sent. The same article describes PAIR distributing inference requests between computers on a local network. These are dated product examples, not universal privacy guarantees. They show why local processing can still involve decisions about another model, another machine or another destination.
For the meeting workflow, inspect the summariser’s actual model setting and any fallback or cloud-assistance option. Ask what happens when the selected model cannot complete the task. If the answer involves another provider, establish what would be sent before using sensitive notes. Do not infer that a task stayed on your device merely because the application was installed there.
Also inspect the source and destination. A document in a synchronised folder and a summary shared with colleagues are separate parts of the route. Record them even if the model itself runs locally. The useful outcome is a map you understand, including the places where you have chosen to share information.
Treat connections as access you will need to manage
A TechCrunch security roundup updated in September 2026 reports that attackers entered Klue using a credential created for a limited pilot in 2022. It also reports exposure of customers’ cloud-service keys. The example concerns that reported breach; it does not establish that every old credential has been misused. It is a concrete reason to remember access after the original experiment ends.
For our notes assistant, keep a small connection register: service, account, purpose and permissions, plus the place where access can be revoked. Do not put secret values in that register or paste them into meeting notes. If a service provides an approved sign-in flow or credential store, use it. A record of what a connection can do is useful; another copy of its secret is not.
Review connections when the task changes or the experiment finishes. Remove access that is no longer needed, and confirm the change in the service that granted it. Ask separately about stored inputs, outputs and logs, including retention and deletion controls. Revoking a connection and deleting previously stored information are different jobs, so do not assume that one completes the other.
Trace one harmless test
Action
Make a fictional meeting note with invented names and a distinctive harmless phrase. Run it through the intended workflow. Watch the selected model and connected services; inspect available activity records and the saved output. Check who can open the result. This is a practical inspection, not proof that there were no other transfers: an activity screen may show only part of the processing.
Return to your four-box map and resolve its question marks using the product’s settings and documentation. Record what is read, where processing occurs, what remains stored and who receives the result. If you cannot establish a route that matters, use less sensitive input or postpone that part of the task. Keep the map with your workflow notes and revisit it after changing a model, connector or sharing setting. You can then make a specific choice about the information you provide, instead of relying on a reassuring label. For the meeting example, a satisfactory answer might be a limited excerpt sent to a chosen service, a private draft saved in one folder and a separate human decision about sharing. The point is that each step is intentional.