Your AI Assistant Is Also Uploading Your Clients' Data

By Lazar Milicevic · Published October 17, 2026 · 10 min read

You connected your inbox to an AI assistant and got three hours a day back. Now think about what's in that inbox: client names, phone numbers, contract terms, invoices with bank details, call notes where someone told you about a divorce or a cash flow problem. None of those people agreed to have that content flow into a general-purpose assistant. Here's exactly how I think about the boundary, and what I build instead.

What the Muse story actually says (and what it doesn't)

The short version: it's an argument about consent, not a breach report. Reading the Muse coverage carefully matters, because the facts are narrower than the headlines, and the business exposure is an inference you have to reason through yourself.

Here's what's on the record. Meta introduced Muse, a personal AI agent for US users, on September 8, 2026. According to TechCrunch, it works by connecting to a user's email, calendars, payments and other apps. TIME's analysis of Muse's internal instructions reports that Muse updates its dossiers every hour, on the user and on people the user mentioned in chats, messages and emails it has read. TIME also reports that people who don't use Muse are subject to this mapping, done by other people's Muse agents. A Meta spokesperson did not dispute TIME's findings and said Muse remembers information about others that the user chooses to share.

The opinion piece driving the current conversation is a Verge article arguing that AI personal assistants like Muse ask you to hand over data about other people who never consented. I only saw an aggregator listing of it, not the full text, so I'm describing its thesis and nothing more.

What the evidence does not show: that a small business's client data gets uploaded to Meta by default. There's no breach and no lawsuit here. The business exposure is a chain of reasoning. If an owner connects an inbox or calendar to an assistant like this, the third-party data inside that inbox falls within the assistant's access. Muse is also a US consumer product, and I haven't seen commercial terms for it. That gap is itself the point: you'd be making a business decision under consumer terms.

You're a data processor, whether you planned to be or not

If client information sits in your accounts, you hold it on their behalf, and any tool you pipe it into becomes part of how you handle it. Your clients shared it for a specific purpose: to get work done by you. Routing it through an assistant whose data handling you haven't read is a different purpose they never approved.

The pattern I see with small teams is consistent:

1. Someone gets excited and connects the whole inbox.
2. Week one is great. Triage that took hours disappears.
3. Nobody checks where the data goes, what retention terms say, or whether the provider trains on it.
4. Months later, a client asks: "Did you put my information into an AI tool?" and the honest answer is "I'm not sure."

That last moment is the real cost. The productivity gain accrues to you. The exposure is carried by your clients.

Look at the defaults for a consumer agent like Muse as a concrete example of the questions you need to ask of any tool:

• Training: Meta says users can opt out of having their Muse interactions used to train Meta's AI models, and says Muse does not share conversations or VM data with Meta's ad systems (Meta's announcement). PCWorld reports that training is on by default, so users must opt out themselves. The reported path is Settings > Data controls > toggle off "Help improve our AI models," per Notis, which cites Meta's help center. Whether that toggle also covers past interactions is disputed between sources, so check Meta's help center directly.
• Deletion: Deleting a conversation is not a full wipe. PCWorld quotes Meta's own wording as saying Muse may still remember what it learned from deleted material.
• Staff access: Meta says staff access to a current Muse VM remains possible to support, secure or operate the service. That's a third-party reading of Meta's public disclosures, so verify it against Meta's documentation.
• Encryption: Meta says it will introduce a Muse Confidential VM "later this year," encrypted with a key only the user holds. As of TIME's October 6, 2026 report, that option wasn't yet available.

To be fair to Meta: it also says Muse checks with the user before sensitive actions like sending an email or making a purchase, and shows an audit trail of what it has done. Email access can be limited to reading or can include sending. Those are good controls. They govern what the agent does. They don't answer what happens to the third-party data it reads.

I'm not singling out one vendor. Run any assistant through the same four questions and you'll find gaps. Muse is just the clearest current example of a tool designed to see everything.

The 30-minute data audit

Do this first, before touching any architecture: list every AI tool your team uses and answer four questions about each. Most owners I talk to can't produce that list in under five minutes, and that tells you everything.

Open a note and make a table:

Then fix the easy wins:

• Turn off training wherever the setting exists.
• Cut scope. Disconnect any tool that has full-mailbox access but only needs one folder.
• Strip identifiers before pasting anything into a chat window: names, account numbers, tax IDs.
• Move recurring client-data work off consumer assistants and into a workflow where you control inputs, logs and retention.

The identifier-stripping step doesn't need to be clever. Here's a minimal version I'd use before any manual paste into a chat tool:

import re

# Illustrative patterns. Tune these to the identifiers your business actually handles.
PATTERNS = {
    "EMAIL": re.compile(r"[\w.+-]+@[\w-]+\.[\w.-]+"),
    "PHONE": re.compile(r"\+?\d[\d\s().-]{7,}\d"),
    "TAX_ID": re.compile(r"\b\d{2}-\d{7}\b"),          # EIN-style example
    "ACCOUNT": re.compile(r"\b\d{8,17}\b"),             # bank-account-length digit runs
}

def redact(text: str, known_names: list[str]) -> tuple[str, dict]:
    """Replace identifiers with stable placeholders; return the mapping so
    you can re-hydrate the model's answer locally."""
    mapping: dict[str, str] = {}

    def swap(label: str, value: str) -> str:
        key = f"[{label}_{len(mapping) + 1}]"
        mapping[key] = value
        return key

    for name in known_names:
        if name in text:
            text = text.replace(name, swap("NAME", name))
    for label, pattern in PATTERNS.items():
        text = pattern.sub(lambda m, l=label: swap(l, m.group(0)), text)
    return text, mapping

Note the design choice: the mapping stays on your machine. The model sees [NAME_1] and [TAX_ID_3], produces its answer, and you swap the real values back locally. Regex redaction will miss things (free-text descriptions of a medical issue won't match any pattern), so treat it as a floor, not a guarantee.

Build agents with the narrowest possible slice

A business automation should be built the opposite way a consumer assistant is: each agent gets the least data it needs to do one job. Consumer assistants are built to see everything because that makes the demo look magical. Narrow scope isn't paranoia. It's also better engineering, because a smaller context means fewer strange mistakes.

Concretely:

• An invoicing agent reads invoice fields. It doesn't need your mailbox.
• A lead follow-up agent needs name, company and the last message. It doesn't need attachments from three years ago.
• A triage agent needs subject, sender and a body excerpt to classify. It doesn't need to send anything.

Write the scope down as config, not as a habit. A declarative manifest per agent makes the boundary reviewable:

# agents/lead_followup.yaml
name: lead_followup
purpose: "Draft a follow-up for leads with no reply after 3 days"
inputs:
  source: crm_export          # not the mailbox
  fields: [first_name, company, last_message_text, last_contact_date]
  max_records_per_run: 25
excluded:
  - attachments
  - fields: [tax_id, bank_account, phone]
permissions:
  read: true
  send: false                 # drafts only; a human sends
model:
  endpoint: business_tier_api # contractual retention + no-training terms
  retention: "per vendor contract"
logging:
  store_prompts: true         # you can answer "what did we send?"
  store_outputs: true
  redact_before_log: true

Two properties matter here. First, send: false mirrors the "check before sensitive actions" idea at the architecture level: the agent drafts, a human approves. Second, store_prompts: true is what lets you answer a client's question with a documented yes-or-no instead of a shrug. You can't audit what you never logged.

For the most sensitive material, such as health details, legal matters or financial hardship in call transcripts, a self-hosted model keeps the data on hardware you control, so the inputs, logs and retention stay in your hands. It doesn't need to be fancy. It needs to be bounded.

The compliance angle, stated carefully

Whether data-protection law applies to you depends on where you and your clients are, so check before assuming. Everything in this section is conditional.

If you or your clients are in the EU/EEA, GDPR is likely in scope. Two provisions are relevant to this exact situation:

• Article 28 requires a binding contract (a DPA) with every processor. Article 28(3) lists eight mandatory sets of terms, including processing only on documented instructions and deleting or returning data at the end of the service.
• Article 28(10) says a processor that starts determining the purposes and means of processing itself is treated as a controller for that processing (text and commentary). That matters for vendors that train on customer data, because training is arguably the vendor deciding its own purposes.

On penalties: GDPR has two fine tiers. The upper tier is up to EUR 20 million or 4% of worldwide annual turnover, whichever is higher, and covers the basic principles for processing and lawful basis. The lower tier is up to EUR 10 million or 2% (Article 83 overview). Under Article 83(4), a breach of the processor obligations in Article 28 falls into this lower tier. Using client data with no lawful basis falls in the upper tier, which makes it a more serious question than a paperwork gap. Ask a qualified privacy lawyer or check the official text of the regulation for how this applies to your situation.

I haven't researched US state laws or UK rules for this post, so I'm not going to characterize them. If you're in the US, UK, Canada or Australia, check what applies to your sector and your client contracts. And note that this is general information, not legal advice.

My practical read: the legal exposure is real but conditional. The commercial exposure is broader and arrives sooner.

Privacy is about to become a sales feature

My bet: the consent problem becomes a sales problem before it becomes a legal one. Clients are going to start asking vendors, "Do you feed my data to AI?" The small shops that can answer with a clear, boring, documented yes-or-no will win deals from the ones that shrug.

That's cheap to get ahead of. What I'd put on a single page, and keep current:

1. Which AI tools touch client data, and which don't.
2. What each one sees (the scope manifest above is your source).
3. Whether the vendor retains or trains on it, and what you did about it.
4. Where a human approves before anything leaves your systems.
5. What happens on request: how you'd find and delete a given client's data from your logs.

The big assistants will keep optimizing for seeing everything. As a solo operator or small team, you can win by building the opposite: an assistant that sees only what it needs and can prove it.

How I approach this

I build AI automations for solopreneurs and small teams. The practices I recommend are the ones above: give each agent a narrow input slice, keep sends behind human approval where it matters, and log inputs and outputs so you can answer a client's "did you use AI on my data?" with a documented yes or no. Those are practices, not guarantees from any product. For your own setup, run your existing tools through the four questions above, and consider a bounded workflow in place of a full-mailbox assistant.

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milićević, senior engineer building practical AI automation.

Visit bizflowai.io for our services, case studies, and AI consulting.